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?

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?

There is exactly one Google hit for '"ieee 768" floating point'[1], which to me indicates one of two possibilities:
1) It's a _really_ unpopular standard ;).
2) There is no such thing as IEEE-768 or it has nothing to with floating point, and either (a) there is approximately one other person who thinks, like you, there is or (b) approximately nobody else thinks so and your name is Steve Harris ;).
(All of this, of course, assumes Google is correct in finding no more matches, which may or may not be true :P)

The D spec page on floating point[2] specifies that all operations should comply with IEEE-754 rules (did you perhaps mean _that_ standard?), but AFAICT that page doesn't actually specify the format of values when stored in memory. So unless a specific storage format is required by IEEE-754, assuming any particular binary format may not be portable. (Note: I have no idea what IEEE-754 specifies, exactly)

Also, there was also some mention a while back that GDC always defines 'real' as the local C 'long double' type, which in the case of the port for PPC turns out to be a weird format consisting of two doubles used to represent a single value. There was some discussion regarding what to do about this, but I can't offhand remember the outcome. IIRC it was in D.gnu, in the announcement thread for GDC 0.23.


[1]: http://www.google.com/search?q=%22ieee+768%22+floating+point&btnG=Search&hl=en
[2]: http://www.digitalmars.com/d/float.html

Reply to Frits,

> 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?
>> 

<Justified but un-needed bashing of my memory> <G>

> The D spec page on floating point[2] specifies that all operations
> should comply with IEEE-754 rules (did you perhaps mean _that_
> standard?), 

yes

> but AFAICT that page doesn't actually specify the format
> of values when stored in memory. So unless a specific storage format
> is required by IEEE-754, assuming any particular binary format may not
> be portable. (Note: I have no idea what IEEE-754 specifies, exactly)
> 

IEEE-754 does spec the bit pattern for 32 & 64 bit FP values

> Also, there was also some mention a while back that GDC always defines
> 'real' as the local C 'long double' type, which in the case of the
> port for PPC turns out to be a weird format consisting of two doubles
> used to represent a single value. There was some discussion regarding
> what to do about this, but I can't offhand remember the outcome. IIRC
> it was in D.gnu, in the announcement thread for GDC 0.23.
> 
> [1]:
> http://www.google.com/search?q=%22ieee+768%22+floating+point&btnG=Sear
> ch&hl=en [2]: http://www.digitalmars.com/d/float.html
> 

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.

So I'm thnking the result is: D floating point can be assumed to use IEEE-754.

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?
> 
> 

You're sure it ain't IEEE 754 ??

-- 

Andreas
-------
MinForth: http://minforth.net.ms/

Reply to Andreas,

> 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?
>> 
> You're sure it ain't IEEE 754 ??
> 

In fact I"m shure it /is/ IEEE 754, but enough about how bad my memory is <g>.

BCS wrote:

> 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?

Currently GDC uses a non-IEEE type for "real" on non-X86 platforms,
but it is being revised for GDC 0.24 ("real" will go back to double)

Only applies to D "real" / C "long double", so float/double are fine.

--anders

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.

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.