Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 16 Jan 2020 16:11:03 +0100
From: Markus Wichmann <>
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

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

> Regards - Damian


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.