Date: Mon, 6 Oct 1997 19:16:05 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dtc@merlin.ee.swin.oz.au (Douglas Thomas Crosher) Cc: tlambert@primenet.com, freebsd-current@freebsd.org Subject: Re: xlock: caught signal 8 while running galaxy mode. Message-ID: <199710061916.MAA17524@usr04.primenet.com> In-Reply-To: <199710061136.VAA08615@merlin.ee.swin.oz.au> from "Douglas Thomas Crosher" at Oct 6, 97 09:36:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Floating point switching is lazy-bound. > ... > > 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. > > There would be no additional overhead in passing the FPU status word > as the signal code on a SIGFPE. If the application needs to > save/restore the FPU state it can do so, other applications avoid the > overhead. I agree with your sigcontext argument, for what that's worth. That's not really at issue; I can't see how anyone could disagree with it. But standing down to that level from the original posting about the "galaxy" screen saver is not really an option. The problem, which is what's also being discussed, is in knowing whether or not a given program will, at any point in the current quantum, make an FPU call. Short of flagging the object in the complier if FPU instructions are generated, and then propagating the flag to the binary from the objects at link time, there's no way to know this for sure, short of either assuming *all* binaries do, and taking the FPU hit on all context switches, or trapping the first instruction reference. I think we can agree from previous arguments that simply masking the exceptions so that they aren't seen on the lazy reporting used by the FPU to maintain low latency is the wrong thing to do. 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?199710061916.MAA17524>