dgh%dgh@Sun.COM (David Hough) (02/06/88)
I just received a copy of this manual, ISBN 0-13-566936-7,
copyright by Motorola but published by Prentice Hall.
The 68882, in case you haven't heard, is a user-mode compatible
higher-performance version of the 68881's used in Macintosh II's
and some models of Sun-3's, PC-RT's, Apollos, etc..
Like the MC68020 manual, being published commercially may mean that
it will be obtainable
in technical bookstores rather than by begging a Motorola sales
office. At last there will be an answer for Sun's customers
that I've told to read a 68881 manual without telling them how
to obtain it. I've heard that Computer Literacy sold the
old manual so they might have the new one soon.
CISC enthusiasts should compare the 68881 instruction set to
anything similar they may have been using to see the difference a
clean orthogonal instruction set can make.
RISC enthusiasts don't care about on-board transcendentals because,
by their own admission, they are smart enough to code them faster
using a smaller instruction set. They would
be well advised, in general, not to be too pleased with their results
until they are reasonably close to the 68881's in accuracy.
From a practical point of view, most chip vendors probably would
not be smart enough to give away the software elementary transcendental function
implementations for their chips. They'd try to make money by selling
the code which hardly anybody would buy (why not just take the stuff that
comes "free" with System V or 4.2?) and the result would
be that their customers, the system integrators, would produce systems
with inaccurate transcendental functions that aren't much faster than
the 68881's.
If the rest of the system is high enough performance then you can certainly
do better than a 68881 or any coprocessor. It's interesting to consider
how a monster chip that integrated CPU and FPU should be organized:
would you even want separate integer and floating point data paths and registers?
The MC68881 is the best existing hardware implementation of IEEE arithmetic
from the standpoint of completeness and correctness, except for
some minor complaints:
transcendental functions are not monotonic in extended precision,
log2(x) and 2**x aren't exact in some places they could be,
there are no fmove-out instructions that round the source
f register to the stored value
not all the information that a user trap handler could exploit
is available in user mode
Transcendental functions
are guided by the spirit rather than the specification of the IEEE
standard, anyway, and most other hardware implementations don't come close.
I don't know whether or not to be surprised, but the page layout
produced by Prentice Hall is
not as aesthetically pleasing as that of the 68881 manual published by
Motorola.
I regret if anybody sees this twice; it appears not to have made it out
the first time it was posted, but with USENET you never can be sure!
David Hough
ARPA: dhough@sun.com
UUCP: {ucbvax,decvax,allegra,decwrl,cbosgd,ihnp4,seismo}!sun!dhoughearl@mips.COM (Earl Killian) (02/08/88)
In article <41174@sun.uucp> dgh%dgh@Sun.COM (David Hough) writes:
From a practical point of view, most chip vendors probably would
not be smart enough to give away the software elementary
transcendental function implementations for their chips. They'd
try to make money by selling the code which hardly anybody would
buy (why not just take the stuff that comes "free" with System V or
4.2?) and the result would be that their customers, the system
integrators, would produce systems with inaccurate transcendental
functions that aren't much faster than the 68881's.
Why not take the stuff that comes "free" with 4.3 instead of ancient
4.2? The accuracy is quite good. Consider Zliu's test suite on
4.3bsd libm and the 68881:
NME = Negative Maximum Error observed in ULPs
PME = Positive Maximum Error observed in ULPs
NMC = Non-monotonicity count.
[ From , to ) N.M.E. P.M.E. NMC
4.3bsd libm:
SIN(X) ALL [ +0.0000000e+00, +1.5707960e+00) -0.6730 +1.0640 0
EXP(X) ALL [ -1.0371094e+00, +1.0087891e+00) -0.7630 +0.7720 0
EXPM1(X) ALL [ -1.0371094e+00, +1.0087891e+00) -0.8070 +0.8630 0
LOG1P(X) ALL [ -2.9289320e-01, +4.1421360e-01) -0.8430 +0.8110 0
ATAN(X) ALL [ -6.5536000e+04, +6.5536000e+04) -1.0610 +1.0680 0
LOG(X) ALL [ +7.0710680e-01, +1.2851563e+00) -0.8100 +0.8030 0
68881:
SIN(X) ALL [ +0.0000000e+00, +1.5707960e+00) -0.5500 +0.5540 0
EXP(X) ALL [ -1.0371094e+00, +1.0087891e+00) -0.5100 +0.5110 0
EXPM1(X) ALL [ -1.0371094e+00, +1.0087891e+00) -0.5560 +0.5550 0
LOG1P(X) ALL [ -2.9289320e-01, +4.1421360e-01) -0.5930 +0.5560 0
ATAN(X) ALL [ -6.5536000e+04, +6.5536000e+04) -0.5450 +0.5460 0
LOG(X) ALL [ +7.0710680e-01, +1.4142136e+00) -0.5930 +0.5610 0
What's more, because the 68881 is so slow, I'd guess that the 4.3 libm
is likely to be faster, given a decent implementation of add,
multiply, and divide.dgh%dgh@Sun.COM (David Hough) (02/09/88)
In article <1519@gumby.mips.COM>, earl@mips.COM (Earl Killian) quotes me: > >> From a practical point of view, most chip vendors probably would >> not be smart enough to give away the software elementary >> transcendental function implementations for their chips. They'd >> try to make money by selling the code which hardly anybody would >> buy (why not just take the stuff that comes "free" with System V or >> 4.2?) and the result would be that their customers, the system >> integrators, would produce systems with inaccurate transcendental >> functions that aren't much faster than the 68881's. > and then comments > Why not take the stuff that comes "free" with 4.3 instead of ancient > 4.2? The accuracy is quite good. Earl is right on the mark. I purposefully mentioned 4.2 rather than 4.3 BSD. However most of the companies that are still in the workstation market (including Sun) started out with 4.2 and added 4.3 extensions as time and energy allowed. Who knows how many are still using 4.2 libm? Basically we have junked much of the math library for our 2.0, 3.0, 3.2, and 4.0 releases, with substantial improvements each time. Most of 4.3BSD libm is in SunOS 3.2; SunOS 4.0 libm will go somewhat beyond 4.3BSD. > What's more, because the 68881 is so slow, I'd guess that the 4.3 libm > is likely to be faster, given a decent implementation of add, > multiply, and divide. The Sun-3 FPA and Sun-4, both based on Weitek 1164/5, are indeed quite a bit faster than the 68881. Interestingly enough, the Sun-3 FPA computes certain elementary transcendental functions about as fast or faster than Sun-4, mainly because the required constants are readily available in on-board registers rather than requiring fetching from memory. So I still consider it arguable whether on-board transcendentals are worthwhile in a high- performance system. David Hough ARPA: dhough@sun.com UUCP: {ucbvax,decvax,decwrl,seismo}!sun!dhough