How to test if float is NaN?

[Don Clugston]

Jarrett Billingsley wrote:
> "Walter Bright" <newshound at digitalmars.com> wrote in message 
> news:e587a9$1k6q$1 at digitaldaemon.com...
> 
>> 'real's are supposed to be the longest floating point type available on 
>> the hardware, so they'd be reals.
> 
> What about hardware that has both 80-bit _and_ 128-bit floats?  ;) 

There is already hardware that supports both 96-bit and 128-bit floats 
(sort of) -- it's called 64-bit Linux <g>.

I really think that 'real' should not be viewed as a built-in type, it 
should be a typedef, since that's how it behaves.
The built-in types could have really obscure names to discourage their use:
eg
typedef float80pad96 real;  // a Linux32 80-bit real
typedef float80pad128 real; // a Linux64 80-bit real
typedef float80pad80 real;  // a Win32 80-bit real

Or they could have even more obscure names, and equivalents to the above 
could be exposed only in std.stdint.
Name mangling would need to be sorted out, though.

However...

80-bit floats are really a poor man's 128 floats. If you had access to 
128 bits, I don't think you'd ever want to use 80 bits, except for 
accessing legacy code.

I think we can safely assume that 128 bit floats will only exist on 
64-bit OS-es. An 80-bit float on 64-bit Linux is binary compatible with 
a 128-bit IEEE float, the only difference is that the lowest bits in the 
mantissa are always zero.
So it should be possible to mix 80-bit and 128-bit Linux code without 
recompiling. 64-bit Windows is more of a problem.
And calling 32-bit Linux code from 64-bit Linux is definitely an issue 
(but in that case it's 128-bit vs 96-bit floats!).

Two questions:
(a) Are there any signs of Intel or AMD actually implementing 128 -bit 
floats?
(b) Are any compiler vendors using 80-bit or 128-bit floats in Win64 
yet? How fixed is the ABI?