GDC release 0.23
Daniel Keep
daniel.keep.lists at gmail.com
Tue Mar 6 19:29:47 PST 2007
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. 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
I might be off-base, but couldn't you do something like this?
> version( GDC )
> pragma(gdc_enable, gdc_longdouble);
>
> // ...
>
> extern(C) gdc_longdouble foo(gdc_longdouble);
Yes, you'd be adding a new type, but at least it's hidden behind a
pragma. Interfacing with C code is fairly important to D, but I'd hate
to have fp code that works fine under DMD and then mysteriously breaks
with gdc--I think compatibility with other D implementations should come
before interfacing with C.
Just my AU$0.02.
-- Daniel
--
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.
v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
More information about the Digitalmars-d-announce
mailing list