Why is it that no one writes with portability in mind in druntime?

[Iain Buclaw]

On 25 November 2013 23:36, IgorStepanov <wazar at mail.ru> wrote:
> On Monday, 25 November 2013 at 22:54:03 UTC, Iain Buclaw wrote:
>>
>> On 25 November 2013 21:44, IgorStepanov <wazar at mail.ru> wrote:
>>>
>>> On Sunday, 24 November 2013 at 11:38:27 UTC, Iain Buclaw wrote:
>>>>
>>>>
>>>> https://github.com/D-Programming-Language/druntime/pull/663
>>>
>>>
>>>
>>> This code is not portable only on CTFE part. (All those float
>>> manipulations
>>> run at compile time)
>>> I see three unportable aspects:
>>> 1. This code supports only 80bit real. What other formats we need to
>>> support? Can  the compiler support operations on those (or more precise)
>>> formats? AFAIK dmd frontend perform all float operations in 80 bit real
>>> and
>>> supports only x86.
>>
>>
>> The following IEEE 'real' formats are currently supported:
>> 64 bit Big-endian  'double' (eg PowerPC)
>> 128 bit Big-endian 'quadruple' (eg SPARC)
>> 64 bit Little-endian 'double' (eg x86-SSE2)
>> 80 bit Little-endian, with implied bit 'real80' (eg x87, Itanium).
>> 128 bit Little-endian 'quadruple' (not implemented on any known
>> processor!)
>>
>> Non-IEEE 128 bit Big-endian 'doubledouble' (eg PowerPC) has partial
>> support
>>
>> At least support for these is a must:
>>
>> version(LittleEndian)
>> {
>>     static assert(real.mant_dig == 53 || real.mant_dig==64
>>                || real.mant_dig == 113);
>> }
>> else
>> {
>>     static assert(real.mant_dig == 53 || real.mant_dig == 113);
>> }
>>
>> 128 bit doubledouble formats (real.mant_dig == 106) - are a future goal.
>>
>>
>>> 2. This code don't considers a float byte order. But compiler don't
>>> inform
>>> user code about float BO. There are LittleEndian/BigEndian versions for
>>> integers, but not for floats. You can add this versions on compiler and
>>> I'll
>>> fix this aspect in druntime code.
>>
>>
>> There doesn't exist a machine where the most significant byte of a
>> word is ordered differently to floats. See std.math if in doubt, as
>> this is already implemented.
>>
>>> 3. FloatTraits. Yes, thay works only with x86. Please, get link to other
>>> supported float formats and I'll extend FloatTraits to those formats.
>>>
>>
>> See std.math, which already has a cross-platform implementation of
>> that template with the same name (that amazingly existed years ago).
>
>
> I can't implement CTFE support of types more precise than x86 80bit real. A
> think, all IEEE floats will be successfully processed like float and double
> (with same algorithm). But until CTFE don't support float with
> real.mant_dig>64 I can't process this types.
> Resume: I'll modify FloatTraits, consider endianess and add assert(0) for
> too precise types.

Then test with a compiler that does have support in CTFE for floats
with 128 bit precision then (actually, 160bit is the max stored :o)