[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200223062513.GN1663@brightrain.aerifal.cx>
Date: Sun, 23 Feb 2020 01:25:13 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
On Sun, Feb 23, 2020 at 04:41:31PM +1100, Damian McGuckin wrote:
> On Sat, 22 Feb 2020, Rich Felker wrote:
>
> >First comment: I couldn't find (maybe I missed?) what you intend fore
> >the contents of fenv-generic.c and fenv-trivial.c to be, but I don't
> >see what you want them for. fenv.c should just use the macros/inlines
> >the fenv_arch.h defines, naturally collapsing to empty functions when
> >they do nothing (for softfloat archs).
>
> I agree. I was seduced by what I thought was a better way.
>
> I assume that I can also have a
>
> fenv_arch_soft_float.h
I don't follow what this would be for. Presumably
arch/generic/fenv_arch.h would be empty and the internal header that
includes fenv_arch.h would define dummy fenv accessor helpers in the
absence of any defined by fenv_arch.h, or similar.
> and
> fenv_arch_common_fpu.h
>
> Each of thes is pulled in at the end of fenv_arch.h for respectively
>
> a) those machines with a generic soft_float architecture
>
> b) those machines with non-Intel (hard) FPUs.
Other way around. fenv_impl.h (this would probably be the right name
according to existing patterns in musl) would include fenv_arch.h and
then define defaults for anything not defined by the latter. Then
source files don't include fenv_arch.h at all, only fenv_impl.h.
Ordering the inclusion this direction keeps duplicate logic out of
arch-specific files.
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.
