Path: utzoo!bnr-vpa!bnr-fos!bnr-public!schow
From: schow@bnr-public.uucp (Stanley Chow)
Newsgroups: comp.arch
Subject: RISC is NOT micro-code (was Re: Compiling - RISC vs. CISC
Message-ID: <753@bnr-fos.UUCP>
Date: 16 Jul 89 06:02:08 GMT
References: <28471@ames.arc.nasa.gov> <200@dg.dg.com> <12233@pur-ee.UUCP>
Sender: news@bnr-fos.UUCP
Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 73
Summary:
Followup-To:
Keywords:

In article <12233@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>
>Let's assume that the RISC and CISC machines under consideration are
>identical except for instruction encoding; the CISC being microcoded and
>each RISC instruction corresponding to one micro instruction.

This has been stated many times in the RISC vs CISC debates. Usually,
the argument is that RISC opcodes running in I-Cache is the equavilent
of micro-code in a CISC machine. 

This argument is wrong for the following reasons:

  1) CISC machines do not have to be micro-coded. It just happens that
     a majority of the CISC CPU's are micro-coded. Please remeber that
     VAX is just one example of CISC. There are many other examples of
     CISC that are totally unlike VAX. If you are arguing against the
     VAX, then say so. Arguing against CISC means you think the CISC
     concept has some *inherent* flaw that you are exposing.

  2) The typical RISC instruction is far from equal to a typical
     micro-code instrcution. Almost any interesting micro-coded CPU
     will have micro-word that is much wider than 32 bits with much
     parallel operations going on. In fact, the whole premise of RISC
     gurantees that a RISC instruction will be *less* than a micro-word.

  3) Even if a sequence of RISC instructions correspond to a sequence
     of micro-code, the effects are still not the same. Usually, a
     micro-coded instruction is atomic (or can be easily made to be).
     Most RISC CPU's require very special fudging to achive fine
     grain atomicity.


>
>CISC compilers tend to pack as many operations together in single
>instructions as they possibly can, but this implies a certain amount of
>redundancy because the complex instructions represent general case sequences
>of micro instructions.  Initially, there will be several RISC instructions
>for each of the CISC instructions, perhaps 3:1.  However, many of them will
>be optimized away.
>

  4) RISC has more opportunaty for optimizations (I will leave open
     the question of whether RISC *requires* optimization). This means
     the compiler is much harder to get right. Please note that I am
     not saying the current RISC compilers don't work. I am merely
     saying that if I have an obscure bug in my program, I would be
     more inclined to suspect a RISC compiler than a dumb CISC compiler.


>This is because the RISC compiler can recognize and remove redundancies in
>the CISC micro instruction sequences.  Generally, RISC implies more available
>expressions, which makes value propagation and common subexpression
>elimination more productive.  Taking arbitrary basic blocks of RISC code and
>doing rather simple analysis, we have often found that only about 1/4 of the
>operations remain after optimization...  this is a very unlikely scenario
>for CISC operations.

The question is, What make it possible to throw away the 3/4? The possible
candidates:
  - Data-flow analysis
  - other optimizations
  - more registers
  - RISC instruction set

It is not clear to me that the RISC instruction set should get all the
credit just because the compiler is a RISC compiler.



Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
Me? Represent other people? Don't make them laugh so hard.