Home > Blockchain >  How RISC reducing cycles while having many instructions?
How RISC reducing cycles while having many instructions?

Time:07-24

I quote from this site: cs.standford.edu

The CISC approach attempts to minimize the number of instructions per program, sacrificing the number of cycles per instruction. RISC does the opposite, reducing the cycles per instruction at the cost of the number of instructions per program.

It said RISC reducing the cycles per instruction at the cost many instructions will be used, how it possible?

AFAIK, one cycle of CPU is defined as:

  • fetch (instruction)
  • decode (instruction)
  • execute

So can I conclude more instructions mean more cycles?

CodePudding user response:

No, one cycle is one period of the clock, not of executing a whole instruction. (e.g. for a 100MHz CPU, one clock cycle is 1/100MHz, or 10 nanoseconds.)

RISC was designed to make pipelining easier (and thus possible in the early 1980s) so those stages of execution could overlap in separate instructions. See Modern Microprocessors A 90-Minute Guide! and https://en.wikipedia.org/wiki/Classic_RISC_pipeline

So can I conclude more instructions mean more cycles?

No. Basically unrelated.

The maximum complexity of any single instruction is what matters, not how many different opcodes the CPU supports. Look at modern AArch64 and PowerPC for example: many different instructions (including SIMD), but each one has an upper limit on how much it can do, so they generally don't need microcode. A limit on the number of register reads and writes per instruction, any computation is something you can build into a pipelined ALU, and memory is only accessed by load/store instructions that don't also do math. (The last point is what makes a machine a "load store" machine.)

The part of the RISC idea that's still truly useful is Reduced Instruction-Set Complexity. e.g. not things like x86's rep stosb (arbitrary-length memset). And also avoiding stuff like x86's partial-flag updates on instructions like rol that leave some FLAGS unmodified but write others. That can be worked around by modern high-performance CPUs, but is still a penalty.

And most obviously, memory-destination instructions like add [rdi], eax that internally have to load / add / store are very non-RISC.

  • Related