[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200118094015.GE23985@port70.net>
Date: Sat, 18 Jan 2020 10:40:15 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
* Rich Felker <dalias@...c.org> [2020-01-18 00:37:59 -0500]:
> On Sat, Jan 18, 2020 at 04:03:01PM +1100, Damian McGuckin wrote:
> > 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".
there is one place where __int128 is used: powerpc64 jmp_buf
and i think aarch64 should use it in ucontext, both are
places where quad float regs are saved, but the kernel and
system software wants to access them with integer code.
(aarch64 uses long double type now)
> 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).
nowadays there is some support for ts 18661-3 in gcc so
a libc can support the interfaces defined there (which
include math functions for _Float128 type), an old draft:
http://www.open-std.org/jtc1/sc22//WG14/www/docs/n1945.pdf
however hw implementation is costly and with current
implementations there is significant gap between double
and quad prec performance so heavy uses of quad is
unlikely even when available in hw.
otoh quad prec software implementations are still much
faster than arbitrary precision float libraries (mpfr,
arb) so there are use cases when quad makes sense in
general (but it might be better to just optimize the
arbitrary precision libraries)
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.
