🚀 go-pugleaf

In article <753@bnr-fos.UUCP> schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) writes:
>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:
....

You missed my point.  I wasn't saying that people should or do design RISC
and CISC machines this way, but rather that this is a convenient and
reasonable assumption so that a more formal analysis could be made of the
possibility of RISC:CISC instruction counts being less than 1:1.

>  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.

Not me...  I'd be more inclined to suspect a bug in the NEWER compiler, be it
RISC or CISC.  However, if it's an optimizing CISC compiler, I'll bet it has
at least a few bugs even if it has been out for years.  Perhaps I'm too much
into the field of optimizing compilers, but from personal experience I have
seen *decent* CISC compilers nearly always be harder than those performing
similar optimizations for RISC...  it is just that the average RISC compiler
is expected to do more optimization than the average CISC compiler.

>>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.

The RISC instruction sets tend to naturally require intermediate results to
be placed in registers and this naturally yields more available expressions.
I'm not quoting gospel here, but the little compilers we've been doing often
manage to get rid of about 3/4 of the ops just doing things straight from
Aho & Ullman's "Principles of Compiler Design":

[1]	Value propagation (get values from where cheapest, remember what
	values appear where and which quantities are equivalent)
[2]	Constant folding (also uses value prop.:  A=5; B=A*A; would get
	coded as if it were A=5; B=25;)
[3]	Common subexpression elimination
[4]	Dead code elimination (get rid of dead stores, etc.)

By the way, my best guess is that a comparable CISC compiler would get rid of
perhaps 1/3 of the instructions.  But that hardly matters.  My point relies
only on the fact that if an entire CISC instruction can be eliminated, then
so can the sequence of RISC instructions which would implement it; whereas a
RISC instruction might be eliminated but the CISC instruction which would
incorporate it cannot be eliminated (because other parts of the CISC
instruction are needed).

I don't want to start another war, but we *never* run out of registers, so
that has no impact.

The prime point of my posting is that it is quite possible that, for
"equivalent" RISC and CISC machines (using the definition I gave in the
first sentence of my posting), the RISC:CISC instruction count ratio could
be 1:1. Lower ratios would indicate that the CISC compiler isn't doing
analysis which the RISC compiler is -- somebody ought to go fix the CISC
compiler.

							-hankd