jtice@arlo.UVic.CA (Jason W. Tice) (04/25/91)
Any information regarding the RISC and CISC chips would be greatly appreciated. What does it do? what are it's parametres? what is the difference between RISC and CISC ? can you tell me where to look to find more information on them? please mail any information on either/or both of the RISC and CISC chips to jason@softwords.bc.ca or jtice@arlo.uvic.ca thank-you. I'll post what I learn! Jason W. Tice -- ----------------------------------------------------------------------------- / "I didn't do it man!" -- Bart Simpson \/ jtice@lester.uvic.ca \ \"I before E except after C." What a weird language. /\ jason@softwords.bc.ca / -----------------------------------------------------------------------------
fangchin@elaine54.Stanford.EDU (Chin Fang) (04/25/91)
In article <1991Apr24.224650.27937@sol.UVic.CA> jtice@arlo.UVic.CA (Jason W. Tice) writes: >Any information regarding the RISC and CISC chips would be greatly appreciated. > >What does it do? A good book on this is Profs. John Hennessy and David Patterson's Computer Archetectures. The first author is the orignator of MIPS, the second is the orignator of RISC (ancestor of SUN's SPARC). A very delightful and information packed book. I love it even I am a Mechanical Engineer (Sigh..) Dr. Hennessy is at Stanford and Dr. Patterson is at Berkeley. Both places are big camps of RISC (coined at Berkeley however) researches with Berkeley CAD (computer aided design) probably stronger. >what are it's parametres? Please see above reference. >what is the difference between RISC and CISC ? ditto. >can you tell me where to look to find more information on them? ^ | I believe many people would enjoy the chance of looking at kernel disk file sizes. Below I give three (vm)unix file sizes: RS6000 supersalar -> multiple instructions per clock, in the case of IBM, the number is 4 1271128 bytes SUN OS 4.1.1 on SPARC -> derivative of Berkeley RISC 1303014 bytes Ultrix 4.1 on MIPS 5500 (DEC System 5500, Stanford MIPS project decendent) 3375632 bytes How about your SysV/386 /unix? Kind of tiny comparing with the trio above right? Note, I didn't care to find out how many drivers are installed in each one. But it's safe to say they are BIG. How about the trio's performance difference? Well, IBM has the best floating point perfomance and the worst UNIX implementation, buggy and nasty to work with. But if it's fast (even the 320 has 8.5 MFLOPS, enough to leave SUN SPARC 2 in dust!) then all it's sins are forgivable to some one who crunches numbers. To system programmers? ...... Cheers Chin Fang Mechanical Engineering Department Stanford University fangchin@leland.stanford.edu
jones@acsu.buffalo.edu (terry a jones) (04/25/91)
In article <1991Apr25.033637.15092@leland.Stanford.EDU> fangchin@elaine54.Stanford.EDU (Chin Fang) writes: >I believe many people would enjoy the chance of looking at kernel >disk file sizes. Below I give three (vm)unix file sizes: > >RS6000 supersalar -> multiple instructions per clock, in the case of > IBM, the number is 4 > 1271128 bytes > >SUN OS 4.1.1 on SPARC -> derivative of Berkeley RISC > > 1303014 bytes > >Ultrix 4.1 on MIPS 5500 (DEC System 5500, Stanford MIPS project decendent) > > 3375632 bytes 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. Terry Terry Jones {rutgers,uunet}!acsu.buffalo.edu!jones SUNY at Buffalo ECE Dept. or: rutgers!ub!jones, jones@acsu.buffalo.edu
fangchin@elaine54.Stanford.EDU (Chin Fang) (04/25/91)
In article <72969@eerie.acsu.Buffalo.EDU> jones@acsu.buffalo.edu (terry a jones) writes: >In article <1991Apr25.033637.15092@leland.Stanford.EDU> fangchin@elaine54.Stanford.EDU (Chin Fang) writes: >>I believe many people would enjoy the chance of looking at kernel >>disk file sizes. Below I give three (vm)unix file sizes: >> >>RS6000 supersalar -> multiple instructions per clock, in the case of >> IBM, the number is 4 >> 1271128 bytes >> >>SUN OS 4.1.1 on SPARC -> derivative of Berkeley RISC >> >> 1303014 bytes >> >>Ultrix 4.1 on MIPS 5500 (DEC System 5500, Stanford MIPS project decendent) >> >> 3375632 bytes > > > 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Terry I built emacs 18.57.1 for our RS6000 lately. After dump (note this difference. I had to dump it to make it fast loading), the size is 1753552 bytes (Man!!) Worst, you cann't strip this animal, otherwise it core dumps! If I get a chance, I will see how big the undumped version can be. Most likely would not be much smaller, probably about the same as the guy below: On DEC system 5500 (MIPS 5500 CPU), same version the size is 937984 bytes (Gee!) This is of course obtained with -s turned on. I haven't compile emacs on SUN yet, so I can't give yall a good number. Now on my 386 ESIX box, after mcs -d and strip, together with shared libs with X support compiled in, the size is 618496 bytes (Hmmm... not bad) Kind of interesting. I am often "surprised" by the "fattening" of executables on RISC machines. The 30% increase is not uncommon indeed. It seems to me just from what I can recall, MIPS seems to be the worst pig among the RISC bunch. The emacs example on RS6000s is an abbration, not a norm. Chin Fang Mechanical Engineering Department Stanford University fangchin@leland.stanford.edu
torek@elf.ee.lbl.gov (Chris Torek) (04/25/91)
(now why did we have `Keywords: init run level'?) This discussion belongs elsewhere. comp.arch would be the place to argue over what makes something a `RISC' (it will only be the 17 million'th time the argument has gone on there). In article <1991Apr25.033637.15092@leland.Stanford.EDU> fangchin@elaine54.Stanford.EDU (Chin Fang) writes: >A good book on this is Profs. John Hennessy and David Patterson's Computer >Archetectures. Yes. Nowadays, however, you also must be aware that `RISC' is a marketing word, with zero meaning. The marketeers believe that customers think `RISC = good', so the marketeers label everything `RISC'. (Well, almost everything. `RISC dinner plates, now on sale...' :-) ) >I believe many people would enjoy the chance of looking at kernel >disk file sizes. Below I give three (vm)unix file sizes ... These sizes are almost meaningless, because the size of the file tells little about the size of the kernel. In particular, the MIPS executable file format typically contains two to three times as much symbol table information (`for debuggers' is an oversimplification, but close enough here) as some other typical formats. For another unfair comparison (slightly more fair than raw file size), use the `size' program: % size /vmunix sys/compile/ss1/vmunix text data bss dec hex 868352 118000 79392 1065744 104310 /vmunix 483328 38664 124416 646408 9dd08 sys/compile/ss1/vmunix /vmunix is SunOS 4.1, sys/compile/ss1/vmunix is my kernel. Mine has almost no device drivers, and is 4BSD rather than SunOS. I am hoping it will shrink when I get around to cleaning some things up.... -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
ken@racerx.UUCP (Ken Hardy) (04/26/91)
In article <1991Apr25.063035.23140@leland.Stanford.EDU>, fangchin@elaine54.Stanford.EDU (Chin Fang) writes: > >> 1271128 bytes > >> 1303014 bytes > >> 3375632 bytes > 1753552 bytes (Man!!) > 937984 bytes (Gee!) Yeah, but WHAT IS THE SIZE ?!? %size emacs text data bss dec hex 606208 184320 0 790528 c1000 (Sun SparcStation) (Gnu emacs) -- Ken Hardy uunet!racerx!ken Bridge Information Systems ken@racerx.com
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (04/26/91)
In article <1991Apr24.224650.27937@sol.UVic.CA> jtice@arlo.UVic.CA (Jason W. Tice) writes: >Any information regarding the RISC and CISC chips would be greatly appreciated. > >What does it do? >what are it's parametres? >what is the difference between RISC and CISC ? >can you tell me where to look to find more information on them? Hennessy (of MIPS and Stanford) and Patteron have an EXCELLENT book which covers this topic in enough detail that you too can become a computer designer! (Of course, you may not end up being a very good one, but that's a separate problem). The book is: Computer Architecture: A Quantitative Approach. It came out last year and should be available in any good university textbook store. If not, grump. This book is THE one to read to understand why RISC machines have an edge over traditional CISC machines. Robert Bernecky rbe@yrloc.ipsa.reuter.com bernecky@itrchq.itrc.on.ca Snake Island Research Inc (416) 368-6944 FAX: (416) 360-4694 18 Fifth Street, Ward's Island Toronto, Ontario M5J 2B9 Canada
martin@mwtech.UUCP (Martin Weitzel) (04/29/91)
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. IMHO that depends on the compiler. A little more than ten years ago, when I started to get in touch with some UNIX-like system, it was on a 6809- microprocessor (the name of this particular OS was UniFLEX, if anyone on the net cares). The other popular microprocessors in this time were the 8080 and Z80. I think it's not wrong to say the 6809 was more like a RISC, the 8080 and the 8086 were more like CISC processors. In these days there existed a very decent C- Compiler for the 6809 (written by James McCosh) which produced fairly efficient code for the 6809. As I was told this was due to the 'orthogonal structure' of the machine instructions of the 6809 (again compared to its competitors) which meant that the compiler could use every instruction whith each of the available adressing modes. For a compiler the problem with the 8080 and Z80 was that the numerous instructions could only combined with certain adressing modes. Because it was difficult to teach the compilers which instructions could be used with which adressing modes, the compiler writers 'played safe', ie. they only used some percentage of the possible instructions. (Note that - unless you take cross-compilers into consideration - on a micro- processor with limited resources you couldn't make the compilers super- smart!) On the other hand, the 6809 lend itself very much to compilers, because every machine instruction could be combined with every adressing mode. It was much pleisure to see how the McCosh-C-Compiler compiled a section of source which read more or less like: int (*ftab[256])(), i, z; .... z = (*ftab[i])(); Again: If some compiler fully exploits the capabilities of a CISC-machine, the size of code may be less (if the length of the machine instructions were tuned against typical usage frequence - which again depends on the application), but in general RISC-machines are not that much worse than it might seem. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
wes@harem.clydeunix.com (Wes Peters) (05/02/91)
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 <std/disclaimer.h> 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