[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2002051144080.24229@key0.esi.com.au>
Date: Wed, 5 Feb 2020 12:32:41 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
Sort of style question. No rush at replying.
As I read it, and I could be wrong, the assumptions on the FENV interface
is that excepts/exceptions fit into an int. MUSL takes this further and
then assumes that these are in the 31 least significant bits of floating
point exception registers.
That works for all known architectures, including Sparc and Itanium.
Mind you, an 'fexcept_t' may be an unsigned long but it is still just an
image of the status register and no architecture has anything which is of
interest to FENV stuck up there in the sign bit.
This MUSL assumption would appear to also be the case for the control
register where the rounding bits appear (which more often than not is the
same register as the status register).
However, the raw bit mask encroaches on the sign bit for a Sparc. And yes,
MUSL does not support Sparc. But I assume if Sparc did it, some hardware
designer may try it into the future for some new chip that MUSL does want
to support (although I see no evidence of that). The user-space rounding
bits fed to fesetrounding() and retrieved from fegetrounding() for a Sparc
are small integers which are shifted into (and out of) their bit position
within the register in a BSD implementation. I have not figured out how
OpenSolaris/Illumnos does it.
Now, I
a) Normally avoid using signed quantities when working with bit
masks as such handling was not always predictable in the past. So
using signed quantities for bit operations is not something with
which I have loads of experience.
b) Am trying to use consistent processing for the status and control
registers because they are often one and the same. And I also want
to cover all eventualities.
Do I just stick with working with (signed) int's as MUSL does currently or
do I try and make this generic code a reference implementation that goes
beyond usefulness in just a Linux environment and the architectures that
MUSL does support. Is this overcomplicating this task?
Thoughts anybody? - 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.
