Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!cornell!batcomputer!pyramid!prls!mips!earl
From: earl@mips.UUCP
Newsgroups: comp.arch
Subject: Re: What should be in hardware but isn't
Message-ID: <705@gumby.UUCP>
Date: Thu, 24-Sep-87 15:28:02 EDT
Article-I.D.: gumby.705
Posted: Thu Sep 24 15:28:02 1987
Date-Received: Sat, 26-Sep-87 14:07:51 EDT
References: <581@l.cc.purdue.edu> <8646@utzoo.UUCP>
Lines: 32

In article <8646@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes:
> Actually, there is one fairly good argument for putting the transcendentals
> in hardware, to wit making a high-quality implementation available cheaply.
> The transcendentals in (say) the 68881 are *better* than anything you will
> come up with in software without large amounts of work.  You can buy a 68881
> for far less than it would cost you to commission or license equivalent code.

The 68881 transcendentals are not implemented in hardware; they are
implemented in microcode.  I believe the extra 0.5-1.5ulp of accuracy
of the 68881 is due to the use of extended precision calculations, not
to either hardware or algorithm (simple rational approximations are
very accurate too when evaluated in extended precision).  This is
likely one reason why the numerical analysts put extended precision
in the IEEE standard.

Usually when someone says "X should be in hardware", it's usually
because they haven't thought very much about how to solve the problem.
Usually the easiest way to solve a problem without thinking about it
is to say "someone else should do it".  In this case "the hardware
designer should solve it".

If an extra half bit of accuracy for transcendentals is important (I'm
not sure it is), then the right way to accomplish this is to add IEEE
extended precision hardware, not transcendental instructions.  In some
ways, this is the RISC approach: when someone says "I need X to do Y",
first ignore X, and then figure out the right way to provide
general-purpose building blocks to accomplish Y.

A final note: implementing transcendentals in 68881 microcode did
nothing to make them fast.  The cycle counts for sin, cos, tan, atan,
log, exp, etc. average about 3.5 longer for 68881 instructions than
for MIPS R2000 libm subroutines.