Lower-priority corrections from Ian's review
#59
Closed
opened 7 years ago by wschmidt-ibm
·
0 comments
Loading…
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Page 1: (Trivial) "Executables and executable-generated data" is plural, so "is not portable" should be "are not portable".
Page 6: (Trivial) In "Table 2.11. Scalar Types", for consistency the "long int" and "signed long int" rows should have the last 3 cells merged.
Page 8: (Trivial) In "Table 2.12. Vector Types", "Vector of 2 double-precision doubles." for consistency should be "Vector of 2 double-precision floats.".
Page 8: "IEEE BINARY 128 EXTENDED PRECISION" should be "IEEE BINARY 128 QUADRUPLE PRECISION".
"Table 2.15. IEEE BINARY 128 EXTENDED PRECISION Type" should be "Table 2.15. IEEE BINARY 128 QUADRUPLE PRECISION Type".
In "Table 2.15. IEEE BINARY 128 EXTENDED PRECISION Type", "IEEE BINARY 128 EXTENDED PRECISION" should be "IEEE BINARY 128 QUADRUPLE PRECISION"
Page 9: In "Table 2.15. IEEE BINARY 128 EXTENDED PRECISION Type", "IEEE BINARY 128 EXTENDED PRECISION" should be "IEEE BINARY 128 QUADRUPLE PRECISION"
Page 9: "IBM EXTENDED PRECISION && IEEE BINARY 128 EXTENDED PRECISION" should be "IBM EXTENDED PRECISION && IEEE BINARY 128 QUADRUPLE PRECISION". (IBM "double double" is extended precision, but IEEE binary128 is quadruple precision.)
Page 9: "the IBM EXTENDED PRECISION format and the IEEE BINARY 128 EXTENDED PRECISION" should be "the IBM EXTENDED PRECISION format and the IEEE BINARY 128 QUADRUPLE PRECISION".
Page 9: "IEEE BINARY 128 EXTENDED PRECISION" should be "IEEE BINARY 128 QUADRUPLE PRECISION".
Page 9: (Trivial) "IEEE128 quad-precision values are passed in VMX parameter registers." should be "IEEE128 quad-precision values are passed and returned in VMX parameter registers.".
Page 10: "The entire aggregate or union must have a size that is a multiple of its alignment." should be "Unless it is packed, the entire aggregate or union must have a size that is a multiple of its alignment.".
Page 19: "A bit field cannot cross its unit boundary; it must occupy part or all or the storage unit allocated for its declared type." Likewise, precede this with "Unless it appears in a packed struct, ..."
Page 23: It might be useful in 2.2.1. Registers to say that some registers are partly nonvolatile and partly volatile (eg, VSRs where the FPR half is non-volatile but the other half is volatile).
Page 27: Table 2.20. Floating-Point Register Roles for Binary Floating-Point Types does not apply to _Float128.
Page 27: "The default implementation of DFP types shall be a software implementation of the IEEE DFP standard (IEEE Standard 754-2008)." made sense originally, when OpenPOWER planned DFP hardware to be optional. Now that DFP hardware is required (see next paragraph), should the default be a hardware implementation, or should it be just "The default implementation of DFP types shall be an implementation of the IEEE DFP standard (IEEE Standard 754-2008)." Should we append "The default may be either a hardware or a software implementation."? I don't think the ABI has to specify whether the default is hardware or software, since either will work and they're required to be compatible.
In the next paragraph, I don't think "For OpenPOWER, DFP support is defined as an optional category." is still true. (Am I wrong?) The rest of that paragraph and the following paragraph need rewriting or removal. [Bill: Agree. In fact, this was wrong from the beginning! DFP was a required category for server (not embedded) even in the 2.07 ISA. I believe this was wrong in an early version of the ISA document, which is probably how this snuck into the ABI.]
Page 28: After Table 2.21, the text and Table 2.22 should have a title like "Vector Registers" instead of being part of "DFP Support".
Page 28: "IEEE BINARY 128 EXTENDED PRECISION" should be "IEEE BINARY 128 QUADRUPLE PRECISION".
Page 28: "Parameters in IEEE BINARY 128 EXTENDED PRECISION format" should be "Parameters and function results in IEEE BINARY 128 QUADRUPLE PRECISION format".
Page 28: "Parameters and function results in the IBM EXTENDED PRECISION format" should be "Parameters in the IBM EXTENDED PRECISION format". [Bill: Agree, but only if you mean the other way round. :)]
Page 32: Should "Section 2.3.2.3, “Rules for Prologue and Epilogue Sequences” [53]." be "See Section 2.3.2.3, “Rules for Prologue and Epilogue Sequences” [53]."? Agree.
Page 35: "and functions are declared without prototype.)" should be "and functions declared without a prototype.)".
Page 122: In "6.2. Vector Operators" "The traditional C/C++ operators . . .", "logical and comparison operators" should be "shift, logical and comparison operators". To be clearer, we could list the shift, logical and relational operators. Also, are the ++ and -- operators included? Are assignment operators like += included? What about ? :, which can be implemented using vsel? [Bill: Agree in general, but I don't really see a need to call out anything with assignment semantics separately.]
Page 126: In Table 6.4, should the "vector long" mentions have a footnote "The vector long types are deprecated due to their ambiguity between 32-bit and 64-bit environments. The use of the vector long long types is preferred." like in Table 2-12 on page 7?
Page 128: Same for Table 6.8 as for Table 6.4?
Page 129: "Table 6.9. Built-In Vector Conversion Function" should be "Table 6.9. Built-In Vector Conversion Functions".
Pages 129/130: Same for Table 6.10 as for Tables 6.4 and 6.8?
Page 135: VEC_AND: "vector bool long long vec_and (vector bool long long, vector bool long long)" should have a ";".
Page 216: "Digits are ordered right-to-left in the order of significance." would be clearer as "Digits are ordered with the most significant on the left and the leastt on the right.".
Page 222: Also LSB sometimes means Least Significant Bit. Agree.
Page 222: Also MSB sometimes means Most Significant Bit. Agree.