Editing Microcode (section)

==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.

A similar approach was used by Digital Equipment Corporation (DEC) 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.