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 64ed7be9 for ; Fri, 24 Jan 2020 06:09:11 +0000 (UTC) Received: (qmail 7232 invoked by uid 550); 24 Jan 2020 06:09:09 -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 7214 invoked from network); 24 Jan 2020 06:09:08 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs Date: Fri, 24 Jan 2020 17:08:54 +1100 (AEDT) From: Damian McGuckin To: musl@lists.openwall.com In-Reply-To: <20200124045554.GR30412@brightrain.aerifal.cx> Message-ID: References: <20200116193343.GP30412@brightrain.aerifal.cx> <20200117164143.GB2020@voyager> <20200118011535.GD23985@port70.net> <20200118053759.GX30412@brightrain.aerifal.cx> <20200118094015.GE23985@port70.net> <20200124011122.GP30412@brightrain.aerifal.cx> <20200124045554.GR30412@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 On Thu, 23 Jan 2020, Rich Felker wrote: > Note that it's not necessary to write that logic in asm just because > it's in the arch-defined part. It could simply be C that fixes up the > value before/after the asm. My rule was to have no logic in the embedded assembler. Just get or set the register and quit. Your skill levels may let you do more. I tried to keep these routine super simple. Here they are for the PowerPC. static inline double get_fpscr_f(void) { double fpscr; __asm__ __volatile__ ("mffs %0" : "=d"(fpscr)); return fpscr; } static inline unsigned int get_csr(void) { return (unsigned int) (union {double f; long i;}) {get_fpscr_f()}.i; } static inline void set_fpscr_f(double fpscr) { __asm__ __volatile__ ("mtfsf 255, %0" : : "d"(fpscr)); } static inline void set_csr(unsigned int fpscr) { set_fpscr_f((union {long i; double f;}) {(long) fpscr}.f); } > But indeed the following may be nicer anyway: ...... >> if (excepts & FE_INVALID) >> excepts |= FE_ALL_INVALID; >> and >> if (excepts & FE_INVALID) >> excepts |= FE_INVALID_SOFTWARE; >> >> An optimize should see the OR with zero for most architectures and >> then ignore that whole 'if' statement because the action was a >> NO-OP. > > Yes, this looks nice (although I would probably include FE_INVALID in > FE_ALL_INVALID just out of principle of least surprise; it should > generate the same code either way. Do you mean if (excepts & FE_INVALID) excepts |= FE_ALL_INVALID | FE_INVALID; If so, will it really be optimized away if FE_ALL_INVALID is zero (0)? >>>> case (FE_OVERFLOW | FE_INEXACT): > > One more style thing: no need for parens here. Sorry. Too much cutting and pasting from the original 'if' that I realized (at the last minute) should be a switch. > Indeed, I think if we make that change it would be nice to factor it > as a separate change later. Please. Sounds wise. > I do think I want to make it, though, I think the idea of a SOFT_FPSR is a really good idea. > feclearexcept would do: > > soft_fpsr = (soft_fpsr | get_sr()) & ~except; > clear_sr(); > > At that point, FE_INVALID is clearable independent of the > specific-reason flags and doesn't seem to need any special treatment. ??? - I need to wrap my head around that one over the weekend. > Note that just using clear_sr() rather than set_sr() here is a huge > optimization on i386 too -- it avoids the need to read-modify-write the > full fenv. Definitely. The Intel architectures are a world unto themselves. > You should consider arch/*/bits/fenv.h as essentially immutable; the > types and macros there are ABI or API conventions. The arch-specific > definitions for fenv stuff should go in arch/$(ARCH)/fenv_arch.h. OK. 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