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=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 b609619f for ; Thu, 16 Jan 2020 15:11:17 +0000 (UTC) Received: (qmail 32541 invoked by uid 550); 16 Jan 2020 15:11:16 -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 32507 invoked from network); 16 Jan 2020 15:11:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579187464; bh=Aylejso0dZW6bwBzA5uqRYOTU/x6EUzhEgLOFW+oHGI=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=PZGcrSqwva+bC4tE85HXMdnBczYjroM3j1BRiXsr1YnoMtSZgTxC09vYuD5Fdy4Ft 0TjaFuwgyMjDMW1r9qYp8cGTvABVDo5vX17uROHoYN60S1qSSXfJE+EPsdYhrywJDw L7KVkoHz5IFJMeIn5M3k3RySfAaVlz0ZMjG88oMw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Date: Thu, 16 Jan 2020 16:11:03 +0100 From: Markus Wichmann To: musl@lists.openwall.com Message-ID: <20200116151103.GA2020@voyager> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Provags-ID: V03:K1:gIC2Mt7R+HhpnlB2/FI1DlBYzRxRRZKTb3t2ijz7FXdlegUFGMX 6F5V/RXFKblGKi85RtbeLqDg43SQ9NkcaUyC3biec7IBsPty/UCHfwauMqZn+mo7a/OXmkU aL0EjuxO+ht8Pxc6GNiZz51sOrf8l9aR/cvyugHiaKaJGw8mOXyTkJrZKdeJrOS7yT3cTpj VGoDAdBSnMCdxSc1b+m7w== X-UI-Out-Filterresults: notjunk:1;V03:K0:jDusWeSOcXQ=:HNl/uzvU22Od+foB943ZuM bRZPm6c8NqwlPXLv2L0K/Ta5oBUV2TSeP9ag3uktWD6DPPh5FveM2lp38Cnm9KPDjTiOFlYPA TNLo6GF7tQ1fZ9vRgl1gUHUio6tWvzkFab7OwKti/G5ulX1Cgu3r1ZD3B2edoNnfUH0LvOtdF N87O56ny4EMMv0MejpSzrCi9yEHN2TUlnuznAg7Tl1ddb9t8nQu8KwFwyXqmr6WoF/Wo+a3Ea eT1Qjq6trdQruEfaqtNnMDeJpsjm8RxxLCwAqL39vnA8r4hWci79OCi0vdw1ARqlzYqUwiGxX wW7+hVoXhxkha91VQnSC9MuriTuKHruNjMU2mVpc7gLAi6+GyczQmPD9bRcAIaAnX2nZ0BjY8 5Of9zbWs7DkP2mZzFiF96Tqz4iafzUqql2JFI7Uvr32HN5KrDYyTKaWg3qN7xp4uxOPiV5xRh 8lItM1BQs6T4ub4zicAusUAXoEUdH6IgztE5aUxr2ohJxlM/IiXtFiSRvafd7vChnqo8SgFdF o0+1QVrLepEh0MEodjDLFk+gew5N4gogDBScMw+IW1CiLQ3bN/D5kQJ2JnfhDkHqp4C9UgWSz Z6K06W20kX/exzcFxCxbQ/NtJatvCBgPuCgsEzN9P5wvE50UUgzROqllUi0Vs1gSEewhhBJMU f6StH+p9FasR7hP8vIo5VSb+cDm4VyyRzJG8TKvsOeAF3vTUaDVanAg+I0ubDQGwU9mdk/gUT j4bsI8YDtFl3FgUkcs0RngviFnhyXcALglrFii8wqKTWLAXExNvhAgtMyaG6g0iqkpu14rHDO 7tHmS0aJKKLKEMSuNnTMStyoeR7cx4oWyL9nZK7TCqHousz1bQl4ZE9kbSJhdCem93k0hNmNo xDzvEJt4jM8OVIFtfocv5KlOi0yM7HQnD4UzdfMXoCK67MLuSAiWuzkGbBG8yIzS+s3cbxdDo HplHOVFRX1F4X0AwmhqDcGjdtwAb79IMgJJ5esp1dXQ+hHSiG50vGfAzfjjsAga29jfs723gv 4kRHuNKMQIjXuqqlgptZZoq9bjntdqiFSr7vwaxBfu+9RomUZn5+zMlDQEWcibsqqnwBJhJ3K vTzkdith1vcD0ZJa84EwZ8Gpzb0xzAh6WVauuSise4i/hlKEjO0KjIgxMyhYqiDUoScVnfuvn 6l062zYRPobItEVG3O30siuyvrjlmmTprd6zu1dlwHDzYKcFVl9Wp9GorezH2qDpV6mFspC7C ullT4efdnRDxJcPu2HAYhmdecpNRoteejdTbX+g== Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Considering x86-64 fenv.s to C On Thu, Jan 16, 2020 at 03:30:03PM +1100, Damian McGuckin wrote: > > I was just looking at fenv.s in x86-64 with a view to doing this as C-co= de > with some __asm__. I have limited experience with playing with this stuf= f in > an SSE-only environment, i.e. no 80-bit floats. Before I attempt anythi= ng, > I need to expand my knowledge. > > My observations on > > musl-1.1.24/src/fenv/x86_64/fenv.s > > * feclearexcept > > considers both the X87 status word and the SSE MXCSR > > * feraiseexcept > > ignores the X87 status word and considers only the SSE MXCSR > > * fetesteexcept > > considers both the X87 status word and the SSE MXCSR > > * fesetround > > considers both the X87 control word and the SSE MXCSR > > * fegetround > > ignores the X87 control word and considers only the SSE MXCSR > > Why is the X87 component of the FPU control/status sometimes ignored and > sometimes not? > feraiseexcept() is merely supposed to set a flag in the fenv such that fetestexcept() can pick it up. Therefore it is sufficient to set the flag in either the X87 SW or the MXCSR, and the MXCSR is nicer to access. fegetround() has to determine rounding mode. Since no conformant code can set the rounding modes in X87 and SSE differently from each other, it is sufficient to read it from either source, and again, the MXCSR is nicer to access. > Does the X87 control or status bits automatically flow through to the > equivalent stuff in the SSE or vica-versa? > No, the CPU treats X87 and SSE as separate. That's why fetestexcept() has to calculate the bitwise OR of the two sources. > I assume that 'fwait' is irrelevant and unnecessary, even if one is usin= g > the x87 FPU? > Yes, fwait was last relevant on the 386, when an external 387 (was there a 487?) was actually a possibility, but ever since the 486DX, the FPU has been moved into the processor. Therefore FPU instructions are now synchronous to program execution, and a synchronization instruction is superfluous. Doesn't hurt, either, it's basically a NOP now. A NOP that can generate #NM under some circumstances, but it doesn't change anything. > Regards - Damian > Ciao, Markus