[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2001211539340.9666@key0.esi.com.au>
Date: Tue, 21 Jan 2020 15:46:12 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
On Mon, 20 Jan 2020, Rich Felker wrote:
> If you don't feel ready to do unification or work on archs you're
> unfamiliar with, I think it's okay to either (1) only do the x86 work
> now, with no unification, or (2) start the unification in src/fenv/*.c,
> but with the arch files left in place in src/fenv/*/*.[csS] for all the
> archs that haven't been converted yet. I don't want to block improvement
> of the x86 versions just because the bigger task is too big.
I will revisit the abstraction without the i386/x86-?? architecture.
I think that would work.
> Another really stupid but perhaps very efficient idea we could do is
> just emulating the flags. Add a TLS slot for an fexcept_t value, move
> exceptions there as needed, and or it onto the result when reading
> back current exceptions. This would also make it dirt cheap for the
> math library to raise any exception it wants, without needing
> arithmetic, and it would make it possible to have the math library
> return errors via exception flags even on softfloat archs.
That makes a lot of sense.
That just leaves rounding and, even on the X86, the abstraction of
getting/setting the register can be made generic.
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.
