Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!oakhill!davet
From: davet@oakhill.UUCP (David Trissel)
Newsgroups: comp.arch
Subject: Re: Compiling - RISC vs. CISC
Message-ID: <2190@oakhill.UUCP>
Date: 8 Jul 89 08:52:54 GMT
References: <13976@lanl.gov>
Reply-To: davet@oakhill.UUCP (David Trissel)
Organization: Motorola Inc., Austin Tx.
Lines: 93

In article <13976@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>Every once in a while, someone in this newsgroup makes the claim
>that RISC trades off hardware complexity for compiler complexity.
>This is simply _NOT_ true.  It is always _easier_ to write a compiler
>for a RISC machine than for a CISC machine.

False. My group has produced essentially the same compiler for both CISC 
(68K family) and RISC (88K family) and we've found the various tradeoffs
cancel each other out. The amount of work is virtually the same. The
code produced by both compilers is comparable.

>For a RISC machine, the only hard part of the "back end" is register
>allocation.  

What about the required pairing of registers for double wide operations such as
floating-point or shifting? That means the compiler has added complexity in 
its register allocation scheme. Never does the 68K architecture require paired
registers. What about the lack of a 32-bit effective address? This forces some 
RISC systems to have to resort to Intel segment-like (UGH!!) approaches to 
support access to the program's common data base. Some RISCS don't even have 
divide or multiply. (The 88K does have them.)

For every CISC compiler hassle you come up with I'll give you a RISC compiler 
hassle. For every RISC compiler hassle I'll give you a CISC compiler hassle.

>Instruction selection is fairly simple since there is
>generally only one way the perform each intermediate code operation.

This is a strange statement. Since in general terms CISC instruction sets are 
supersets of RISC models then why are the "extra" available CISC 
instructions mandated to be used by a CISC compiler? Indeed, one of the
arguments for RISC is the elimination of "unused" instructions from the
instruction set. Although this may bring up important architectural differences
between RISC and CISC it has no bearing on the complexity of a compiler.

>On a pipelined machine, code ordering comes into play (at least if
>you want optimized code).  This compilcates matters, since a different
>code ordering makes different register allocation constraints.
>For this reason, optimizing can be difficult, even on a RISC machine.

But as CISC implementations become more advanced the applicability of code
reordering is starting to surface there as well.

>On a CISC machine, instruction selection can be a real problem.  This
>is because there are generally several instruction sequences possible
>to implement each operation.  

I presume what you are driving at is that a CISC may have a shorter more 
complex instruction sequence available to it than a RISC for a given piece of 
code.  Point one is that the CISC compiler does not have to generate the more
complex sequence since it can still produce the degenerate case. Point two
is that the CISC compiler has the option of improving the instruction stream
while the RISC implementation has to wait for a future more advanced hardware
implementation to come along which can support something like simultaneous 
instruction execution.

As a case in point consider the somewhat common C expression *p++. The 68K
family could issue the standard:

   mov.l  (%an),%dn
   add.l  &4,%an

or the faster

   mov.l  (%an)+,%dn

The 68K requires a routine in the compiler peephole optimizer to "discover" 
and implement this optimization. But the result is a single 16-bit instruction
which (I think) executes in a single clock on the MC68040.

>Instruction selection obviously
>effects the register allocation phase (and the code ordering phase).  

True for both RISC and CISC. No difference.

>To make matters worse, instruction selection is context sensitive.
>This means that different code ordering during optimization could
>invalidate the instruction selection choice (or, at least make the
>selected instructions sub-optimal).

True for both RISC and CISC. No difference.

>There may indeed be a trade off between RISC and CISC.  But this
>trade off is certainly _not_ in the complexity of the compiler.

Correct.

>In fact, as shown above, the circumstance is quite the opposite.

This is counter-indicated above. Perhaps you have some concrete examples
in mind to show otherwise.

 -- Dave Trissel  Motorola Austin