Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!mit-eddie!godot!harvard!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.arch
Subject: Re: Re: RISC vs VAX
Message-ID: <270@rlgvax.UUCP>
Date: Fri, 30-Nov-84 03:29:14 EST
Article-I.D.: rlgvax.270
Posted: Fri Nov 30 03:29:14 1984
Date-Received: Sun, 2-Dec-84 05:50:10 EST
References: <1839@inmet.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 75

> (1) I said that RISCs are not suited for floating point/matrix multiplication
>     because: (a) attaching a floating point coprocessor to a RISC perverts
>     the very idea of a reduced instruction set; and (b) the original question
>     asked if a RISC could be produced in the same class as a VAX.  No RISC
>     can perform every function of a 780 faster than a 780 because there are
>     tradeoffs made when you give up instruction set complexity for speed.
>     Usually floating point stuff is the first to go -- except when you make
>     a purely floating-point processor, in which case everything has been
>     given up.  You can't have your floating point cake and eat it too.

Anybody have any data on how a "strict RISC" (i.e., one cycle per instruction,
which rules out multiply unless you have a parallel multiplier and rules
out divide unless somebody has a non-iterative divide algorithm) does on
jobs requiring a lot of multiplies and divides (which it has to do with
library routines)?  If it can do them as well as, say, an 11/780, it might be
able to do software floating point as well also.  Basically, think of RISC
instructions as vertical microcode; if you can do it fast with vertical
microcode, you can do it fast on a RISC as long as you can avoid going
to memory for the instructions every time.

Also, attaching a floating point coprocessor doesn't "pervert the very idea
of a reduced instruction set".  If you can't do FP fast on a RISC, there's
no need to go to instruction set complexity except for the floating-point
instructions.  A RISC with an FP chip might still be faster than a
(more expensive, in cost or chip real-estate or whatever) CISC.  I believe
a lot of the reason for a RISC is that in non-number-crunching applications
a lot of the cycles go to "bureaucratic overhead" (moving things from memory/
registers into other memory/registers, testing things, etc.) and that a RISC
may be able to deal with that as well as or better than a CISC.  Number-
crunching may have a different character (although I remember a study by
Knuth of FORTRAN programs that found that a surprisingly large number of
lines were exactly that kind of "bureaucratic overhead" - "j = j + 1" counts
as overhead if the only purpose "j" serves is to point to an element in an
array full of the numbers you're crunching); if it does, maybe a "different
horses for different courses" approach would be more cost-effective.

> (2) Yes, an ACIA and a VAX have different cycle times.  So do a washing
>     machine and an ECL flip-flop.  But if you build a fancy interface to
>     the ECL flip-flops, the washing machine still won't be able to talk
>     to them.  Having a nice DZ-11 multiplexor on a VAx is great -- it provides
>     intelligent communications processing, so the VAX doesn't burn cycles
>     doing low-level ACIA handshaking.  Now how could a RISC talk to a DZ?
>     Letting them share a memory space might be the best thing, but gee,
>     then you might need another processor to arbitrate memory accesses, and
>     then it starts to look like plugging a RISC into a VAX again.

What?  Why couldn't you plug a DZ (which, by the way, hardly provides
"intelligent communications processing" in the conventional sense of the
word) to a RISC?  Are you worried about the DZ not being able to do a
bus cycle in a reasonable amount of time, and tying the machine up twiddling
its thumbs waiting for the DZ to respond so it can finish the "move" instruction
that's stuffing the character into the DZ's output buffer register?
Presumably you can build a bus interface chip that's as fast as the RISC,
and if your bus is fast enough it won't tie the RISC up for a long time
(if it isn't fast enough, it'll tie up any fast machine up too long, not
just a RISC).  Equating a DZ and a bus interface to a VAX-11 in complexity
is bogus; the UBA on a VAX may be big, but then it does a hell of a lot
more than just act as a bus interface, given its multiple data paths, and
maps, and so forth and so on.

>     Comparing a RISC to a VAX in terms of performance, when the
>     RISC has two or three half- or quarter-VAXen doing its i/o, is cheating.

Who says it requires a half- or quarter-VAX to do the I/O for a RISC?

>     Hey, my Toyota can outrace the space shuttle when you strap two solid
>     rocket boosters to it.

Not a bad analogy; if your goal is met better by the Toyota+rocket boosters
than by the space shuttle, why not go with it?  If you're trying to break
the land speed record, you build a land speed record car, not a jet plane
with detachable wings and landing gear that can handle 700+ MPH.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy