develooper Front page | perl.perl5.porters | Postings from September 2014

Re: new long doubles option: gcc libquadmath

Thread Previous | Thread Next
From:
Reini Urban
Date:
September 20, 2014 14:53
Subject:
Re: new long doubles option: gcc libquadmath
Message ID:
CAHiT=DGFrFUTB43gvgPBHxBvWbTneUccTAojn14ZavOLj7YOgQ@mail.gmail.com
On Fri, Sep 19, 2014 at 3:12 PM, Jarkko Hietaniemi <jhi@iki.fi> wrote:
> On Friday-201409-19, 14:46, Reini Urban wrote:
>>
>> All serializers should support all possible number formats. There are
>> dozens.
>>>
>>> From the standardized float and double to the varying versions of long
>>> double:
>>
>> double-double as on ppc, the two intel variants with 10 or 12 extended
>> prec.,
>
> I think the "12 bytes" for the x86 extended precision is an "urban
> legend" of misunderstanding: the number of bits is always 80 (64 for
> mantissa, 15 for exponent, 1 for sign, no "implicit bit").  The 12
> comes from the ILP32 way of storing the 10-byte thing in three 4-byte words.
> In LP64 (like x86_64) it's stored in two 8-byte words, hence 16
> bytes.  The unused bytes (2 or 6) are unused garbage.  They might be
> zero bits, or they might contain your credit card number.

I know. I implemented the binary converters for all floating point formats
in parrot.
But it has to be separated when you implement binary serializers.

> As for the libquadmath: it's not a new format.  It's an implementation
> of the perfectly standard IEEE 754.  Of course one may understand as
> "standard" only the double precision of 64/53 bits, but there's no
> escaping it's the same standard.
>
>> the hw or sw quad math standards, and several more hw specific variants,
>> little and big-endian.
>>
>> If you transport them as strings you need to do nothing, as blob you need
>> to
>> mark the variant in the header and do something like the parrot native_pbc
>> translators (fast, but not recommended).
>
>
> Yeah.  The output/transport/storage is easy: output the tag, output the raw
> bytes, bam, done.  The input is where the pain begins: if you have
> different runtime than you are importing from, you obviously will have to
> leave something on the cutting room floor.  Chop? Round? Round how?

Round to nearest as Intel does. Rounding is not yet done in parrot, just chop,
but most of the converters are done.
It would deserve a seperate c library (libfloatbin e.g.), but I have no time and
interest to maintain that beast.

See https://github.com/parrot/parrot/blob/native_pbc2/src/packfile/pf_items.c#L554

> One option would be to have a "portable (binary) floating point":
> instead of packing the {sign_bit,exponent,implicit_bit,mantissa}
> into a single 8/10/16 byte string, one could output as a tuple of
> {sign_bit,var_length_signed_exponent,implicit_bit,var_length_mantissa_bits_string}
> (Just thinking aloud.)  Something needed for the exceptional values
> like Inf and NaN, one could follow the IEEE 754 conventions.  The
> obvious upside of a portable fp format: always stores faithfully,
> and reduces the N x M conversion issue into N + M.  The obvious
> downside: speed loss both on write and read.

-- 
Reini Urban
http://cpanel.net/   http://www.perl-compiler.org/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About