On 3 Jul 2014 04:50, "Sean Kelly via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
>
> On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d wrote:
>>
>>
>> I'm not sure I understand how removing support 80-bit floats hurts interoperability with C? I thought none of the standard C float types map to the x87 80-bit float?
>
>
> The C spec never says anything specific about representation because it's meant to target anything, but the x86 and AMD64 ABIs basically say that "long double" is 80-bit for calculations.  The x86 spec says that the type is stored in 96 bits though, and the AMD64 spec says they're stored in 128 bits for alignment purposes.
>
> I'm still unclear whether we're aiming for C interoperability or hardware support though, based on Walter's remark about SPARC and PPC.  There, 'long double' is represented differently but is not backed by specialized hardware, so I'm guessing D would make 'real' 64-bits on these platforms and break compatibility with C.  So... I guess we really do need a special alias for C compatibility, and this can map to whatever intrinsic type the applicable compiler supports for that platform.

I take the spec to mean that I can map float, double, and real to the native C types for float, double, and long double - or in jargon terms, the native single, double, and extended (or quad if the user or backend requests it) types.

Certainly I have implemented my bits of std.math with real == double and real == quad in mind.  PPC will have to wait, but it is easy enough to identify doubledouble reals in CTFE.

Iain.