|
Message-ID: <alpine.LRH.2.02.2002091439580.20013@key0.esi.com.au> Date: Sun, 9 Feb 2020 16:04:47 +1100 (AEDT) From: Damian McGuckin <damianm@....com.au> To: musl@...ts.openwall.com Subject: Re: Considering x86-64 fenv.s to C 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
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.