FloatingPoint in D

[BCS]

Reply to Don,

> BCS wrote:
> 
>>>> Can any D implementation be assumed to use IEEE-768? In other
>>>> words: can I safely build floats and double from bits and expect it
>>>> to work on an arbitrary compiler including ones that don't exits
>>>> yet?
>>>> 
>>>> I guess a corollary is, are there any platforms that D is likely to
>>>> be used on that have a hardware FP system *other* than IEEE-768?
>>>> 
> Not many non-IEEE 754 systems exist any more. The most notable
> exception is some Cray systems.
> 
> (actually, AMD's 3DNow! also isn't IEEE 754 compliant.).
> 
>> real will be a pain however it's cut because even in x86 where it is
>> 80bit IEEE-754 doesn't define an exact bit pattern.
>> 
> Yes, but it specifies several aspects of it -- significand must be
> continuous, exponent must be continuous. There's not much room to
> move.
> (a) IEEE 754R specifies the storage of 128-bit reals, and they are
> identical to x86 80-bit reals, except that the significand has some
> trailing zeros. (x86 80-bit reals are a poor-man's quadruple).
> (b) AFAIK, the only systems with 80-bit reals are x86, Itanium, and
> 68K,
> and they are all identical.
> So in practice, it's a de-facto standard, and 754R will goes a long
> way
> towards standardising it.
> The only hardware implementations of 'real' are 64-bit double, 80-bit
> x86-compatible (with or without implicit bit), and 128-bit quadruple
> (which is binary defined on some Sparc systems, but not implemented on
> any hardware AFAIK).
> Itanium also has an 81-bit real, but it's only used by the OS to
> provide
> fast implementations of 80-bit hypot() and similar functions - I
> think
> it's technically not IEEE compliant.
> In practice, the situation is not nearly as bad as it appears.
> 
>> So I'm thnking the result is: D floating point can be assumed to use
>> IEEE-754.
>> 
> Yes.
> 

Good. I guess as counter cases are found static asserts or ifs can be used.