Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jan 2020 15:46:12 +1100 (AEDT)
From: Damian McGuckin <>
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.