Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site ucbcad.UUCP
Path: utzoo!linus!security!genrad!decvax!microsoft!uw-beaver!tektronix!ucbcad!ucbesvax.turner
From: ucbesvax.turner@ucbcad.UUCP
Newsgroups: net.arch
Subject: Re: Risc Over-blown - (nf)
Message-ID: <1124@ucbcad.UUCP>
Date: Sat, 17-Dec-83 06:55:47 EST
Article-I.D.: ucbcad.1124
Posted: Sat Dec 17 06:55:47 1983
Date-Received: Mon, 19-Dec-83 04:28:48 EST
Sender: notes@ucbcad.UUCP
Organization: UC Berkeley CAD Group
Lines: 30

#R:ncsu:-241700:ucbesvax:27900004:000:1405
ucbesvax!turner    Dec 17 03:19:00 1983

Not to quibble overmuch with Howard's defense of the RISC methodology
(hi howard!), but he neglects to mention that the HP "wonder chip"
outperforms RISC I by far in floating point computation.  The benchmarks
that showcase RISC I performance are all integer codes.

Much of the complexity of the HP chip springs from its implementation
of the IEEE floating-point standard.  The arithmetic algorithms are
not terribly involved, but they are carefully designed with a view
toward preserving accuracy, and representing odd cases (plus/minus
infinity/infinitesimal).  As we all know, program complexity is in
large part a function of boundary conditions--programs typically
spend a lot of time trying to decide whether or not to add 1 to
something.  (As do programmers, come to think of it :-)  Microcode
of this kind is not much different, I think.

A fair amount (~40%?) of the HP microcode is taken up by IEEE FP.  The
natural question is: if you put an IEEE FP implementation in RISC native
code in ROM on the RISC chip, and redesigned the timing to take advantage
of the proximity of this "floating point microcode", would you have
something faster than the HP chip?  Maybe not, but, for reasons given
previously, you'd probably have more chip-space to work with afterward.

As Howard points out, there are potential dissertations and gold in such
questions.
---
Michael Turner (ucbvax!ucbesvax.turner)