From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] Considering x86-64 fenv.s to C
Date: Thu, 16 Jan 2020 16:11:03 +0100 [thread overview]
Message-ID: <20200116151103.GA2020@voyager> (raw)
In-Reply-To: <alpine.LRH.2.02.2001161525030.19959@key0.esi.com.au>
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-code
> with some __asm__. I have limited experience with playing with this stuff in
> an SSE-only environment, i.e. no 80-bit floats. Before I attempt anything,
> 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 using
> 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
next prev parent reply other threads:[~2020-01-16 15:11 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-16 4:30 Damian McGuckin
2020-01-16 15:11 ` Markus Wichmann [this message]
2020-01-16 16:14 ` Rich Felker
2020-01-16 18:56 ` Damian McGuckin
2020-01-16 19:33 ` Rich Felker
2020-01-16 21:31 ` Damian McGuckin
2020-01-17 3:36 ` Damian McGuckin
2020-01-17 3:48 ` Damian McGuckin
2020-01-17 3:53 ` David Edelsohn
2020-01-17 14:13 ` Rich Felker
2020-01-17 14:19 ` David Edelsohn
2020-01-17 14:53 ` Rich Felker
2020-01-18 4:45 ` Damian McGuckin
2020-01-18 5:29 ` Rich Felker
2020-01-19 8:50 ` Damian McGuckin
2020-01-19 9:07 ` Damian McGuckin
2020-01-19 10:42 ` Szabolcs Nagy
2020-01-19 12:25 ` Damian McGuckin
2020-01-20 5:32 ` Damian McGuckin
2020-01-20 17:38 ` Rich Felker
2020-01-20 21:11 ` [musl] Triggering Overflow (or Underflow) without triggering Inexact on i386 Damian McGuckin
2020-01-20 22:32 ` Szabolcs Nagy
2020-01-21 3:53 ` [musl] Considering x86-64 fenv.s to C Damian McGuckin
2020-01-21 4:22 ` Rich Felker
2020-01-21 4:46 ` Damian McGuckin
2020-01-21 7:26 ` Damian McGuckin
2020-01-17 16:41 ` Markus Wichmann
2020-01-18 1:15 ` Szabolcs Nagy
2020-01-18 5:03 ` Damian McGuckin
2020-01-18 5:37 ` Rich Felker
2020-01-18 9:40 ` Szabolcs Nagy
2020-01-24 0:42 ` Damian McGuckin
2020-01-24 1:11 ` Rich Felker
2020-01-24 4:13 ` Damian McGuckin
2020-01-24 4:55 ` Rich Felker
2020-01-24 6:08 ` Damian McGuckin
2020-01-24 13:44 ` Rich Felker
2020-01-24 14:45 ` Damian McGuckin
2020-01-24 23:59 ` Damian McGuckin
2020-01-25 0:11 ` Rich Felker
2020-01-26 3:28 ` Damian McGuckin
2020-01-26 3:28 ` Damian McGuckin
2020-01-26 3:30 ` Damian McGuckin
2020-01-26 3:32 ` Damian McGuckin
2020-01-26 5:25 ` Damian McGuckin
2020-01-27 3:32 ` Damian McGuckin
2020-01-27 5:39 ` Damian McGuckin
2020-02-02 0:47 ` Damian McGuckin
2020-02-03 0:54 ` Damian McGuckin
2020-02-03 2:09 ` Rich Felker
2020-02-03 2:12 ` Damian McGuckin
2020-02-22 20:17 ` Rich Felker
2020-02-22 20:53 ` Damian McGuckin
2020-02-23 5:41 ` Damian McGuckin
2020-02-23 6:25 ` Rich Felker
2020-02-23 8:35 ` Damian McGuckin
2020-02-07 21:25 ` Damian McGuckin
2020-02-07 21:38 ` Rich Felker
2020-02-07 23:53 ` Damian McGuckin
2020-02-09 5:04 ` Damian McGuckin
2020-01-24 7:10 ` Damian McGuckin
2020-01-18 5:04 ` Markus Wichmann
2020-02-03 14:16 [musl] PPC64(LE) support in musl requires ALTIVEC Romain Naour
2020-02-03 14:50 ` Rich Felker
2020-02-05 1:32 ` [musl] Considering x86-64 fenv.s to C Damian McGuckin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200116151103.GA2020@voyager \
--to=nullplan@gmx.net \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).