Date: Tue, 8 Jan 2002 15:29:16 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Nate Williams <nate@yogotech.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, <arch@FreeBSD.ORG> Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <20020108150914.N3450-100000@gamplex.bde.org> In-Reply-To: <15418.17529.641960.608906@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jan 2002, Nate Williams wrote: > > > Also, forgive my ignorance, but why are we using fnsave instead of > > > fsave? From my reading of the x86 manuals, it would seem that there is > > > > Because we aren't broken. > > Go on.... See previous mail. > > This is only for 8086/8087 systems, to work around a bug in the 8086. > > See Morse, Isaaacson and Albert's _The 80386/387 Architechure_ p.150. > > The 8086 doesn't wait for the 8087 to become idle before before > > proceeding past an 8087 instruction. The synchronization must be done > > in software by putting a "wait" instruction before every 8087 instruction, > > even though this breaks correct operation of control instructions like > > fnsave (see below). The bug was fixed on the 80286/80287. > > So, all FPU's post 287 do not need the 'wait' instruction? In that > case, is fsave essentially the same operation as fnsave? All CPUs post 8086 do not need the `wait' instruction. Some software running on post-8086 CPUs might want to use it to trigger FPU exceptions at the right place (IIRC, using fnop for this is not as good since it is not a control instruction so using it clobbers the address of the last FPU instruction, in particular the address of the instruction that caused the exception if there was one). fsave is quite different from fnsave since it begins with a `wait' instruction. > > Manuals (up to at least the 486 one) also say that "wait" instruction > > is required _after_ FPU instructions if the memory written to by the > > FPU instruction is read by the CPU. E.g., the wait is required for > > "fnsave mem; movl mem,%eax", and "fistpl mem; movl mem,%eax" but not > > for "fnsave mem; frstor mem" or "fstpl mem; fldl mem". I've never > > seen this rule followed. > > The manual I read had something like this, hence the reason for using > fsave (vs. fnsave). fsave puts the wait in precisely the wrong place to affect this. > > The gcc maintainers knew about it and decided > > not to follow it long ago, since it would be a significant pessimization > > for normal FPU code. However, it would only be an insignificant > > pessimization after fnsave. > > So, you're saying that the manuals are wrong? Docs are always right :-). The programs depended on undefined behaviour. > > > Or, is there something else I'm missing? (The reason I ask is that the > > > JDK uses fsave to be 'safe', but maybe it's not buying us anything other > > > than warm fuzzies. :) > > > > This is negatively safe. fsave is just an abbreviation for "wait; fnsave". > > Using "wait" before an FP control instruction is usually wrong because > > it prevents the "no-wait" feature of FP control operations from working. > > It causes any unmasked exceptions to be signaled immediately. > > Isn't this a good thing, since if the currently executing thread has > encountered an exception, it will be signaled during the current > thread's context? No. It breaks instruction sequences like: fldz fld1 fdiv %st,%st(1) # 1.0 / 0.0, exception on this instruction # but no trap yet fnstsw %ax # no trap yet since this is control instruction fnclex # forget about exception; no trap at all since # we did only control instructions after the # one that cause the exception > > It is especially wrong for fnsave in context switches because it > > causes the signals in the context of the context switcher instead of > > in the context of the thread that caused the exception. > > Which signals are you refering to? The SIGFPE that you get for `wait'. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020108150914.N3450-100000>