🚀 go-pugleaf

In article <3562@odin.SGI.COM> pkr@maddog.sgi.com (Phil Ronzone) writes:
>In article <7826@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:

>>So, is it a wash? More-or-less, yes - if RISC designs stand still.
>>But they aren't. RISC is moving to ECL and GaAs, where transistors
>>are scarce. They are also moving to superscalar designs, where the
>>RISC/CISC difference is between incredible complexity and stupefying
>>complexity.

>I see that as the ONLY large advantage that RISC has. It simply has
>been able to reduce the design time.

"Simply" is the correct word, but not just applied to design time.
The "incredible complexity" vs. "stupefying complexity" also
aplies to the problem of generating code for the super-scalar
design.  A chip like the 860 is hard enough; if somebody builds a
a similar machine with complex addressing modes, etc... it'll
be really difficult to build a good compiler for.

Lindsay pointed out that RISC machines were a response to compilers that
only used the simple instructions.  I expect (don't know for sure) that the
compilers for 80x86's and 680x0's are still mostly using the simple
instructions.  Speed isn't the only reason for avoiding complex instruction;
you avoid them because they're difficult to generate, because they don't
do what you want in the first place, and because the intermediate
results aren't available for reuse.

For (an old, perhaps overworked) example:
Suppose I want to load a value from
memory and add it to a register.  On most CISC's I can do it in one
instruction.  On most RISC's, I have to use 2 instructions.
On the RISC machine, the value I loaded will still be in a register
where I can reuse it later.  Of course, we could also use 2 instructions
on the CISC.  How often does this case arise?  That depends on
your code and the strength of your optimizer.  The RISC bet (supported
by dynamic code measurements) is that it happens a lot.

So, no matter how fast the CISC people make that "add from memory"
instruction run, it won't matter much because it isn't used much.

Preston Briggs
preston@titan.rice.edu