Date: Tue, 8 Jan 2002 11:01:42 -0700 From: Nate Williams <nate@yogotech.com> To: Bruce Evans <bde@zeta.org.au> Cc: Nate Williams <nate@yogotech.com>, 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: <15419.13318.535192.666599@caddis.yogotech.com> In-Reply-To: <20020108150914.N3450-100000@gamplex.bde.org> References: <15418.17529.641960.608906@caddis.yogotech.com> <20020108150914.N3450-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. So far I'm with you. > > > 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. This is don't completely understand, but see below. > > > 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'. So, when is SIGFPE going to be triggered above, since it appears to be masked by using fnstw vs. fstw. In other words, how do I actually make sure that I receive the exception/trapf for FP errors? Nate 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?15419.13318.535192.666599>