Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!mcdphx!hrc!gtephx!robertsw From: robertsw@gtephx.UUCP (Wild Rider) Newsgroups: comp.arch Subject: Re: What is the ratio of programs sizes CISC versus RISC Message-ID: <1991Jun20.044303.953@gtephx.UUCP> Date: 20 Jun 91 04:43:03 GMT References: <32580034@hpcuhe.cup.hp.com> Reply-To: robertsw@gtephx.UUCP (Wild Rider) Organization: AG (formerly GTE) Comm. Sys., Phx, AZ Lines: 76 In article <32580034@hpcuhe.cup.hp.com> sramesh@hpcuhe.cup.hp.com writes: >/ hpcuhe:comp.arch / rwallace@unix1.tcd.ie (russell wallace) / 7:25 pm Jun 16, 1991 / >"RISC" these days is not to be taken very literally. Most modern RISC >processors have: > >lots of 32-bit registers ^^^^^^^^^^^^^^^^^^^^^^^^^ uh, pardon me, but i was under the distinct impression that one of the design philosophies of risc was to free up more silicon real estate for _registers_. in other words, lots of 32-bit registers sounds more like risc than cisc to me. i was under the impression that risc stood for "reduced _instruction_ set computer," i.e., only the _instruction_ set is reduced, not the number of _registers_. [ ... stuff deleted ... ] >on the SPARC, function calls with parameter passing in a single >instruction ever program a sparc in assembly language? the sparc is a very risc-y machine. once you get the hang of it, you kinda like it. f'rinstance, the call opcode can address the entire 4gb address space, yet packs the opcode + the address in 32 bits. how? well, since it's a risc, you're guaranteed that each instruction will fall on a 4-byte boundary. hence, you really only need 30 bits to encode the address. that's right, the upper two bits denote the instruction as a call opcode, & the other 30 bits are the address. i thought this was a good example of the risc opcode rule: "all opcodes (except load/store) will fit in one machine word, including address modes." > >on several RISC chips, every instruction can be conditional on one of >the status bits, and can optionally set the status register > >Therefore, a program on a modern "RISC" chip takes fewer instructions >(usually by about 30% or so) than the same program on a 680x0 or 80x86. >However because every instruction on a RISC chip is 32 bits wide whereas >some instructions on a 680x0 are only 16 bits and a few on an 80x86 are >only 8 bits (e.g. RET), the object file will probably be larger to the >tune of 10-15% ... in other words, not a significant difference. sorry, i'll have to disagree here. the risc philosophy represents a classic example of the space/time tradeoff: the risc object code is "looser" (bigger), hence faster than cisc object code (which is denser & slower). to use your example above: the 68k family encodes a _majority_ of instructions in 16 bits. optimizing compilers take advantage of the 16-bit 68k instructions, since they tend to be quicker. the 80x86 (yuck, now i'll have to wash my hands since i typed that vile number) encodes most of its instructions in 8 or 16 bits. on the other hand, the _smallest_ instruction for a sparc is 32 bits wide. plus, because the sparc lacks even the more mundane addressing modes of the 68k (auto{inc,dec}rement), it will use _more_ instructions to do the same task as a 68k. this leaves us with the obvious conclusion that given equally competent compilers (or assembly programmers :-), the sparc code will inevitably be larger. again, a classic example of the space/time tradeoff. > >"To summarize the summary of the summary: people are a problem" >Russell Wallace, Trinity College, Dublin >rwallace@unix1.tcd.ie >---------- cheers, wr (the wild rider) -- Wallace Roberts, AG (formerly GTE) Communication Systems, Phoenix, AZ UUCP: ...!{ncar!noao!asuvax | uunet!zardoz!hrc | att}!gtephx!robertsw Internet: gtephx!robertsw@asuvax.eas.asu.edu Bike: '82 GS1100L Suz voice: (602)581-4555 fax: (602)582-7624 Cage: '89 Mustang GT