View source for Microcode

{{Short description|Layer of hardware-level instructions or data structures}}
{{For|the CAD software vendor|MicroCode Engineering, Inc.}}
{{Program execution}}

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.<ref name="Kent2813">{{cite book |last1=Kent |first1=Allen |url=https://books.google.com/books?id=EjWV8J8CQEYC |title=Encyclopedia of Computer Science and Technology: Volume 28 - Supplement 13 |last2=Williams |first2=James G. |date=April 5, 1993 |publisher=Marcel Dekker, Inc |isbn=0-8247-2281-7 |location=New York |page=34 |access-date=Jan 17, 2016 |archive-url=https://web.archive.org/web/20161120161636/https://books.google.com/books?id=EjWV8J8CQEYC |archive-date=November 20, 2016 |url-status=live}}</ref> It consists of a set of hardware-level instructions that implement the higher-level [[machine code]] instructions or control internal [[finite-state machine]] sequencing in many [[digital processing]] components. 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.<ref name="FogMicro">{{cite report |url=https://www.agner.org/optimize/microarchitecture.pdf |title=The microarchitecture of Intel, AMD and VIA CPUs |last1=Fog |first1=Agner |date=2017-05-02 |publisher=Technical University of Denmark |access-date=2024-08-21 |archive-url= https://web.archive.org/web/20170328065929/https://agner.org/optimize/microarchitecture.pdf |archive-date=2017-03-28 |url-status=live}}</ref>

Housed in special high-speed memory, microcode translates machine instructions, [[state machine]] data, or other input into sequences of detailed circuit-level operations. It separates the machine instructions from the underlying [[electronics]], thereby enabling greater flexibility in designing and altering instructions. Moreover, it facilitates the construction of complex multi-step instructions, while simultaneously reducing the complexity of computer circuits. The act of writing microcode is often referred to as ''microprogramming'', and the microcode in a specific processor implementation is sometimes termed a ''microprogram''.

Through extensive microprogramming, [[microarchitecture]]s of smaller scale and simplicity can [[Emulator|emulate]] more robust architectures with wider [[Word (computer architecture)|word]] lengths, additional [[execution unit]]s, and so forth. This approach provides a relatively straightforward method of ensuring software compatibility between different products within a processor family.

==Overview==
===Instruction sets===
At the hardware level, processors contain a number of separate areas of circuitry, or "units", that perform different tasks. Commonly found units include the [[arithmetic logic unit]] (ALU) which performs instructions such as addition or comparing two numbers, circuits for reading and writing data to external memory, and small areas of onboard memory to store these values while they are being processed. In most designs, additional high-performance memory, the [[register file]], is used to store temporary values, not just those needed by the current instruction.<ref name=CPU>{{cite web |url=https://www.redhat.com/sysadmin/cpu-components-functionality |title=The central processing unit (CPU): Its components and functionality |website=Red Hat |first=David |last=Both |date=23 July 2020}}</ref>

To properly perform an instruction, the various circuits have to be activated in order. For instance, it is not possible to add two numbers if they have not yet been loaded from memory. In [[RISC]] designs, the proper ordering of these instructions is largely up to the programmer, or at least to the [[compiler]] of the [[programming language]] they are using. So to add two numbers in memory and store the result in memory, for instance, the compiler may output instructions to load one of the values into one register, the second into another, perform the addition function in the ALU, putting the result into a register, and then store that register into memory.<ref name=CPU/>

As the sequence of instructions needed to complete this higher-level concept, "add these two numbers in memory", may require multiple instructions, this can represent a performance bottleneck if those instructions are stored in [[main memory]]. Reading those instructions one by one takes time that could be used to read and write the actual data. For this reason, it is common for non-RISC designs to have many different instructions that differ largely on where they store data. For instance, the [[MOS 6502]] has eight variations of the addition instruction, {{code|ADC}}, which differ only in where they look to find the two operands.<ref>{{cite web |url=http://www.6502.org/tutorials/6502opcodes.html |title= NMOS 6502 Opcodes |first= John |last=Pickens |website=6502.org}}</ref>

Using the variation of the instruction, or "[[opcode]]", that most closely matches the ultimate operation can reduce the number of instructions to one, saving memory used by the program code and improving performance by leaving the [[data bus]] open for other operations. Internally, however, these instructions are not separate operations, but sequences of the operations the units actually perform. Converting a single instruction read from memory into the sequence of internal actions is the duty of the [[control unit]], another unit within the processor.<ref name=microcode>{{cite web |url=http://www.righto.com/2022/11/how-8086-processors-microcode-engine.html#:~:text=In%201951%2C%20Maurice%20Wilkes%20came,memory%20called%20a%20control%20store. |title=How the 8086 processor's microcode engine works |website=Ken Shirriff's blog |first=Ken |last=Shirriff}}</ref>

===Microcode===
The basic idea behind microcode is to replace the custom hardware logic implementing the instruction sequencing with a series of simple instructions run in a "microcode engine" in the processor. Whereas a custom logic system might have a series of diodes and gates that output a series of voltages on various control lines, the microcode engine is connected to these lines instead, and these are turned on and off as the engine reads the microcode instructions in sequence. The microcode instructions are often bit encoded to those lines, for instance, if bit 8 is true, that might mean that the ALU should be paused awaiting data. In this respect microcode is somewhat similar to the paper rolls in a [[player piano]], where the holes represent which key should be pressed.

The distinction between custom logic and microcode may seem small, one uses a pattern of diodes and gates to decode the instruction and produce a sequence of signals, whereas the other encodes the signals as microinstructions that are read in sequence to produce the same results. The critical difference is that in a custom logic design, changes to the individual steps require the hardware to be redesigned. Using microcode, all that changes is the code stored in the memory containing the microcode. This makes it much easier to fix problems in a microcode system. It also means that there is no effective limit to the complexity of the instructions, it is only limited by the amount of memory one is willing to use.

The lowest layer in a computer's software stack is traditionally raw [[machine code]] instructions for the processor. In microcoded processors, fetching and decoding those instructions, and executing them, may be done by microcode. To avoid confusion, each microprogram-related element is differentiated by the ''micro'' prefix: microinstruction, microassembler, microprogrammer, etc.<ref>{{Cite web |title=ISO/IEC/IEEE 24765:2017(en) Systems and software engineering — Vocabulary |url=https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:24765:ed-2:v1:en |access-date=2024-06-23 |website=www.iso.org}}</ref>

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.  For example, the [[VAX 9000]] has a hardwired IBox unit to fetch and decode instructions, which it hands to a microcoded EBox unit to be executed,<ref>{{cite book|url=http://www.bitsavers.org/pdf/dec/vax/9000/EK-KA90S-TD-001_VAX_9000_System_Technical_Description_May90.pdf|title=VAX 9000 System Technical Description|publisher=[[Digital Equipment Corporation]]|date=May 1990|id=EK-KA90S-TD-001|pages=3{{hyp}}5-3{{hyp}}32}}</ref> and the [[VAX 8800]] has both a microcoded IBox and a microcoded EBox.<ref>{{cite book|url=http://bitsavers.org/pdf/dec/vax/8800/EK-KA882_8800sysTech2_Jul86.pdf|title=VAX 8800 System Technical Description Volume 2|publisher=[[Digital Equipment Corporation]]|date=July 1986|id=EK-KA882-TD-PRE}}</ref>

A high-level programmer, or even an [[assembly language]] programmer, does not normally see or change microcode. Unlike machine code, which often retains some [[backward compatibility]] among different processors in a family, microcode only runs on the exact [[electronic circuit]]ry for which it is designed, as it constitutes an inherent part of the particular processor design itself.

===Design===
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)<ref>{{cite journal |last1=Manning |first1=B.M. |last2=Mitby |first2=J.S |last3=Nicholson |first3=J.O. |title=Microprogrammed Processor Having PLA Control Store |journal=IBM Technical Disclosure Bulletin |volume=22 |issue=6 |date=November 1979 |url=http://www.computerhistory.org/collections/accession/102660026 |access-date=2011-07-10 |url-status=live |archive-url=https://web.archive.org/web/20121001165413/http://www.computerhistory.org/collections/accession/102660026 |archive-date=2012-10-01}}</ref> structure, or in a combination of both.<ref>Often denoted a ROM/PLA control store in the context of usage in a CPU; {{cite web |last=Supnik |first=Bob |date=24 February 2008 |title=J-11: DEC's fourth and last PDP-11 microprocessor design ... features ... ROM/PLA control store |url=http://simh.trailing-edge.com/semi/j11.html |access-date=2011-07-10 |url-status=live |archive-url=https://web.archive.org/web/20110709032923/http://simh.trailing-edge.com/semi/j11.html |archive-date=2011-07-09}}</ref> However, machines also exist that have some or all microcode stored in [[static random-access memory]] (SRAM) or [[flash memory]]. This is traditionally denoted as ''writable [[control store]]'' in the context of computers, which can be either read-only or [[read–write memory]]. In the latter case, the CPU initialization process loads microcode into the control store from another storage medium, with the possibility of altering the microcode to correct bugs in the instruction set, or to implement new machine instructions.

===Microprograms===

Microprograms consist of series of microinstructions, which control the CPU at a very fundamental level of hardware circuitry. For example, a single typical ''horizontal'' microinstruction might specify the following operations simultaneously:
* Connect register 1 to the ''A'' side of the [[Arithmetic logic unit|ALU]]
* Connect register 7 to the ''B'' side of the ALU
* Set the ALU to perform [[Two's complement|two's-complement]] addition
* Set the ALU's carry input to zero
* Connect the ALU output to register 8
* Update the condition codes from the ALU status flags (''negative'', ''zero'', ''overflow'', and ''carry'')
* Microjump to a given [[program counter|μPC]] address for the next microinstruction

To simultaneously control all processor's features in one cycle, the microinstruction is often wider than 50 bits; e.g., 128 bits on a [[IBM System/360 Model 85|360/85]] with an emulator feature. Microprograms are carefully designed and optimized for the fastest possible execution, as a slow microprogram would result in a slow machine instruction and degraded performance for related application programs that use such instructions.

==Justification==
Microcode was originally developed as a simpler method of developing the control logic for a computer. Initially, CPU [[instruction set]]s were [[hardwired control unit|hardwired]]. Each step needed to fetch, decode, and execute the machine instructions (including any operand address calculations, reads, and writes) was controlled directly by [[combinational logic]] and rather minimal [[sequential circuit|sequential]] state machine circuitry. While such hard-wired processors were very efficient, the need for powerful instruction sets with multi-step addressing and complex operations (''see below'') made them difficult to design and debug; highly encoded and varied-length instructions can contribute to this as well, especially when very irregular encodings are used.

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. Even late in the design process, microcode could easily be changed, whereas hard-wired CPU designs were very cumbersome to change. Thus, this greatly facilitated CPU design.

From the 1940s to the late 1970s, a large portion of programming was done in [[assembly language]]; higher-level instructions mean greater programmer productivity, so an important advantage of microcode was the relative ease by which powerful machine instructions can be defined. The ultimate extension of this are "Directly Executable High Level Language" designs, in which each statement of a high-level language such as [[PL/I]] is entirely and directly executed by microcode, without compilation. The [[IBM Future Systems project]] and [[Data General]] Fountainhead Processor are examples of this. During the 1970s, CPU speeds grew more quickly than memory speeds and numerous techniques such as [[Direct memory access|memory block transfer]], [[Prefetching|memory pre-fetch]] and [[multi-level cache]]s were used to alleviate this. High-level machine instructions, made possible by microcode, helped further, as fewer more complex machine instructions require less memory bandwidth. For example, an operation on a character string can be done as a single machine instruction, thus avoiding multiple instruction fetches.

Architectures with instruction sets implemented by complex microprograms included the [[IBM]] [[System/360]] and [[Digital Equipment Corporation]] [[VAX]]. The approach of increasingly complex microcode-implemented instruction sets was later called [[complex instruction set computer]] (CISC). An alternate approach, used in many [[microprocessor]]s, is to use one or more [[programmable logic array]] (PLA) or [[read-only memory]] (ROM) (instead of combinational logic) mainly for instruction decoding, and let a simple state machine (without much, or any, microcode) do most of the sequencing. The [[MOS Technology 6502]] is an example of a microprocessor using a PLA for instruction decode and sequencing. The PLA is visible in photomicrographs of the chip,<ref>{{cite web |url=http://www.visual6502.org/images/6502/ |title=6502 Images |access-date=January 22, 2015 |url-status=live |archive-url=https://web.archive.org/web/20160304093548/http://www.visual6502.org/images/6502/ |archive-date=March 4, 2016}}</ref> and its operation can be seen in the [[transistor]]-level simulation.

Microprogramming is still used in modern CPU designs. In some cases, after the microcode is debugged in simulation, logic functions are substituted for the control store.{{citation needed|date=March 2014}} Logic functions are often faster and less expensive than the equivalent microprogram memory.

===Benefits===
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. In coordination with the hardware, the microcode implements the programmer-visible architecture. The underlying hardware need not have a fixed relationship to the visible architecture. This makes it easier to implement a given instruction set architecture on a wide variety of underlying hardware micro-architectures.

The IBM System/360 has a 32-bit architecture with 16 general-purpose registers, but most of the System/360 implementations use hardware that implements a much simpler underlying microarchitecture; for example, the [[IBM System/360 Model 30|System/360 Model 30]] has 8-bit data paths to the arithmetic logic unit (ALU) and main memory and implemented the general-purpose registers in a special unit of higher-speed [[Magnetic-core memory|core memory]], and the [[IBM System/360 Model 40|System/360 Model 40]] has 8-bit data paths to the ALU and 16-bit data paths to main memory and also implemented the general-purpose registers in a special unit of higher-speed core memory. The [[IBM System/360 Model 50|Model 50]] has full 32-bit data paths and implements the general-purpose registers in a special unit of higher-speed core memory.<ref>{{cite book|title=IBM System/360 Model 50 Functional Characteristics|url=http://bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6898-1_360-50_funcChar_1967.pdf|publisher=[[IBM]]|id=A22-6898-1|page=7|year=1967|access-date=October 29, 2021}}</ref> The Model 65 through the Model 195 have larger data paths and implement the general-purpose registers in faster transistor circuits.{{Citation needed|date=September 2011}} 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. This dramatically reduces the number of unique system software programs that must be written for each model.

The [[Digital Equipment Corporation]] [[PDP-11]] is a 16-bit [[PDP-11 architecture|architecture]] with eight general-purpose registers. It was introduced in 1970 and the basic architecture remained unchanged through the 1990s. Only the original machine in the series was not microcoded. From the years 1972 to 1976, the width of the PDP-11's underlying microprogram varied from 22 to 64 bits. The length of the microprogram varied from 256 to 1,024 words with longer microprogram lengths generally corresponding to narrower widths.<ref name="bellstreckerpdp11vaxalpha">{{Cite report |url=https://archive.computerhistory.org/resources/text/DEC/alpha/dec.alpha.bell_stecker.pdp-11_vax_and_alpha.1998.102630388.pdf |title=What Have We Learned from the PDP-11 – What We Have Learned from VAX and Alpha |last1=Bell |first1=Gordon |author-link1=Gordon Bell |last2=Strecker |first2=W.D. |page=30 |access-date=2025-06-26}}</ref> The variety of microprogram widths imply that there were at least seven different implementations of the PDP-11 in just four years. 

A similar approach was used by Digital Equipment Corporation in their VAX family of computers. As a result, different VAX processors use different microarchitectures, yet the programmer-visible architecture does not change.

Microprogramming also reduces the cost of field changes to correct defects ([[Computer bug|bugs]]) in the processor; a bug can often be fixed by replacing a portion of the microprogram rather than by changes being made to [[hardware logic]] and wiring.

==History==
===Early examples===
The ACE computer, designed by [[Alan Turing]] in 1946, used microprogramming.<ref>{{cite book | title=Modern Mathematics | date=2006 | publisher=Infobase | isbn=978-0-7910-9720-5 | url=https://books.google.com/books?id=5LMVSFNhFI0C&dq=ace+microprogramming&pg=PA121 }}</ref>

In 1947, the design of the [[Whirlwind (computer)|MIT Whirlwind]] introduced the concept of a control store as a way to simplify computer design and move beyond ''[[ad hoc]]'' methods. The control store is a [[diode matrix]]: a two-dimensional lattice, where one dimension accepts "control time pulses" from the CPU's internal clock, and the other connects to control signals on gates and other circuits. A "pulse distributor" takes the pulses generated by the [[CPU clock]] and breaks them up into eight separate time pulses, each of which activates a different row of the lattice. When the row is activated, it activates the control signals connected to it.<ref>{{Cite tech report |last1=Everett |first1=R.R. |last2=Swain |first2=F.E. |year=1947 |title=Whirlwind I Computer Block Diagrams |publisher=MIT Servomechanisms Laboratory |id=R-127 |url=http://www.cryptosmith.com/wp-content/uploads/2009/05/whirlwindr-127.pdf |access-date=June 21, 2006 |url-status=dead |archive-url=https://web.archive.org/web/20120617112919/http://www.cryptosmith.com/wp-content/uploads/2009/05/whirlwindr-127.pdf |archive-date=June 17, 2012}}</ref>

In 1951, [[Maurice Wilkes]]<ref>{{multiref|{{cite tech report |last=Wilkes |first=Maurice |year=1951 |title=The Best Way to Design an Automatic Calculating Machine |institution=[[University of Manchester]]}}|{{cite book |last=Wilkes |first=Maurice |chapter=The Best Way to Design an Automatic Calculating Machine |chapter-url=https://www.cs.princeton.edu/courses/archive/fall09/cos375/BestWay.pdf |editor-first=M. |editor-last=Campbell-Kelly |title=The early British computer conferences |publisher=MIT Press |date=1989 |isbn=978-0-262-23136-7 |pages=182–4 }}}}</ref> enhanced this concept by adding ''conditional execution'', a concept akin to a [[Conditional (programming)|conditional]] in computer software. His initial implementation consisted of a pair of matrices: the first one generated signals in the manner of the Whirlwind control store, while the second matrix selected which row of signals (the microprogram instruction word, so to speak) to invoke on the next cycle. Conditionals were implemented by providing a way that a single line in the control store could choose from alternatives in the second matrix. This made the control signals conditional on the detected internal signal. Wilkes coined the term ''microprogramming'' to describe this feature and distinguish it from a simple control store.

===The 360===
{{main|System/360}}
Microcode remained relatively rare in computer design as the cost of the ROM needed to store the code was not significantly different from the cost of custom control logic. This changed through the early 1960s with the introduction of mass-produced [[core memory]] and [[core rope]], which was far less expensive than dedicated logic based on diode arrays or similar solutions. The first to take real advantage of this was [[IBM]] in their 1964 [[System/360]] series. This allowed the machines to have a very complex instruction set, including operations that matched high-level language constructs like formatting binary values as decimal strings, encoding the complex series of internal steps needed for this task in low cost memory.<ref name=IBM>{{cite web |url=https://www.righto.com/2022/01/ibm360model50.html |title=Simulating the IBM 360/50 mainframe from its microcode |website=Ken Shirriff's blog |first=Ken |last=Shirriff}}</ref>

But the real value in the 360 line was that one could build a series of machines that were completely different internally, yet run the same ISA. For a low-end machine, one might use an 8-bit ALU that requires multiple cycles to complete a single 32-bit addition, while a higher end machine might have a full 32-bit ALU that performs the same addition in a single cycle. These differences could be implemented in control logic, but the cost of implementing a completely different decoder for each machine would be prohibitive. Using microcode meant all that changed was the code in the ROM. For instance, one machine might include a [[floating point unit]] and thus its microcode for multiplying two numbers might be only a few lines line, whereas on the same machine without the FPU this would be a program that did the same using multiple additions, and all that changed was the ROM.<ref name=IBM/>

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. This lowered the barrier to entry and the 360 was a runaway success. By the end of the decade, the use of microcode was ''de rigueur'' across the mainframe industry.

===Moving up the line===
[[File:Motorola 68000 die.JPG|thumb|The microcode (and "nanocode") of the [[Motorola 68000]] is stored in the two large square blocks in the upper right and controlled by circuitry to the right of it. It takes up a significant amount of the total chip surface.]]
Early [[minicomputer]]s 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. But it was not long before their designers began using more powerful [[integrated circuit]]s that allowed for more complex ISAs. By the mid-1970s, most new minicomputers and [[superminicomputer]]s were using microcode as well, such as most models of the [[PDP-11]] and, most notably, most models of the [[VAX]], which included high-level instruction not unlike those found in the 360.<ref>{{cite book |date=May 1988 |title=VLSI VAX Micro-Architecture |first=Bob |last=Supnik |publisher=Digital Equipment |url=http://simh.trailing-edge.com/docs/microarch.pdf}}</ref>

The same basic evolution occurred with [[microprocessor]]s as well. Early designs were extremely simple, and even the more powerful 8-bit designs of the mid-1970s like the [[Zilog Z80]] had instruction sets that were simple enough to be implemented in dedicated logic. By this time, the control logic could be patterned into the same die as the CPU, making the difference in cost between ROM and logic less of an issue. However, it was not long before these companies were also facing the problem of introducing higher-performance designs but still wanting to offer [[backward compatibility]]. Among early examples of microcode in micros was the [[Intel 8086]].<ref name=microcode/>

Among the ultimate implementations of microcode in microprocessors is the [[Motorola 68000]]. This offered a highly [[orthogonal instruction set]] with a wide variety of [[addressing mode]]s, all implemented in microcode. This did not come without cost, according to early articles, about 20% of the chip's surface area (and thus cost) is the microcode system<ref>{{cite magazine |magazine=Byte |date= April 1983 |title=Design Philosophy Behind Motorola's MC68000 |first= Thomas |last= Starnes |url=http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm}}</ref> and {{cn|reason=later estimates suggest approximately 23,000|date=December 2024}} of the systems 68,000 transistors were part of the microcode system.

===RISC enters===
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 (computer scientist)|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. They learned that this was because those instructions were always implemented in hardware, and thus run the fastest. Using the other instruction might offer higher performance on some machines, but there was no way to know what machine they were running on. This defeated the purpose of using microcode in the first place, which was to hide these distinctions.<ref name=risc>{{Cite journal
 | last1 = Cocke | first1 = John
 | last2 = Markstein | first2 = Victoria
 | doi = 10.1147/rd.341.0004
 | url = https://www.cis.upenn.edu/~milom/cis501-Fall11/papers/cocke-RISC.pdf
 | title = The evolution of RISC technology at IBM
 | journal = IBM Journal of Research and Development
 | volume = 34| issue = 1
 | pages = 4–11
 | date=January 1990
 }}</ref>

The team came to a radical conclusion: "Imposing microcode between a computer and its users imposes an expensive overhead in performing the most frequently executed instructions."<ref name=risc/>

The result of this discovery was what is today known as the [[RISC]] concept. 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. When complex sequences of instructions are needed, this is left to the compiler, which is the entire purpose of using a compiler in the first place. The basic concept was soon picked up by university researchers in California, where simulations suggested such designs would trivially outperform even the fastest conventional designs. It was one such project, at the [[University of California, Berkeley]], that introduced the term RISC.

The industry responded to the concept of RISC with both confusion and hostility, including a famous dismissive article by the VAX team at Digital.<ref name=comments>{{cite journal |url=https://dl.acm.org/doi/pdf/10.1145/641914.641918 |title=Comments on "The Case for the Reduced Instruction Set Computer," by Patterson and Ditzel|first1=Douglas |last1=Clark |first2=William |last2=Strecker |date=September 1980 |journal= ACM SIGARCH Computer Architecture News|volume=8 |issue=6 |pages=34–38 |doi=10.1145/641914.641918 |s2cid=14939489 |url-access=subscription }}</ref> A major point of contention was that implementing the instructions outside of the processor meant it would spend much more time reading those instructions from memory, thereby slowing overall performance no matter how fast the CPU itself ran.<ref name=comments/> Proponents pointed out that simulations clearly showed the number of instructions was not much greater, especially when considering compiled code.<ref name=risc/>

The debate raged until the first commercial RISC designs emerged in the second half of the 1980s, which easily outperformed the most complex designs from other companies. By the late 1980s it was over; even DEC was abandoning microcode for their [[DEC Alpha]] designs, and CISC processors switched to using hardwired circuitry, rather than microcode, to perform many functions.  For example, the [[Intel 80486]] uses hardwired circuitry to fetch and decode instructions, using microcode only to execute instructions; register-register move and arithmetic instructions required only one microinstruction, allowing them to be completed in one clock cycle.<ref>{{cite conference|title=The execution pipeline of the Intel i486 CPU|book-title= Digest of Papers Compcon Spring '90. Thirty-Fifth IEEE Computer Society International Conference on Intellectual Leverage|publisher=[[IEEE]]|isbn=0-8186-2028-5|location=San Francisco, CA|doi=10.1109/CMPCON.1990.63682}}</ref>  The [[Pentium Pro]]'s fetch and decode hardware fetches instructions and decodes them into series of micro-operations that are passed on to the execution unit, which schedules and executes the micro-operations, possibly doing so [[out-of-order execution|out-of-order]].  Complex instructions are implemented by microcode that consists of predefined sequences of micro-operations.<ref>{{cite web|url=http://stffrdhrn.github.io/content/2019/Intel_PentiumPro.pdf|title=Pentium Pro Processor At 150, 166, 180, and 200 MHz|publisher=[[Intel]]|date=November 1995|type=Datasheet}}</ref>

Some processor designs use machine code that runs in a special mode, with special instructions, available only in that mode, that have access to processor-dependent hardware, to implement some low-level features of the instruction set. The DEC Alpha, a pure RISC design, used [[PALcode]] to implement features such as [[translation lookaside buffer]] (TLB) miss handling and interrupt handling,<ref name="axp-architecture-manual">{{cite book|url=http://bitsavers.org/pdf/dec/alpha/Sites_AlphaAXPArchitectureReferenceManual_2ed_1995.pdf|title=Alpha AXP Architecture Reference Manual|edition=Second|chapter=Part I / Common Architecture, Chapter 6 Common PALcode Architecture|publisher=[[Digital Press]]|date=1995|isbn=1-55558-145-5}}</ref> 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.<ref name="axp-architecture-manual" /> CMOS [[IBM System/390]] CPUs, starting with the G4 processor, and [[z/Architecture]] CPUs use [[millicode]] to implement some instructions.<ref>{{cite journal|last=Rogers|first=Bob|title=The What and Why of zEnterprise Millicode|journal=IBM Systems Magazine|date=Sep–Oct 2012|url=http://www.ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/|archive-url=https://web.archive.org/web/20121009085728/http://www.ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/|archive-date=October 9, 2012|url-status=dead}}</ref>

==Examples==
* The [[Analytical engine]] envisioned by [[Charles Babbage]] uses [[Read-only memory|pegs inserted into rotating drums]] to store its internal procedures.
* The [[EMIDEC 1100]]<ref>{{cite web |url=http://www.emidec.org.uk/ |title=EMIDEC 1100 computer |publisher=Emidec.org.uk |access-date=April 26, 2010 |url-status=live |archive-url=https://web.archive.org/web/20100612184405/http://www.emidec.org.uk/ |archive-date=June 12, 2010}}</ref> reputedly uses a hard-wired control store consisting of wires threaded through ferrite cores, known as "the laces".
* Most models of the IBM System/360 series are microprogrammed:
** The [[IBM System/360 Model 25|Model 25]] is unique among System/360 models in using the top 16&nbsp;K bytes of core storage to hold the control storage for the microprogram. The 2025 uses a 16-bit microarchitecture with seven control words (or microinstructions). After system maintenance or when changing operating mode, the microcode is loaded from the card reader, tape, or other device.<ref>{{cite book |title=IBM System/360 Model 25 Functional Characteristics |date=January 1968 |publisher=IBM |id=A24-3510-0 |page=22 |url=http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A24-3510-0_360-25_funcChar_Jan68.pdf |access-date=October 29, 2021}}</ref> The [[IBM 1410]] emulation for this model is loaded this way.
** The [[IBM 2030|Model 30]] uses an 8-bit microarchitecture with only a few hardware registers; everything that the programmer saw is emulated by the microprogram. The microcode for this model is also held on special punched cards, which are stored inside the machine in a dedicated reader per card, called "CROS" units (Capacitor Read-Only Storage).<ref name="360-30-feto">{{cite book |url=http://www.bitsavers.org/pdf/ibm/360/fe/2030/Y24-3360-1_2030_FE_Theory_Opns_Jun67.pdf |title=Field Engineering Theory of Operation, 2030 Processing Unit, System/360 Model 30 |edition=First |date=June 1967 |publisher=IBM |id=Y24-3360-1 |access-date=2019-11-09 |url-status=live |archive-url=https://web.archive.org/web/20200401215647/http://www.bitsavers.org/pdf/ibm/360/fe/2030/Y24-3360-1_2030_FE_Theory_Opns_Jun67.pdf |archive-date=2020-04-01}}</ref>{{rp|2–5}} Another CROS unit is added for machines ordered with 1401/1440/1460 emulation<ref name="360-30-feto"/>{{rp|4–29}} and for machines ordered with 1620 emulation.<ref name="360-30-feto"/>{{rp|4–75}}
** The [[IBM System/360 Model 40|Model 40]] uses 56-bit control words. The 2040 box implements both the System/360 main processor and the multiplex channel (the I/O processor). This model uses ''TROS'' dedicated readers similar to ''CROS'' units, but with an inductive pickup (Transformer Read-only Store).
** The [[IBM System/360 Model 50|Model 50]] has two internal datapaths which operated in parallel: a 32-bit datapath used for arithmetic operations, and an 8-bit data path used in some logical operations. The control store uses 90-bit microinstructions.
** The [[IBM System/360 Model 85|Model 85]] has separate instruction fetch (I-unit) and execution (E-unit) to provide high performance. The I-unit is hardware controlled. The E-unit is microprogrammed; the control words are 108 bits wide on a basic 360/85 and wider if an emulator feature is installed.
* The [[NCR 315]] is microprogrammed with hand wired ferrite cores (a [[Read-only memory|ROM]]) pulsed by a sequencer with conditional execution. Wires routed through the cores are enabled for various data and logic elements in the processor.
* The Digital Equipment Corporation [[PDP-9]] processor, KL10 and KS10 [[PDP-10]] processors, and [[PDP-11]] processors with the exception of the PDP-11/20, are microprogrammed.<ref>{{cite book|url=https://archive.org/details/computerstructur01siew/page/671|chapter-url=http://gordonbell.azurewebsites.net/computer_structures_principles_and_examples/csp0687.htm|editor1=Daniel P. Siewiorek|editor-link1=Daniel Siewiorek|editor2=C. Gordon Bell|editor-link2=Gordon Bell|editor3=Allen Newell|editor-link3=Allen Newell|title=Computer Structures: Principles and Examples|chapter=Implementation and Performance Evaluation of the PDP-11 Family|author1=Edward A. Snow|author2=Daniel P. Siewiorek|page=[https://archive.org/details/computerstructur01siew/page/671 671]|publisher=[[McGraw-Hill|McGraw-Hill Book Company]]|location=[[New York, NY]]|year=1982|isbn=0-07-057302-6|url-access=registration}}</ref>
* Most [[Data General Eclipse]] minicomputers are microprogrammed. The task of writing microcode for the [[Data General Eclipse MV/8000|Eclipse MV/8000]] is detailed in the Pulitzer Prize-winning book titled ''[[The Soul of a New Machine]]''.
* Many systems from [[Burroughs Corporation|Burroughs]] are microprogrammed:
:* The B700 "microprocessor" execute application-level opcodes using sequences of 16-bit microinstructions stored in main memory; each of these is either a register-load operation or mapped to a single 56-bit "nanocode" instruction stored in read-only memory. This allows comparatively simple hardware to act either as a mainframe peripheral controller or to be packaged as a standalone computer.
:* The [[B1700]] is implemented with radically different hardware including bit-addressable main memory but has a similar multi-layer organisation. The operating system preloads the interpreter for whatever language is required. These interpreters present different virtual machines for [[COBOL]], [[Fortran]], etc.
* [[Microdata Corporation|Microdata]] produced computers in which the microcode is accessible to the user; this allows the creation of custom assembler level instructions. Microdata's [[Pick operating system|Reality]] operating system design makes extensive use of this capability.
* The [[Xerox Alto#Architecture|Xerox Alto]] workstation used a microcoded design but, unlike many computers, the microcode engine is not hidden from the programmer in a layered design. Applications take advantage of this to accelerate performance.
* The [[IBM System/38]] is described as having both [[IBM System/38#Microcode|horizontal and vertical microcode]].<ref>{{cite journal|url=https://www.computer.org/csdl/magazine/co/1981/09/01667517/13rRUwciPii|title=Design of a Small Business Data Processing System|first=Frank|last=Soltis|journal=[[IEEE Computer]]|date=September 1981|volume=14|pages=77–93|doi=10.1109/C-M.1981.220610|s2cid=398484|url-access=subscription}}</ref> In practice, the processor implements an instruction set architecture named the ''Internal Microprogrammed Interface'' (IMPI) using a horizontal microcode format. The so-called vertical microcode layer implements the System/38's hardware-independent [[IBM System/38#Machine Interface|Machine Interface]] (MI) instruction set by translating MI code to IMPI code and executing it. Prior to the introduction of the [[IBM RS64]] processor line, early [[IBM AS/400]] systems used the same architecture.<ref name="inside-as400">{{cite book|title=Inside the AS/400, Second Edition|url=https://books.google.com/books?id=5DoPAAAACAAJ|isbn=978-1882419661|author=Frank G. Soltis|year=1997|publisher=Duke Press}}</ref> 
* The [[Nintendo 64]]'s [[Reality Coprocessor]] (RCP), which serves as the console's [[graphics processing unit]] and audio processor, utilizes microcode; it is possible to implement new effects or tweak the processor to achieve the desired output. Some notable examples of custom RCP microcode include the high-resolution graphics, particle engines, and unlimited draw distances found in [[Factor 5]]'s ''[[Indiana Jones and the Infernal Machine]]'', ''[[Star Wars: Rogue Squadron]]'', and ''[[Star Wars: Battle for Naboo]]'';<ref name="Interview: Battling the N64 (Naboo)">{{cite web |url=http://ign64.ign.com/articles/087/087646p1.html |title=Interview: Battling the N64 (Naboo) |publisher=IGN64 |date=November 10, 2000 |access-date=March 27, 2008 |url-status=live |archive-url=https://web.archive.org/web/20070913180626/http://ign64.ign.com/articles/087/087646p1.html |archive-date=September 13, 2007}}</ref><ref name="Indiana Jones and the Infernal Machine">{{cite web |title=Indiana Jones and the Infernal Machine |website=IGN |url=http://www.ign.com/articles/2000/12/13/indiana-jones-and-the-infernal-machine-2 |date=December 12, 2000 |access-date=September 24, 2013 |url-status=live |archive-url=https://web.archive.org/web/20130927083807/http://www.ign.com/articles/2000/12/13/indiana-jones-and-the-infernal-machine-2 |archive-date=September 27, 2013}}</ref> and the [[full motion video]] playback found in [[Rockstar San Diego|Angel Studios]]' ''[[Resident Evil 2]]''.<ref name="Postmortem RE2 N64">{{cite news |last=Meynink |first=Todd |date=July 28, 2000 |url=http://www.gamasutra.com/view/feature/3148/postmortem_angel_studios_.php |title=Postmortem: Angel Studios' Resident Evil 2 (N64 Version) |work=[[Gamasutra]] |publisher=[[United Business Media|United Business Media LLC]] |access-date=October 18, 2010 |url-status=dead |archive-url=https://web.archive.org/web/20121021070818/http://www.gamasutra.com/view/feature/3148/postmortem_angel_studios_.php |archive-date=October 21, 2012}}</ref>
{{Further|topic=Nintendo 64 microcode|Nintendo 64 programming characteristics|Nintendo 64 Game Pak}}
* The VU0 and VU1 vector units in the [[Sony]] [[PlayStation 2]] are microprogrammable; in fact, VU1 is only accessible via microcode for the first several generations of the SDK.
* The MicroCore Labs [http://www.microcorelabs.com/mcl86.html MCL86] {{Webarchive|url=https://web.archive.org/web/20161103224205/http://www.microcorelabs.com/mcl86.html |date=2016-11-03 }} , [http://www.microcorelabs.com/mcl51.html MCL51] {{Webarchive|url=https://web.archive.org/web/20170202042033/http://www.microcorelabs.com/mcl51.html |date=2017-02-02 }} and [http://www.microcorelabs.com/mcl65.html MCL65] {{Webarchive|url=https://web.archive.org/web/20181221000146/http://www.microcorelabs.com/mcl65.html |date=2018-12-21 }} are examples of highly encoded "vertical" microsequencer implementations of the Intel 8086/8088, 8051, and MOS 6502.
* The Digital Scientific Corporation Meta 4 Series 16 computer system was a user-microprogammable system first available in 1970. The microcode had a primarily vertical style with 32-bit microinstructions.<ref>{{cite book |url=http://www.bitsavers.org/pdf/digitalScientific/7032MO_Meta4Series16RefMan.pdf |title=Digital Scientific Meta 4 Series 16 Computer System Reference Manual |id=7032MO |publisher=Digital Scientific Corporation |date=May 1971 |access-date=2020-01-14 |url-status=live |archive-url=https://web.archive.org/web/20200114014526/http://www.bitsavers.org/pdf/digitalScientific/7032MO_Meta4Series16RefMan.pdf |archive-date=2020-01-14}}</ref> The instructions were stored on replaceable program boards with a grid of bit positions. One (1) bits were represented by small metal squares that were sensed by amplifiers, zero (0) bits by the absence of the squares.<ref>{{cite book |url=http://www.bitsavers.org/pdf/digitalScientific/7024MO_ROMmanual_Mar70.pdf|title=Digital Scientific Meta 4 Computer System Read-Only Memory (ROM) Reference Manual |id=7024MO |publisher=Digital Scientific Corporation |date=March 1970 |access-date=2020-01-14 |url-status=live |archive-url=https://web.archive.org/web/20190923061816/http://bitsavers.org/pdf/digitalScientific/7024MO_ROMmanual_Mar70.pdf |archive-date=2019-09-23}}</ref> The system could be configured with up to 4K 16-bit words of microstore. One of Digital Scientific's products was an emulator for the [[IBM 1130]].<ref>{{cite book |url=http://www.bitsavers.org/pdf/digitalScientific/7006MO_Meta16_SysMan_Jun70.pdf |title=The Digital Scientific Meta 4 Series 16 Computer System Preliminary System Manual |id=7006MO |publisher=Digital Scientific Corporation |date=June 1970 |access-date=2020-01-14 |url-status=live |archive-url=https://web.archive.org/web/20190923061755/http://bitsavers.org/pdf/digitalScientific/7006MO_Meta16_SysMan_Jun70.pdf |archive-date=2019-09-23}}</ref><ref>{{cite book |url=http://www.bitsavers.org/pdf/digitalScientific/M4-005P-170_1130rom_Jan70.pdf |title=Digital Scientific Meta 4 Computer System Typical ROM Pattern Listing and Program To Simulate The IBM 1130 Instruction Set |id=M4/005P-170 |publisher=Digital Scientific Corporation |date=January 1970 |access-date=2020-01-14 |url-status=live |archive-url=https://web.archive.org/web/20200324115023/http://bitsavers.org/pdf/digitalScientific/M4-005P-170_1130rom_Jan70.pdf |archive-date=2020-03-24}}</ref>
* The [[MCP-1600]] is a [[microprocessor]] made by [[Western Digital]] from 1975 through the early 1980s. It was used to implement three different computer architectures in microcode: the [[Pascal MicroEngine]], the [[WD16]], and the [[Digital Equipment Corporation|DEC]] [[PDP-11#LSI-11|LSI-11]], a cost-reduced PDP-11.<ref>{{cite web |url=http://www.antiquetech.com/?page_id=782 |title=Western Digital 1600 |publisher=AntiqueTech |access-date=5 January 2017 |url-status=dead |archive-url=https://web.archive.org/web/20170103021205/http://www.antiquetech.com/?page_id=782 |archive-date=3 January 2017}}</ref>
* Earlier [[x86]] processors are fully microcoded. x86 processors implemented [[patchable microcode]] (patch by [[BIOS]] or [[operating system]]) since [[P6 (microarchitecture)|Intel P6 microarchitecture]] and [[Athlon|AMD K7 microarchitecture]]. Such processors implemented microcode ROM and microcode SRAM in their silicon.
* Many [[graphics adapter]]s, [[network interface controller]]s, and [[host adapter]]s are microcoded.

==Implementation==
Each microinstruction in a microprogram provides the bits that control the functional elements that internally compose a CPU. The advantage over a hard-wired CPU is that internal CPU control becomes a specialized form of a computer program. Microcode thus transforms a complex electronic design challenge (the control of a CPU) into a less complex programming challenge. To take advantage of this, a CPU is divided into several parts:
* An [[I-unit]] may decode instructions in hardware and determine the microcode address for processing the instruction in parallel with the [[Execution unit|E-unit]].
* A [[microsequencer]] picks the next word of the control store. A sequencer is mostly a counter, but usually also has some way to jump to a different part of the control store depending on some data, usually data from the [[instruction register]] and always some part of the control store. The simplest sequencer is just a register loaded from a few bits of the control store.
* A [[processor register|register]] set is a fast memory containing the data of the central processing unit. It may include registers visible to application programs, such as [[general-purpose registers]] and the [[program counter]], and may also include other registers that are not easily accessible to the application programmer. Often the register set is a triple-ported [[register file]]; that is, two registers can be read, and a third written at the same time.
* An [[arithmetic and logic unit]] performs calculations, usually addition, logical negation, a right shift, and logical AND. It often performs other functions, as well.

There may also be a [[memory address register]] and a [[memory data register]], used to access the main [[computer storage]]. Together, these elements form an "[[execution unit]]". Most modern [[Central processing unit|CPUs]] have several execution units. Even simple computers usually have one unit to read and write memory, and another to execute user code. These elements could often be brought together as a single chip. This chip comes in a fixed width that would form a "slice" through the execution unit. These are known as "[[bit slicing|bit slice]]" chips. The [[AMD Am2900]] family is one of the best known examples of bit slice elements.<ref>{{cite book
 |title=Computer Architecture and Organization |last=Hayes |first=John P. |isbn=0-07-027363-4 |year=1978 |page=300|publisher=McGraw-Hill }}</ref> The parts of the execution units and the whole execution units are interconnected by a bundle of wires called a [[Computer bus|bus]].

Programmers develop microprograms, using basic software tools. A [[microassembler]] allows a programmer to define the table of bits symbolically. Because of its close relationship to the underlying architecture, "microcode has several properties that make it difficult to generate using a compiler."<ref name=Kent2813 /> A [[simulator]] program is intended to execute the bits in the same way as the electronics, and allows much more freedom to debug the microprogram. After the microprogram is finalized, and extensively tested, it is sometimes used as the input to a computer program that constructs logic to produce the same data.{{citation needed|date=February 2018}} This program is similar to those used to optimize a [[programmable logic device|programmable logic array]]. Even without fully optimal logic, heuristically optimized logic can vastly reduce the number of transistors from the number needed for a [[read-only memory]] (ROM) control store. This reduces the cost to produce, and the electricity used by, a CPU.

Microcode can be characterized as ''horizontal'' or ''vertical'', referring primarily to whether each microinstruction controls CPU elements with little or no decoding (horizontal microcode){{efn|IBM horizontally microcoded processors had multiple micro-orders and register select fields that required decoding.}} or requires extensive decoding by [[combinatorial logic]] before doing so (vertical microcode). Consequently, each horizontal microinstruction is wider (contains more bits) and occupies more storage space than a vertical microinstruction.

===Horizontal microcode===
"Horizontal microcode has several discrete micro-operations that are combined in a single microinstruction for simultaneous operation."<ref name=Kent2813 /> Horizontal microcode is typically contained in a fairly wide control store; it is not uncommon for each word to be 108 bits or more. 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.

In a typical implementation a horizontal microprogram word comprises fairly tightly defined groups of bits. For example, one simple arrangement might be:
{| class="wikitable"
|-
| Register source A || Register source B || Destination register || [[Arithmetic and logic unit]] operation || Type of jump || Jump address
|}

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:
{{sxhl|
   # Any line starting with a number-sign is a comment
   # This is just a label, the ordinary way assemblers symbolically represent a 
   # memory address.
 InstructionJUMP:
       # To prepare for the next instruction, the instruction-decode microcode has already
       # moved the program counter to the memory address register. This instruction fetches
       # the target address of the jump instruction from the memory word following the
       # jump opcode, by copying from the memory data register to the memory address register.
       # This gives the memory system two clock ticks to fetch the next 
       # instruction to the memory data register for use by the instruction decode.
       # The sequencer instruction "next" means just add 1 to the control word address.
    MDR, NONE, MAR, COPY, NEXT, NONE
       # This places the address of the next instruction into the PC.
       # This gives the memory system a clock tick to finish the fetch started on the
       # previous microinstruction.
       # The sequencer instruction is to jump to the start of the instruction decode.
    MAR, 1, PC, ADD, JMP, InstructionDecode
       # The instruction decode is not shown, because it is usually a mess, very particular
       # to the exact processor being emulated. Even this example is simplified.
       # Many CPUs have several ways to calculate the address, rather than just fetching
       # it from the word following the op-code. Therefore, rather than just one
       # jump instruction, those CPUs have a family of related jump instructions.
|ucode}}
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.

===Vertical microcode===
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.). This is in contrast with horizontal microcode, in which the bit fields either directly produce the control and sequencing signals or are only minimally encoded. Consequently, vertical microcode requires smaller instruction lengths and less storage, but requires more time to decode, resulting in a slower CPU clock.<ref>{{cite web
 |url          = http://euler.mat.uson.mx/~havillam/ca/CS323/0708.cs-323003.html
 |title        = CS-323: High Performance Microprocessors – Chapter 1. Microprogramming
 |date         = 2009-10-12
 |access-date  = 2015-08-08
 |author1      = Neal Harman
 |author2      = Andy Gimblett
 |website      = mat.uson.mx
 |archive-date = 2015-04-19
 |archive-url  = https://web.archive.org/web/20150419164703/http://euler.mat.uson.mx/~havillam/ca/CS323/0708.cs-323003.html
 |url-status   = dead
}}</ref>

Some vertical microcode is just the assembly language of a simple conventional computer that is emulating a more complex computer. Some processors, such as [[DEC Alpha]] processors and the CMOS microprocessors on later IBM mainframes [[System/390]] and [[z/Architecture]], use machine code, running in a special mode that gives it access to special instructions, special registers, and other hardware resources unavailable to regular machine code, to implement some instructions and other functions,<ref>{{cite book |last=Vaupel |first=Robert |year=2013 |url=https://books.google.com/books?id=1-dt0ABZQOcC&q=millicode |title=High Availability and Scalability of Mainframe Environments using System z and z/OS as example |page=26 |publisher=KIT Scientific |isbn=978-3-7315-0022-3}}</ref><ref>{{cite journal |last=Rogers |first=Bob |date=September–October 2012 |title=The What and Why of zEnterprise Millicode |journal=IBM Systems Magazine |url=http://www.ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/ |access-date=2013-11-07 |url-status=dead |archive-url=https://web.archive.org/web/20131016100828/http://ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/ |archive-date=2013-10-16}}</ref> such as page table walks on Alpha processors.<ref>{{cite web |url=http://download.majix.org/dec/palcode_dsgn_gde.pdf|title=PALcode for Alpha Microprocessors System Design Guide |publisher=[[Digital Equipment Corporation]] |date=May 1996 |access-date=November 7, 2013 |url-status=live |archive-url=https://web.archive.org/web/20110815022514/http://download.majix.org/dec/palcode_dsgn_gde.pdf |archive-date=August 15, 2011}}</ref>  This is called [[PALcode]] on Alpha processors and [[millicode]] on IBM mainframe processors.

Another form of vertical microcode has two fields:
{| class="wikitable"
|-
| Field select || Field value
|}

The ''field select'' selects which part of the CPU will be controlled by this word of the control store. The ''field value'' controls that part of the CPU. With this type of microcode, a designer explicitly chooses to make a slower CPU to save money by reducing the unused bits in the control store; however, the reduced complexity may increase the CPU's clock frequency, which lessens the effect of an increased number of cycles per instruction.

As transistors grew cheaper, horizontal microcode came to dominate the design of CPUs using microcode, with vertical microcode being used less often.

When both vertical and horizontal microcode are used, the horizontal microcode may be referred to as ''nanocode'' or ''picocode''.<ref>{{cite book |last=Spruth |first=Wilhelm |date=December 2012 |title=The Design of a Microprocessor |publisher=Springer Science & Business Media |isbn=978-3-642-74916-2 |page=31 |url=https://books.google.com/books?id=0YmqCAAAQBAJ |access-date=Jan 18, 2015 |url-status=live |archive-url=https://web.archive.org/web/20161120195023/https://books.google.com/books?id=0YmqCAAAQBAJ |archive-date=November 20, 2016}}</ref>

=={{Anchor|IML}}Writable control store==
{{Main|Writable control store}}

A few computers were built using ''writable microcode''. In this design, rather than storing the microcode in ROM or hard-wired logic, the microcode is stored in a RAM called a ''writable control store'' or ''WCS''. Such a computer is sometimes called a ''writable instruction set computer'' (WISC).<ref>{{cite journal |last=Koopman |first=Philip Jr. |date=1987 |url=http://www.ece.cmu.edu/~koopman/forth/rochester_87.pdf |title=Writable instruction set, stack oriented computers: The WISC Concept |journal=The Journal of Forth Application and Research |pages=49–71 |url-status=live |archive-url=https://web.archive.org/web/20080511192958/http://www.ece.cmu.edu/~koopman/forth/rochester_87.pdf |archive-date=2008-05-11}}</ref>

Many experimental prototype computers use [[#Writable control store|writable control stores]]; there are also commercial machines that use writable microcode, such as the [[Burroughs Small Systems]], early [[Xerox PARC|Xerox]] workstations, the [[Digital Equipment Corporation|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,<ref>{{cite newsgroup |last=Smith |first=Eric |date=3 September 2002 |url=http://pdp10.nocrew.org/cpu/kl10-ucode.txt |title=Re: What was the size of Microcode in various machines |message-id=qhn0qyveyu.fsf@ruckus.brouhaha.com |newsgroup=alt.folklore.computers |access-date=18 December 2008 |url-status=live |archive-url=https://web.archive.org/web/20090126231132/http://pdp10.nocrew.org/cpu/kl10-ucode.txt |archive-date=26 January 2009}}</ref> and the [[Data General Eclipse MV/8000]].<ref>{{cite web |last=Smotherman |first=Mark |title=CPSC 3300 / The Soul of a New Machine |url=https://people.computing.clemson.edu/~mark/330/eagle.html |quote=4096 x 75-bit SRAM writable control store: 74-bit microinstruction with 1 parity bit (18 fields) |access-date=2023-10-27}}</ref>

The IBM System/370 includes a facility called ''Initial-Microprogram Load'' (''IML'' or ''IMPL'')<ref>{{cite book
 |publisher    = IBM
 |title        = IBM System/370 Principles of Operation
 |id           = GA22-7000-4
 |version      = Fourth Edition
 |date         = September 1974
 |url          = http://www.bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
 |pages        = 98, 245
 |access-date  = 2012-08-27
 |archive-date = 2012-02-29
 |archive-url  = https://web.archive.org/web/20120229195635/http://bitsavers.org/pdf/ibm/370/princOps/GA22-7000-4_370_Principles_Of_Operation_Sep75.pdf
 |url-status   = live
}}</ref> that can be invoked from the console, as part of ''[[Power-on reset#Power-on reset on IBM mainframes|power-on reset]]'' (''POR'') or from another processor in a [[tightly coupled system|tightly coupled]] [[multiprocessor]] complex.

Some commercial machines, for example IBM 360/85,<ref>{{cite book
 |publisher    = IBM
 |title        = IBM System/360 Model 85 Functional Characteristics
 |id           = A22-6916-1
 |url          = http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A22-6916-1_360-85_funcChar_Jun68.pdf
 |version      = SECOND EDITION
 |date         = June 1968
 |access-date  = October 29, 2021
}}</ref><ref>{{cite book
 | publisher = IBM
 | title     = IBM System/360 Special Feature Description 709/7090/7094 Compatibility Feature for IBM System/360 Model 85
 | id        = GA27-2733-0
 | version   = First Edition
 | date      = March 1969}}</ref> have both a read-only storage and a writable control store for microcode.

WCS offers several advantages including the ease of patching the microprogram and, for certain hardware generations, faster access than ROMs can provide. User-programmable WCS allows the user to optimize the machine for specific purposes.

Starting with the [[Pentium Pro]] in 1995, several [[x86]] CPUs have writable [[Intel Microcode]].<ref name="Stiller_1996">{{cite journal |last1=Stiller |first1=Andreas |last2=Paul |first2=Matthias R.<!-- info contributor on processor internals --> |date=1996-05-12 |title=Prozessorgeflüster |series=Trends & News |language=de |journal=[[c't|c't – magazin für computertechnik]] |publisher=[[Heise Verlag]] |url=https://www.heise.de/ct/artikel/Prozessorgefluester-284546.html |access-date=2017-08-28 |url-status=live |archive-url=https://web.archive.org/web/20170828172141/https://www.heise.de/ct/artikel/Prozessorgefluester-284546.html |archive-date=2017-08-28}}</ref><ref>{{cite book |url=http://www.intel.com/Assets/PDF/manual/253668.pdf |title=Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: System Programming Guide, Part 1 |chapter=9.11: Microcode update facilities |publisher=[[Intel]] |date=September 2016}}</ref> This, for example, has allowed bugs in the [[Intel Core 2]] and Intel [[Xeon]] microcodes to be fixed by patching their microprograms, rather than requiring the entire chips to be replaced. 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 (security vulnerability)|Spectre]] and [[Meltdown (security vulnerability)|Meltdown]] – which went public at the start of 2018.<ref>[http://www.tomshardware.com/news/intel-meltdown-spectre-patch-silicon,36672.html Intel Patches All Recent CPUs, Promises Hardware Fixes For Upcoming 8th Gen Chips] by Paul Alcorn on March 15, 2018</ref><ref>{{cite web |url=https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File |title=Download Linux* Processor Microcode Data File |access-date=2018-03-21 |url-status=dead |archive-url=https://web.archive.org/web/20180319202103/https://downloadcenter.intel.com/download/27591/Linux-Processor-Microcode-Data-File |archive-date=2018-03-19}}</ref> A microcode update can be installed by Linux,<ref>{{cite web |url=http://urbanmyth.org/microcode/ |title=Intel Microcode Update Utility for Linux |archive-url=https://web.archive.org/web/20120226174302/http://urbanmyth.org/microcode/ |archive-date=2012-02-26 |url-status=dead}}</ref> [[FreeBSD]],<ref>{{cite web |url=https://svnweb.freebsd.org/ports/head/sysutils/cpupdate/ |title=[ports] Index of /head/sysutils/cpupdate |publisher=Freebsd.org |access-date=2020-01-16 |url-status=live |archive-url=https://web.archive.org/web/20200401215701/https://svnweb.freebsd.org/ports/head/sysutils/cpupdate/ |archive-date=2020-04-01}}</ref> Microsoft Windows,<ref>{{Cite news |url=http://support.microsoft.com/kb/936357 |title=A microcode reliability update is available that improves the reliability of systems that use Intel processors |access-date=2008-02-25 |url-status=live |archive-url=https://web.archive.org/web/20080223074207/http://support.microsoft.com/kb/936357 |archive-date=2008-02-23}}</ref> or the motherboard BIOS.<ref>{{cite web |url=http://www.intel.com/support/motherboards/server/sb/cs-021619.htm |title=Server Products - BIOS Update required when Missing Microcode message is seen during POST |date=January 24, 2013 |website=Intel |archive-url=https://web.archive.org/web/20140901063251/http://www.intel.com/support/motherboards/server/sb/cs-021619.htm |archive-date=September 1, 2014}}</ref>

Some machines offer user-programmable writable control stores as an option, including the [[HP 2100]], DEC [[PDP-11|PDP-11/60]], [[TI-990]]/12,<ref>{{cite web |title=Model 990/12 LR Computer Depot Maintenance and Repair Manual |url=http://www.bitsavers.org/pdf/ti/990/990-12/2268241_990-12CPU_DepoRepair_Feb83.pdf |website=Bitsavers.org |publisher=Texas Instruments |access-date=15 February 2024}}</ref><ref>{{cite book |title=Texas Instruments Model 990 Computer MDS-990 Microcode Development System Programmer's Guide |location=Texas Instruments Archives, RG-20 accession 94-08, Box 10, 45C. DeGolyer Library, Southern Methodist University, Dallas, TX USA |edition=15 August 1979}}</ref> and [[Varian Data Machines]] V-70 series [[minicomputer]]s. WCS options extended down to microprocessors too. The [[PDP-11#LSI-11|DEC LSI-11]] has an option to allow programming of the internal 8-bit micromachine to create application-specific extensions to the instruction set.<ref>{{cite book |title=LSI-11 WCS user's guide |date=June 1978 |publisher=Digital Equipment Corporation |edition=1st |url=http://www.bitsavers.org/pdf/dec/pdp11/1103/EK-KUV11-TM_LSI11_WCS.pdf |access-date=7 January 2023 |archive-date=23 February 2023 |archive-url=https://web.archive.org/web/20230223212303/http://www.bitsavers.org/pdf/dec/pdp11/1103/EK-KUV11-TM_LSI11_WCS.pdf |url-status=live }}</ref>

Some microcode peripheral devices and adapters have writable microcode, which is usually loaded by an operating system [[device driver]]. Such microcode is loaded to the device's [[Static random-access memory|SRAM]] or [[DRAM]], for example, [[GDDR SDRAM]] of a video card.

==Comparison to VLIW and RISC==
{{unreferenced section|date=August 2023}}
{{Update|section|reason=Many CISC processors now do instruction fetch and decode in hardware, and execute most if not all instructions in hardware, and both RISC and CISC processors execute several operations per clock cycle|date=December 2023}}
The design trend toward heavily microcoded processors with complex instructions began in the early 1960s and continued until roughly the mid-1980s. At that point the [[RISC]] design philosophy started becoming more prominent.

A CPU that uses microcode generally takes several clock cycles to execute a single instruction, one clock cycle for each step in the microprogram for that instruction. Some [[Complex instruction set computer|CISC]] processors include instructions that can take a very long time to execute. Such variations interfere with both [[interrupt latency]] and, what is far more important in modern systems, [[Instruction pipelining|pipelining]].

When designing a new processor, a [[hardwired control]] RISC has the following advantages over microcoded CISC:
* Programming has largely moved away from assembly level, so it's no longer worthwhile to provide complex instructions for productivity reasons.
* Simpler instruction sets allow direct execution by hardware, avoiding the performance penalty of microcoded execution.
* Analysis shows complex instructions are rarely used, hence the machine resources devoted to them are largely wasted.
* The machine resources devoted to rarely used complex instructions are better used for expediting performance of simpler, commonly used instructions.
* Complex microcoded instructions may require many clock cycles that vary, and are difficult to [[pipeline (computing)|pipeline]] for increased performance.

There are counterpoints as well:
* The complex instructions in heavily microcoded implementations may not take much extra machine resources, except for microcode space. For example, the same ALU is often used to calculate an effective address and to compute the result from the operands, e.g., the original [[Z80]], [[8086]], and others.
* The simpler non-RISC instructions (i.e., involving direct memory [[operand]]s) are frequently used by modern compilers. Even immediate to stack (i.e., memory result) arithmetic operations are commonly employed. Although such memory operations, often with varying length encodings, are more difficult to pipeline, it is still fully feasible to do so - clearly exemplified by the [[i486]], [[AMD K5]], [[Cyrix 6x86]], [[Motorola 68040]], etc.
* Non-RISC instructions inherently perform more work per instruction (on average), and are also normally highly encoded, so they enable smaller overall size of the same program, and thus better use of limited cache memories.

Many RISC and [[Very long instruction word|VLIW]] processors are designed to execute every instruction (as long as it is in the cache) in a single cycle. This is very similar to the way CPUs with microcode execute one microinstruction per cycle. VLIW processors have instructions that behave similarly to very wide horizontal microcode, although typically without such fine-grained control over the hardware as provided by microcode. RISC instructions are sometimes similar to the narrow vertical microcode.

==Micro-operations==
Modern CISC implementations, such as the [[x86]] family starting with the [[NexGen]] Nx586, Intel [[Pentium Pro]], and [[AMD K5]], decode instructions into dynamically buffered [[micro-operation]]s with an instruction encoding similar to RISC or traditional microcode. A hardwired instruction decode unit directly emits microoperations for common x86 instructions, but falls back to a more traditional microcode ROM containing microoperations for more complex or rarely used instructions.<ref name=FogMicro/>

For example, an x86 might look up microoperations from microcode to handle complex multistep operations such as loop or string instructions, [[floating-point unit]] [[transcendental function]]s or unusual values such as [[denormal number]]s, and special-purpose instructions such as [[CPUID]].

==Alternate meanings of "microcode"==
===PDP-8===
The [[PDP-8]] is a family of [[12-bit computing|12-bit]] [[minicomputer]]s that was launched [[Digital Equipment Corporation]] in 1965. The [[PDP-8#OPR_(OPeRate)|OPR (OPeRate)]] instruction was said to be "microcoded." This did not mean what the word means today, but meant that each bit of the instruction word specifies a certain action, and the programmer could achieve several actions in a single instruction cycle by setting multiple bits. Examples of these actions are: clear accumulator, complement accumulator, rotate right, rotate right twice, and byte swap.

===Embedded firmware===
Some hardware vendors, notably [[IBM]] and [[Lenovo]], use the term ''microcode'' interchangeably with embedded ''[[firmware]]''. In this context, all code within a device is termed microcode, whether it is microcode or machine code. For instance, updates to a [[hard disk drive]]'s microcode may encompass updates to both its microcode and firmware.<ref>{{cite web |title=IBM pSeries Servers - Microcode Update for Ultrastar 73LZX (US73) 18/36 GB |url=http://download.boulder.ibm.com/ibmdl/pub/software/server/firmware/73lzx.html |url-status=dead |archive-url=https://web.archive.org/web/20190419105117/http://download.boulder.ibm.com/ibmdl/pub/software/server/firmware/73lzx.html |archive-date=April 19, 2019 |access-date=January 22, 2015 |website=IBM}}</ref> Embedded firmware has been popular in application-specific processors such as [[network processor]]s, [[digital signal processor]]s, [[Channel I/O|channel controller]]s, [[disk controller]]s, [[network interface controller]]s, [[flash memory controller]]s, [[graphics processing unit]]s, and in other hardware.

==See also==
{{Portal|Electronics}}
{{Div col|colwidth=20em}}
* [[Address generation unit]] (AGU)
* [[CPU design]]
* [[Finite-state machine]] (FSM)
* [[Firmware]]
* [[Floating-point unit]] (FPU)
* [[Pentium FDIV bug]]
* [[Instruction pipeline]]
* [[Microsequencer]]
* [[MikroSim]]
* [[Millicode]]
* [[Superscalar]]
{{div col end}}

==Notes==
{{Notelist}}

==References==
{{Reflist|30em}}

==Further reading==
* {{cite journal
 | last=Smith |first=Richard E.
 | year       = 1988
 | title      = A Historical Overview of Computer Architecture
 | journal    = [[Annals of the History of Computing]]
 | volume     = 10
 | issue      = 4
 | pages      = 277–303
 | url        = http://doi.ieeecomputersociety.org/10.1109/MAHC.1988.10039
 | access-date= June 21, 2006
 | doi        = 10.1109/MAHC.1988.10039 |bibcode=1988IAHC...10d.277S
 |s2cid = 16405547
| url-access= subscription
 }}
* {{cite web
 | author     = Smotherman, Mark
 | title      = A Brief History of Microprogramming
 | date       = October 2022
 | url        = https://people.computing.clemson.edu/~mark/uprog.html
 | access-date = October 27, 2023}}
* {{cite journal
 |last1=Wilkes |first1=M. V. |author1-link=Maurice Wilkes
 | title      = The Genesis of Microprogramming
 | journal    = Annals of the History of Computing
 | year       = 1986
 | volume     = 8
 | issue      = 2
 | pages      = 116–126
 | url        = http://doi.ieeecomputersociety.org/10.1109/MAHC.1986.10035
 | access-date = August 7, 2006
 | doi        = 10.1109/MAHC.1986.10035 |s2cid = 1978847
| url-access= subscription
 }}
* {{cite journal
 |last1=Wilkes |first1=M. V. |author1-link=Maurice Wilkes |last2=Stringer |first2=J. B. |author2-link=John Bentley Stringer
 | date       = April 1953
 | title      = Microprogramming and the Design of the Control Circuits in an Electronic Digital Computer
 | journal    = [[Mathematical Proceedings of the Cambridge Philosophical Society]]
 | volume     = 49
 | issue      =2
 | pages      = 230–238
 | url        = http://research.microsoft.com/~gbell/Computer_Structures_Principles_and_Examples/csp0174.htm
 | access-date = August 23, 2006
 | doi        = 10.1017/S0305004100028322| bibcode = 1953PCPS...49..230W
|s2cid=62230627 | url-access= subscription
 }}
* {{cite book
 | last=Husson |first=S.S.
 | year       = 1970
 | title      = Microprogramming Principles and Practices
 | publisher  = Prentice-Hall
 | isbn       = 0-13-581454-5
 | url-access = registration
 | url        = https://archive.org/details/microprogramming00huss}}
* {{cite journal
 | last    = Tucker
 | first   = S.G.
 | year    = 1967
 | url     = http://domino.research.ibm.com/tchjr/journalindex.nsf/a3807c5b4823c53f85256561006324be/758c1e6a8a3e5d0285256bfa00685a2f?OpenDocument
 | title   = Microprogram control for SYSTEM/360
 | journal = [[IBM Systems Journal]]
 | volume  = 6
 | issue   = 4
 | pages   = 222–241
 | doi = 10.1147/sj.64.0222
| url-access= subscription
 }}
* {{cite web |first=Ken |last=Shirriff |title=How the 8086 processor's microcode engine works |date=December 2022 |url=https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html}}

==External links==
{{Wiktionary}}
* [http://c2.com/cgi/wiki?WritableInstructionSetComputer Writable Instruction Set Computer]
* [http://www.research.ibm.com/journal/rd/102/ibmrd1002F.pdf Capacitor Read-only Store]


{{Processor technologies}}

[[Category:Instruction processing]]
[[Category:Firmware]]
[[Category:Central processing unit]]
[[Category:BIOS]]
[[Category:Device drivers]]