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 d98d89e6 for ; Thu, 16 Jan 2020 19:33:57 +0000 (UTC) Received: (qmail 9905 invoked by uid 550); 16 Jan 2020 19:33:55 -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 9887 invoked from network); 16 Jan 2020 19:33:55 -0000 Date: Thu, 16 Jan 2020 14:33:43 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200116193343.GP30412@brightrain.aerifal.cx> References: <20200116161427.GO30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Considering x86-64 fenv.s to C On Fri, Jan 17, 2020 at 05:56:06AM +1100, Damian McGuckin wrote: > On Thu, 16 Jan 2020, Rich Felker wrote: > > >As an aside, rather than implementing x86-specific C versions of > >these, I'd like to end up with a general framework where the arch > >just exposes a header (fenv_arch.h?) defining some primitives, and > >the actual fenv function logic is all shared C. I'm not sure what > >the right generalization is though. It looks like all archs have a > >get/set exception-flags (status word) operation, but the rest > >varies a bit. > > I will try and put together a summary of what things do and we can > go from there. It will need input from somebody with way more > expertise on ARM and RISC-V (and X87) than I. > > >Would you be interested in assessing what kind of abstraction makes > >sense here? > > I think the abstraction might need to be consensus. Some of it is > not even 'fenv' related. For example, some routines only ever return > zero, while for other FPUs, the same routine can return a (-1) if > the exception mask > had an component (bit) which was not a valid exception. That's one point of having the high level logic in C: not having to repeat it in each arch where it's potentially subtly wrong. The C code should check the validity of the mask before attempting to use the arch primitive to set it. Rich