Date: Sun, 19 Jan 2020 11:42:07 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: Considering x86-64 fenv.s to C * Damian McGuckin <damianm@....com.au> [2020-01-19 20:07:56 +1100]: > On Fri, 17 Jan 2020, Rich Felker wrote: > > > > x86_64 > > > > > > * In assembler > > > > > > * Why does 'feclearexcept' disrespect the flags by clearing ALL x86 bits? > > > > As you said above, updating x87 status register is expensive because > > the only way to write it is to read-modify-write the whole fenv. But > > since we know on x86_64 we have sse registers, we can just move all > > the flags to the sse register, then use fnclex to clear the x87 one > > inexpensively, and the effective set of raised flags remains the same. > > I am worried about the lack of consistency. > > What if something that is only using (say) 80-bit floating arithmetic comes > back looking for a raised exception in the x87 status register & > MUSL has moved effectively moved it to the mxcsr. only musl internally has to be cosistent, which it is. if anything else looks at fpu status it must look at both x87 and sse status otherwise it will be wrong no matter what musl does (fp operations are outside the control of musl and whoever else tries to look at fpu status) but i think if something looks at fpu status behind the libc it's already wrong: libc can implement fe* however it wants to as long as the behavior follows the language semantics, so internal hw registers are meaningless as soon as a libc call is made. iirc gcc can emit software float code on x86 that uses the x87 status register to record the soft float fenv status, so those bits can change even if there was no hard float instruction, i.e. the flags make sense on the c language level but not on the hw level, if you mix those two levels you are in trouble.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.