Xref: utzoo comp.arch:5210 comp.compilers:261
Path: utzoo!attcan!uunet!husc6!spdcc!ima!compilers-sender
From: peterd@june.cs.washington.edu (Peter Damron)
Newsgroups: comp.arch,comp.compilers
Subject: Re: Compiler complexity (was: VAX Always Uses Fewer Instructions)
Summary: current retargetable compilers
Keywords: RISC CISC
Message-ID: <1117@ima.ISC.COM>
Date: 17 Jun 88 23:03:07 GMT
References: <6921@cit-vax.Caltech.Edu> <28200161@urbsdc> <10595@sol.ARPA> <20338@beta.lanl.gov>
Sender: compilers-sender@ima.ISC.COM
Reply-To: peterd@june.cs.washington.edu (Peter Damron)
Organization: U of Washington, Computer Science, Seattle
Lines: 54
Approved: compilers@ima.UUCP

In article <20338@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes:
> This discussion brings up a question about the actual use of CISC
> instructions.  It seems that RISC vs. CISC is probably about a draw
> for raw compute speed of special coded sequences.  The question is:
> how many programs actually get full advantage from the large instruction
> sets offered by CISC?
> 
> In more recent years, has the state of the compiler art improved so that
> good code generators for CISC machines can be built easily?  Or is it
> still a hit or miss operation?  Do modern compilers for CISC make good
> use of the variety in the instruction set?
> 
> J. Giles
> Los Alamos

The current state of the art in retargetable code generators is such
that the addressing modes of CISC machines can be easily handled
(with the possible exeption of addressing mode with side-effects).
Complex instructions like the VAX polynomial instruction and string
move instructions are still problematic.

These code generators are based on machine descriptions written
as regular tree grammars and on tree parsing techniques.

I have been working on techniques for handling complex instructions
in a retargetable code generator, but it is a hard problem.

Further problems include the integration of register allocation,
instruction selection, and instruction scheduling.

Any further discussion along these lines should probably be moved
to comp.compilers.

Peter Damron
Department of Computer Science
University of Washington
peterd@june.cs.washington.edu
[My impression is that taking advantage of complicated instructions often
adds ugly irregularities to an otherwise clean register model.  For example,
the IBM 370's BXLE and BXH instructions do just the right thing for a
count-by-N loop, but only if the operands are in adjacent registers.  Ditto
the Vax string move instructions.  A separate problem is that in many cases
(again Vax MOVC5 is an example) the instructions do something so complicated
that in a low-level language like C or Fortran you'd have to write a fairly
large chunk of code that the code generator would have to recognize as
sufficiently close to the instruction.  As the RISC crowd points out, these
complicated instructions often end up being slower than the equivalent
operation synthesized out of simpler ops, particularly if some compile-time
optimization is possible, so the only gain is in instruction density.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request