www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - FloatingPoint in D

reply BCS <ao pathlink.com> writes:
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?
Mar 13 2007
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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
Mar 13 2007
parent reply BCS <ao pathlink.com> writes:
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.
Mar 13 2007
parent reply Don Clugston <dac nospam.com.au> writes:
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.
Mar 14 2007
parent BCS <ao pathlink.com> writes:
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.
Mar 14 2007
prev sibling next sibling parent reply Andreas Kochenburger <akk nospam.org> writes:
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/
Mar 13 2007
parent BCS <ao pathlink.com> writes:
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>.
Mar 13 2007
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 13 2007