Will@cup.portal.com (Will E Estes) (03/18/90)
What is the MIPS rating of these microprocessors: 386SX-15 386-20 386-25 386-33 Also, since the 80386 has a more complex instruction set and does more work in a given instruction than does a typical RISC chip, does comparing MIPS figures between RISC and non-RISC architectures really tell you anything of worth? Finally, why is everyone so excited about RISC? Why the move to simplicity in microprocessor instruction sets? You would think that the trend would be just the opposite - toward more and more complex instruction sets - in order to increase the execution speed of very high-level instructions by putting them in silicon and in order to make implementation of high-level language constructs easier. Thanks, Will
marshall@wind55.seri.gov (Marshall L. Buhl) (03/21/90)
Will@cup.portal.com (Will E Estes) writes: >Finally, why is everyone so excited about RISC? Why the move to >simplicity in microprocessor instruction sets? You would think >that the trend would be just the opposite - toward more and more >complex instruction sets - in order to increase the execution >speed of very high-level instructions by putting them in silicon >and in order to make implementation of high-level language >constructs easier. Just a wild guess. Hardware guys like RISC, software guys like CISC. RISC puts the work on the shoulders of the software folks. It's easier to impliment RISC in hardware. If I were developing software in assembler, I'd probably hate RISC. It is probably harder to write a compiler for RISC. If you use high-level languages, you may not care. Users probably don't care unless one costs more for the same application performance (which is all that really counts). -- Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov Senior Computer Engineer VOICE: (303)231-1014 Wind Research Branch 1617 Cole Blvd., Golden, CO 80401-3393 Solar Energy Research Institute Solar - safe energy for a healthy future
santol@cbnewsc.ATT.COM (shawn.r.antol) (03/21/90)
Someone wrote: > Also, since the 80386 has a more complex instruction set and does > more work in a given instruction than does a typical RISC chip, > does comparing MIPS figures between RISC and non-RISC > architectures really tell you anything of worth? Absolutely not. The figures must be taken with respect to some type of standard, ie. application program that is common to both architectures - compiled by the same compiler. Good luck finding this. The problem in comparing the two is easily explained (see below). > Finally, why is everyone so excited about RISC? Why the move to > simplicity in microprocessor instruction sets? You would think > that the trend would be just the opposite - toward more and more > complex instruction sets - in order to increase the execution > speed of very high-level instructions by putting them in silicon > and in order to make implementation of high-level language > constructs easier. Simplicity in design means LESS board space for the CPU. Of course nobody is going to switch just because of board space, but imagine using the *extra* space for caching, floating point hardware, etc. The RISC architecture is well know for its very high MIPS rating. Most notably, one machine instruction during EVERY clock cycle. Compare that with 3-25 clock pulses for a CISC architecture and you can easily see that the RISC can outperform the CISC in SOME applications <--Very important! Consider doing an integer multiply in CISC: Load the registers and let the CPU do it! in RISC: Load more registers, AND write the routine to multiply. It takes more machine cycles but might do it faster! The RISC/CISC debate is a very hotly debated subject and I can't wait to see all of the email this article will cause :-( One reason people prefer CISC is that it has a large number of unique machine language instructions. However, studies have shown that say, for a CPU with 300 instructions, only 20-45% of the unique instructions are utilized by people coding in assembly language. So you say, "who in the hell codes in assembly language these days?" Although there are quite a few who do/need to code in assembly, the truth is that compilers are taking over the show and all in all, the space required to put the added complexity on the CPU does not outweigh the benefits of having complex instructions because the compilers use even LESS of the unique instructions available in CISC. One very important point is that as architectures are performing more and more parallel processing, the COMPILER becomes the determining force for speed in code execution. It is my opinion that one needs to closely define what his/her application is and decide if RISC or CISC is better. Clearly there is no "winner", but "what is the application". I do not advocate one over the other because they both have benefits/faults the other doesn't have. Only the future can tell us which will preside. Shawn R. Antol AT&T Bell Labs Naperville, IL - USA voice: 708-979-5622 email: att!ihlpb!santol #include <std.disclaimers>
kmont@hpindda.HP.COM (Kevin Montgomery) (03/21/90)
> Also, since the 80386 has a more complex instruction set and does > more work in a given instruction than does a typical RISC chip, > does comparing MIPS figures between RISC and non-RISC > architectures really tell you anything of worth? nopers... "MIPS are meaningless" > Finally, why is everyone so excited about RISC? Why the move to > simplicity in microprocessor instruction sets? You would think > that the trend would be just the opposite - toward more and more > complex instruction sets - in order to increase the execution > speed of very high-level instructions by putting them in silicon > and in order to make implementation of high-level language > constructs easier. First, I'd refer you to comp.arch, where this is talked about endlessly. The advantage is that the simpler a design is, the more it can be optimized. A couple of profs at Berkeley (Patterson and Sequin) looked at the usage of the instructions of a few machines and found that 10% of the instructions were being used 90% of the time. Even though some snazzy, neato, high-level instructions existed (who can forget the VAX polynomial instruction?), the code spit out by the compiler never made use of them (to say nothing of the fact that alot of these functions were in microcode!). So, you had 95% of the code in the world suffering to get their stuff done because the design of the processor was convoluted by having functions that only a few people used. So, these guys at UCB (along with some great folks at Stanford) said, "Gee (no GTE), maybe we should only have the instructions we need and optimize the hardware/stacks in a big way" (UCB) and "Gee (same joke), maybe we should get the compiler writers and hardware guys to talk together" (Stanford). So, UCB cut out the deadwood and optimized the hardware, and Stanford cut out the deadwood, got the compiler writers and hardware guys talking, used a larger set of general registers, left Stanford and begat MIPS (okay, a little simplistic, but hey, it's MY posting). Other companies were looking at the technology at the time and picked either one of the camps (Sun->UCB, HP&MIPS ->Stan). So, in general, you want to only have the instructions you're going to use and you want these as fast as can be. Unused instructions are deadwood that prevents you from optimizing the remaining instructions. Also, by making the designs less complicated, clock speeds can go through the roof. So, you get these screaming little processors that need more and more memory to keep them fed. Also, since you have the chip space and life is simpler, you can do other nice things like pipelining. Also, don't forget- since it's simpler, you can crank out a design in half the time it used to take. Will it hold up? Dunno. Personally, I think that multiprocessor designs may be the undoing of RISC-based systems, unless someone can build a good, cheap, fast dual-ported memory. Remember, the faster the CPU goes, the more the memory bottleneck grows. And having more processors increases the contention for memory. We'll see how it shakes out, but for now, the customer wins big. kevin
Ralf.Brown@B.GP.CS.CMU.EDU (03/21/90)
In article <40970054@hpindda.HP.COM>, kmont@hpindda.HP.COM (Kevin Montgomery) wrote: }were being used 90% of the time. Even though some snazzy, neato, high-level }instructions existed (who can forget the VAX polynomial instruction?), the If you think that one is neat, what about the VAX string-edit instruction? Feed it the address of a string and the address of a list of edit commands and let it fly. You could probably write the equivalent of the Unix SED in about fifty lines of VAX assembler.... -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 "How to Prove It" by Dana Angluin Disclaimer? I claimed something? 16. proof by cosmology: The negation of the proposition is unimaginable or meaningless. Popular for proofs of the existence of God.
robert@ireq.hydro.qc.ca (R.Meunier 8516) (03/21/90)
Once a compiler is completed for a RISC Architecture, it should be easely ported to another one because the RISC instruction between two RISC microprossesor should be the almost the same. -- ----------------------------------------------------------------------- Robert Meunier Institut de Recherche d'Hydro-Quebec Ingenieur 1800 Montee Ste-Julie, Varennes Internet: robert@ireq.hydro.qc.ca Qc, Canada, J3X 1S1
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) (03/22/90)
In article <40970054@hpindda.HP.COM> kmont@hpindda.HP.COM (Kevin Montgomery) writes: >nopers... "MIPS are meaningless" > >First, I'd refer you to comp.arch, where this is talked about endlessly. A few weeks ago I made the remark on the net that it seems meaningless to compare RISC MIPS with CISC MIPS. I was soundly rebutted by any number of netters telling me that all the manufacturers use VAX MIPS when rating their cpu's. In other words, benchmarks are run for various types of cpu-intensive applications, and the results are compared to the same benchmarks on a VAX 11/780, which is the platinum standard by which all cpu's are measured. -- John Dudeck "You want to read the code closely..." jdudeck@Polyslo.CalPoly.Edu -- C. Staley, in OS course, teaching ESL: 62013975 Tel: 805-545-9549 Tanenbaum's MINIX operating system.
nelson_p@apollo.HP.COM (Peter Nelson) (03/22/90)
:> Also, since the 80386 has a more complex instruction set and does
:> more work in a given instruction than does a typical RISC chip,
:> does comparing MIPS figures between RISC and non-RISC
:> architectures really tell you anything of worth?
Obviously the instruction sets of different machines are very different.
This isn't just a problem between RISC and CISC but between different CISC
machines too. The venerable Z80's instruction set was 4 ticks for r-r ops,
7 ticks for 8 bit r-m ops, 10 ticks for 16 bit r-m ops, etc. You could
easily make a case for an "average" program's mix to be ~8 ticks per instruction
since the 4 and 7 tick instructions predominate and drag the average down.
Does this mean that a 4 MHz Z80 was a full half MIPS??? Of course not.
NOBODY I know is compring "RISC MIPS" to "CISC MIPS". The
standard use of the term "MIPS" these days is 1 VAX-11/780 MIPS.
Obviously you are still at the mercy of the compiler for such comparisons
although this is not such a bad thing since you would also be at the
compiler's mercy in the real world of software development. In other
words its perfectly reasonable to say "using the best compiler we could
find, machine X is 2X as fast as machine Y using the best compiler we could
find for machine Y.
---Peter
kluksdah@hpspcoi.HP.COM (Keith Kluksdahl) (03/22/90)
All this does not mention microcode, which is the real reason that RISC processors can achieve greater throughput. Each time one of the complex instructions is fetched, it requires many microcode instructions to execute. Fancy instructions such as multiply require quite a number of microcode instructions. And each microcode instruction requires a clock cycle. The simplier instructions require a penalty or several microcode instructions, and clock cycles, to execute. Most of the instructions executed in a computer are loads, stores, and branches, which are relatively simple to perform. RISC systems perform these instructions in one clock cycle (with some exceptions, of course), instead of the multiple clock cycles required by CISC processors. By adding things like barrel shifters, many other instructions can also execute in one clock cycle. The result is a fairly rich instruction set, which isn't really reduced. Writing code for RISC machines is much like writing microcode. And it can be more difficult than writing CISC code. But the performance seems to make it worthwhile. Time will tell. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ | These views are my own, but I may | Keith Kluksdahl | | be re-programmed tomorrow........ | HP Bedford Falls | \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Tested tough in Alaska. |<---------- So Long ---------->|
ssingh@watserv1.waterloo.edu ($anjay "lock-on" $ingh - Indy Studies) (03/22/90)
In article <1990Mar20.233504.4946@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: > >Just a wild guess. Hardware guys like RISC, software guys like CISC. >RISC puts the work on the shoulders of the software folks. It's easier >to impliment RISC in hardware. My question isn't exactly germaine to the newsgroup, but I'll ask in the hope that because of the high volume here, someone might be able to answer this for me. Daniel Hillis, chief designer of the Connection Machine said in his 1985 thesis on the architecture of this machine that the only way to achieve continued increases in computer power is to abandon the current design philosophy in hardware engineering pioneered by Von Neumann. Since today's computers are essentially implementations of a Turing machine they are extremely flexible when it comes to applications programming. That is, given liberal time and memory constraints, ANYTHING can be simulated (the Church-Turing thesis). Now what happens is that everything is encoded in memory and must then travel to the processor through a bus (with a limited bandwidth) for processing, and then it must be re-written. This limiting bandwidth was not a problem until people like AI researchers and fluid dynamics people began developing extremely powerful algorithms that often are very iterative. Also, microprocessor development has been accelerating, while memory is not able to keep up anymore. Anyone who has a computer with "memory wait-states" will attest to this. So the solution Hillis argues, is to break up this Von Neumann bottleneck over thousands (65536 of them) of processors and do computations in parallel. Each processor can communicate with any other by message passing, and each has it's own local memory. Such computers lend themselves well to applications which can breakdown naturally into chunks which can be executed in parallel. Thinking appears to be one of these, hence the current interest in neural-net models. Having said all this, my question: What type of processor lends itself better to highly parallel architectures, RISC or CISC? -- "No one had the guts... until now..." |-$anjay "lock [+] on" $ingh ssingh@watserv1.waterloo.edu N.A.R.C. ]I[-| "No his mind is not for rent, to any God or government."-Rush, Moving Pictures !being!mind!self!cogsci!AI!think!nerve!parallel!cybernetix!chaos!fractal!info!
rick@NRC.COM (Rick Wagner) (03/22/90)
Will@cup.portal.com (Will E Estes) writes: >Finally, why is everyone so excited about RISC? Why the move to >simplicity in microprocessor instruction sets? You would think >that the trend would be just the opposite - toward more and more >complex instruction sets - in order to increase the execution >speed of very high-level instructions by putting them in silicon >and in order to make implementation of high-level language >constructs easier. Ask Seymore Cray ;-). Back when IBM was impressing themselves with the CISC architecture of the 3[67]0 series of main-frame computer, Seymore Cray was designing the CDC 6000 series machine (circa 1966 I think, thus the top of the line 6000 was the 6600. Maybe they came out with one each year: 6200, 6300,.., 6600?). The 6000 series was basically CISC, which because of its simplicity in design, allowed the instructions to be hard-wired, instead of micro-coded like many of the CISC machines. So while you had to use more elementary instructions, the CDCs could really plow through them, making the program level throughput relatively high. And after all, most of you program boils down to a few basic instructions: add(/subtract, basically the same thing), compare (essentially a subtract), move and branch, and a bunch of multiplies for indexing, or if you have a math intensive program. So if your machine is optimized to run 90% of your instructions, your program is going to be fast. The RISC architecture also made it much easier to design "segmented" (not the Intel address space definition) cpus. The cpu was actually a bunch of dedicated processing units, each of which executed only specific groups of instructions. Thus you had multiple, parallel instructions being executed. By coding your instructions sequences properly, the machine could run at one instruction per (very fast) clock, even if you used slower (multiply - 7 clocks) instructions in your loop. Thus it was that the Cyber series (6000, 7000, 170 series) were the "power" machines of the '60s, '70s, and first couple years of the '80s. That dominance was toppled by Cray when he introduced the CRAY-1. The same philosophy is now being realized in the micro-computer industry. With memory becoming "cheap", more space can be burnt on program size, and the CPU design can concentrate on optimizing the basic instructions, and parallelism. --rick -- =============================================================================== Rick Wagner Network Research Corp. rick@nrc.com 2380 North Rose Ave. (805) 485-2700 FAX: (805) 485-8204 Oxnard, CA 93030 Don't hate yourself in the morning; sleep 'til noon.
lbr@holos0.uucp (Len Reed) (03/22/90)
In article <1990Mar20.233504.4946@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: >Just a wild guess. Hardware guys like RISC, software guys like CISC. >RISC puts the work on the shoulders of the software folks. It's easier >to impliment RISC in hardware. If I were developing software in >assembler, I'd probably hate RISC. >Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov >Senior Computer Engineer VOICE: (303)231-1014 This shows some odd reasoning for someone with the title of "Senior Computer Engineer." In my experience hardware people *love* to do complicated things in hardware, and software people love to do complicated stuff in software. This makes the job interesting and keeps management from being able to hire people who are not as good. Sure, there are a lot of people who want their jobs to be easy rather than interesting, but they aren't the folks doing state of the art microprocessor and compiler design. (This is not to say that people like fighting stupid challenges, like working with poor tooling.) RISC does *not* put the burden on the software folks, but rather upon a small subset of them: compiler writers. Or really, compiler writers involved in optimization and code generation. As to developing software in assembler for a RISC machine: you don't do it, or you do only a tiny amount of it. Most software people, even in operating systems, will use something above the assembler level. You speak as if "writing in assembler" is a choice made independent of architecture, as if some problems are naturals for assembler and some are not. Nonsense. The idea is to do almost everything in a language *above* the base architecture level in a RISC machine; things that are coded in assembler on a CISC would not necessarily be so coded on a RISC. The alleged benefit of RISC has *nothing* to do with ease of implementation, except as that affects speed. It's supposed to be faster. (Whether it will be in the long run is yet to be seen.) I find it amazing that you could envision a bunch of microprocessor designers saying "To hell with this, let's just dump it all on the software guys." -- Len Reed Holos Software, Inc. Voice: (404) 496-1358 UUCP: ...!gatech!holos0!lbr
rcd@ico.isc.com (Dick Dunn) (03/22/90)
jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > A few weeks ago I made the remark on the net that it seems meaningless to > compare RISC MIPS with CISC MIPS. I was soundly rebutted by any number > of netters telling me that all the manufacturers use VAX MIPS > when rating their cpu's. In other words, benchmarks are run for various > types of cpu-intensive applications, and the results are compared to the > same benchmarks on a VAX 11/780, which is the platinum standard by which > all cpu's are measured. Would that it were so simple! Manufacturers will run various benchmarks and may quote one real number, one invented ("theoretical") number, the best number they can get, lots of numbers, etc., with or without any explanation or rationale. Example - You may have seen the new IBM RISC boxes advertised as "27.5 MIPS". That's based on ONE benchmark that's out of date and known to be inadequate for any machine with a decent compiler. The number is, in fact, a comparison with a VAX number for the same benchmark. However, if you look at other numbers IBM has published for the RS/6000, you'll find that it could be characterized as 15.8 MIPS (integer SPEC) or 22.3 MIPS (integer plus FP SPEC). The 15.8, 22.3, and 27.5 numbers are all relative to a VAX 11/780. The differences are in what is measured and whether the measurement is realistic. But if you're comfortable with the idea that 15.8 is almost the same as 27.5, then MIPS figures make sense... -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Relax...don't worry...have a homebrew.
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/22/90)
In article <28011@cup.portal.com> Will@cup.portal.com (Will E Estes) writes:
$Also, since the 80386 has a more complex instruction set and does
$more work in a given instruction than does a typical RISC chip,
$does comparing MIPS figures between RISC and non-RISC
$architectures really tell you anything of worth?
Well, if you're counting in native MIPS, no. If you're using VAX
MIPS (which really aren't MIPS on anything other than a VAX), then yes.
$Finally, why is everyone so excited about RISC? Why the move to
$simplicity in microprocessor instruction sets? You would think
$that the trend would be just the opposite - toward more and more
$complex instruction sets - in order to increase the execution
$speed of very high-level instructions by putting them in silicon
$and in order to make implementation of high-level language
$constructs easier.
The reason is that RISC architectures run faster. Typically, it
has been found that a given program implemented for a RISC processor
takes around 30% more instructions, but the average instruction operates
3-5 times faster. Overall, then, you get at least a 2x increase in
speed for a given clock rate. This is why RISC excites so many people.
As for complex instructions ... RISC architectures typically have
very efficient subroutine-calling methods specifically for such
purposes. For example, a CISC chip would have a multiply instruction,
whereas a RISC chip would have a multiply step instruction that implements
one step in the multiplication. Each compiler would have in its library
a subroutine that uses this multiply step instruction as the heart of
a multiplication routine, and this subroutine is linked in using the
efficient subroutine calling mechanism.
The same idea is applied to other complex instructions - you use
a subroutine from your compiler's library (which the compiler would
put in automatically for you, just as a C compiler for a system with
no floating point coprocessor automatically puts in a call to its
own floating-point emulator) instead of a highly-complex instruction.
This leads to another advantage - a given-size CISC chip has a very
large (often over 50%) portion devoted to decoding instructions. On
a RISC chip, the decoding logic is far smaller, leaving room for a
barrel shifter, an on-chip cache, an on-chip MMU, or whatever - stuff
that boosts performance.
So, all in all, the complexity of high-level language constructs
is partially built into the architecture of a CISC chip, whereas it's
left up to the compiler in a RISC architecture. (Also, compilers
for RISC systems generally have more optimization in them for such
things as register usage - RISC chips usually have large numbers of
registers - and to maximize the advantages of pipelined execution).
This article, of course, is just a very, very brief overview; there
are a lot of questions and answers about RISC that there just isn't
room to discuss here (I did a seminar on RISC in a course last term,
and had a _lot_ of trouble keeping the amount of material down to the
20 minute limit; I could go on for hours about RISC).
If you want a lively discussion of RISC architectures, try reading
comp.arch - this sort of topic pops up pretty frequently over there,
so you won't have to read for long. Also, try looking through your
local/campus library for computer architecture books and magazines.
You'll find answers to all of your RISC questions are available there.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."kdq@demott.COM (Kevin D. Quitt) (03/23/90)
In article <628@s3.ireq.hydro.qc.ca> robert@ireq.hydro.qc.ca (R.Meunier 8516) writes: > > Once a compiler is completed for a RISC Architecture, it should >be easely ported to another one because the RISC instruction between >two RISC microprossesor should be the almost the same. In your dreams, maybe. What ever gave you this idea? Have you looked at the different architecture styles? Use of register frames for parameter passing, number of registers, etc. RISC architectures are no more alike than CISC or buildings. kdq -- Kevin D. Quitt Manager, Software Development DeMott Electronics Co. VOICE (818) 988-4975 14707 Keswick St. FAX (818) 997-1190 Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last 34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com "Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red October
kdq@demott.COM (Kevin D. Quitt) (03/23/90)
Meaningless
Information
Provided by
Salesmen
Motorola published an excellent article on the perils of MIPS, by
comparing code fragments between the 68010 and 68020. Given that these
are closer in architecture than most other comparisons, this case outght
to be straightforward.
The article demonstrated code that ran on the 68010, and compared it
with functionally identical code on the 68020. The 68020 code was about
half the size, and took 1/3 the time to run, but the MIPS rating for the
'10 was about double that for the '20!
Even 'normalized' MIPS are pretty meaningless, as several other
articles have mentioned. (And no, not everybody normalizes to VAX MIPS,
otherwise, how could a RISC machine have a MIPS rating equivalent to its
clock?)
kdq
--
Kevin D. Quitt Manager, Software Development
DeMott Electronics Co. VOICE (818) 988-4975
14707 Keswick St. FAX (818) 997-1190
Van Nuys, CA 91405-1266 MODEM (818) 997-4496 Telebit PEP last
34 12 N 118 27 W srhqla!demott!kdq kdq@demott.com
"Next time, Jack, write a God-damned memo!" - Jack Ryan - Hunt for Red Octoberdhinds@portia.Stanford.EDU (David Hinds) (03/23/90)
In article <26083220.22927@maccs.dcss.mcmaster.ca>, cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > This leads to another advantage - a given-size CISC chip has a very > large (often over 50%) portion devoted to decoding instructions. On > a RISC chip, the decoding logic is far smaller, leaving room for a > barrel shifter, an on-chip cache, an on-chip MMU, or whatever - stuff > that boosts performance. > > So, all in all, the complexity of high-level language constructs > is partially built into the architecture of a CISC chip, whereas it's > left up to the compiler in a RISC architecture. (Also, compilers > for RISC systems generally have more optimization in them for such > things as register usage - RISC chips usually have large numbers of > registers - and to maximize the advantages of pipelined execution). It looks to me like the success of RISC technology is partially the result of a temporary imbalance in circuit design technology vs. the limits of circuit density. People talk about the 80486 as implementing some RISC features. Why? Because it is fast? It seems to me that the 80486 is instead the antithesis - and nemesis - of RISC technology. If we now have the ability to design a CISC processor so efficiently that most of its instructions take only a cycle or two, why move to a less complex architecture? The 80486 had sufficient circuit space left over for a respectable amount of support stuff, as well. You could say, well, a smaller instruction set would have allowed a larger cache or more registers. But both of these follow the law of diminishing returns - beyond some threshold, you have to increase the number of registers or the amount of cache a LOT to get even a small improvement in performance. And the thresholds aren't very high. I seem to remember that analysis of register usage has shown that 4 (I think) registers were enough to efficiently code all common high-level language constructs. If you have enough registers to allocate them for variables, that is a different matter - but with high-speed caches and pipelining, a register loses most of its edge over main memory. -David Hinds dhinds@popserver.stanford.edu
bcw@rti.rti.org (Bruce Wright) (03/23/90)
In article <2607b76e.5ca0@polyslo.CalPoly.EDU>, jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > > A few weeks ago I made the remark on the net that it seems meaningless to > compare RISC MIPS with CISC MIPS. I was soundly rebutted by any number > of netters telling me that all the manufacturers use VAX MIPS > when rating their cpu's. In other words, benchmarks are run for various > types of cpu-intensive applications, and the results are compared to the > same benchmarks on a VAX 11/780, which is the platinum standard by which > all cpu's are measured. Unfortunately, although this might be useful in some situations, it is too often abused: the manufacturer tries a number of benchmarks, and advertizes the one that shows his machine off the best, as if it were the typical case rather than the best case. Unfortunately, not all machines perform their operations with equal efficiency - even VAXes don't all execute all their instructions in times that are simple multiples of each other. And we are probably all aware of how far off things like the Norton SI index are for PC's. This is even worse when you are talking about machines with such drastically different machine architectures as a VAX and a RISC machine - sometimes you can find situations where a single VAX instruction -> a single RISC instruction, and other times a VAX instruction -> several dozen (or hundred) RISC instructions. Comparison for all possible applications is extremely difficult, which enhances the probability that at least one benchmark will show off one machine particularly well against another. And, of course, sometimes machines and compilers are designed with a particular benchmark _in mind_, resulting in even more anomolous results. In fairness this isn't new with the RISC-CISC debate - it's a tradition that's been going on for decades. Bruce C. Wright
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (03/23/90)
In article <628@s3.ireq.hydro.qc.ca> robert@ireq.hydro.qc.ca (R.Meunier 8516) writes:
$ Once a compiler is completed for a RISC Architecture, it should
$be easely ported to another one because the RISC instruction between
$two RISC microprossesor should be the almost the same.
Not really. Different RISC designs use different register schemes,
have different pipelines, etc. An extreme example would be porting from
some RISC design to a MIPS processor, where the compiler has to ensure that
the instructions it generates will not clash as they go through the
CPU's pipeline (this is implemented in hardware on most other designs).
Also, the optimizer requires a lot of changes since different optimization
strategies provide different performance on different RISC architectures.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
****************************************************************************
"So sorry, I never meant to break your heart ... but you broke mine."ralf@b.gp.cs.cmu.edu (Ralf Brown) (03/23/90)
In article <10453@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: }some RISC features. Why? Because it is fast? It seems to me that the }80486 is instead the antithesis - and nemesis - of RISC technology. If }we now have the ability to design a CISC processor so efficiently that }most of its instructions take only a cycle or two, why move to a less }complex architecture? The 80486 had sufficient circuit space left over }for a respectable amount of support stuff, as well. You could say, well, Yeah, but how many RISC CPUs have 1.2 million transistors? That's something like EIGHT to TEN times as many gates as the typical RISC CPU.... -- {backbone}!cs.cmu.edu!ralf ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/46 BITnet: RALF%CS.CMU.EDU@CMUCCVMA AT&Tnet: (412)268-3053 (school) FAX: ask DISCLAIMER? | _How_to_Prove_It_ by Dana Angluin 3. by vigorous handwaving: What's that?| Works well in a classroom or seminar setting.
ajai@sce.carleton.ca (Ajai Sehgal) (03/26/90)
In article <1990Mar21.210152.3294@holos0.uucp>, lbr@holos0.uucp (Len Reed) writes: > In article <1990Mar20.233504.4946@seri.gov> marshall@wind55.seri.gov (Marshall L. Buhl) writes: > > >Just a wild guess. Hardware guys like RISC, software guys like CISC. > >RISC puts the work on the shoulders of the software folks. It's easier > >to impliment RISC in hardware. If I were developing software in > >assembler, I'd probably hate RISC. > > This shows some odd reasoning for someone with the title of "Senior > Computer Engineer." In my experience hardware people *love* to do On the contrary, this is very good reasoning for a Senior Computer ENGINEER (not computer scientist). RISC certainly does put the burden on the shoulders of the software folks. Although it probably wasn't a contrived "plot" , it remains a fact. > RISC does *not* put the burden on the software folks, but rather upon > a small subset of them: compiler writers. Or really, compiler writers > involved in optimization and code generation. As to developing software > in assembler for a RISC machine: you don't do it, or you do only a tiny > amount of it. Most software people, even in operating systems, will > use something above the assembler level. You speak as if "writing in > assembler" is a choice made independent of architecture, as if some problems > are naturals for assembler and some are not. Nonsense. The idea is > to do almost everything in a language *above* the base architecture > level in a RISC machine; things that are coded in assembler on a CISC > would not necessarily be so coded on a RISC. > > The alleged benefit of RISC has *nothing* to do with ease of implementation, Your view on who is programming what using what type of language and at what level is narrowed by a lack of experience outside of your own domain (sorry for the flame but ....). The people who would most be attracted to the performance gains available in RISC architectures certainly are concerned with programming in assembly language. For example, any real time application where timing is critical (such as Digital Signal Processing), requires code optimisation that cannot be achieved with even the most optimal of optimizing compilers (good luck to whoever wants to write an optimising compiler for a RISC chip such as the i860!). Even on CISCs an FFT (fast fourier transform - basic building block for DSP) algorithm, implemented in C or FORTRAN and compiled with the best compilers can only come within 35% of a hand coded (assembly) version of the same algorithm - in terms of speed of execution [see article by L.R. Morris in IEEE Micro Sep 87]. Now try to program a RISC chip by hand (assembly). The intel i860 for example with its "exposed" pipeline has a ridiculous learning curve. If we can't program these chips in assembly and writing optimising compilers are difficult (either impossible or too expensive - I don't believe anything is impossible [except dribbling a football!]) we won't use them --- unless the performance improvements are such that using "dirty" compilers still give better performance than CISCs. With the introduction of the 80486 and the 68040 with most of the most often used instructions approaching single cycle execution as in RISCs, it is unlikely that the RISCs will grab an appreciable slice of the market. RISC is a passing fad that as technology advances, will be left in the dust. TO PREEMPT ANY FLAMERS OUT THERE - I apologize for posting this to this Newsgroup and in future will refrain from doing so. Ajai (ajai@sce.carleton.ca)
kmont@hpindda.HP.COM (Kevin Montgomery) (03/27/90)
> Having said all this, my question: What type of processor lends > itself better to highly parallel architectures, RISC or CISC? This is what I was trying to get at earlier in the discussion (or later, depending on the bit-wind near your site). I agree with the connection approach in that 1) parallelism is necessary to dramatically increase performance and 2) the memory bottleneck still exists (unless someone makes a good, fast, CHEAP dual-ported memory). I think the problem will be more evident with parallelized RISC machines than CISC machines, although the probability of CISC compiler-writers actually using this architectural advantage is probably low. More likely what will happen are RISC machines plowing ahead into parallelism and people using huge amounts of cache to get around this problem. Then either an advance I can't see will happen in memory technology (which would be great!), or we're going to have to do more per main-memory instruction to decrease this problem. The return of main-memory macrocode and internal caching/microcode? Maybe. Would be a bizarre twist. Maybe someone will step back from our RISC code and say "Gee, these same patterns keep showing up- why don't we eliminate it and use a macrocode opcode for these?" Dunno. Then I suppose we'd end up applying what we've been pushed to do to support RISC implementations (GaAs, CMOS, etc) to RISC+ (slightly CISC-er RISC) implementations. Oh well, this probably belongs in comp.arch at this point... kevbop
dan@tinton.UUCP (03/28/90)
In article <1990Mar20.233504.4946@seri.gov> marshall@wind55.UUCP writes: >Will@cup.portal.com (Will E Estes) writes: > >>Finally, why is everyone so excited about RISC? > >Just a wild guess. Hardware guys like RISC, software guys like CISC. Actually, the *software* world seems to contain the large portion of RISC proponents. >RISC puts the work on the shoulders of the software folks. It is >easier to impliment RISC in hardware. WRONG. It simply changes the 'type' of work to be done. Given a certain board area for a processor board in a system, the board will be filled with chips, regardless of whether the CPU chipset is RISC or CISC. The hardware complexity of the BOARD is the same, with the following exception: RISC parts tend to run at higher clock freqs than their CISC counterparts, thus making it HARDER to design a RISC-based board. As for the hardware complexity of the chipset, it's probably a toss. The RISC chips are a design challenge in that they run at very high clock rates. Also, typically these parts have a hardwired instruction set, while I believe that CISC parts are usually microcoded (of course, I could be wrong...). >If I were developing software in assembler, I'd probably hate RISC. The software people actually have an easier time of it with RISC. a) you have less instructions to remember, and thus spend less time thumbing through the manual to try to find out whether the STRING_MOVE_CONVERT_ASCII_TO_INT_VECTOR_MULTIPLY instruction sets the carry flag. b) there are no superfast and glizzy instructions; thus, there is no temptation to badly structure a software system to try to make use of said instruction. this is important if you want to port the software system to another platform. c) if there are CISC-type functions that you commonly want to use, you can code them once and keep them around as a source library, similar to a library of commonly-used C routines that you may keep around. If you go to another platform, this library is probably straightforward (although time-consuming) to translate, since it is made up of rudimentary instructions that most likely have a one-to-one equivalent in the new instruction set. Admitedly, RISC takes a lot of the 'art and glamour' out of assembly programming. However, it is this artful use of complicated assembly instructions that causes software systems to be complicated, unreliably, unmaintainable, and nonportable. The simplification of the instruction set frees you up to apply your art at a higher level. >It is probably harder to write a compiler for RISC. HUH? Assuming you don't care about the performance of the generated code, it is a wash. If you do care, then RISC is the clear winner. The code generation section of the compiler (the only part of the compiler that will be drastically different between the two versions) is much less complex. This is basically because it has less to choose from. TRUE RISC, by my way of thinking, says that all instructions take equal time, and this time is not data-dependant. It is clearly easier to write a code generator/optimizer based on this assumption. Some commercial RISC parts do not have equal time per instruction, but it is close (much more so than typical CISC), and it is data-independant, which one can imagine is an important assumption for simlifying code generators. >If you use high-level languages, you may not care. >Users probably don't care unless one costs more for the same application >performance (which is all that really counts). Yes, you WILL care, even if you use high-level languages. The downside of RISC is that it is memory-hungry (for every complex machine instruction that you may have used in a CISC system, you may need 10 or 20 RISC instructions). The code that a compiler generates will take more memory space in a RISC system. Some estimate up to twice the space. This translates into more main memory for your system, as well as more disk storage space. Also, memory will be more expensive, since the typical RISC part will run faster and thus need higher memory speeds (or cache) to satisfy its faster instruction fetch rate. >Marshall L. Buhl, Jr. EMAIL: marshall@wind55.seri.gov ---------------------------------------------------------------- Dan Masi (dan@tinton.tinton.ccur.com) 201-758-7699 Concurrent Computer Corp. 106 Apple Street Tinton Falls, NJ 07724
dan@tinton.UUCP (03/28/90)
In article <8564@pt.cs.cmu.edu> ralf@b.gp.cs.cmu.edu.UUCP writes: >In article <10453@portia.Stanford.EDU> dhinds@portia.Stanford.EDU (David Hinds) writes: >}some RISC features. Why? Because it is fast? It seems to me that the >}80486 is instead the antithesis - and nemesis - of RISC technology. If >}we now have the ability to design a CISC processor so efficiently that >}most of its instructions take only a cycle or two, why move to a less >}complex architecture? The 80486 had sufficient circuit space left over >}for a respectable amount of support stuff, as well. You could say, well, > >Yeah, but how many RISC CPUs have 1.2 million transistors? That's something >like EIGHT to TEN times as many gates as the typical RISC CPU.... Nope. The 'typical' RISC CPU will have as many transistors as the typical CISC CPU. The commercial RISC CPU I am currently designing with has 1.0 million. They are just USED DIFFERENTLY (put to better use, IMHO). In a typical RISC part, you need less transistors for the CPU portion, thus you can include more support-type functionality (cache control, cache RAM, floating point, etc) on-chip. ---------------------------------------------------------------- Dan Masi (dan@tinton.tinton.ccur.com) 201-758-7699 Concurrent Computer Corp. 106 Apple Street Tinton Falls, NJ 07724