Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!husc6!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.sys.ibm.pc Subject: Re: Optimizers and RISC (Re: Why unix doesn't catch on) Message-ID: Date: 3 May 89 03:25:22 GMT References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <7697@phoenix.Princeton.EDU> <268@tree.UUCP> <13595@ncoast.ORG> <369@utgard.UUCP> <3181@looking.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 20 >Did RISC machines cause a push in optimizing compilers? I always thought >the big advantage of the RISC was that it made the low level optimizations >so much simpler -- there's only one way to code the thing, so no need to >worry about the best use of fancy instructions and addressing modes. Sort of. Actually it's probably better to say that RISC *depended upon* a push in optimizing compilers. How much it depends upon them depends upon the specific architecture. Some of the original RISC proposals include things like delayed branching, and in fact the SPARC (Sun 4) does that. That is, a branch instruction doesn't take effect until after the next instruction. In order to produce optimal code, your compiler may have to rearrange code. Simple-minded compilers just put a no-op after the branch. Also, in order to get the benefit out of RISC, you have to be able to use all those registers. This means a compiler intended for RISC should have a good register allocation method. When you can refer to memory about as easily as a register, that's not quite as critical for CISC (though of course minimizing memory references certainly helps there too). The conventional wisdom is that RISC machines need very smart compilers in order to give reasonable performance.