[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Jan 2020 00:37:59 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
On Sat, Jan 18, 2020 at 04:03:01PM +1100, Damian McGuckin wrote:
> On Sat, 18 Jan 2020, Szabolcs Nagy wrote:
>
> >* Markus Wichmann <nullplan@....net> [2020-01-17 17:41:43 +0100]:
> >>On Fri, Jan 17, 2020 at 02:36:20PM +1100, Damian McGuckin wrote:
> >>>Also, and I could be wrong, currently MUSL assumes that there is an integral
> >>>type for every floating type.
> >>
> >>Let me stop you there. Musl assumes that for long doubles, you can
> >>create a union ldshape. So there is no need for a 128 bit data type, a
> >>64 bit one is good enough.
>
> What does it assume for a long double which has 128-bits?
Just that there's a struct ldshape defined for the specific long
double type and endianness, that can be used to access its
representation.
> >actually it's quite annoying to deal with N bit long double
> >without N bit int, because sometimes you want to fiddle with the
> >bits using int operations and if you don't have N bit int type you
> >have to deal with endianness (you can always copy the long double
> >into an array of bytes, but the layout of the bytes is not
> >portable, same for union with multiple fields: you need variants
> >for different endianness)
>
> I was just seeking others experience and whether they is solution
> about which I am unaware. But it seems not. I am looking at this
> issues in the context of (purchasing) a Power9 CPU which has no
> 80-bit floats but has instead 128-bit floats.
The musl ABI for powerpc[64] uses 64-bit long double because the
compiler support for IEEE quad is very lacking and was pretty much
nonexistent at the time musl added these archs.
> Do we have to start supporting 128-bit floats, we will need to use
> the __int28_t and __uint128_t about which I know nothing. But they
> have their own limitations.
No, these are not used at all in musl, and are problematic types
because they can't formally be extended integer types, since they
mismatch intmax_t being 64-bit. We just use "ldshape".
> Are hardware versions of these on the horizon for Intel or others?
>
> Should we start lobbying the chip makers to get their act together??
>
> Probably not questions to which I will get resolutions any time soon.
I don't think it really makes any difference. Existing ABIs are not
going to be changed, and the consensus from people who actually want
to use IEEE quad seems to be that they want a __float128 type that's
uniform across archs, not having it for long double. This puts it
outside the scope of math library for the time being, and would
probably be a separate add-on math library if there eventually is a
math library for these since musl can't/won't depend on compiler
support for new/optional types to build a working libc.so (this would
preclude using any compiler without them).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
