Compilers and RISC (was: '040 vs. SPARC)

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

Return to the comp.compilers page.
Search the comp.compilers archives again.