GDC release 0.23

David Friedman dvdfrdmn at users.ess-eff.net
Tue Mar 6 19:03:05 PST 2007


Sean Kelly wrote:
> Anders F Björklund wrote:
> 
>>>> GDC now supports 64-bit targets! A new x86_64 Linux binary is
>>>> available and the MacOS X binary supports x86_64 and ppc64.
>>>
>>>
>>> Excellent news! I'll try it on ppc64 Linux too (Fedora Core)
>>
>>
>> Except for some strange (temporary?) build error with soft-float,
>> it built just fine for powerpc64-unknown-linux-gnu (with FC5/PPC*)
> 
> 
> That reminds me.  Is it really a good idea to map the GCC/PPC "long 
> double" to "real" in D?  I know this has come up before:
> 
> http://www.digitalmars.com/d/archives/digitalmars/D/20790.html
> 
> and the data type seems like an aberration.  Here is some more info:
> 
> http://lists.apple.com/archives/Darwin-development/2001/Jan/msg00499.html
> 
> And from the ELF ABI:
> 
>     This "Extended precision" differs from the IEEE 754 Standard
>     in the following ways:
> 
>     * The software support is restricted to round-to-nearest
>       mode. Programs that use extended precision must ensure
>       that this rounding mode is in effect when
>       extended-precision calculations are performed.
>     * Does not fully support the IEEE special numbers NaN and
>       INF. These values are encoded in the high-order double
>       value only. The low-order value is not significant.
>     * Does not support the IEEE status flags for overflow,
>       underflow, and other conditions. These flag have no
>       meaning in this format.
> 
> I can't claim to have the maths background of some folks here, but this 
> suggests to me that this 128-bit representation isn't truly IEEE-754 
> compliant and therefore probably shouldn't be a default data type in D?
> 
> 
> Sean

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.

David


More information about the D.gnu mailing list