How many clock cycles does a RISC/CISC instruction take to execute?

Question

According to Digital Design and Computer Architecture by Harris and Harris, there are several ways to implement a MIPS processor, including the following:

The single-cycle microarchitecture executes an entire instruction in one cycle. (...)

The multicycle microarchitecture executes instructions in a series of shorter cycles. (...)

The pipelined microarchitecture applies pipelining to the single-cycle microarchitecture.

Architectures are often classified as either RISC or CISC. From RISC vs. CISC:

RISC processors only use simple instructions that can be executed within one clock cycle.

Since MIPS is RISC architecture, I am a litte confused by the above definitions and wonder if there isn't some sort of contradiction between them. More specifically:

1. If a RISC instruction can be split into shorter cycles (Fetch, Decode, ...), how can we say that it only takes one clock cycle to execute the whole instruction? Doesn't it take one clock cycle to execute each of the steps?
2. Does it really take one clock cycle to execute one RISC instruction? What happens, for example, if a cache miss occurs and the processor has to wait for slow DRAM? Shouldn't this prolong the execution of the instruction by quite a bit?
3. What exactly is one instruction cycle? Is it the time that it takes for one instruction to finish (i.e. one/multiple clock cycles)?
4. How long does one CISC instruction take in clock/instruction cycles?

Answer 1

The practical definitions of RISC and CISC are so muddied and blurred now they are almost meaningless. Now it is best to think of them as more about "philosophy", in the sense that a CISC architecture has a richer instruction set with more powerful individual instructions (e.g. DIV and the like) while a RISC instruction set is bare bones and fast, and leaves it to the compiler to implement complex operations. Even purportedly CISC instruction sets (like x86) are translated into internal instructions in both Intel and AMD chips and implemented more like RISC processors. To answer your questions:

1. The original academic RISC processors (and I think maybe the very first commercial versions) did indeed execute one instruction per cycle, including fetch and decode. This was possible because the datapaths were super clean because the operations of each stage were simple and well defined. (the tradeoff here is only very simple instructions can be implemented this way). Once it hit the real world things got blurred. Things like pipelining and superscalar architecture make a simple RISC/CISC dichotomy impossible.

2. The original RISC chips attempted to execute one instruction per cycle and they could if the data was available in the register file. Of course if the processor had to go to DRAM it would take a (lot) longer. RISC is about "attempting" to execute an instruction per cycle.

3. One instruction cycle is the time it takes between fetches.

4. In depends enormously on the instruction and the instruction set architecture. Even in a CISC architecture some instructions could execute very quickly (like a shift left or right for example). Some executed very slowly (10s of cycles or more). The VAX architecture (probably the pinnacle of the CISC philosophy) had instructions that were really complex. Incidentally, a CISC architecture is usually easier to program in assembly than a RISC architecture because it is almost like a high-level language!

Answer 2

The short answer

1. The steps in decoding and executing the instruction are executed in parallel with the next step of the previous instruction. This technique is known as pipelining. See On RISC Processors below.

2. A single-issue RISC architecture will typically average slightly less than one instruction per cycle due to wait states and time taken for load/store operations that hit memory rather than just being register to register. Delay slots give you an architectural hook that may allow you to get some of this time back. See On RISC processors below.

3. An instruction cycle is the length of time needed to execute an instruction. This will vary with architecture and (in some cases) instructions. For example, most instructions on something like a MIPS R2000/3000 take one cycle. Instructions involving memory access (load/store, branch) take more than one cycle, although the delay slots mean you may be able execute something else (possibly just a NOP) in the delay slot. Non-pipelined architectures can have instruction cycles of several clock cycles, often varying with the addressing mode. See On RISC processors, Traditional CISC architecures and Hardwired Architectures below.

   Multiple-issue designs can blur this concept somewhat by executing more than one instruction in parallel.

4. CISC processors can have instructions that take varying lengths of time. The exact number of clock cycles depends on the architecture and instructions. The varying number of clock cycles taken on CISC ISAs is one of the reasons they are hard to build into heavily pipelined architectures. See Traditional CISC architectures below.

The longer answer

For a single issue MIPS, SPARC or other CPU, all (for a first approximation) instructions issue in one cycle, although they can have something known as a 'delay slot.'

On RISC Processors

In this context, a single issue CPU is one where the CPU doesn't do any on-the-fly dependency analysis and parallel issuance of instructions in the way that modern CPUs do, i.e. they have just one execution unit that executes the instructions in the order they are read from memoty. More on this later.

Most older RISC processors are single-issue designs, and these types are still widely used in embedded systems. A 32-bit single-issue integer RISC core can be implemented in around 25,000-30,000 gates, so CPU cores of this type have very low power consumption and very small footprints. This makes them easy and cheap to integrate into SOC (system-on-chip) products.

RISC CPU designs are pipelined - processing the instruction is done in several stages, with each instruction being passed down the pipeline to the next stage every clock cycle. In most cases a single-issue pipelined CPU will execute something close to one instruction per clock cycle.

Some architectures have instructions like branching or load/store from memory where the additional cycle taken by the memory access is visible to the code.

For example, in a SPARC V7/V8 design the next instruction after a branch is actually executed before the branch itself takes place. Typically you would put a NOP into the slot after the branch but you could put another instruction into it if you could find something useful to do.

The MIPS R2000/R3000 architecture had a similar delay slot in the load/store instructions. If you loaded a value from memory, it would not actually appear in the register for another cycle. You could put a NOP in the slot or do something else if you could find something useful to do that was not dependent on the load operation you just issued.

If the memory was slower than the CPU, which was often the case, you might get additional wait states on memory accesses. Wait states freeze the CPU for one or more clock cycles until the memory access is completed. In practice, these wait states and extra time for memory accesses mean that single-issue CPU designs average slightly less than one instruction per clock cycle. Delay slots give you some possible opportunities to optimise code by executing some other instruction while a memory operation takes place.

Traditional CISC processors

CISC processors were designs that could have instructions taking varying lengths of time. Often they had more complex instructions implemented directly in hardware that would have to be done in software on a RISC CPU.

Most mainframe architectures and pretty much all PC designs up to the M68K and intel 386 were traditional microcoded CISC CPUs. These designs proved to be slower per-clock and used more gates than RISC CPUs.

Microcode

An example of a microcoded architecture (MOS 6502) can be seen in emulation here. The microcode can be seen at the top of the image.

Microcode controls data flows and actions activated within the CPU in order to execute instructions. By looping through the steps in the microcode you can activate the parts of a CPU, moving data through ALUs or carrying out other steps. Re-usable components in the CPU can be co-ordinated over multiple clock cycles to execute an instruction. In the case of the 6502 some pipelined actions could also be executed by the microcode.

Microcoded designs used less silicon than hard-wired chips at the expense of potentially taking several clock cycles to complete an instruction. Depending on the design, these CPUs would take varying lengths of time per instruction.

Hardwired architectures

Hardwired designs (not necessarily mutually exclusive with microcode) execute an instruction synchronously, or may have their own coordinators to do something across multiple clock cycles. They are typically faster at the expense of more dedicated hardware and are thus more expensive to implement than a microcoded design of equivalent functionality.

A famous example of this was the original Amdahl 470/6 CPU, which was a drop-in replacement for the CPU on certain IBM System/370 models. The Amdahl CPU was a hardwired design at a time when IBM's 370 CPUs were heavily based on microcode. The Amdahl CPU was about 3 times faster than the IBM CPUs they replaced.

Needless to say, IBM was not amused and this resulted in a court battle that ended up forcing IBM to open their mainframe architecture until the consent decree expired a few years ago.

Typically, a hardwired design of this type was still not as fast clock-for-clock as a RISC CPU as the varying instruction timings and formats didn't allow as much scope for pipelining as a RISC design does.

Multiple-issue designs

Most modern CPUs are multiple issue architectures that can process more than one instruction at a time within a single thread. The chip can do a dynamic dependency analysis on the incoming instruction stream and issue instructions in parallel where there is no dependency on the result of a previous computation.

The throughput of these chips depends on how much parallelism can be achieved in the code but most modern CPUs will average several instructions per cycle on most code.

Modern Intel and other x86/X64 ISA CPUs have a layer that interprets the old-school CISC instruction set into micro instructions that can be fed through a pipelined RISC-style multiple issue core. This adds some overhead that is not present on CPUs with ISAs that are designed for pipelining (i.e. RISC architectures such as ARM or PowerPC).

VLIW designs

VLIW designs, of which the Intel Itanium is perhaps the best known, never took off as mainstream architectures, but IIRC there are a number of DSP architectures that use this type of design. A VLIW design makes multiple-issue explicit with an instruction word containing more than one instruction that is issued in parallel.

These were dependent on good optimising compilers, which identified dependencies and opportunities for parallelism, dropping instructions into the multiple slots available on each instruction word.

VLIW architectures work quite well for numerical applications as matrix/array ops tend to offer opportunities for extensive parallelism. The Itanium had a niche market in supercomputing applications for a while, and there was at least one supercomputer architecture - the Multiflow TRACE - was produced using an ISA of this type.

Memory and caching

Modern CPUs are much, much faster than memory, so direct reads from memory can generate hundreds of wait states which block the CPU until the memory access completes. Caching, now done in multiple layers, holds the most recently used memory locations in the cache. As CPUs typically spend the vast majority of time executing code in loops this means you get good hit rates of re-using memory locations that you've used recently. This property is called 'locality of reference.'

Where you get locality of reference the CPU can operate at close to optimum speed. Cache misses down to the next level incur a number of wait states; cache misses down to main memory can incur hundreds.

Thus, the actual throughput of CPU chips can be heavily dependent on the efficiency of memory access patterns. Whole books have been written on optimising code for this, and it's a complex topic in its own right.

Answer 3

It's a simplification for students.

Every non-trivial processor is pipelined. There is a prefetch unit shovelling instructions in one end, a number of execution units in the middle doing actual work, and an issue unit responsible for declaring instructions completed after the write to register or memory has finished. If there are multiple execution units (say, an integer ALU, a floating point ALU, and vector unit) it may be possible to issue (sometimes called "retire") multiple instructions per clock cycle. How can a CPU deliver more than one instruction per cycle? goes into lots more detail on this.

As you say, what if there is a cache miss delay? Intel Hyperthreading is a novel solution to this: two lots of CPU state registers, one lot of control logic and issue units. As soon as one virtual CPU stalls, swap to the other's state. (this is a gross oversimplification itself)

The result of this is that modern CPU manuals give much vaguer instruction timings, and it's much harder to write cycle-accurate timing code, if for example you're trying to output video in real time from hardware that should not be capable of it.

(Specific answer to "How long does one CISC instruction take in clock/instruction cycles?" is "look in the manufacturer's reference manual and it will have timings per instruction")

Answer 4

The other guys have written a lot of good material, so I'll keep my answer short: In the old days, (1980's here), the 8 bit processors of the day (6800, 6502, Z80, 6809 and others) were considered CISC. Some instructions could execute in 2 clock cyles but these were simple instuctions such as setting/clearing flag bits in a processor status register. Other instructions could take anywhere from 2-6 and even up to 9 clock cycles to execute. These processors had some fairly powerful instructions, the Z80 had some memory block clearing instructions which would write the same value in to a series of bytes in memory, effectively clearing a large block in a single instruction, just set up a few registers and execute the LDIR instruction (load, increment and repeat).

The 6502 processor (from memory) had 56 instructions but 13 addressing modes creating a powerful instruction set.

RISC came a long and adopted a different approach, have a handful instructions which all execute in a single clock cycle. The programs tend to be longer and occupy more memory because the instructions are simple in what operations they carry out so you need more of them.

If I recall correctly the first attempt at a RISC architecture was either the transputer or Acorn Risc processor?