CISC and RISC
CISC
Until 1970, compilers were not yet mature enough, and not many people trusted them, so many programs were still written in assembly language. As such, people generally thought that the instruction set should be richer and the instructions themselves should be more powerful. Also, in the 1970s, memory sizes were only a few KB to tens of KB. To load more programs into such a small memory, the machine instructions had to be designed very precisely to reduce the storage space the programs took up. That is, the following requirements existed:
- It should be possible to complete more tasks with a single machine command. Instead of commands like ‘
Extend right leg,Stop,Extend left leg,Repeat this motion to the water fountain,...’, a single command is needed: ‘Give me a glass of water’. - Machine instructions should be variable in length, so that the storage space occupied by the program itself can be reduced.
- Machine instructions should be highly encoded to save space.
From these requirements, CISC (Complex Instruction Set Computer) was born. The x86 architecture is based on CISC, and the manufacturers that produce these x86 processors are Intel and AMD.
Microcode
At this time, CPU instruction sets were all hardwired. That is, each stage, including instruction fetch (IF), instruction decode (ID), and Execute (EX), was directly controlled by a specific circuit. This method was very efficient in executing instructions, but it was very inflexible, making it difficult to respond to changes in the instruction set.
The essence of the problem was that changing hardware was very cumbersome, but software could be easily changed. If the operations included in most instructions are defined as small programs composed of simpler instructions and stored in the CPU, there is no need to design dedicated hardware circuits corresponding to all machine instructions. In other words, software replaces hardware. This simpler instruction is microcode. When adding more instructions, the main work is focused on modifying microcodes, and hardware modifications are rarely required, so the complexity of CPU design can be reduced.
However, bugs cannot be avoided in code. Microcodes were no exception. The problem was that fixing bugs in microcodes is much more difficult than fixing bugs in general programs, and microcode design consumes a lot of transistors. In 1979, David Patterson took on the important task of improving microcode design and published a paper on the subject. However, he soon changed his mind. He thought that the complex problems caused by microcode were very difficult to solve and that microcode itself was the problem to be solved.
RISC
David Patterson made a key point: instructions that are thought to improve performance of CISC are actually intercepted by microcode inside the CPU. The design idea of microcode is to translate complex machine instructions into relatively simple machine instructions inside the CPU, so the compiler is unaware of this process. Therefore, if there is a bug in the microcode, there is nothing the compiler can do to avoid it. David Patterson also found that some complex machine instructions execute more slowly than several simple instructions that do the same thing.
This led to the birth of RISC (Reduced Instruction Set Computer), and this philosophy is mainly reflected in the following three aspects:
- It is a very simple idea, removing complex instructions and replacing them with a number of simple instructions. The idea of reducing the instruction set does not mean that the number of instructions in the instruction set is reduced, but that the operations required for each instruction are simpler. For example, a CISC instruction may mean the entire process of ‘eating’, while a RISC instruction may mean ‘taking a bite’, which is one small step in that process.
- In CISC, the CPU hides the execution details of machine instructions, such as microcode, from the compiler, so the compiler can do nothing about it. However, CPUs using RISC provide more details to the compiler.
- In CISC, IF, EX, and WB operations can all be performed with just one machine instruction. However, this is taboo in RISC. RISC instructions can only process data in registers, and cannot directly process data in memory. That is, instructions other than
LOAD/STOREcannot access memory.
Obviously, programs using RISC require more storage space than CISC, which makes it more cumbersome for programmers who write code in assembly language. However, the original intention of RISC design was not to have programmers write code in assembly language directly, but to leave this task to the compiler, which would automatically generate specific machine instructions.
RISC instructions are very simple, so they do not require complex hardware structures to interpret the code within the CPU, which saves more transistors. These transistors can then be used for other functions of the CPU. What is more important is that each instruction is very simple, so that, except for memory-related instructions, the execution time is almost the same for all of them. Therefore, execution efficiency can be improved through pipelining. Pipelining does not shorten the execution time of one machine instruction, but increases the throughput.
If you can’t beat them, join them
In the mid-1980s, commercial CPUs using RISC began to appear. By the late 1980s, CPUs designed using RISC were easily outperforming CISC designs in performance. CISC entered its dark ages, and if it were to abandon CISC and introduce RISC now, compatibility with chips that had already been sold would be a problem.
The way to turn the situation around was to use the concept of a function interface. The advantage of using a function is that the code using the function does not need to be changed as long as the function’s interface does not change. Since an interface to a CPU is a set of instructions, even if the set of instructions cannot be changed, the internal implementation of the CPU, that is, the method of executing instructions, can be changed. In other words, CISC instructions are also converted to RISC instructions inside the CPU. Instructions similar to these RISC instructions are called micro-operation. The micro-operations are all very simple and their execution times are almost the same, so pipelining can be also utilized.
Hyperthreading
In addition to making CISC look like RISC, the CISC camp also developed another technology called hyperthreading, also called hardware thread. This technology creates an illusion in the operating system that there are multiple logical CPU cores, when in reality there is only one physical CPU core.
Usually, the pipeline cannot always be fully filled due to dependencies between instructions, and eventually slots will occur. In this case, when there is only one instruction stream, the CPU has limited choices in choosing which instructions to place in a slot. Therefore, the concept of hyperthreading is to introduce an additional instruction stream and select instructions from two instruction streams.
Technically speaking, an hyperthreading core consists of two register files and two instruction decode units, but with a single ‘back end’ for executing instructions, and a single shared L1 cache. This design enables an hyperthreading core to run two independent threads, while requiring fewer transistors than a dual core CPU, thanks to the shared back end and L1 cache. This sharing of hardware components also results in lower instruction throughput relative to a comparable dual core CPU, because the threads contend for these shared resources.
The important thing here is that software threads, that is, threads that programmers can recognize, are created, scheduled, and managed by the operating system. On the other hand, hyperthreading, which corresponds to hardware threads, is a function of the CPU hardware and has nothing to do with the operating system.
Hyperthreading technology was proposed in the CISC camp, but this technology can also be introduced to RISC, and hyperthreading can be seen being used in some high-performance RISC-based CPUs.
References
[1] 루 샤오펑. 2024. 컴퓨터 밑바닥의 비밀, 길벗
[2] J. Gregory, Game Engine Architecture, Third Edition, CRC Press
