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 11:14:27 -0500
From: Rich Felker <dalias@...c.org>
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?
> 
> Does the X87 control or status bits automatically flow through to the
> equivalent stuff in the SSE or vica-versa?
> 
> I assume that 'fwait' is irrelevant and unnecessary, even if one is
> using the x87 FPU?

As an aside, rather than implementing x86-specific C versions of
these, I'd like to end up with a general framework where the arch just
exposes a header (fenv_arch.h?) defining some primitives, and the
actual fenv function logic is all shared C. I'm not sure what the
right generalization is though. It looks like all archs have a get/set
exception-flags (status word) operation, but the rest varies a bit.

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

Rich

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.