OK, I think I can manage with that for both SET CONTENT OF and MOVE. |
> Subject: Re: Payload length and interpretation in IEEE Std 754-2008
> From: scanon@xxxxxxxxx
> Date: Fri, 29 Apr 2011 10:35:51 -0700
> CC: forieee@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx; bobkarlin@xxxxxxxxxxxxxxxxx; wmklein@xxxxxxxxxxxxx
> To: charles.stevens@xxxxxxxx
> 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.
> - Steve