[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200116193343.GP30412@brightrain.aerifal.cx>
Date: Thu, 16 Jan 2020 14:33:43 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
On Fri, Jan 17, 2020 at 05:56:06AM +1100, Damian McGuckin wrote:
> On Thu, 16 Jan 2020, Rich Felker wrote:
>
> >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.
>
> I will try and put together a summary of what things do and we can
> go from there. It will need input from somebody with way more
> expertise on ARM and RISC-V (and X87) than I.
>
> >Would you be interested in assessing what kind of abstraction makes
> >sense here?
>
> I think the abstraction might need to be consensus. Some of it is
> not even 'fenv' related. For example, some routines only ever return
> zero, while for other FPUs, the same routine can return a (-1) if
> the exception mask
> had an component (bit) which was not a valid exception.
That's one point of having the high level logic in C: not having to
repeat it in each arch where it's potentially subtly wrong. The C code
should check the validity of the mask before attempting to use the
arch primitive to set it.
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.
