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