Date: Tue, 25 Apr 95 12:50:59 -0700 From: Bakul Shah <bakul@netcom.com> To: terry@cs.weber.edu (Terry Lambert) Cc: mycroft@ai.mit.edu (Charles M. Hannum), hackers@FreeBSD.org Subject: Re: benchmark hell.. Message-ID: <199504251951.MAA27349@netcom9.netcom.com> In-Reply-To: Your message of "Tue, 25 Apr 95 12:08:44 MDT." <9504251808.AA00479@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Part of my campaign to refuse to acknowledge factions in the BSD camp. > You'll also notice a studious lack of "we", "us", "they", "our", and > "them" when discussing relative issues. Nice to know there is atleast one other person who has his head in the sand (err.. feels the same way) as I do in this regard. No smiley though. > The idea here is that by default, processes are assumed to not use the > FPU, and thus by default the FPU trap results in code fixup rather than > FPU operations. Thus it does not matter which FPU operation is used > first. Isn't it easier to just assume that everyone may _eventually_ use FP and simply initialize the FP state on exec? If they never use FP there is no loss. One time initialization hit is not worth worrying about. There are no FPU operations involved (you just copy the initial state from somewhere and set the `stale' bit). Charles writes: > (With a slight kluge, it may be possible to combine this with the > check for whether you're using the emulator or not, and eliminate the > extra bit altogether. I'll have to try this.) This can even be considered a `cleaner" solution! When someone else is using the FPU, _you_ don't have it! So your choices are to either take it away from this someone else or emulate!! Emulation may even be cheaper than save/restore of FPU state for some simple FP operation (once or twice)! Though, probably not worth microoptimizing like this. I will pass on the page protection discussion :-) --bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504251951.MAA27349>