Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I don't think that's sufficient to make it a RISC processor. That would 
>> mean both the PDP-11 and the X-560 were RISC processors.
> 
>   Who says they weren't?

Maybe because both were obsolete before the term RISC was invented? 
Because neither had lots of variables? Because they both had complex 
addressing modes beyond LOAD and STORE? Because they both had 
instructions that took variable numbers of cycles?

*I* say they weren't. They might meet your definition of RISC, but I'm 
pretty sure your definition doesn't align with the definitions of most 
others when talking about it.

>   I don't think RISC has been ever defined to mean "you can only perform
> very simple operations with a single opcode". RISC stands for *reduced*
> instruction set computer, not *simplified* instruction set computer.

No, but it also means the ALU only talks to the registers, and there 
aren't any complex addressing modes. Neither of those are true of the 
two CPUs I named here.

>   I don't really understand where the concept of a RISC opcode being
> *simple* has come from.

Well, because that made it fast. Read the link I pointed you to. The 
point of reducing the instruction set and addressing modes was to make 
it faster and to make more room for registers, by eliminating the 
microcode.

>   What makes RISC processors simpler is that their fetching and decoding
> steps, pipelines and code caches are simpler because all the opcodes have
> exactly the same size and the meaning of the bits in each opcode has
> been fixed. CISC processors are more complicated because of variable-sized
> opcodes which can contain almost anything.

Again, I think you're oversimplifying. You're using a definition for 
RISC at odds with the definition created by the people who created the 
term. By leaving off significant portions of the original "meaning" of 
the term, you're turning it into a binary situation. However, the 
original meaning of RISC has several components (addressing modes, 
increased number of registers, simplified decoding), and processors 
nowadays combine these things to different degrees.

I think if you asked a modern CPU designer whether he'd consider a 
hardware operation equivalent to sprintf() to be "RISC", you'd almost 
invariably get the answer "no".

-- 
Darren New / San Diego, CA, USA (PST)
  Helpful housekeeping hints:
   Check your feather pillows for holes
    before putting them in the washing machine.

Post a reply to this message