Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: VAX polyd instruction
Message-ID: <5100026@ccvaxa>
Date: Sat, 8-Mar-86 22:29:00 EST
Article-I.D.: ccvaxa.5100026
Posted: Sat Mar  8 22:29:00 1986
Date-Received: Wed, 12-Mar-86 02:11:28 EST
References: <759@harvard.UUCP>
Lines: 27
Nf-ID: #R:harvard.UUCP:759:ccvaxa:5100026:000:1706
Nf-From: ccvaxa.UUCP!aglew    Mar  8 21:29:00 1986


This RISC type is not upset at implementing SIN as a "primitive"
instruction. True, it pretty much has to be microcoded, but it is
an example of a good microcoded instruction - one that will cook
around in your floating point unit for a long time, and not require
lots of memory accesses (see my earlier note about RISCs and coprocessors).

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). (2) it must be a reasonably good SIN, so that the library functions
that use it don't have to go through contortions to determine if it's going
to provide an accurate result or not. Most importantly, (3) there should not
be a more important potential use of the circuitry and delays that SIN will
add to the chip. Eg. if SIN adds one level of logic, slowing down all 
instructions in the pipeline by, say, 10%, and SINs take up less than 10%
of execution time on your machine without the SIN, then throw the SIN out!
This type of judgement can only be done with statistics and knowledge of how
your users use your machine.

Let me qualify that: if SIN takes up less than 10% of the time, but the
applications that use SIN are the applications and benchmarks that most 
influence your customers to buy your machine, fine, put SIN in. You don't 
build fast computers for the sake of building them, you build them to sell
them. But watch out!: that comes close to selling your customer short, so
if he finally determines that what he wanted was fast computers, not just
fast benchmarks, he may not come back to you for his next machine.