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 1438465d for ; Wed, 5 Feb 2020 01:33:00 +0000 (UTC) Received: (qmail 9246 invoked by uid 550); 5 Feb 2020 01:32:58 -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 9228 invoked from network); 5 Feb 2020 01:32:57 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs Date: Wed, 5 Feb 2020 12:32:41 +1100 (AEDT) From: Damian McGuckin To: musl@lists.openwall.com In-Reply-To: <20200203145030.GP1663@brightrain.aerifal.cx> Message-ID: References: <05c1e691-c0b6-f1af-4850-68670f2d915d@gmail.com> <20200203145030.GP1663@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 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