From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id a645ce2a for ; Mon, 27 Jan 2020 05:40:06 +0000 (UTC) Received: (qmail 20054 invoked by uid 550); 27 Jan 2020 05:40:05 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 20032 invoked from network); 27 Jan 2020 05:40:04 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs Date: Mon, 27 Jan 2020 16:39:51 +1100 (AEDT) From: Damian McGuckin To: musl@lists.openwall.com In-Reply-To: <20200125001100.GY30412@brightrain.aerifal.cx> Message-ID: References: <20200118053759.GX30412@brightrain.aerifal.cx> <20200118094015.GE23985@port70.net> <20200124011122.GP30412@brightrain.aerifal.cx> <20200124045554.GR30412@brightrain.aerifal.cx> <20200124134402.GS30412@brightrain.aerifal.cx> <20200125001100.GY30412@brightrain.aerifal.cx> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [musl] 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