Date: Mon, 6 Oct 1997 01:20:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dtc@scrooge.ee.swin.oz.au (Douglas Thomas Crosher) Cc: freebsd-current@FreeBSD.ORG Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710060120.SAA02357@usr05.primenet.com> In-Reply-To: <199710041810.EAA00380@scrooge.ee.swin.oz.au> from "Douglas Thomas Crosher" at Oct 5, 97 04:10:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 1. Enabling and detecting specific exceptions. E.g. An overflow, > underflow, loss of precision etc. Not possible in FreeBSD. > > 2. Monitoring the accrued exceptions. Not reliable in FreeBSD as a > SIGFPE will clear these and gives the application no chance of > restoring them when doing the equivalent of a long jump. > > If freebsd isn't going to save the NPX state in the sigcontext then > perhaps it could pass the status word back to the application - see > PR4597. This would at least give the application a chance of doing the > right thing. Floating point switching is lazy-bound. That means that I can context switch between three programs, and if only one uses the FPU, I don't need to waste time context switching the FPU state. It also means that if I have 10 processes which use the FPU, I only need to waste context switching the FPU state on entry to a program that uses the FPU. This is a good thing, and it is why things are the way they are: most programs do not use the FPU, and should not have to incurr the overhead simply because some minority of programs *do* use the FPU. The problem here is that an exception, if any, is signalled on the instruction following the instruction which triggered the exception. This lets a program buzz along without a latency cycle on each FPU instruction, since the most common case will be that the programmer is smart enough to write code which will never throw an exception. Always optimize for the most common case. There are three fixes to the current dilemma: 1) Keep an "fpuprevproc". This is a hard thing to do in an SMP environment, but it can be done. 2) Mask the exceptions. If they don't happen, there's no problem. 3) Context switch the FPU registers for all processes, and then rememebr the exception reporting that is brought about by the FPU instructions to do the register dumps. Of these, I like #1 best, since it is the lowest overhead in the most common case. Always optimize for the most common case. This will also mean that you must set a trap on context switch from a program that uses the FPU. It will trap the first attempt to use an FPU instruction in a subsequent program. This is used for marking and for exit-marking so you can reset the trap. This will add a latency to the first instruction, since you must take the trap, set the flag, and execute the instruction that triggered the trap. You can "route around" this to a limited extent by unsetting the trap; this requires that you "remember" that you are an FPU using program between context switches, and reset the trap on exit, anyway. Much better to leave the trap set: you account for programs that sometimes use the FPU and sometimes don't. The final piece will be that, when you context switch between processors, the exception signalling is context switched as well. That means that I might take but not signal an exception yet, context switch, and schedule the process that should have gotten the exception to run on another CPU before an FPU process triggers the signal of an exception back to the original excepting process. Because of this, on SMP, you *must* cause the exception to be signalled at the time the context switch takes place. This means that you will probably want to trap initial FPU usage and use the trap to decide to try to trigger the exception (if any). The most likely implementation that will result from this (since it's the most trivial) will be to set a "process uses FPU" flag on first FPU reference, and if so, determine if there is a fault at context switch time if this flag has ever been set. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710060120.SAA02357>