On Monday, 25 November 2013 at 12:28:27 UTC, qznc wrote:
> On Monday, 25 November 2013 at 09:05:14 UTC, Brad Roberts wrote:
>> On 11/24/13 3:38 AM, Iain Buclaw wrote:
>>> https://github.com/D-Programming-Language/druntime/pull/663
>>
>> There's only one effective way to keep things portable, and that's continuous testing on multiple platforms that exercise the various differences.  The only way to get that is to have druntime and phobos pulls continuously tested against dmd and gdc and ldc as a condition of merging.
>
> The gold standard: Every pull request (or every commit) should be tested with DMD/LDC/GDC on x86/amd64/arm

And MIPS, PPC, PPC64, SPARC :))))


> with Linux/Win/OSX.

And FreeBSD

> That is already 27 variants. Actually there should probably be more like with/without SSE.

On 11/24/13 11:43 PM, Iain Buclaw wrote:
> Library maintainers need to stop writing code with the assumption that
> their code is only going to be used with dmd and x86, and they should
> have stopped doing it 6 months ago.

I agree, but the real solution to that would be unittests that fail.

Andrei

Am Mon, 25 Nov 2013 09:46:14 -0800
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 11/24/13 11:43 PM, Iain Buclaw wrote:
> > Library maintainers need to stop writing code with the assumption that their code is only going to be used with dmd and x86, and they should have stopped doing it 6 months ago.
> 
> I agree, but the real solution to that would be unittests that fail.
> 
> Andrei
> 
> 

Or static asserts. It looks like some people just don't know that the D real type is platform specific. A simple

static if (real.mant_dig == 64)
else static assert(false);

Already helps a lot. If the code instead just assumes x86 real layout we usually only see memory corruption or bogus / invalid results and debugging that is not much fun.

On 11/24/2013 11:43 PM, Iain Buclaw wrote:
> My biggest problem with stuff like this (see link in original post) is that
> after so much combined effort getting things working across multiple
> architectures - just take a look at any pull for version MIPS, PPC, PPC64,
> SPARC, ARM, etc... or my pull for implementing std.math for almost all
> (double-double reals the main one missing), IEEE real types - someone goes ahead
> and breaks support for all these targets and no one thinks or lifts an eyebrow
> over it.

My experience with porting code across architectures is that if one personally has not done it before, one always gets it wrong, despite the best intentions.

There's no substitute for a review of such pull requests by someone who has been there done that before. Saying people should be better educated about this simply will not work.

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.
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.
3. FloatTraits. Yes, thay works only with x86. Please, get link to other supported float formats and I'll extend FloatTraits to those formats.

P.S. This PR expected pull during month. You could write you portability suggestion in the discussion.
P.P.S. This is experemental CTFE float->ubyte[] code. It can be fixed later and don't break any existing code.

On 25 November 2013 21:44, IgorStepanov <wazar@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).

On Monday, 25 November 2013 at 22:54:03 UTC, Iain Buclaw wrote:
> On 25 November 2013 21:44, IgorStepanov <wazar@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.

On 25 November 2013 23:36, IgorStepanov <wazar@mail.ru> wrote:
> On Monday, 25 November 2013 at 22:54:03 UTC, Iain Buclaw wrote:
>>
>> On 25 November 2013 21:44, IgorStepanov <wazar@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)

 I understand that it is converting a uint32 to a int32.  My point is that in C++ you can make this a warning, and then make all warnings errors. So this would not compile in any sane codebase since a int cannot express the full range of a uint. Perhaps D just better errors/warnings if it is unable to capture this...


On Monday, 25 November 2013 at 11:51:22 UTC, Jonathan M Davis wrote:
> On Monday, November 25, 2013 12:14:59 froglegs wrote:
>> >>int len = arr.length;
>> 
>>   That isn't an error in D?
>> 
>>   Every C++ code base I've worked in enables max warnings/warnings
>> as errors, this would never compile--
>> 
>>   Does it at least trigger a warning?
>
> No. It's not a warning, and dmd is not big on warnings (and IMHO warnings you
> should be abolished, but that's another discussion). Regardless, given how
> size_t is implemented, the compiler doesn't really even know that it exists
> anyway. It's aliased to uint on 32-bit systems and ulong on 64-bit systems, so
> every place that size_t is used, it gets replaced with the type that it's
> aliased to, and the compiler forgets that it was ever anything else - the same
> thing happens with all aliases.
>
> So, on 32-bit systems, size_t is uint and
>
> int len = arr.length;
>
> works just fine, because uint implicitly converts to int. Whereas on 64-bit
> systems, size_t is ulong, and ulong does _not_ implicitly convert to int, so
> you get an error.
>
> So, on 32-bit systems, it compiles just fine, and 64-bit systems you get an
> error, but no systems will give you a warning.
>
> - Jonathan M Davis