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