Xref: utzoo comp.arch:13713 comp.compilers:781
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!spdcc!ima!esegue!compilers-sender
From: Moss@cs.umass.edu
Newsgroups: comp.arch,comp.compilers
Subject: Compilers and RISC (was: '040 vs. SPARC)
Message-ID: <1990Feb9.161153.4190@esegue.segue.boston.ma.us>
Date: 9 Feb 90 16:11:53 GMT
References: <8905@portia.Stanford.EDU> <160@zds-ux.UUCP>
	<38415@apple.Apple.COM> <2101@crdos1.crd.ge.COM>
	<19233@dartvax.Dartmouth.EDU>
Sender: compilers-sender@esegue.segue.boston.ma.us
Reply-To: Moss@cs.umass.edu
Followup-To: comp.arch,comp.compilers
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Lines: 47
Approved: compilers@esegue.segue.boston.ma.us
Original-sender: news@dime.cs.umass.edu
In-Reply-To: jskuskin@eleazar.dartmouth.edu's message of 8 Feb 90 06:57:40 GMT

In article <19233@dartvax.Dartmouth.EDU> jskuskin@eleazar.dartmouth.edu (Jeffrey Kuskin) writes:

Yes, but how much do we benefit from the richer instruction sets, even
if all the instruction are hardwired and execute at 1 cycle/instruction?
Isn't one of the RISC folks' main arguments for simple instruction sets
that current compilers don't effectively exploit the complex addressing
modes and instructions supported in CISC chips?  Perhaps someone would
like to speculate on what progess the next decade will bring in
compiler technology...

To which I respond .... 

While I will not claim to be a true expert in these matters, the effect of
RISC on compilers appears to be more subtle than that. A simpler instruction
set makes the task of *instruction selection* easier, but simpler instructions
are not the *only* RISC tenet. A load/store architecture with somewhat more
registers than most CISCs is another typical RISC attribute, and dealing with
that aspect effectively requires really good register allocation -- perhaps
better than you need for a CISC. One actually needs inter-procedural as
opposed to merely "global" (all of a procedure; local = within a basic block)
optimizations to exploit RISC fully. My impression is that RISC chips have
mostly shifted the burden but have not really simplified the job of writing a
compiler. You should also take into account the additional complexities of
dealing with instruction scheduling (results of a load are generally not
available immediately, etc.) and delay slot filling. I do see one *possible*
advantage accruing from all of this, though, which is that instruction
scheduling, delay slot filling, and register allocation may be somewhat more
machine independent in concept and more amenable to being table driven across
architectures than instruction selection generally proves to be. Another
interesting point is that there are now fast optimal techniques for
instruction selection within basic blocks (under some moderately reasonable
conditions) -- see the recent article in TOPLAS (Ganapathi is one of the
authors if I recall correctly) on optimal code generation from trees.

[Note: this discussion originated in comp.arch, but I am following up there as
well as comp.compilers.]
--
		J. Eliot B. Moss, Assistant Professor
		Department of Computer and Information Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206; Moss@cs.umass.edu
-- 
Send compilers articles to compilers@esegue.segue.boston.ma.us
{spdcc | ima | lotus}!esegue.  Meta-mail to compilers-request@esegue.
Please send responses to the author of the message, not the poster.