[Stds-754] IEEE 754 Revision, comments from IFIP WG 2.5

[Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx>]

(1)  Standardised NaN codes.

I'm sure the issue of trying to standardise NaNs has come up a few times
already.  When one analyses the various implications, one tends to revert
to the status-quo of not saying too much of anything.

Clearly the current practice of returning the default qNaN must continue
to be conforming, so the issue boils down to whether there is any chance
of hardware and software manufacturers to agree on (a) which distinctions
to make, and (b) how to encode them.

For Binary FP, we already have to accomodate two different choices for
the interpretation of the Q-bit (0 for PA-RISC, 1 for IBM and others).
The new standard at least recommends Q=1 -- but that conflicts with the
choice for DFP, and the desire to have all-ones be signalling.

Then there is the fact that some of the conditions that are distinguished
in clause 9.2 are hardware-detected, so new hardware would have to have
the encoding built-in -- and processor architectures that now state that
a default QNaN is returned would have to document an incompatible change.

Finally, let us assume that we agree on interpreting the 5 bits that
follow the Q-bit (1st bit of BFP trailing significand).   Variations
among platforms could conceivably be hidden behind preprocessor macros
for languages like C, just as variations in IEEE flags and masks are
dealt with today.  We would however have to deal with DFP as well.  In
DFP it is the rightmost digits that survive transit through narrower
formats, so we would pick the rightmost two digits -- but then we may
run into BID vs DPD issues.  We also run into the fact that, because of
the transit properties of BFP (where it is the leftmost bits that survive
a transit), NaN conversion between BFP and DFP would preferably convert
the bit-reversed BFP payload into a DFP payload, both interpreted as
integers (with sufficiently small integers guaranteed to survive transit
through multiple format conversions).   Does this mean that the 5-bit
codes have to be bit-reversed too?  Well, perhaps we could be smart and
choose only palindromic codes...

I note that PowerPC records the distinction between some of the classes
mentioned in 9.2 by setting separate bits in the FPSCR, with the IEEE
Invalid flag being the implicit OR of those bits.  IBM mainframes do
not record these distinctions; the FPC has a single IEEE Invalid flag.

(2)  Explicit rounding-direction in arithmetic operations.

I believe 754R has addressed this issue.  It is of course practical only
when hardware instructions exist that incorporate rounding information
in the opcode.  Some of the IBM mainframe (S/390, z/Series) instructions
do, notably the rounding instructions and divide-to-integer, but the
general arithmetic instructions do not.  Are there any machines that have
such instructions?  There are indications that there might be such in the
future, as several committee members are trying to address multi-threaded
environments where mode switching becomes *really* horrible.

When even individual arithmetic operations are implemented as subroutine
calls or long in-line sequences, the possibility of exploiting explicit
rounding versions becomes more palatable -- this is likely to be the
case for many initial implementations of DFP.

The 754R way of dealing with this is to use "constant-mode" directives,
attached to syntactic blocks.  Compilers can then generate appropriate
instructions if available, or schedule mode switches to minimise the
pain, if not:

   { #pragma round_to_positive   ap = bp + cp; }
   { #pragma round_to_negative   am = bm + cm; }

The details are of course language-specific, and I invented the syntax
above just for the purpose of this example.

Michel.
Sent: 2006-08-18 21:40:29 UTC