Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!viusys!uxui!unislc!harem!wes From: wes@harem.clydeunix.com (Wes Peters) Newsgroups: comp.unix.questions Subject: Re: RISC (Reduced Instruction-Set Chip) vs. CISC Summary: Code density on RISC very bad? Keywords: init run level Message-ID: <229@harem.clydeunix.com> Date: 1 May 91 23:28:35 GMT References: <1991Apr24.224650.27937@sol.UVic.CA> <72969@eerie.acsu.Buffalo.EDU> Organization: Raxco, Inc., Orem, UT Lines: 28 In article <72969@eerie.acsu.Buffalo.EDU>, jones@acsu.buffalo.edu (terry a jones) writes: > One thing to keep in mind also, is the fact that RISC compiled objects > are generally larger than their CISC counterparts would be. Makes good sense > to me, since there are fewer instructions for the compiler implementer to > use, his code sequences will generally require more of them. I don't have > any hard figures available at the moment. I'm sure that I could come up > with some if the need arose. I recall figures of approx. 30% in some of the > recent literature that I have read. There are some other tradeoffs than just instruction set size. On the MIPS (Stanford) chip, the compiler often packs NOPs of various sizes immediately following multiple-cycle instructions to keep the instruction pipeline from "stalling." I found on the SGI Iris 4D/70 that if you optimize for minimum space, the executables would shrink as much as 30 - 40%, but would run MUCH (i.e. 2x to 3x) slower. (Using SGI/MIPS f77). One thing they never tell you when you look at a RISC system is that you need to buy much larger disks and more memory, because code space is so large in RISC executables. Once again, more mips = more $$$$. Ah well. 68040 lives! Moto forever! Wes Peters -- #include The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes