Re: [musl] Considering x86-64 fenv.s to C

[Damian McGuckin <damianm@esi.com.au>]

On Thu, 16 Jan 2020, Rich Felker wrote:

> Would you be interested in assessing what kind of abstraction makes
> sense here?

I think it is quite difficult, but eventually feasibly.

Even having one abstract version for i386/x32 and x86_64 is not easy.

My thoughts were to do an abstraction that works for at least those three,
simplify this to be even more abstract,  and then see how well it works for 
say something else.  The i386/x32 and x86 are arguably among the worst as
they effectively have 2 lots of status and control registers which are
not synced on-chip but that need to be for MUSL.

The only assembler in which I have even limited skills is Sparc32/64 which 
is not terribly useful for MUSL but in terms of an abstraction, may be as 
good as anything. I will be investing in an ARM soon but my skills will be 
starting from a base of none.

On Fri, 17 Jan 2020, Rich Felker wrote:

> As you said above, updating x87 status register is expensive because
> the only way to write it is to read-modify-write the whole fenv. But
> since we know on x86_64 we have sse registers, we can just move all
> the flags to the sse register, then use fnclex to clear the x87 one
> inexpensively, and the effective set of raised flags remains the same.
>
> I think we could do this on i386 too with a couple tricks:
>
> 1. Do the same thing if sse is available (hwcap check).

Yes.
>
> 2. If sse is not available, clear all flags then re-raise the desired
> set via arithmetic operations.

That works.  That said, Based on a comment earlier today, my thoughts are 
to use an arithmetic expression for the case where only a single exception 
was active, including the pairs INEXACT/OVERFLOW and INEXACT/UNDERFLOW, 
and use a fegetenv/set-register/fesetenv for anything more complex.

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