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

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

The overall generic design is that each architecture has its own

 	fenv.c

file and

a)	if it is soft float, they pull in the trivial fenv.c file
 	currently in ../fenv (which I will call trivial.c) as

 		#include "../trivial.c"

b)	otherwise,

 	i) most architectures, except Intel then pull in two files

 		#include "../regular.c"

 		#include "../generic.c"

 	ii) Intel architectures pull in solely

 		#include "../generic.c"

All decision making logic is in "generic.c". There is no decision making 
in the "regular.c" file.

There is no decision making in the "fenv.c" file which is largely embedded 
assembler and a few definitions EXCEPT or

a	Intel i386 basically trying to figure out whether it has XMM
 	instructions and trying to optimize the use of clearing the
 	exceptions or writing to the environment.

b)	PowerPC where it has to figure out whether to augment the
 	exception mask in the case of the INVALID exception.

The i386, x32 and x86_64 will only use "generic.c" but not "regular.c". 
They need extend their own "fenv.c" file as this architecture is just too 
different.

The code within "generic.c" file will, when it is asked to raise a single 
excepion, do so arithmetically irrespective of architecture. For more than 
one exception, the use of the status register is, at this stage of the 
design process, deemed more cost effective. This is only done for 'raise'. 
It does not try and optimize 'feclearexcept' or 'fesetexceptlags'. It just 
gets too messy.

There are 2 #define's in "regular.c" to cater for a SPARC into the future. 
If MUSL will never support this architecture, six lines can be dropped and 
two lines simpliied.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer