1.1.2 - RISC and CISC processors
Processors can offer different kinds of instructions for doing the same job. You will compare RISC and CISC approaches by following the work their instructions express and the hardware that implements it. Their useful trade-offs depend on the program, implementation and constraints of the device.
Simple and complex instruction sets
An instruction set is the collection of machine instructions a processor can execute. Reduced Instruction Set Computer (RISC) and Complex Instruction Set Computer (CISC) describe different design approaches to that set and its implementation. “Reduced” refers to a relatively small, simple set of instruction types, not a computer's storage size or an assurance that each program contains fewer instructions.
In the traditional comparison, RISC uses relatively simple, regular instructions, often fixed-length, with fewer addressing modes. Arithmetic commonly works on registers, with separate load and store instructions for memory transfers. Regular instructions can make decoding and pipeline scheduling simpler.
CISC traditionally provides a larger, more varied instruction set, often with variable-length instructions and more addressing modes. Some instructions express several low-level actions or operate directly on memory. A single such instruction may therefore represent work that takes several simpler instructions in another design. More varied operations require more complex decoding/control hardware in the traditional model.
These are design tendencies, not universal guarantees about every modern chip. RISC instructions are often designed for simple execution and efficient pipelining; not every instruction on every RISC processor necessarily completes in one clock cycle. Modern CISC processors can also pipeline and can internally translate complex instructions into simpler operations. The external instruction set and the internal implementation are related but not identical.
The same work can need different instruction counts
The number of instructions in a program depends on what each instruction can do. To compare two instruction sets, hold the desired result constant rather than comparing one arbitrarily selected instruction from each.
Here are two invented instruction sets, with explicit meanings. They illustrate the principle rather than reproduce a real processor. The task is to add memory[A] and memory[B], then store the sum in memory[C]. LOAD R, X copies memory[X] into register R; ADD R1, R2 adds R2 into R1; STORE X, R copies R into memory[X]. The complex instruction ADDSTORE C, A, B performs the entire stated task.
Simple-instruction version
LOAD R1, A
LOAD R2, B
ADD R1, R2
STORE C, R1
Complex-instruction version
ADDSTORE C, A, B
For memory[A] = 7 and memory[B] = 9, both versions store 16 in memory[C]. In the first, R1 and R2 become 7 and 9, R1 becomes 16, then 16 is stored. In the second, the hardware must still obtain both values, add them and write the result, even though one machine instruction expresses those actions. A shorter listing does not remove the underlying work.
If the simple instructions each take one cycle and this particular complex instruction takes five cycles, the simple version takes four cycles and the complex version five. If the complex instruction instead takes three cycles, that conclusion reverses. Those are stated hypothetical timings: instruction count alone cannot establish which design is faster. Encoded instruction length also matters when comparing program memory usage; fewer instructions can make code compact, but count is not automatically byte size.
Hardware, pipelines and program size
Simple, regular instructions can make a processor's control circuitry less complex. In a traditional RISC comparison, fewer instruction forms and addressing modes mean less decoding complexity, which can support efficient implementation and lower power use. Lower power and heat are valuable where battery life or cooling capacity is limited. Actual power consumption also depends on fabrication, frequency and workload, so the label alone is insufficient evidence.
Regular stage behaviour also makes instructions easier to pipeline. If many instructions follow similar steps, the designer can overlap them predictably. CISC's varied lengths and complex operations can make decoding and stage timing more difficult. This means “more challenging to implement”, not “CISC cannot use pipelining”. Contemporary implementations overcome some of these difficulties internally.
On the software side, a RISC compiler may need more simple instructions to express a complex operation. This can increase code storage and instruction-fetch demand compared with a suitable compact CISC encoding. CISC can provide complex operations that reduce the number of instructions and support existing software compiled for that instruction set. There is still a cost in implementing and decoding those operations.
A fair comparison thus pairs a feature with its consequence: regular simple instructions can ease decoding/pipelining; richer instructions can express more work per instruction and offer compact code for appropriate tasks. Neither “smaller instruction set” nor “fewer instructions” is a complete argument about total execution time, energy or memory use.
Choosing for a device and its software
Processor suitability follows from requirements, rather than from an absolute ranking of instruction sets. A portable measurement device with limited battery and cooling may benefit from an efficiently implemented RISC design. Connect the choice to simpler control, efficient execution and potential lower energy use, then confirm that its software and workload are supported.
A desktop system that must run existing software compiled for a particular CISC instruction set has a different priority: compatibility. A processor supporting that instruction set can execute the existing machine code without translating it to an unrelated set. Compatibility is a specific practical benefit; it does not prove that every new application would run faster on CISC.
Memory-constrained software may benefit from compact instruction encoding, but compare actual compiled code sizes for the intended program. A performance-critical program should be measured on candidate implementations. Clock frequency, cache, cores, compiler choices and memory access can outweigh a simple RISC/CISC label.
For example, recommend an energy-efficient implementation for a battery-powered logger because it must operate for long periods without much cooling. Recommend a compatible implementation for an organisation retaining an existing software library because avoiding a software rewrite is important. Both are contextual judgements with a reason; neither is “all mobile devices are RISC” or “all desktops are CISC”.