Microcode
In processor design, microcode serves as an intermediary layer situated between the central processing unit (CPU) hardware and the programmer-visible instruction set architecture of a computer, also known as its machine code.
While microcode is utilized in Intel and AMD general-purpose CPUs in contemporary desktops and laptops, it functions only as a fallback path for scenarios that the faster hardwired control unit is unable to manage.
Through extensive microprogramming, microarchitectures of smaller scale and simplicity can emulate more robust architectures with wider word lengths, additional execution units, and so forth.
This approach provides a relatively straightforward method of ensuring software compatibility between different products within a processor family.
[3] At the hardware level, processors contain a number of separate areas of circuitry, or "units", that perform different tasks.
In most designs, additional high-performance memory, the register file, is used to store temporary values, not just those needed by the current instruction.
So to add two numbers, for instance, the compiler may output instructions to load one of the values into one register, the second into another, call the addition function in the ALU, and then write the result back out to memory.
[7] Complex digital processors may also employ more than one (possibly microcode-based) control unit in order to delegate sub-tasks that must be performed essentially asynchronously in parallel.
Engineers normally write the microcode during the design phase of a processor, storing it in a read-only memory (ROM) or programmable logic array (PLA)[10] structure, or in a combination of both.
Microcode simplified the job by allowing much of the processor's behaviour and programming model to be defined via microprogram routines rather than by dedicated circuitry.
Architectures with instruction sets implemented by complex microprograms included the IBM System/360 and Digital Equipment Corporation VAX.
A processor's microprograms operate on a more primitive, totally different, and much more hardware-oriented architecture than the assembly instructions visible to normal programmers.
[citation needed] In this way, microprogramming enabled IBM to design many System/360 models with substantially different hardware and spanning a wide range of cost and performance, while making them all architecturally compatible.
[16] The outcome of this design was that customers could use a low-end model of the family to develop their software, knowing that if more performance was ever needed, they could move to a faster version and nothing else would change.
Early minicomputers were far too simple to require microcode, and were more similar to earlier mainframes in terms of their instruction sets and the way they were decoded.
While companies continued to compete on the complexity of their instruction sets, and the use of microcode to implement these was unquestioned, in the mid-1970s an internal project in IBM was raising serious questions about the entire concept.
As part of a project to develop a high-performance all-digital telephone switch, a team led by John Cocke began examining huge volumes of performance data from their customer's 360 (and System/370) programs.
This led them to notice a curious pattern: when the ISA presented multiple versions of an instruction, the compiler almost always used the simplest one, instead of the one most directly representing the code.
The complex microcode engine and its associated ROM is reduced or eliminated completely, and those circuits instead dedicated to things like additional registers or a wider ALU, which increases the performance of every program.
The industry responded to the concept of RISC with both confusion and hostility, including a famous dismissive article by the VAX team at Digital.
The DEC Alpha, a pure RISC design, used PALcode to implement features such as translation lookaside buffer (TLB) miss handling and interrupt handling,[23] as well as providing, for Alpha-based systems running OpenVMS, instructions requiring interlocked memory access that are similar to instructions provided by the VAX architecture.
On each tick of a sequencer clock a microcode word is read, decoded, and used to control the functional elements that make up the CPU.
For example, one simple arrangement might be: For this type of micromachine to implement a JUMP instruction with the address following the opcode, the microcode might require two clock ticks.
The engineer designing it would write microassembler source code looking something like this: For each tick it is common to find that only some portions of the CPU are used, with the remaining groups of bits in the microinstruction being no-ops.
With careful design of hardware and microcode, this property can be exploited to parallelise operations that use different areas of the CPU; for example, in the case above, the ALU is not required during the first tick, so it could potentially be used to complete an earlier arithmetic instruction.
In vertical microcode, each microinstruction is significantly encoded, that is, the bit fields generally pass through intermediate combinatory logic that, in turn, generates the control and sequencing signals for internal CPU elements (ALU, registers, etc.).
[45] Many experimental prototype computers use writable control stores; there are also commercial machines that use writable microcode, such as the Burroughs Small Systems, early Xerox workstations, the DEC VAX 8800 (Nautilus) family, the Symbolics L- and G-machines, a number of IBM System/360 and System/370 implementations, some DEC PDP-10 machines,[46] and the Data General Eclipse MV/8000.
[47] The IBM System/370 includes a facility called Initial-Microprogram Load (IML or IMPL)[48] that can be invoked from the console, as part of power-on reset (POR) or from another processor in a tightly coupled multiprocessor complex.
WCS offers several advantages including the ease of patching the microprogram and, for certain hardware generations, faster access than ROMs can provide.
A second prominent example is the set of microcode patches that Intel offered for some of their processor architectures of up to 10 years in age, in a bid to counter the security vulnerabilities discovered in their designs – Spectre and Meltdown – which went public at the start of 2018.
