Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!purdue!ames!apple!usc!orion.cf.uci.edu!uci-ics!ucla-cs!frazier
From: frazier@oahu.cs.ucla.edu (Greg Frazier)
Newsgroups: comp.arch
Subject: Re: Compiling - RISC vs. CISC
Message-ID: <25562@shemp.CS.UCLA.EDU>
Date: 9 Jul 89 23:27:01 GMT
References: <13976@lanl.gov> <25547@shemp.CS.UCLA.EDU> <26247@amdcad.AMD.COM>
Sender: news@CS.UCLA.EDU
Reply-To: frazier@cs.ucla.edu (Greg Frazier)
Organization: UCLA Computer Science Department
Lines: 62

In article <26247@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
>No, RISCs don't *require* very good optimizers; they just make it easier
>to perform some optimizations.  Very simple compilers can be used with
>fairly good results.

To take advantage of their RISC-ness, the DO require the optimizations.
Of course, they can run lousy code - they just go slow.

>| This is complex.  In addition, most RISC architectures expose their
>| pipelines, and hence require the compiler to avoid interlocks,
>| etc.  This is also complex.
>
>*Most* RISC architectures?  The Stanford MIPS processor did not have
>interlocks, but nearly all other RISC processors do (a recent exception
>is the i860, which exposes the pipeline in pipelined floating-point mode).

When you have single-cycle instructions, talking about exposed
pipelines is rather non-sensical.  On most RISCs, the only
instructions which are multi-cycle are loads and stores, which
are variable and thus require interlocks.
The i860 is the only RISC with a significant number of multi-cycle
instructions on it (and it's still a RISC! :-) - as more processors
move in that direction, you are going to see more exposed piplines.
Also, if you'll allow me to stretch things a bit, putting inst'ns
in delayed branch slots does count as exposing the pipeline, I
think - it is very implementation dependent.

>I would claim that the stack-cache operation of the Am29000 register
>file is *easier* to generate code for than a standard register file. 
>Just determine the maximium number of registers required by a function
>and allocate them on function entry -- register spilling & filling is
>taken care of automatically by bounds checks.  Yes, delayed branches
>have to be taken care of, but they aren't particularly hard -- some
>systems don't put this in the compiler; it is done at assembly or link
>time, along with other optimizations.

You're right - unfortunately, I was confusing in my memory someone
complaining how hard it is to write assembly code for register-
window machines.  Yes, they do make life easier for the compiler,
unless you are trying to optimize over/underflows!

>| Finally, as you pointed out, RISCs require
>| sophisticated register allocation.
>
>No, it is just useful to help reduce memory traffic.

Well, if you don't do the optimizations, and don't reduce the
memory traffic, then once again you are throwing out the
advantages of a RISC arch, and you might as well be running
on a CISC.  My basic thrust, please correct me if I'm wrong,
is that RISCs are much more dependent upon compiler optimizations
for their performance, and if you're not willing to invest in
a sophisticated compiler, you're probably working on the wrong
machine.

Greg Frazier
&&&&&&&&&&&&&&&&&&&##########################%%%%%%%%%%%%%%%%%%%%%

Greg Frazier	    o	Internet: frazier@CS.UCLA.EDU
CS dept., UCLA	   /\	UUCP: ...!{ucbvax,rutgers}!ucla-cs!frazier
	       ----^/----
		   /