Path: utzoo!censor!comspec!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!ukma!wuarchive!sdd.hp.com!spool.mu.edu!uwm.edu!bionet!agate!shelby!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott
From: scott@erick.gac.edu (Scott Hess)
Newsgroups: comp.sys.next
Subject: Re: 68040 Math / Why so much system time?
Message-ID: <SCOTT.91Feb14212146@erick.gac.edu>
Date: 15 Feb 91 05:21:46 GMT
References: <1991Feb14.160749.19048@batcomputer.tn.cornell.edu> <702@chiton.ucsd.edu>
Distribution: na
Organization: Gustavus Adolphus College
Lines: 23
Nntp-Posting-Host: erick.gac.edu
In-reply-to: cdl@chiton.ucsd.edu's message of 14 Feb 91 17:54:39 GMTLines: 23

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
<I still speak for nobody>
"Tried anarchy, once.  Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."