[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
encoding of binary qNaN/sNaN
[Qbit vs Sbit] Is there any reason? Is it because IEEE 754-1985 doesn't
specify the encoding either, to avoid breaking the compatibility with
existing IEEE-754 implementations?
Yes.
PA-Risc chose to have a 1-bit for SNaN; most others chose it for QNaN.
I'm not sure why the choice was left open in 1985. The original x87 did
not yet have QNaNs (effectively; the distinction hadn't been made yet),
but by the time the 386/387 arrived, a Qbit was used.
Perhaps it was because there was a desire for all-ones to be SNaN, which
was the motivation for DFP, where confusion with Inf was not an issue.
The advantage of the Qbit is that any SNaN can be quieted without changing
the payload -- and SNaN quieting is a standard feature.
Another choice that was in fact made in 1985 concerns NaN propagation via
narrowing or widening. The simplest choice was truncation or padding on
the right, which means that payload info to be preserved has to be in the
leftmost bits of the significand. If payloads are interpreted as small
integers, this suggests bit-reversed encoding -- and this is relevant now
when converting between DFP and BFP payloads. It might have been just as
simple to right-align the payload, given that the exponent field has to
be re-encoded anyway (otherwise simple truncation would indeed have been
a no-brainer). Now we have to live with it.
IBM have implemented BFP-DFP conversions which preserve NaN payload by
interpreting it as an integer -- naturally for DFP and bit-reversed for
BFP -- but this is not part of 754R (which only requires that round-trip
conversion preserve the payload if it is expressible in both formats).
I wonder how other vendors have done (or plan to do) this.
Michel.
Sent: 2007-08-02 15:25:39 UTC