[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.2001271634530.23690@key0.esi.com.au>
Date: Mon, 27 Jan 2020 16:39:51 +1100 (AEDT)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: Considering x86-64 fenv.s to C
The PowerPC is ever so close to being generic.
Generic Handling of Floating Point Exceptions (And Causes Thereof)
------------------------------------------------------------------
The PowerPC architecture has the non-standard concept of the cause of an
INVALID exception, the reason why an FE_INVALID exception has occurred.
There are nine such causes, encapsulated in a non-contiguous mask across
nine bits, the OR'd combination of which is the FE_ALL_INVALID macro.
Instructions performing invalid operations (as I read the documentation)
only need to see the CAUSE bit, which implicitly raises the FE_INVALID
exception. So, an FE_INVALID implies the existence of a CAUSE bit, and
vica versa. On a PowerPC, MUSL supports one of those 9 causes, the macro
called FE_INVALID_SOFTWARE (if _GNU_SOURCE is defined) which says that
a FE_INVALID exception has been caused 'by an explicit software request'.
The handling of cause bits is awkward. However they must be addressed as
they can stab the user, well MUSL, in the back if not done right.
An incoming exception list (of bits) to be cleared, raised, or tested, is
validated by masking it with respect to an mask comprising the net OR'd
combination of all IEEE 754 exceptions. This approach results in any bits
which are not a valid exception being thrown away. For anything other than
a PowerPC, this mask is defined as simply
#define FE_EXCEPT_MASK (FE_ALL_EXCEPT)
It is proposed that for a PowerPC, it is instead defined as
#define FE_EXCEPT_MASK (FE_ALL_EXCEPT | FE_ALL_INVALID)
*** This change also greatly simplifies the generic nature of handling ***
This also allows the user to interrogate, clear and raise these extra
cause bits on the PowerPC and provides consistent handling. A bonus.
Mind you, I do not yet have a PowerPC64 with which to test any of this,
so I could just be talking through my hat.
Everything needs to be tested!
If the user wants to specify a CAUSE bits, i.e. one within the those
for which FE_ALL_INVALID is a mask, the FE_INVALID_SOFTWARE bit should
probably not be also introduced.
That needs to be tested too!!
Comments, Complaints, Criticism??????
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.
