sl179060@silver.bacs.indiana.edu (Chima Echeruo) (11/17/89)
I have an IBM AT clone (@ 20Mhz) and sometimes it seems that it is no faster than an AT (@12Mhz). Most of the bottlenecks seemed to be the disk IO and the graphics card (8 bit EGA). I expected the 20 Mhz 286 to average 8+ MIPS and when I ran the MIPS (Chips & Tech) benchmark, I got a disappointing 2.5 - 3.00 MIPS. Does that mean that the 'average' 286 instruction takes 8 cycles? The Acorn Archimedes A310 (a RISC computer) has a clock rate of 8Mhz yet it is capable of 4 MIPS. I have been told that the higher the clock rate, the more expensive the hardware (eg. 33 Mhz 386 vs 16 Mhz). If this is so why does INTEL keep raising the clock speeds on their chips? Would it not be cheaper and more efficient to modify their chips to make use of the RISC technology? Would the RISC 286 (@10 Mhz) not outperform the CISC 286 (@20)? What are the factors involved in the decision to make a chip RISC or CISC? ----- Chima -----
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (11/17/89)
In article <29806@iuvax.cs.indiana.edu> sl179060@silver.bacs.indiana.edu (Chima Echeruo) writes: >I have an IBM AT clone (@ 20Mhz) and sometimes it seems that it is no faster >than an AT (@12Mhz). Most of the bottlenecks seemed to be the disk IO and >the graphics card (8 bit EGA). I expected the 20 Mhz 286 to average 8+ MIPS and >when I ran the MIPS (Chips & Tech) benchmark, I got a disappointing 2.5 - 3.00 >MIPS. Does that mean that the 'average' 286 instruction takes 8 cycles? Put some extended memory in, and use a disk cache device driver, like SMARTDRV.SYS (DOS 4.01), this will greatly improve disk performance, and alleviate the disk bottleneck. >Would the RISC 286 (@10 Mhz) not outperform the CISC 286 (@20)? What are the >factors involved in the decision to make a chip RISC or CISC? There may be more technical answers than this one, but the instruction set is what determines RISC vs CISC. If you had a different instruction set, then it wouldn't be a 286 any more. Furthermore, the 80x86 is a micro-coded machine, and most RISC machines have a hard coded instruction set. NEC was rumored to be producing a V33, essentially an 8086 with hard coded logic, rather than micro-coded logic. I don't know if it ever came to be. But it was thought that it would be blazingly fast compared to an Intel micro- code 8086. These rumors circulated around the time when NEC was doing legal battle with Intel over Vx0/80x86 copyright/patent infringements, so the death of the Vx3 family may have been because of this. Benson, you are so mercifully devoid of the ravages of intelligence. kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
cs9a-ax@dorothy.Berkeley.EDU (Mike Morrison) (11/17/89)
In article <29806@iuvax.cs.indiana.edu> sl179060@silver.bacs.indiana.edu (Chima Echeruo) writes: >expensive the hardware (eg. 33 Mhz 386 vs 16 Mhz). If this is so why does INTEL >keep raising the clock speeds on their chips? Would it not be cheaper and more >efficient to modify their chips to make use of the RISC technology? > >Would the RISC 286 (@10 Mhz) not outperform the CISC 286 (@20)? What are the >factors involved in the decision to make a chip RISC or CISC? >----- >Chima >----- RISC stands for Reduced Instruction Set Computer, and CISC stands for Complex(?) Instruction Set Computer. It is impossible to make a "RISC 286" since this would mean modifying the instruction set, which would render all of the available software useless -- if you change the instruction set it is no longer a '286. There are also those who say that the 8086 series IS RISC. I don't buy it though. Mike Morrison cs9a-ax@dorothy.berkeley.edu morrison@ocf.berkeley.edu
silver@eniac.seas.upenn.edu (Andy Silverman) (11/17/89)
I may be mistaken, but I thought the whole idea behind RISC was to make the chips simple so that they COULD be run at blinding speeds. Since RISC instructions don't do very much, they'd have to be run extremely fast to be useful. Isn't it easier to make a simple chip run really fast than a very complex one? +-----------------------+-----------------------------------------+ | Andy Silverman | Internet: silver@eniac.seas.upenn.edu | | "All stressed out and | Compu$erve: 72261,531 | | nobody to choke." | | +-----------------------+-----------------------------------------+
pfratar@watserv1.waterloo.edu (Paul Frattaroli - DCS) (11/17/89)
In article <29806@iuvax.cs.indiana.edu> sl179060@silver.bacs.indiana.edu (Chima Echeruo) writes: > >I have an IBM AT clone (@ 20Mhz) and sometimes it seems that it is no faster >than an AT (@12Mhz). Most of the bottlenecks seemed to be the disk IO and >the graphics card (8 bit EGA). I expected the 20 Mhz 286 to average 8+ MIPS and Yes. Choice of hard disk and controller can make a big difference in overall performance. But, 8 MIPS is a bit extravagent for a 286 based machine >when I ran the MIPS (Chips & Tech) benchmark, I got a disappointing 2.5 - 3.00 That sounds about right. >MIPS. Does that mean that the 'average' 286 instruction takes 8 cycles? > >The Acorn Archimedes A310 (a RISC computer) has a clock rate of 8Mhz yet it >is capable of 4 MIPS. I have been told that the higher the clock rate, the more >expensive the hardware (eg. 33 Mhz 386 vs 16 Mhz). If this is so why does INTEL >keep raising the clock speeds on their chips? Would it not be cheaper and more >efficient to modify their chips to make use of the RISC technology? Probably not, from INTEL's standpoint. In my opinion, INTEL is a company that grew up with the IBM PC. Everyone and their dog makes microprocessors but INTEL made them for the IBM PC. The problem is that RISC and CISC are in most cases incompatible. The idea of RISC is to reduce the instruction set of the cpu ( hence the name ) and thus the complexity. So, if INTEL were to make a RISC version of the 8086 for instance, by cutting down the instruction set to the bare bones, it would not be able to run many of the software packages available for the PC today. Those that make use of the instructions that get canned. This is however an extreme example. But INTEL would be looking at losing the PC market, for at least that chip. But, once the complexity is reduced, things such as built in coprocessors and hardware implemented double precision square roots can be integrated inside the chip itself, instead of outside. This has happened to the 486 to some extent. Although not truly RISC, the 486 is a more efficient 386 with a built in 387 coprocessor and some built in instruction cache ( about 2k I think ) > >Would the RISC 286 (@10 Mhz) not outperform the CISC 286 (@20)? What are the >factors involved in the decision to make a chip RISC or CISC? >----- >Chima >----- Of course, RISC and CISC are relative, and they lack formal definitions. If you look at the DIGITAL PDP-8 for example, ( or is it 7? ), it only had maybe a dozen instructions of any consequence. By todays standards, that is superRISC... ....Paul F -- Paul Frattaroli - Department of Computing Services University of Waterloo Waterloo, Ontario Canada N2L-3G1 < pfratar@watshine.UWaterloo.ca > < pfratar@watserv1.UWaterloo.ca > < pfratar@watdcs.bitnet > -------------------------------------------------------------------------------- "My friend Paco, there are two types of people in this world, those with loaded guns, and those who dig. You dig." - Blondie [ Clint Eastwood ], The Good, the Bad and the Ugly.
pec@necntc.nec.com (Paul Cohen) (11/17/89)
In Article 5276 of comp.binaries.ibm.pc.d, Kaleb Keithley writes: > NEC was rumored to be producing a V33, essentially an 8086 with hard > coded logic, rather than micro-coded logic. I don't know if it ever > came to be. But it was thought that it would be blazingly fast compared > to an Intel micro-code 8086. These rumors circulated around the time > when NEC was doing legal battle with Intel over Vx0/80x86 copyright/patent > infringements, so the death of the Vx3 family may have been because of this. Rumors of the death of the V33 appear to have been greatly exaggerated! This part has been in production for some time now and there will soon be a high integration version (along the lines of the V40/V50/80186) called the V53. These parts support dynamic bus sizing. The formal part number for the V33 is uPD70136, available in three different packages, in both 12.5 and 16MHz versions. The 16 MHz part is approximately four times as fast as the 10 MHz V30 with which it is upward compatible (the V30 is 5% to 10% faster than an 8086 at the same clock frequency). It supports a 16 MByte address space through an internal address translation mechanism (which directly supports LIM 4.0). A floating point co-processor, the uPD72291, is available which performs at 500 KFlop's.
mbt@bridge2.ESD.3Com.COM (Brad Turner) (11/18/89)
Based on my limited knowledge in the subject area I thought that the
distinguishing characteristics of a RISC chip were the following:
o Hardcoded logic.
o All instruction execute in 1 clock cycle
It is the combination of the two above items that generally require
the instruction set to be small. I suppose in theory you could have
a large number of instructions and as long as all the instructions
adhered to the above constraints the chip could be considered RISC.
-brad-
--
v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v
Brad Turner |2081 Shoreline Blvd.|(415) 969-2099 ext 217 | I speak for myself
3Com Corp. |Mtn. View, CA 94043 |mbt@bridge2.ESD.3Com.Com| NOT for my employerhalliday@cheddar.cc.ubc.ca (Laura Halliday) (11/18/89)
In article <1104@bridge2.ESD.3Com.COM> mbt@bridge2.ESD.3Com.COM (Brad Turner) writes: >Based on my limited knowledge in the subject area I thought that the >distinguishing characteristics of a RISC chip were the following: > o Hardcoded logic. > o All instruction execute in 1 clock cycle RISC originally stood for Reduced Instruction Set Computer, with the idea being that you could make a very simple chip with a small, simple intruction set, run it *very* fast, and execute zillions of simple little instructions, for a net increase in performance. >It is the combination of the two above items that generally require >the instruction set to be small. This has been changing. As chip people have figured out how to make more and more complicated chips, the emphasis has indeed shifted from simple instruction sets to as few clock cycles per instruction as possible. Personally, I think it's time for a bit of a breather, so that we can figure out how to program such computers effectively and make real use of their awesome power. Too many systems team up 1990's hardware with 1960's software. Perhaps this should be followed up in comp.arch. ...laura
sl179060@silver.bacs.indiana.edu (Chima Echeruo) (11/18/89)
Being the author of the original note I would like to move this discussion to comp.arch. Thanks, ----- Chima -----
cs9a-ax@dorothy.Berkeley.EDU (Mike Morrison) (11/18/89)
In article <1104@bridge2.ESD.3Com.COM> mbt@bridge2.ESD.3Com.COM (Brad Turner) writes: >Based on my limited knowledge in the subject area I thought that the >distinguishing characteristics of a RISC chip were the following: > o Hardcoded logic. > o All instruction execute in 1 clock cycle I don't think so -- any instruction that loads something from memory still requires more than one clock -- one to put the address on the bus and one to receive the data, plus any other overhead. Mike Morrison cs9a-ax@dorothy.berkeley.edu
kaleb@mars.jpl.nasa.gov (Kaleb Keithley) (11/18/89)
In article <28384@necntc.nec.com> pec@necntc.UUCP (Paul Cohen) writes: >The formal part number for the V33 is uPD70136, available in three >different packages, in both 12.5 and 16MHz versions. The 16 MHz part >is approximately four times as fast as the 10 MHz V30 with which it is >upward compatible (the V30 is 5% to 10% faster than an 8086 at the same >clock frequency). It supports a 16 MByte address space through an >internal address translation mechanism (which directly supports LIM 4.0). >A floating point co-processor, the uPD72291, is available which performs >at 500 KFlop's. I've seen the V53, which I have some passing interest in, however, I'm more interested in a V23. Any chance that they made such a thing? Benson, you are so mercifully devoid of the ravages of intelligence. kaleb@mars.jpl.nasa.gov (818)354-8771 Kaleb Keithley
hideki@is.s.u-tokyo.ac.jp (YOSHIDA Hideki) (11/18/89)
>when I ran the MIPS (Chips & Tech) benchmark, I got a disappointing 2.5 - 3.00 >MIPS. Does that mean that the 'average' 286 instruction takes 8 cycles? No. $ MIPS = 1 / average execution time of a instruction $ is an old-fashioned definition. In most cases, MIPS value is obtained by comparing the result of a benchmark with that of VAX-11/780, so that RISC chips will be evaluated more correctly. -- Hideki Yoshida Department of Information Science Faculty of Science The University of Tokyo hideki@is.s.u-tokyo.ac.jp
bwwilson@lion.waterloo.edu (Bruce Wilson) (11/20/89)
This discussion about RISC vs CISC seems to conclude that a RISC machine by reducing the instruction set can run these instructions much faster but won't reducing the instruction set increase the number of instructions required to perform a specific task. If the RISC instructions are twice as fast but require twice as many, what is gained? I know that in the real-world RISC-based machines are faster but why? yours ponderingly, bruce (bwwilson@lion.waterloo.edu) bruce Wilson |"you don't have to earn what you don't spend..." bwwilson@lion.waterloo.edu | from Blake (a film by Bill Mason)
pechter@ocpt.ccur.com (Bill Pechter <pechter>) (11/20/89)
In article <28384@necntc.nec.com>, pec@necntc.nec.com (Paul Cohen) writes: > > The formal part number for the V33 is uPD70136, available in three > different packages, in both 12.5 and 16MHz versions. The 16 MHz part As a happy V30 user -- I have one question. Is it pin compatible with the V30 i now have in my AT&T PC6300? I'd love to drop in another upgrade... Also - anyone know where I could get V30 spec sheets. -- Bill Pechter -- Home - 103 Governors Road, Lakewood, NJ 08701 (201)370-0709 Work -- Concurrent Computer Corp., 2 Crescent Pl, MS 172, Oceanport,NJ 07757 Phone -- (201)870-4780 Usenet . . . rutgers!pedsga!tsdiag!scr1!pechter ** MS-DOS is CP/M on steroids, bigger, bulkier and not much better **
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (11/21/89)
I have this car that has a 6 cylinder engine. I'm thinking about
replacing it with an 8 cylinder. Will that help me get the
groceries from the store to home quicker? Would it help if I
replaced the automatic transmission with a 4-speed? How about a
5-speed? And which would be better for towing my vacation trailer?
Gee, maybe it just depends on what I want to use my car for...?
[For those of you who may thing I've mis-posted this, please
substutite some "computer-ese sounding" words in the appropriate
places and you'll probably see what I'm getting at.]
kEITHe
PS - THIS DOESN'T BELONG IN THE BINARIES DISCUSSION GROUP, so I'm
redirecting followups the the ibm.pc group.
THANK YOU VERY MUCH!!!!jb@aablue.UUCP (John B Scalia) (11/22/89)
In article <18323@watdragon.waterloo.edu> bwwilson@lion.waterloo.edu (Bruce Wilson) writes: >This discussion about RISC vs CISC seems to conclude that a RISC >machine by reducing the instruction set can run these instructions >much faster but won't reducing the instruction set increase the >number of instructions required to perform a specific task. This was a major argument back when RISC was first argued as a possible logical successor to current CPU designs. If you look at some of the early arguments, the term "Code Expansion" comes up a lot. Some early estimates argued that the amount of expansion that would take place would negate any increase in speed. While I don't recall the specific values argued, I generally remember a figure of 30% being bandied around. Of course, modern compiler designs have pretty much rendered that argument moot, by my understanding. jb@aablue -- A A Blueprint Co., Inc. - Akron, Ohio +1 216 794-8803 voice UUCP: {uunet!}aablue!jb (John B. Scalia) Just a little more nonsense to clutter up the net.
bobmon@iuvax.cs.indiana.edu (RAMontante) (11/23/89)
bwwilson@lion.waterloo.edu (Bruce Wilson) <18323@watdragon.waterloo.edu> : - -If the RISC instructions are twice as fast but require twice as -many, what is gained? The speedup comes from (at least) three things: Number of cycles used to perform a function. Years ago it was noticed on some VAXen that some operations which had their own complex instruction for just the purpose, could nonetheless be done faster in a subroutine that used only simple instructions (I don't remember the detailsof the instruction). The simple instructions were faster, because they needed fewer clock cycles to decode and execute. The number of clock cycles needed to set up the complex instruction outweighed the number used in subroutine overhead.... Since the specialized instructions aren't commonly used anyway, you can make a strong case for keeping them out of the cpu (which simplifies its design enormously) and putting lots of sweat into doing them right in a coprocessor if they're a really good idea (e.g. trig functions). Clock rate. The simpler cpu design allows circuits to be packed into a smaller area. This means that signals don't have to travel as far --- one of the approaching hard limits on cpu speed is the "speed of light", i.e. signal propagation in a wire. Also, simpler instructions can be decoded and executed using fewer circuit elements (gates). Since each gate involves a gate delay, and the clock period must be long enough to span the longest set of gate delays, reducing these allows a faster clock. Cache, pipeline, etc. Since the cpu design is *smaller*, there is more real estate available on the chip for laying out cache memory, pipelines, and so forth, all of which speed things up. Another choice made by one design is to put in *lots* of registers; when the processor context-switches, it doesn't need to save the register state on a stack in memory, it just moves on to a different set of registers on the chip.