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 89d58d39 for ; Sun, 23 Feb 2020 06:25:27 +0000 (UTC) Received: (qmail 23827 invoked by uid 550); 23 Feb 2020 06:25:26 -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 23809 invoked from network); 23 Feb 2020 06:25:25 -0000 Date: Sun, 23 Feb 2020 01:25:13 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200223062513.GN1663@brightrain.aerifal.cx> References: <20200124045554.GR30412@brightrain.aerifal.cx> <20200124134402.GS30412@brightrain.aerifal.cx> <20200125001100.GY30412@brightrain.aerifal.cx> <20200203020945.GK1663@brightrain.aerifal.cx> <20200222201704.GL1663@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) Subject: Re: [musl] Considering x86-64 fenv.s to C On Sun, Feb 23, 2020 at 04:41:31PM +1100, Damian McGuckin wrote: > On Sat, 22 Feb 2020, Rich Felker wrote: > > >First comment: I couldn't find (maybe I missed?) what you intend fore > >the contents of fenv-generic.c and fenv-trivial.c to be, but I don't > >see what you want them for. fenv.c should just use the macros/inlines > >the fenv_arch.h defines, naturally collapsing to empty functions when > >they do nothing (for softfloat archs). > > I agree. I was seduced by what I thought was a better way. > > I assume that I can also have a > > fenv_arch_soft_float.h I don't follow what this would be for. Presumably arch/generic/fenv_arch.h would be empty and the internal header that includes fenv_arch.h would define dummy fenv accessor helpers in the absence of any defined by fenv_arch.h, or similar. > and > fenv_arch_common_fpu.h > > Each of thes is pulled in at the end of fenv_arch.h for respectively > > a) those machines with a generic soft_float architecture > > b) those machines with non-Intel (hard) FPUs. Other way around. fenv_impl.h (this would probably be the right name according to existing patterns in musl) would include fenv_arch.h and then define defaults for anything not defined by the latter. Then source files don't include fenv_arch.h at all, only fenv_impl.h. Ordering the inclusion this direction keeps duplicate logic out of arch-specific files. Rich