GDC release 0.23

[Don Clugston]

David Friedman wrote:
> 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.

Agreed, but we need to be able to do it without wrecking 
interoperability with D!

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

I disagree -- superficially, a new type looks like a bigger divergence, 
but when it actually comes to writing FP code, it's much less of a 
divergence, because it wouldn't mess with the semantics of existing 
floating point types.
In fact, since all CPUs are capable of using double+double, I would like 
to see it become a regular part of the language at some point -- it's a 
portable data type.