Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!uw-beaver!ubc-cs!alberta!alberta!edson!news From: keen@ee.ualberta.ca (Jeff '876393' Keen) Newsgroups: comp.sys.next Subject: Re: 68040 Math / Why so much system time? Message-ID: <1991Feb15.045235.5984@ee.ualberta.ca> Date: 15 Feb 91 04:52:35 GMT References: <1991Feb14.160749.19048@batcomputer.tn.cornell.edu> <702@chiton.ucsd.edu> Sender: news@ee.ualberta.ca Distribution: na Organization: University of Alberta Electrical Engineering Lines: 41 In article scott@erick.gac.edu (Scott Hess) writes: >In article <702@chiton.ucsd.edu> cdl@chiton.ucsd.edu (Carl Lowenstein) writes: > One hopes that eventually libm.a will be re-written to not call > the built-in transcendentals of the 68882, computing transcendental > functions using only the floating point instructions native to the > 68040, and thus avoiding the exception traps. > >Hmm. That is a very good idea. Using shared libraries, NeXT could >presumably fix this up so that it would work under either the '030 >or the '040 by simply (yes, that is "simply" :-) using a different >shared library depending on the processor on the machine. > >I would recommend just that. Actually changing libm.a without such >a scheme would more than likely break on an '030 machine, which is >something none of us want. Well, I guess it would just run slooowwww. > >Later, >-- >scott hess scott@gac.edu >Independent NeXT Developer GAC Undergrad > >"Tried anarchy, once. Found it had too many constraints . . ." >"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by >Richard Simmons . . ." No. That is not a good idea. It may seem like one but it is that way for a reason. This is the same reason it is like this on any of the 680x0 chips. Any instruction that is legal but not implemented causes a trap to a vector. If other hardware is designed to implement these features (like the 68882) the trap can be used to hand off the instruction to the extra hardware. This speeds up the hole affair without a change in any software. Anyway the 68040 executes the floating point faster, so the minimal overhead in the trap wouldn't change the time much. This is based on my personal knowledge of the 68040, if I had a spec sheet handy I could confirm this, but I don't so I won't. -- ----------------------------------------------------- Jeff Keen University of Alberta keen@bode@alberta -----------------------------------------------------