[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2001181545420.21223@key0.esi.com.au>
Date: Sat, 18 Jan 2020 16:03:01 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
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?
> 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.
As you say, it is annoying. I had this problem ages ago when a long was a
32-bit integer and a double was 64-bits. And now the problem has come back
again.
I find MUSL just so much more elegant that the old SUN library because
MUSL no longer has to worry the get/set hi/lo twin pairs of macros and the
soft arithmetic that was often necessary to support the 2 32-bit integers.
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.
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.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
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.
