From owner-freebsd-arch Mon Jan 7 17: 0: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id D123D37B404 for ; Mon, 7 Jan 2002 16:59:54 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id RAA25986; Mon, 7 Jan 2002 17:59:42 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g080xc801738; Mon, 7 Jan 2002 17:59:38 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15418.17529.641960.608906@caddis.yogotech.com> Date: Mon, 7 Jan 2002 17:59:37 -0700 To: Bruce Evans Cc: Nate Williams , Daniel Eischen , Dan Eischen , Peter Wemm , Archie Cobbs , Alfred Perlstein , Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <20020108111521.D2910-100000@gamplex.bde.org> References: <15418.4935.657413.312252@caddis.yogotech.com> <20020108111521.D2910-100000@gamplex.bde.org> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > 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.... > > the possibility of getting bogus FPU results with fnsave (vs. fsave) > > since by using fsave, we give the FPU a chance to finish up the current > > FPU operations before we save the state? I could see where they might > > be a race where we might end up storing intermediate results of the FPU > > in some instances. > > 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? > 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). > 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? > > 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? > 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? > It normally works OK in > -current and RELENG_4 (but not in RELENG_3) only because it has no > significant effects (all exceptions are masked by default). Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message