GDC release 0.23

[Don Clugston]

Anders F Björklund wrote:
> Sean Kelly wrote:
> 
>>> The double+double type has caused me no end of trouble, but I think 
>>> it is important to maintain interoperability with C.  If I make the D 
>>> 'real' implementation IEEE double, there would be no way interact 
>>> with C code that uses 'long double'.  I could add another floating 
>>> point type for this purpose, but that would diverge from the D spec 
>>> more than what I have now.
>>
>> Yeah that doesn't sound like a very attractive option.  Some of the 
>> later replies in the Darwin thread mention a compiler switch:
>>
>> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00471.html
>>
>> Is that a possibility?  Or did that switch not make it into an actual 
>> release?
> 
> There are two switches: -mlong-double-64 and -mlong-double-128,
> just that the second one ("double-double") is now the default...
> 
> So if you changed the meaning of "long double" back to the old one
> (i.e. same as "double"), it wouldn't be compatible with C/C++ ABI ?
> 
> 
> This is similar to the -m96bit-long-double and -m128bit-long-double
> for Intel, but those just change the padding (not the 80-bit format)
> 
> But on the X86_64 architecture, a "long double" is now padded to 16
> bytes instead of the previous 12 bytes (the actual data is 10 bytes)
> 
> 
> These were all known problems with adding "real" as a built-in, though.
> In all the D specs I've seen, it's pretty much #defined to long double.
> 
> Such as http://www.digitalmars.com/d/htod.html
> http://www.digitalmars.com/d/interfaceToC.html
> 
> Might as well keep the real <-> long double one-to-one mapping, and
> recommend *not* using real/ireal/creal types for any portable code ?

No, that does not work. double is *not* portable!
I'll say it again, because it's such a widespread myth: **double is not 
portable**. Only about 20% of computers world-wide have native support 
for calculations at 64-bit precision! More than 90% have native support 
for 80-bit precision.
(The most common with 64-bit precision are PPC and Pentium4. Earlier 
Intel/AMD CPUs do not support it).

Suppose you have the code

double a;

a = expr1 + expr2;

where expr1 and expr2 are expressions.

Then you want to split this expression in two:
b = expr1;
a = b + expr2;

Q. What type should 'b' be, so that the value of 'a' is unchanged?
A. For x87, it should be an 80-bit fp number. For PPC, it should be a 
64-bit fp number. Using 'double' on x87 for intermediate results causes 
roundoff to occur twice. That's what 'real' is for -- it prevents weird 
things happening behind your back.

There is no choice -- intermediate calculations are done at 'real' 
precision, and the precision of 'real' is not constant across platforms.
In adding 'real' to D, Walter hasn't just provide the possibility to use 
  80-bit floating point numbers -- that's actually a minor issue. 'real' 
reflects the underlying reality of the hardware.