Newsgroups: comp.arch Path: utzoo!utgpu!jarvis.csri.toronto.edu!csri.toronto.edu!norvell From: norvell@csri.toronto.edu (Theodore Stevens Norvell) Subject: Re: Compiling - RISC vs. CISC Message-ID: <1989Jul9.202858.27121@jarvis.csri.toronto.edu> Organization: University of Toronto, CSRI References: <13976@lanl.gov> <2190@oakhill.UUCP> In article <2190@oakhill.UUCP> davet@oakhill.UUCP (David Trissel) writes: >In article <13976@lanl.gov> jlg@lanl.gov (Jim Giles) writes: > >>Instruction selection is fairly simple since there is >>generally only one way the perform each intermediate code operation. > >This is a strange statement. Since in general terms CISC instruction sets are >supersets of RISC models then why are the "extra" available CISC >instructions mandated to be used by a CISC compiler? Indeed, one of the >arguments for RISC is the elimination of "unused" instructions from the >instruction set. Although this may bring up important architectural differences >between RISC and CISC it has no bearing on the complexity of a compiler. Of course no one forces you to use a CISC instruction, but one of the goals of writing a compiler (and the one that Mr. Giles was focusing on)is to generate code that's close to optimal for the target machine. The compiler writer is under the obligation to consider all possible instruction sequences that accomplish a goal. The more instructions, and the more complicated each instruction, the harder this task becomes. In many cases, the best sequence can not be determined by the compiler writer and so he must write complex code to determine (or sometimes guess) it at compile time. Again the more instructions and the more complicated they are, the harder this is -- and it makes code selection slower and the compiler bigger. The situation is worst (whether CISC or RISC) when the machine operations don't match the source language. But the choice of instructions is not the hard part of instruction selection (on a CISC). There is also the choice of address modes. Suppose you are compiling the C statement i = *p ; where i and p are both memory (not register) variables. Do you: (A) Emit a move using an indirect address mode. (B) load p and do a memory to memory move (C) load *p with an indirect address mode and store i (D) load p, load *p and then store i If both p and *p are dead, (A) is likely best; if p is live and *p is dead, (B) is best; if p is dead and *i is live, (C) is best; if both are live (D) is best. But if registers are in short supply, (A) might be best in any case. Then again, if registers aren't in short supply and something useful can be scheduled after the loads, (B), (C), or (D) might be better than (A). In other words, even in a simple assignment statement, there are phase ordering problems between instruction selection and, optimization, register allocation and scheduling. In a RISC (or a CISC with impoverished address modes), the only answer is (D). Mr. Trissel's group seem to have solved this phase ordering problem by putting some of the address mode selection into a peephole optimizer. This seems reasonable, but it moves the complexity to the peephole optimizer. >>Instruction selection obviously >>effects the register allocation phase (and the code ordering phase). > >True for both RISC and CISC. No difference. Right, it's more a question of whether register allocation and scheduling (code ordering) affect instruction selection. >>To make matters worse, instruction selection is context sensitive. >>This means that different code ordering during optimization could >>invalidate the instruction selection choice (or, at least make the >>selected instructions sub-optimal). > >True for both RISC and CISC. No difference. The difference is that if there is only one good way to select the instructions (as is more often true on a RISC than a CISC), then there is no phase ordering problem, You simply select the instructions first with no fear of picking a sequence that screws up the register allocation or scheduling. Not because it won't, but because there probably wasn't another sequence that would have been better. On the whole I agree with the rest of Mr. Trissel's statements. As to whether CISC or RISC compilers (generating high quality code) are easier to build or less complex, I don't know. The problems are a bit different and both are hard. Theodore Norvell norvell@csri.toronto.edu University of Toronto but formerly employed in compiler writing for a machine that was half RISC and half CISC and half bourbon. The above does not represent the opinion of my university, my former employer, and probably won't represent my opinion once I've thought it over.