Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!linus!philabs!cmcl2!harvard!seismo!utah-cs!utah-gr!thomas
From: thomas@utah-gr.UUCP (Spencer W. Thomas)
Newsgroups: net.arch
Subject: Re: VAX polyd instruction
Message-ID: <1706@utah-gr.UUCP>
Date: Thu, 13-Mar-86 08:59:22 EST
Article-I.D.: utah-gr.1706
Posted: Thu Mar 13 08:59:22 1986
Date-Received: Sun, 16-Mar-86 00:44:57 EST
References: <759@harvard.UUCP> <5100026@ccvaxa>
Reply-To: thomas@utah-gr.UUCP (Spencer W. Thomas)
Organization: University of Utah CS Dept
Lines: 21

In article <5100026@ccvaxa> aglew@ccvaxa.UUCP writes:
>
>But let me qualify this acceptance: (1) instruction SIN must be faster than
>I could do it in software. It must handle the special cases as well and as
>fast as I can do (there are different algorithms for different values 
>of SIN). 
Interesting note:  I was sitting in on an architecture course this
quarter (which, of course, automatically qualifies me to post to this
group :-).  We were discussing (I think) the Symbolics Lisp Machine
(3600).  It has a floating point accelerator you can buy.  If you don't
have it, floating point is done in software, of course.  Well, it turns
out that even if you do have it, the software (microcode?) floating
point routine is run in parallel.  Whichever one finishes first "wins".
Now, I can hear you ask "when would software EVER be faster than the
FPA".  The software has code to take care of some easy special cases
(e.g., multiplication by zero).  For these cases, it will finish before
the FPA, because it just grinds through the bits, no matter what the
input values.

-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)