Re: [musl] Considering x86-64 fenv.s to C

[Damian McGuckin <damianm@esi.com.au>]

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