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 0cc6df0b for ; Tue, 21 Jan 2020 04:46:27 +0000 (UTC) Received: (qmail 4033 invoked by uid 550); 21 Jan 2020 04:46:25 -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 4012 invoked from network); 21 Jan 2020 04:46:24 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs Date: Tue, 21 Jan 2020 15:46:12 +1100 (AEDT) From: Damian McGuckin To: musl@lists.openwall.com In-Reply-To: <20200121042231.GO30412@brightrain.aerifal.cx> Message-ID: References: <20200116161427.GO30412@brightrain.aerifal.cx> <20200116193343.GP30412@brightrain.aerifal.cx> <20200117145350.GR30412@brightrain.aerifal.cx> <20200121042231.GO30412@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 Mon, 20 Jan 2020, Rich Felker wrote: > If you don't feel ready to do unification or work on archs you're > unfamiliar with, I think it's okay to either (1) only do the x86 work > now, with no unification, or (2) start the unification in src/fenv/*.c, > but with the arch files left in place in src/fenv/*/*.[csS] for all the > archs that haven't been converted yet. I don't want to block improvement > of the x86 versions just because the bigger task is too big. I will revisit the abstraction without the i386/x86-?? architecture. I think that would work. > Another really stupid but perhaps very efficient idea we could do is > just emulating the flags. Add a TLS slot for an fexcept_t value, move > exceptions there as needed, and or it onto the result when reading > back current exceptions. This would also make it dirt cheap for the > math library to raise any exception it wants, without needing > arithmetic, and it would make it possible to have the math library > return errors via exception flags even on softfloat archs. That makes a lot of sense. That just leaves rounding and, even on the X86, the abstraction of getting/setting the register can be made generic. 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