GDC release 0.23
David Friedman
dvdfrdmn at users.ess-eff.net
Wed Mar 7 14:54:41 PST 2007
Walter Bright wrote:
> Don Clugston wrote:
>
>> There's just no way D real can be equal to C long double in general,
>> when the C long double is playing silly games. The only reason gcc can
>> even do that, is that the C spec for floating point is ridiculously
>> vague, and consequently no-one actually uses long double. To mimic it
>> is to immediately break D's support for IEEE.
>>
>> Seriously, the viability of D as a numeric computing platform is at
>> stake here.
>
>
> I don't really understand the issues with the PPC 'double double', but:
>
> 1) real.sizeof is 10 on Win32, and 12 on Linux. This caused some (now
> fixed) compiler bugs, but shouldn't have affected any user code.
>
> 2) D floating point arithmetic is supposed to be IEEE 754. Some wacky
> real type for the PPC is going to cause grief and break code in
> irritating and unforeseeable ways.
>
Alright. Given the strict requirement for IEEE, D's real cannot be
implemented as double+double.
> 3) The D implementation is allowed to evaluate floating point ops in
> higher precision than that specified by the type. FP algorithms should
> be coded to not break if more accurate answers are delivered.
>
> 4) I suggest supporting the wacky PPC double double with:
> a) a special type, like __doubledouble, that is NOT real, ireal, or creal.
> b) real should map to C's double, but still be a distinct type to the
> compiler
> c) if doing __doubledouble is a pain as an inbuilt type, perhaps do it
> as a struct and a library type?
If I do implement it as a primitive type, how do you suggest I mangle it
and the imaginary/complex variants? Should there be an
'implementation specific extension' mangle character?
David
More information about the D.gnu
mailing list