Re: Payload length and interpretation in IEEE Std 754-2008
On Apr 29, 2011, at 10:20 AM, Charles Stevens wrote:
PS: We also have the capability of converting a NaN in one IEEE format into
another IEEE format (say, Binary128 to Decimal64) through the MOVE statement.
The currently-proposed specification is that the payload is transferred
intact, with trailing bit or digit truncation of the payload as needed if the
capacity of the receiving data item does not allow for a payload of that
size. If the payload is other than a "left-justified integer" in the
sending operand, this might make the payload value in the receiving NaN. I'm
trying to avoid that.
Clause 5.4.2 seems to allow this for NaNs, applying the rules of Clause 4 to
imply that the end result is rounded if need be. For MOVE in COBOL, the only
rounding mode is roundTowardZero, so that could be interpreted as applying
what is currently proposed for COBOL.
This is almost OK, with a slight caveat:
As you have noted, a binary "NaN" with a zero significand field not a NaN at
all, so you must take care that if your truncation results in a payload of
zero, you set some other bit in the payload to avoid producing an infinity
instead of a NaN. Of course, this can be avoided if you use the recommended
convention for quiet NaNs where the leading bit of the significand field is
always set; if you adopt that convention, then payload truncation never
produces zero, and you have nothing to worry about.
The relevant section of IEEE-754 is clause 6.2.3, paragraph 4:
"Conversion of a quiet NaN to a floating-point format of the same or a
different radix that does not allow the payload to be preserved, shall return a
quiet NaN that should provide some language-defined diagnostic information."
Your proposed implementation (either with a fix for payloads of zero or using
the recommended qNaN encoding) clearly satisfies this requirement.