68K vs 286 on floats

Message-ID: <bnews.microsof.5537>
Newsgroups: net.micro.68k,net.micro
X-Path: utzoo!decvax!microsof!gordonl
From: microsof!gordonl
Date: Fri Feb 18 05:58:33 1983
Subject: 68K vs 286 on floats
Posted: Thu Feb 17 09:14:00 1983
Received: Fri Feb 18 05:58:33 1983

A recent article claims that the 68K can emulate floating the floating
point sequence:
	load
	multiply
	store
faster than the Intel 286 Floating point chip (80287, I think its called)
This is, of course, an interesting comparison.  First, the comparison
is invalid as the particular example is load/store intensive; something
a coprocessor will naturally do less well.  I'm sure the timings heavily
favor the chip in a "real world" example.  Further, John Gilmore was
comparing the 32-bit floating point on the SUN with an 80-bit IEEE
standard floating point chip!  Those that have studied the chip know
that theres a hell of a lot of work in supporing a IEEE standard
floating point unit.  There are several kinds of rounding, several kinds
of infinity control, etc.  I'm sure that the SUN package ignores these
things.

So long as we're going to compare apples and oranges I'd like to point
out that my Heath H8 is faster than the Sun system becase the H8 can
compliment a register faster than the 68K can.

Its easy for systems software hacks (such as myself) to say "well, who
cares about all that crazy floating point stuff?"  Unfortunately, an
important set of end-users of these machines are people who care
very very much.  The IEEE FP standard is not that complex because it
was "designed by comittee", its that complex because the users of FP
need those things.  I'm sure we wouldnt like it if a bunch of FP hacks
got together and speced out what an OS should look like and laughed at
us when we complained...

By the way, I thought that SUN was planning on marketing to scientific
users.  If thats so, they certainly have a wider package than the
32-bit version.  Its important to compare the speeds of the "full
strength" packages 'cause people who care about FP timings also
(usually) care about precision.  Can you fill us in, John?

	gordon letwin
	microsoft
	decvax!microsoft!gordonl

Message-ID: <bnews.sun.201>
Newsgroups: net.micro.68k
From: sun!gnu
Date: Mon Feb 21 20:16:10 1983
Subject: 68K vs 286 on floats
References: <bnews.ima.286>
Posted: Thu Feb 17 03:47:51 1983

Anyone who thinks the 286 (80287 co-processor really) is fast on floats
has not read the specs.  Some timings from published Intel documents:

	Load 64-bit	10 us
	Store 64-bit	21 us
	Add/Sub		14/18 us
	Mul 32-bit	19 us
	Mul 80-bit	27 us
	Div		39 us

While the chip can indeed multiply pretty fast, it takes it almost as long
to store the result in memory as it does to do the multiply!  And to load a
value, add another, and store the result takes 45 us -- our 68000 software
float is faster than that (tho: it is only operating on 32-bit floats).

I can't understand how it can take them 21 us to store 4 words in memory.

(Note, these timings are for 5MHz parts.  8MHz parts will be available
"later"...  I don't know if you can run a 5MHz 80287 with an 8MHz 80286, or
even if 8MHz 80286's are available, but of course the 8MHz is what all the
slanted comparison ads have been for.)

	John Gilmore, Sun Microsystems

Message-ID: <bnews.utzoo.2839>
Newsgroups: net.micro.68k
From: utzoo!henry
Date: Mon Feb 28 17:01:27 1983
Subject: Re: 68K vs 286 on floats 
Posted: Mon Feb 28 17:01:27 1983

No offense to John Gilmore and the other folks at Sun, but comparing
Sun's 32-bit software floating point to the IEEE-standard 8087/80287 is
really comparing a Piper Cub to a Concorde.  What are the error bounds
of the Sun package?  What is its roundoff algorithm, and why?  Under what
circumstances is it unsafe to use?  (Alas, considering my past experience
with software floating-point packages, a better question would probably
be "under what circumstances is it safe to use?".)  I don't doubt that
the folks who did it were competent -- certainly the Sun people that I
know are pretty good -- but designing floating-point arithmetic algorithms
is a job for a numerical-mathematics expert, not a systems programmer.
It really is too big and too hard a job for an amateur to do well.  If
somebody like (say) Kahan was numerical-mathematics consultant to the
project, and is satisfied with the result, then I'd be happy to use it.
Otherwise, I wouldn't trust the numbers coming out.  Sorry.

Actually, what I would like to see is a decent 68000 or 16032 system
(the Sun is reasonable) with an 80[2]87 on it for floating-point work.
The promised 68000 and 16032 floating-point auxiliaries are useful
things, but they don't have quite the same awe-inspiring capabilities
and specs as the Intel chips.  A lot of people have cursed the 8087
for being impossible to interface to anything but an 8086;  by the
sounds of things, the 80287 may be easier to deal with.

					Henry Spencer
					U of Toronto

Message-ID: <bnews.sun.209>
Newsgroups: net.micro.68k
From: sun!gnu
Date: Tue Mar  8 07:38:22 1983
Subject: Re: 68K vs 286 on floats
References: <bnews.utzoo.2839>
Posted: Mon Mar  7 21:23:32 1983

Henry Spencer of U.T. is right about the relative capabilities of 32-bit
software float and 64-bit (80-bit internally) IEEE float.  32-bit float is
not for serious float work.  It does OK for graphics, though.

By the way, anyone have a decent exponential routine for the 8087?  A friend
of mine is doing the float math routines for an APL on the IBM PC and
since the 8087 only does sorta exponential on a very limited domain,
his routine turns out longer and slower than he expects is possible.
The documentation claims the domain of the critical instruction is 0 to .5
whereas -.5 to +.5 would be reasonable -- if this is known to be a typo,
please let me know.  (What was this about Intel's "awe-inspiring" specs?
At least the 68881 will have a true exponential instruction -- when it arrives
in a year...)

	John Gilmore, Sun Microsystems