peterd@june.cs.washington.edu (Peter Damron) (06/18/88)
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
samples@dougfir.Berkeley.EDU (A. Dain Samples) (06/21/88)
My $0.02 worth: In article <1117@ima.ISC.COM> peterd@june.cs.washington.edu (Peter Damron) writes: >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. This isn't clear at all, although there have been several articles attempting to clarify the relative speeds of the two architecture styles. >> [more questions] >> J. Giles >> Los Alamos > > [Peter's response is correct] > >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. > [essentially correct examples] >As the RISC crowd points out, these >complicated instructions often end up being slower than the equivalent >operation synthesized out of simpler ops, A slight correction needs to be made here: there is only one instance that I know of where a complex instruction on a CISC architecture turned out to run more slowly than the same operation coded with simpler instructions ON THE SAME MACHINE. I believe the instruction was one of the CALL instructions in an early version of the microcode for one of the smaller VAXen, but I'm not real sure. The net result was that DEC fixed the microcode so the performance of the instruction was improved. [As dmr noted in his recent comp.arch note, it was the 780's calling instructions.] A more correct statement of what the RISC crowd is pointing out is captured in the following question: What is the cost of the additional hardware/microcode necessary to support complex instructions? It is almost never the case (although it does sometimes happen) that an instruction can be added to an existing CPU instruction set without impacting the design of the hardware. In general, such an enhancement requires more control lines, more microcode, and rarely it may require a new function to the ALU. The question is then: how much more slowly does the hardware run as a whole due to the addition of this additional hardware? Stated another way: If you had spent as much time on making a small instruction set run very fast as you spent making a large instruction set run acceptably fast, how much faster would the majority of the programs run? >particularly if some compile-time >optimization is possible, so the only gain is in instruction density. -John] In my compiler-oriented opinion, this comment captures the true winnings from RISCs. Compile-time optimization means throwing away as much generality as you can while preserving the semantics of the operation IN CONTEXT. Since simple operations run very fast on RISCs, and since the majority of instructions emitted by a compiler (any compiler) are simple instructions anyway, and since streams of simple instructions are easier to analyze and improve (although at the cost of having more of them to look at), the net result is faster programs. A. Dain Samples, UC Berkeley, samples@renoir.berkeley.edu, 642-9542, 785-5644 -- 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
daryl@ihlpe.att.com (06/21/88)
> In article <20338@beta.lanl.gov>, jlg@beta.lanl.gov (Jim Giles) writes: > > Do modern compilers for CISC make good > > use of the variety in the instruction set? > > J. Giles > 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. One thing I noticed on a VMS machine once that most UNIX hacks wouldn't see is that languages such as PL/I and PASCAL with the internal strings and nested subroutines made far better use of the VAX instruction set than the C compiler. Have any RISC studies been done with languages with more abstractions than C? Daryl Monge UUCP: ...!ihnp4!ihcae!daryl AT&T CIS: 72717,65 Bell Labs, Naperville, Ill AT&T 312-979-3603 [For the IBM 801 work, their working language was PL.8, the 80% of PL/I that they found useful. As far as I know, the conclusions they came to were much the same as the other RISC efforts, even though unlike many of the other groups they from the first included some of the best compiler people in the world. They have since grafted C and Pascal front ends on to the PL.8 compiler and they apparently produce good code, too, though some of their early misunderstandings about the semantics of C were pretty amazing. -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