Xref: utzoo comp.arch:5249 comp.compilers:264 Path: utzoo!attcan!uunet!husc6!spdcc!ima!compilers-sender From: samples@dougfir.Berkeley.EDU (A. Dain Samples) Newsgroups: comp.arch,comp.compilers Subject: Re: Compiler complexity (was: VAX Always Uses Fewer Instructions) Keywords: RISC CISC Message-ID: <1127@ima.ISC.COM> Date: 20 Jun 88 19:39:57 GMT References: <6921@cit-vax.Caltech.Edu> <28200161@urbsdc> <10595@sol.ARPA> <20338@beta.lanl.gov> <1117@ima.ISC.COM> Sender: compilers-sender@ima.ISC.COM Reply-To: samples@dougfir.Berkeley.EDU (A. Dain Samples) Organization: University of California, Berkeley Lines: 74 Approved: compilers@ima.UUCP 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