pb@idca.tds.PHILIPS.nl (P. Brouwer) (06/12/91)
Who can give me some information about the ratio of program sizes of RISC versus CISC. -- # Peter Brouwer, | Philips Information Systems, # # NET : pb@idca.tds.philips.nl | Department P9000-i Building V2, # # UUCP : ....!mcsun!philapd!pb | P.O.Box 245,7300AE Apeldoorn,The Netherlands# # PHONE:ext [+31] [-0]55 432992,| FAX :ext [+31] [-0]55 432070 #
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/13/91)
In article <pb.676737175@atperf.idca.tds.philips.nl> pb@idca.tds.philips.nl (Peter Brouwer) writes: | Who can give me some information about the ratio of program sizes of RISC | versus CISC. Code size (text) and total executable file size, both 32 bit systems, both unix flavors. Several files compiled in Xenix/386 (SCO C), Sun4 (Sun C), and MIPS (Ultrix C). All use -O. 386 Sun4 R3000 386 Sun4 R3000 Code Code Code File File File file1 56036 65536 81920 71716 81920 98304 zoo 2.10 alpha file2 43560 49152 69632 55368 65536 86016 zoo 2.01 file3 50692 65536 90122 64708 73728 106496 zip 0.82 file4 96468 163840 188416 107620 172032 200704 ksh 88e file5 76944 114688 151552 96416 139264 176128 memacs 3.9p3 Draw any conclusions you want, I've never seen a program which wasn't 15-25% larger in RISC, but that doesn't seem to a good reason for choosing a machine. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
tim@proton.amd.com (Tim Olson) (06/14/91)
In article <pb.676737175@atperf.idca.tds.philips.nl> pb@idca.tds.philips.nl (Peter Brouwer) writes: | Who can give me some information about the ratio of program sizes of RISC | versus CISC. Here is some (somewhat dated) information: 68020 .text Am29000 .text Program (Sun 3/260) MetaWare C ratio ----------------------------------------------------- compress 6600 8792 1.33 dhrystone 1.1 1608 1892 1.17 dhrystone 2.0 2984 3056 1.02 diff 10448 14492 1.39 grep 2640 4288 1.62 nroff 35328 59708 1.69 sipasm 52032 71528 1.37 stanford 9064 9752 1.08 ------------------------------------------------------------ Total 120704 173508 1.44 It is a bit difficult to compare code sizes because the compilers are different, and are performing different optimizations. It would be better to try a comparison using, say, the GNU C compiler. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
preston@ariel.rice.edu (Preston Briggs) (06/14/91)
pb@idca.tds.philips.nl (Peter Brouwer) writes: >| Who can give me some information about the ratio of program sizes of RISC >| versus CISC. Code size (text) and total executable file size, both 32 >bit systems, both unix flavors. davidsen@crdos1.crd.ge.com (bill davidsen) writes: >Several files compiled in Xenix/386 (SCO C), Sun4 (Sun C), and MIPS >(Ultrix C). All use -O. ... >Draw any conclusions you want, I've never seen a program which wasn't >15-25% larger in RISC, but that doesn't seem to a good reason for >choosing a machine. I don't much like this sort of comparison. Compilers behave too differently for executable sizes to be of architectural significance. For example, the MIPS and Sparc compilers do loop-unrolling. The RS/6000 compilers don't. I don't know about particular 386 compilers. More interesting is path-length comparisons (number of instructions actually executed). Pixie (and pixie-clones) can get these numbers. If they'll tell you the average instruction length for the CISC machines, then you could find something interesting (like number of bytes of instruction fetched). Of course, I'd really prefer to count delays caused by I-cache misses. Preston Briggs
thor@thor.atd.ucar.edu (Richard Neitzel) (06/14/91)
In article <3429@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: |> In article <pb.676737175@atperf.idca.tds.philips.nl> pb@idca.tds.philips.nl (Peter Brouwer) writes: |> | Who can give me some information about the ratio of program sizes of RISC |> | versus CISC. Code size (text) and total executable file size, both 32 |> bit systems, both unix flavors. |> |> Several files compiled in Xenix/386 (SCO C), Sun4 (Sun C), and MIPS |> (Ultrix C). All use -O. |> |> 386 Sun4 R3000 386 Sun4 R3000 |> Code Code Code File File File |> |> file1 56036 65536 81920 71716 81920 98304 zoo 2.10 alpha |> file2 43560 49152 69632 55368 65536 86016 zoo 2.01 |> file3 50692 65536 90122 64708 73728 106496 zip 0.82 |> file4 96468 163840 188416 107620 172032 200704 ksh 88e |> file5 76944 114688 151552 96416 139264 176128 memacs 3.9p3 |> |> Draw any conclusions you want, I've never seen a program which wasn't |> 15-25% larger in RISC, but that doesn't seem to a good reason for |> choosing a machine. |> -- |> bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) |> "Most of the VAX instructions are in microcode, |> but halt and no-op are in hardware for efficiency" Well, they aren't always bigger - some of the smaller programs I've compiled for my Sun3s and Sun4s are indentical in size. What I find interesting is that of the larger programs, the 2 statically linked ones (emacs & epoch) are 19 & 15 percent larger then the Sun3 version, but the shared library programs (mwm & ups) are 35 & 28 percent larger. Anyone have any ideas why? txt data bss dec hex File size (.o) 516096 188416 0 704512 ac000 704512 Sun3 emacs 647168 188416 0 835584 cc000 835584 Sun4 emacs 516096 491520 0 1007616 f6000 1007616 Sun3 epoch 778240 385024 0 1163264 11c000 1163264 Sun4 epoch 24576 8192 0 32768 8000 32768 Sun3 g++ 24576 8192 0 32768 8000 32768 Sun4 g++ 24576 8192 0 32768 8000 32768 Sun3 gcc 24576 8192 0 32768 8000 32768 Sun4 gcc 8192 8192 0 16384 4000 16384 Sun3 geteaddr 8192 8192 0 16384 4000 16384 Sun4 geteaddr 163840 16384 0 180224 2c000 180224 Sun3 mwm 221184 16384 1088 238656 3a440 237568 Sun4 mwm 344064 40960 10256 395280 60810 385024 Sun3 ups 458752 40960 7272 506984 7bc68 499712 Sun4 ups -- Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn.
rodman@sgi.com (Paul K. Rodman) (06/14/91)
In article <1991Jun13.173625.24315@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes: >pb@idca.tds.philips.nl (Peter Brouwer) writes: >>| Who can give me some information about the ratio of program sizes of RISC >>| versus CISC. Code size (text) and total executable file size, both 32 >>bit systems, both unix flavors. >I don't much like this sort of comparison. >..... >Of course, I'd really prefer to count delays caused by I-cache misses. > >Preston Briggs Right on. Of course you should at itlb misses and text page faults to really be totally fair...:-) -- Paul K. Rodman Advanced Systems Division rodman@sgi.com Silicon Graphics, Inc. KA1ZA Mountain View, Ca.
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (06/14/91)
In article <1991Jun13.173625.24315@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes: | I don't much like this sort of comparison. | More interesting is path-length comparisons (number of instructions | actually executed). The original asked about code size, not speed, instructions executed, etc. I provided some data points on that. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Most of the VAX instructions are in microcode, but halt and no-op are in hardware for efficiency"
slackey@bbn.com (Stan Lackey) (06/14/91)
>In article <3429@crdos1.crd.ge.COM>, davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes: >|> "Most of the VAX instructions are in microcode, >|> but halt and no-op are in hardware for efficiency" Once when looking at machine X microcode listing, I noticed the microcode word for no-op had the comment ; do nothing Just under it was the microword for the halt instruction. The comment was: ; do even less Just wasting a little bandwidth. -Stan
ron@sco.COM (Ron Irvine) (06/15/91)
In article <1991Jun14.001039.4172@shinobu.sgi.com> rodman@sgi.com (Paul K. Rodman) writes: >In article <1991Jun13.173625.24315@rice.edu> preston@ariel.rice.edu (Preston Briggs) writes: >>pb@idca.tds.philips.nl (Peter Brouwer) writes: >>>| Who can give me some information about the ratio of program sizes of RISC >>>| versus CISC. Code size (text) and total executable file size, both 32 >>>bit systems, both unix flavors. > >>I don't much like this sort of comparison. >>..... >>Of course, I'd really prefer to count delays caused by I-cache misses. >> >>Preston Briggs > >Right on. Of course you should at itlb misses and text page faults to >really be totally fair...:-) There are many application where performance is not critical but size is. I chose the NS32000 processor for a job that required lots of code in EPROM (over 1 Meg.). The 32000 is a very compact code machine, plus it had import/export addressing that allowed dynamic shared libraries in Eprom! Performance of the machine was not a problem since the communication lines to and from the machine were the bottle neck. However, the cost and size of the Eprom was a problem (this was back in 1985). Code size costs in ram/eprom/disk space and expense. Some times you can live with the cost, some times you can not. CISC verus RISC gives product designers an option.
rwallace@unix1.tcd.ie (russell wallace) (06/17/91)
"RISC" these days is not to be taken very literally. Most modern RISC processors have: lots of 32-bit registers orthogonal 3-operand instructions load/store with powerful addressing modes and optional sign-extension on loads integral floating-point on the SPARC, function calls with parameter passing in a single instruction 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. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@unix1.tcd.ie
pkl@ee.mu.OZ.AU (Peter Kenneth LAWREY) (06/18/91)
In article <rwallace.677125555@unix1.tcd.ie> rwallace@unix1.tcd.ie (russell wallace) writes: >"RISC" these days is not to be taken very literally. Most modern RISC >processors have: >lots of 32-bit registers >orthogonal 3-operand instructions >load/store with powerful addressing modes and optional sign-extension on loads >integral floating-point In one of the booklettes on the Transputer put out by inmos it describes the Transputer as begining a "Reduced Instruction Set Computer for compact programs" It has three registers, a stack and instructions that can be any multiple of 8 bits up to 72 or more. One quote of a definition of RISC "Any CPU announced after 1985" or such. Peter.
sramesh@hpcuhe.cup.hp.com (06/18/91)
/ 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 orthogonal 3-operand instructions load/store with powerful addressing modes and optional sign-extension on loads integral floating-point on the SPARC, function calls with parameter passing in a single instruction 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. "To summarize the summary of the summary: people are a problem" Russell Wallace, Trinity College, Dublin rwallace@unix1.tcd.ie ----------
robertsw@gtephx.UUCP (Wild Rider) (06/20/91)
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
colin@array.UUCP (Colin Plumb) (06/28/91)
In article <rwallace.677125555@unix1.tcd.ie> rwallace@unix1.tcd.ie (russell wallace) writes: >"RISC" these days is not to be taken very literally. Most modern RISC >processors have: > > load/store with powerful addressing modes and optional sign-extension on > loads Er... come again? Some RISCs (e.g. 290x0) have just register indirect, most have just register+offset, some can scale the register, the i860 has postincrement, and the ARM has fairly powerful post/pre-indexing features. But none of these compare to what the VAX or 680[234]0 can do. Even the 8086's and 68000's reg+reg+offset is more than any RISC chip I know of does. Do you feel like defending that claim? -- -Colin