Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!acornrc!rbbb
From: rbbb@acornrc.UUCP (David Chase)
Newsgroups: comp.arch
Subject: Re: RISC is a nasty no-no!
Message-ID: <641@acornrc.UUCP>
Date: 2 Mar 88 00:49:43 GMT
References: <179@wsccs.UUCP>
Organization: Acorn Research Centre, Palo Alto, CA
Lines: 49
Summary: Read before you flame, please

It seems that people out there have invented a new meaning for RISC.
You can read about the old meaning in (for example) "Reduced Instruction
Set Computers", an IEEE Tutorial by William Stallings.

Comments like 

> Please. We are discussing hardware, not software.

and 

>         I am all for RISC machines when reasonably implimented.  My idea of
> RISC is an instruction set that is sufficently small to allow the
> manufacturer
> to call it RISC and not get sued, but sufficiently varied to allow me to go
> off and have the assembler impliment enough macro's that my compiler thinks
> it's running on a 680x0.  ----Oh rats!  If I can't have that, at LEAST my
> portable C compiler should be.

demonstrate how misunderstood RISC is.  To quote from the above reference,

  A vital element in achieving high performance on a RISC system is an 
  optimizing compiler.

When you have a high-quality register allocator, instruction scheduler, loop
invariant code mover, strength reducer, and constant propagater 
implemented in assembler macros, let me know (I'm morbidly curious).  It may
be the case that these optimizations aren't common in C compilers, but so it
goes.  You are certainly free to learn about them and implement them in a
compiler and sell it to the world.

Understand also that (as has been noted by other posters) complaining about
the slowness of a rare operation is silly; RISC designers HAVE done 
instruction mix profiles, and try to make their compiler+machine combinations
fast for those mixes.  Of course, with a stupid compiler there will be a
lot more multiply operations.  That's why you can't exclude software from
this discussion.

On an unrelated note, the Acorn RISC Machine appears to do its shift-and-OP
instructions without overhead provided that the shift is constant (that is,
not obtained from a register).  A second pair of odd features (that I'm
sure will be the subject of furious discussion for the next week or so) is
(1) a SET-CC bit--if 0, then the condition code is left unmodified and (2)
a condition flag for every instruction (not just branches).  (The reference
for this is the A.R.M CPU Software Manual, Version 1.00.  Since it is over
two years old things have undoubtedly changed slightly.)  When you combine
all these you get very compact loops for (general) multiplies, byte-swapping,
and division (division is not as compact as the other two).

David Chase
Olivetti Research Center, Menlo Park