rtrauben@cortex.Sun.COM (Richard Trauben) (04/05/90)
> How about a definition of RISC (we can all agree upon): This reminds me of the meta-religous arguments regarding how many angels fit on the head of a pin. -:) Given that as a disclaimer, here's my .02$ contribution: >3) can an architecture which is not load/store qualify as RISC? No. >5) is it RISC if it doesn't have delayed load? delayed branch? Yes. >6) does an instruction set with variable-length instructions qualify as > RISC? No. The remaining 4 points have arbitrary answers and seem peripheral to the general design philosophy. However, the more state that needs to be kept for complex instructions that required implied sequences will complicate error recovery in the machine. This provides sufficient encouragement to ISA designers to eliminate complexity until system-wide performance is shown to suffer. Apply Occam's razor, your milage may vary. Richard Trauben Sun MicroSystems Mt. View, California
mshute@cs.man.ac.uk (Malcolm Shute) (05/02/90)
>In article <1192@m1.cs.man.ac.uk> I wrote: >>[A suggestion that we should define a metric so that RISC vs CISC was >>no longer a black/white issue, but a sliding scale, say from 0.0 to 1.0] In article <1990Apr27.161912.15649@robohack.UUCP> sanwalk@robohack.UUCP (A. Roy Sanwalka) writes: >[Some sensible objections on grounds of implementation vs architecture] >[A good reductio ad absurdum indication (it didn't have the power of a >proof) that defining ultimate RISC and CISC instruction sets won't give >us a sensible metric] He also writes: >Sure thing Malcolm, whatever you say... I take your point... and the text which follows won't be any closer to sanity I'm afraid (I'm relying on everyone's ability to hit the 'n' key when they wish). HOWEVER... I would like to stretch the idea just a bit further, and ask the net if they can see any glimmer of hope in the following idea: Since measuring the instruction set complexity directly has been shown to be unworkable (the reductio ad absurdum above), suppose we were to adopt an indirect method. Suppose we were to define a metric which is the quotient of: (chip area of random logic) / (total chip area) we would have to *define* what is meant by 'area of random logic', for instance: (total chip area) - (area of regular logic) and then *define* what *can* be included in 'regular logic', for example: 1) area of chip that acts as cache memory 2) any area that acts as a register bank 3) any area that contains a regular bus (at least a byte wide) We would have a metric which RISCs would tend to score low on, and CISCs would tend to score high on. What would be the point of it all? The next time we have a "This is a RISC. No, it's a CISC" discussion, the above coefficient might lend a *little* weight to the argument. Notice that I am not claiming that it will *define* the difference between RISC and CISC, just act as metric which might shed some extra light on the question. Notice also, that I recognise that this metric is most definitely measuring implementation rather than architecture, which is a pity, but there we are. As I say, I would be interested in any constructive response to such a suggestion. As I admitted in my original posting, it's all a bit irrelevent in the end (so I would appreciate that flames and non constructive responses be converted into the silent hitting of the 'n' key). -- Malcolm SHUTE. (The AM Mollusc: v_@_ ) Disclaimer: all
baum@Apple.COM (Allen J. Baum) (05/03/90)
[] >In article <1252@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >>In article <1192@m1.cs.man.ac.uk> I wrote: >>>[A suggestion that we should define a metric so that RISC vs CISC was >>>no longer a black/white issue, but a sliding scale, say from 0.0 to 1.0] > >Since measuring the instruction set complexity directly has been shown >to be unworkable (the reductio ad absurdum above), suppose we were to >adopt an indirect method. Suppose we were to define a metric which is >the quotient of: As the guy said in the movie "Big": I don't get it. Why do you need this metric? Will you use it to decide which processor to buy? This is a bad idea. You should pick a processor on the basis of things like: cost performance (for YOUR application mix!!!!!) ease of integrating into a system software base support chips second sources whether you think the supplier will be around in a few years ease of working with the supplier architectural upgrade paths how easy/hard performance upgrades will be how easy/hard next-generation will be to design (add your own-- I'm curious what other people think are important) These are not in priority order. The order depends on what is important to YOU, like the application mix, which is specific to YOU. If a CISC were to come out ahead by the above metrics (which don't even care about what the instruction set looks like, you'll notice), which should the RISC/CISC label make a difference? Like, who cares? Again, my point is that RISC is a design philosophy that, if used, will allow a processor design to look its best, using the above metrics. -- baum@apple.com (408)974-3385 {decwrl,hplabs}!amdahl!apple!baum
lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) (05/04/90)
In article <1252@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: >>In article <1192@m1.cs.man.ac.uk> I wrote: >>>[A suggestion that we should define a metric so that RISC vs CISC was >>>no longer a black/white issue, but a sliding scale, say from 0.0 to 1.0] >The next time we have a "This is a RISC. No, it's a CISC" discussion, >the above coefficient might lend a *little* weight to the argument. The problem with this debate is that the premise is incorrect. The unstated premise is that RISC vs CISC is an important performance metric worth measuring. But, what definition of "RISC" gives the distinction a difference? Is there an architectural definition of RISC? Better to ask: Why have so many implementations of VAX, 68k, etc, been "slow" (such that comparable silicon implementations of competing architectures, such as MIPS, have been faster)? The difference is simply that the "slow" machines all have operand specifiers which need to be decoded. Therefore, a meaningful definition of RISC vs CISC is just that: simple operand specifiers vs decoded operand specifiers. All you need to do is come up with some sort of phrasing of that fact so that the acronyms are RISC and CISC :-) On a related tangent, for at least five years I have been hearing rumors of "clever" operand specifier decode schemes which will obliterate this problem and make VAX, 68K, etc. look just as fast as "RISC"s. For some reason, these schemes were always just around the corner, but, as soon as they hit, would show that "RISC" was just a flash in the pan. Again, with new implementations of "RISC"s coming out, more hints have been dropped in various trade rags, etc. Does anyone know for sure whether or not such schemes were used in the VAX 9000, 68040, or other places, and, if so, how much performance has been regained, and, at what cost in gates/transistors/chip real estate/etc.? For example, if it took a large translation buffer of some sort to do it, how large? Could three operands be decoded in parallel? How are deferred address modes supported, and do they cause serialization? Hugh LaMaster, M/S 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)604-6117
baxter@ics.uci.edu (Ira Baxter) (05/04/90)
lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) writes: >In article <1252@m1.cs.man.ac.uk> mshute@cs.man.ac.uk (Malcolm Shute) writes: [ discussion about RISC metric deleted] >The problem with this debate is that the premise is incorrect. The unstated >premise is that RISC vs CISC is an important performance metric worth >measuring. But, what definition of "RISC" gives the distinction a >difference? Is there an architectural definition of RISC? >Better to ask: Why have so many implementations of VAX, 68k, etc, been "slow" >(such that comparable silicon implementations of competing architectures, >such as MIPS, have been faster)? >The difference is simply that the "slow" machines all have operand specifiers >which need to be decoded. Therefore, a meaningful definition of RISC vs >CISC is just that: simple operand specifiers vs decoded operand specifiers. >All you need to do is come up with some sort of phrasing of that fact so >that the acronyms are RISC and CISC :-) If this were all there were to it, why couldn't one decode an instruction on fetch from main memory, and simply store the decoding information along with the PC value into the I-cache rather than storing the instruction there? A cache with a 50nS hit, 300nS miss, 95% hit rate would deliver roughly 16 million *decoded* instructions per second to the CPU. Just a random thought. -- Ira Baxter
mash@mips.COM (John Mashey) (05/04/90)
In article <26407B03.9044@paris.ics.uci.edu> baxter@ics.uci.edu (Ira Baxter) writes: >>The difference is simply that the "slow" machines all have operand specifiers >>which need to be decoded. Therefore, a meaningful definition of RISC vs >>CISC is just that: simple operand specifiers vs decoded operand specifiers. >>All you need to do is come up with some sort of phrasing of that fact so >>that the acronyms are RISC and CISC :-) >If this were all there were to it, why couldn't one decode an instruction >on fetch from main memory, and simply store the decoding information >along with the PC value into the I-cache rather than storing the instruction >there? A cache with a 50nS hit, 300nS miss, 95% hit rate would deliver >roughly 16 million *decoded* instructions per second to the CPU. This kind of thing has been done, of course, and is certainly one of the good potential ways for CISCs to get faster. Of course, it costs, because now you've got another hunk of storage that wants to be fast and bigger than a register set, as well as extra circuitry for saving the decoded state, some really wide datapaths, potentially (consider the expanded form of the longest VAX instructions... obviously, this would work better with X86 or 68K), appropriate mechanisms for invalidation in addition to the cache invalidation. Anyway, this is certainly a plausible method, especially when you get lots more transitors on a chip. On the other hand, at the same level of technology, the RISC gets to use the same space for other useful things. Finally, even with pre-decoded, OTHER CISC-typical things still are impediments, like: condition codes with single-CC bottlenecks unaligned addressing and need to cope with multiple translations and exceptions in middle of pipeline, per data reference less registers Also, let me agree with various posters, who think that getting a really solid metric of RISC-vs-CISC is silly. I give a talk that starts: "How many of you in audience use RISCs?" (some, more than used to) "How many use CISCs?" (lots) "How many aren't sure what's in there?" (laughs) "How many could care less, as long as it's, fast, cheap, and runs your s/w?" (all hands) (and of course, as baum points out, there are plenty of other relevant metrics) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash DDD: 408-524-7015 or 408-720-1700 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Publius@dg.dg.com (Publius) (05/04/90)
In article <26407B03.9044@paris.ics.uci.edu> baxter@ics.uci.edu (Ira Baxter) writes: >If this were all there were to it, why couldn't one decode an instruction >on fetch from main memory, and simply store the decoding information >along with the PC value into the I-cache rather than storing the instruction >there? A cache with a 50nS hit, 300nS miss, 95% hit rate would deliver >roughly 16 million *decoded* instructions per second to the CPU. The time is not spent in instruction decoding per se. Rather, it is due to the fact that a CISC instruction has to be broken down into a few "micro-operations" to be handled by hardware. By breaking down the CISC instruction barrier among micro-operations, RISC allows better pipelining and micro-parallelism and thus achieves better performance. -- Disclaimer: I speak (and write) only for myself, not my employer. Publius "Old federalists never die, they simply change their names." publius@dg-pag.webo.dg.com