[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use of SNaN



On 2012-01-09 17:35:56 +0000, N.M. Maclaren wrote:
On Jan 9 2012, Michel Hack wrote:
Vincent Lef�vre wrote:
Sorry, I should have been more accurate.  I meant that it can be
possible in languages (at least in C), partly based on the fact
that IEEE 754 specifies the sNaN encoding.  In C, this can be
done by storing a sequence of bytes using a union. Of course,
this can only be implementation-defined because IEEE 754 specifies
the encoding only as a bit-string (not as a sequence of bytes).

Not even that.  That trick is undefined behaviour, and won't always
work.

This trick has a well-defined behavior as long as the object is
supported by the implementation. Now, an implementation is free
to regard sNaN objects as undefined behaviour. But in such a case,
I'm not sure that it could claim conformance to IEEE 754 (while
we are in the context of IEEE 754). With GCC, you can use the
-fsignaling-nans (experimental) option to support signaling NaNs.

 In C90, you could have used a cast to 'unsigned char *' to do
it without explicitly undefined behaviour, but C99's introduction of
'effective type' probably breaks even that.

No, using the character type is OK, and C99 is explicit about that.
Actually, there is no need to use a union (though this may make the
code more readable). A union with other types is probably OK too
(though the standard is quite badly written on this point).

That was supposedly to assist compilers that use assumptions about
type implying aliasing for extra optimisation - i.e. explicitly
excluding your technique.

That's why I wasn't suggesting a pointer cast, but a union.
Anyway using the character type disables the effective type.

Unfortunately sNaN encoding is specified only for DFP by 754-2008.
For BFP the encoding is only suggested:  the 1st bit of the trailing
significand SHOULD be 1 for qNaN and 0 for sNaN.  That's because
there is existing hardware (HP's PA-RISC, I believe) that uses the
opposite polarity.

I just re-read 6.2.1 and noticed that even the position of the bit
is only a SHOULD, never mind the polarity.  But I think everybody
does use the same bit.  (This is why stds-754 is CCed.)

They certainly used not to - if I recall, it wasn't even a bit on
some systems, but I may be misremembering there.

I suppose that the current particular systems will remain the only
exceptions, but it isn't much more complicated than dealing with
the endianness problems.

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


754 | revision | FAQ | references | list archive