[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200116161427.GO30412@brightrain.aerifal.cx>
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.
