[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200116151103.GA2020@voyager>
Date: Thu, 16 Jan 2020 16:11:03 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
On Thu, Jan 16, 2020 at 03:30:03PM +1100, Damian McGuckin wrote:
>
> I was just looking at fenv.s in x86-64 with a view to doing this as C-code
> with some __asm__. I have limited experience with playing with this stuff in
> an SSE-only environment, i.e. no 80-bit floats. Before I attempt anything,
> I need to expand my knowledge.
>
> My observations on
>
> musl-1.1.24/src/fenv/x86_64/fenv.s
>
> * feclearexcept
>
> considers both the X87 status word and the SSE MXCSR
>
> * feraiseexcept
>
> ignores the X87 status word and considers only the SSE MXCSR
>
> * fetesteexcept
>
> considers both the X87 status word and the SSE MXCSR
>
> * fesetround
>
> considers both the X87 control word and the SSE MXCSR
>
> * fegetround
>
> ignores the X87 control word and considers only the SSE MXCSR
>
> Why is the X87 component of the FPU control/status sometimes ignored and
> sometimes not?
>
feraiseexcept() is merely supposed to set a flag in the fenv such that
fetestexcept() can pick it up. Therefore it is sufficient to set the
flag in either the X87 SW or the MXCSR, and the MXCSR is nicer to
access.
fegetround() has to determine rounding mode. Since no conformant code
can set the rounding modes in X87 and SSE differently from each other,
it is sufficient to read it from either source, and again, the MXCSR is
nicer to access.
> Does the X87 control or status bits automatically flow through to the
> equivalent stuff in the SSE or vica-versa?
>
No, the CPU treats X87 and SSE as separate. That's why fetestexcept()
has to calculate the bitwise OR of the two sources.
> I assume that 'fwait' is irrelevant and unnecessary, even if one is using
> the x87 FPU?
>
Yes, fwait was last relevant on the 386, when an external 387 (was there
a 487?) was actually a possibility, but ever since the 486DX, the FPU
has been moved into the processor. Therefore FPU instructions are now
synchronous to program execution, and a synchronization instruction is
superfluous. Doesn't hurt, either, it's basically a NOP now. A NOP that
can generate #NM under some circumstances, but it doesn't change
anything.
> Regards - Damian
>
Ciao,
Markus
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.
