Re: Compiler complexity (was: VAX Always Uses Fewer Instructions)

My $0.02 worth:


In article <1117@ima.ISC.COM> peterd@june.cs.washington.edu (Peter Damron) writes:
>In article <20338@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes:
>> This discussion brings up a question about the actual use of CISC
>> instructions. It seems that RISC vs. CISC is probably about a draw
>> for raw compute speed of special coded sequences.


This isn't clear at all, although there have been several articles
attempting to clarify the relative speeds of the two architecture styles.


>> [more questions]
>> J. Giles
>> Los Alamos
>
> [Peter's response is correct]
>
>Peter Damron
>Department of Computer Science
>University of Washington
>peterd@june.cs.washington.edu
>[My impression is that taking advantage of complicated instructions often
>adds ugly irregularities to an otherwise clean register model.
> [essentially correct examples]
>As the RISC crowd points out, these
>complicated instructions often end up being slower than the equivalent
>operation synthesized out of simpler ops,


A slight correction needs to be made here: there is only one instance
that I know of where a complex instruction on a CISC architecture turned
out to run more slowly than the same operation coded with simpler
instructions ON THE SAME MACHINE. I believe the instruction was one
of the CALL instructions in an early version of the microcode for one
of the smaller VAXen, but I'm not real sure. The net result was that
DEC fixed the microcode so the performance of the instruction was improved.
[As dmr noted in his recent comp.arch note, it was the 780's calling
instructions.]


A more correct statement of what the RISC crowd is pointing out is captured
in the following question:


What is the cost of the additional hardware/microcode necessary
to support complex instructions?


It is almost never the case (although it does sometimes happen) that an
instruction can be added to an existing CPU instruction set without
impacting the design of the hardware. In general, such an enhancement
requires more control lines, more microcode, and rarely it may require a
new function to the ALU. The question is then: how much more slowly does
the hardware run as a whole due to the addition of this additional
hardware? Stated another way: If you had spent as much time on making a
small instruction set run very fast as you spent making a large instruction
set run acceptably fast, how much faster would the majority of the programs
run?


>particularly if some compile-time
>optimization is possible, so the only gain is in instruction density. -John]


In my compiler-oriented opinion, this comment captures the true winnings
from RISCs. Compile-time optimization means throwing away as much
generality as you can while preserving the semantics of the operation
IN CONTEXT. Since simple operations run very fast on RISCs, and since the
majority of instructions emitted by a compiler (any compiler) are simple
instructions anyway, and since streams of simple instructions are easier to
analyze and improve (although at the cost of having more of them to look
at), the net result is faster programs.


A. Dain Samples, UC Berkeley, samples@renoir.berkeley.edu, 642-9542, 785-5644


--

Return to the comp.compilers page.
Search the comp.compilers archives again.