From: willmore@iastate.edu (David Willmore) Subject: Re: Intel, the Pentium and Linux Date: Wed, 28 Apr 1993 23:36:05 GMT
rabagley@termite.occ.uc.edu (Ross Bagley) writes:
>>There are just too many factors at play to be able to say that. A well
>>designed CISC should *always* be able to execute more instructions than
>>a RISC processor *per cycle*. The differences lie in that the CISC chip
>>will have taken much more work to design and won't be able to be run at
>>the clock speed that the RISC processor can.
>
>What? I'm thinking that you are a little confused, because what you stated
>has little to do with the RISC paradigm. Per cycle... hmmm is that "per
>instruction cycle"? If so then there are some problems with your statement.
>First of all instruction cycles are not a good base to use for comparison
>because one of the things inherent in RISC is a smaller instruction cycle.
>Smaller instruction set -> simpler decoder -> smaller instruction cycle.
You're right that I was a little vague. :) I had several assumptions that
I didn't state. One thing that we should start with is that reality has
little to do with the RISC paradigm.
For a RISC processor to execute a job equal to one CISC instruction, it has
to execute quite a few more instructions. A RISC processor will take more
cycles to complete the same amount of work than a CISC processor. So,
measured in CISC instructions, a CISC processor gets more CISC instructions
done per cycle than a RISC does. The catch is that the RISC can execute
much more quickly and has much more flexible control of the CPU.
Make sense?
>Second, many CISC machines have commonly used instructions which take more
>(sometimes much more) than a single instruction cycle to complete. RISC
>chips (at least strict RISC, which many RISC chips are able to conform to
>without difficulty) do not have multiple cycle instructions (divide by 2 and
>other clock cycle/pipeline modification notwithstanding).
Sure, but they tend to do more work. The whole point of my comment is that
Intel's assertion that since the Pentium does as much work at 66Mhz as, say,
an 80 Mhz Alpha, that the Pentium is a better processor. It doesn't mean
that at all. It means that the Alpha should be running much faster, which
it can and, in the 200 Mhz Model 10000, it does.
>Third, a CISC processor running a single large complex instruction (such as
>string copy) may (in many cases will) take longer than a RISC processor
>running a program segment to do the same thing. This is at the same clock
>speed and with equivalent clock dividers or whatever in place to make it
>fair. This is because a RISC compiler can remove many test cases at
>compile time which the CISC processor must test every time the instruction
>is called at run time.
Not likely. More likely a modern CISC processor would win because (at the
same clock speed) there are fewer instruction fetches (i.e. none) in the
CISC case and therefore less memory bandwidth wasted for I fetch. In fact,
the memory system and memory interface will play a much more inportant
part of this than the CPU architecture.
>If you mean clock cycle, then there is no basis for comparison because
>each design can use the clock however it pleases.
No kidding? Geesh, you mean calling an Alpha 200Mhz doesn't meant that
*everything* in that CPU system runs at 200Mhz? Really? As a matter of
fact, the Alpha always clocks it's memory bus at one half of the CPU
clock rate and in some cases as slow as one eighth the speed. Hmmm.
To make it even more interesting, the R4x00 family does the opposite.
They claim the cpu is 75Mhz when internally, it runs at 150Mhz. Only
the bus runs at 75Mhz. Maybe you meant to say 'there is no *meaningful*
comparison.' :)
>Everything is moving to RISC, even the x86 line has had much RISC in it
>since the 386... 486 has loads of RISC and the two pipeline Pentium will
>have even more. The more complex instructions are actually internal
>programs of the less complex ones, and that's just the way they chose to
>do it. the addressing modes are the only thing that I am aware of which
>Intel has not shifted to a RISC paradigm, and they really can't do that
>without heavily increasing the register count which might stop them from
>being able to have the backwards compatibility everyone values so much.
You mean 'that the lemmings value so much'? ;)
>I'm not an expert but I did just take a class which went over this topic in
>detail, and much of it is still fresh in my mind. I don't mean to flame
>anyone, but it appeared to me that there was a pretty large misconception
>about the concept of RISC vs. CISC and I hope that this could help
>to clear some of the misunderstandings up.
Trust me, the only way to clear this up if for everyone out there to take a
class like the one that you mention. I've taught one before. The most
important thing that most students learn is that RISC is not a system, it's
a 'holy grail.' It's a guideline for one way of making processors. There
are no 'hard and fast' rules. You have to try every little trick and see
if it works. If it does and it's worth the expense, keep it, if not, chuck
it and try something else.
I admit that my remarks may have been confusing and misleading, but they
weren't inacurate. ;)
I'm sorry for getting us all off the track. :) We'll now resume the normal
Linux discussion.
Later,
David
-- =========================================================================== willmore@iastate.edu | "Death before dishonor" | "Better dead than greek" | David Willmore | "Ever noticed how much they look like orchids? Lovely!" | ===========================================================================