Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!apple!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Compiling - RISC vs. CISC
Message-ID: <26257@amdcad.AMD.COM>
Date: 10 Jul 89 18:23:53 GMT
References: <13976@lanl.gov> <25547@shemp.CS.UCLA.EDU> <26247@amdcad.AMD.COM> <25562@shemp.CS.UCLA.EDU>
Sender: news@amdcad.AMD.COM
Reply-To: tim@amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 44
Summary:
Expires:
Sender:
Followup-To:

In article <25562@shemp.CS.UCLA.EDU> frazier@cs.ucla.edu (Greg Frazier) writes:
| 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.

I don't agree with this.  Our experience with the early (PCC-based)
internal compiler for the Am29000 showed pretty good performance with
little or no standard optimizations (no load scheduling,
common-subexpression elimination, dead-code elimination, live/dead
analysis for register allocation, etc.) The only things it performed
were those required by the architecture, i.e.  delayed branches.  Of
course, the compiler utilized the features of the architecture, such as
keeping all scalar local variables and function parameters in registers,
which you may or may not want to count as "optimization". 

| >| This is complex.  In addition, most RISC architectures expose their
| >| pipelines, and hence require the compiler to avoid interlocks,
| >| etc.  This is also complex.

When I first read this, I though you were referring to architectures
without hardware interlocks -- now I see that you were probably
referring to increasing the performance by scheduling instructions,
trying to avoid the interlocks.

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

If by "exposed pipeline" you mean that performance will be
enhanced by instruction scheduling, then I agree.  However, I don't
agree that most RISCs will expose the pipeline to software like the i860
-- most will provide hardware interlocks.

	-- Tim Olson
	Advanced Micro Devices
	(tim@amd.com)