From: rabagley@termite.occ.uc.edu (Ross Bagley) Subject: Re: Intel, the Pentium and Linux Date: Tue, 27 Apr 1993 20:32:38 GMT
>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.
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).
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.
If you mean clock cycle, then there is no basis for comparison because
each design can use the clock however it pleases.
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.
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.
Back to comp.os.linux... ;)
-- _____________________________________
_______ | |
/\______\ | rabagley@ddt.occ.uc.edu |
/ / ___ /_____ ______ ______ | |
/ / /_\/ /______\\_____\\_____\ | Life would be so much easier if |
/ / _ __// ___ // ___// ___/ | we could just see the source code |
/ / / \ \ / /_\/ //___ //___ / | -Dave Oleson SGI |
\/_/ \_\\_____//_____//_____/ |___________________________________|