Microcode

From Wikipedia, the free encyclopedia

Microprogramming (i.e. writing microcode) is a method that can be employed to implement machine instructions in a CPU relatively easily, often using less hardware than with other methods. It is a set of very detailed and rudimentary lowest-level routines which controls and sequences the actions needed to execute (perform) particular instructions, sometimes also to decode (interpret) them. A machine instruction implemented by a series of microinstructions is thus loosely comparable to how an interpreter implements a high-level language statement using a series of machine instructions.

The microcode is normally written by the CPU engineer during the design phase. It is generally not meant to be visible or changeable by a normal programmer, not even an assembly programmer, one of the reasons being that microcode (by design) can be dramatically changed with a new microarchitecture generation. Machine code often retains backwards compatibility. Microcode has often been used to let one microarchitecture emulate another, usually more powerful, architecture.

Some hardware vendors, especially IBM, also use the term microcode as a synonym for firmware, whether or not it actually implements the microprogramming of a processor.[1] Even simple firmware, such as the one used in a hard drive, is sometimes described as microcode.[2] Such use is not discussed here.

Contents

[edit] Overview

The elements composing a microprogram exist on a lower conceptual level than a normal application program. Each element is differentiated by the "micro" prefix to avoid confusion: microinstruction, microassembler, microprogrammer, microarchitecture, etc.

The microcode usually does not reside in the main memory, but in a special high speed memory, called the control store. It might be either read-only or read-write memory. In the latter case the microcode would be loaded into the control store from some other storage medium as part of the initialization of the CPU, and it could be altered to correct bugs in the instruction set, or to implement new machine instructions.

Microprograms consist of series of microinstructions. These microinstructions control the CPU at a very fundamental level of hardware circuitry. For example, a single typical microinstruction might specify the following operations:

  • Connect Register 1 to the "A" side of the ALU
  • Connect Register 7 to the "B" side of the ALU
  • Set the ALU to perform two's-complement addition
  • Set the ALU's carry input to zero
  • Store the result value in Register 8
  • Update the "condition codes" with the ALU status flags ("Negative", "Zero", "Overflow", and "Carry")
  • Microjump to MicroPC nnn for the next microinstruction

To simultaneously control all processor's features in one cycle, the microinstruction is often as wide as 50 or more bits. Microprograms are carefully designed and optimized for the fastest possible execution, since a slow microprogram would yield a slow machine instruction which would in turn cause all programs using that instruction to be slow.

[edit] The reason for microprogramming

Microcode was originally developed as a simpler method of developing the control logic for a computer. Initially CPU instruction sets were "hard wired". Each step needed to fetch, decode and execute the machine instructions (including any operand address calculations, reads and writes) was controlled directly by combinatorial logic and rather minimal sequential state machine circuitry. While very efficient, the need for powerful instruction sets with multi-step addressing and complex operations (see below) made such "hard-wired" processors 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 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, so this greatly facilitated CPU design.

In the 1940s through the late 1970s, much programming was done in assembly language; higher level instructions meant greater programmer productivity, so an important advantage of microcode was the relative ease by which powerful machine instructions could be defined. [3] During the 1970s, CPU speeds grew more quickly than memory speeds and numerous techniques such as memory block transfer, memory pre-fetch and multi-level caches 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 could 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 CISC. A middle way, used in many microprocessors, is to use PLAs and/or ROMs (instead of combinatorial logic) mainly for instruction decoding, and let a simple state machine (without much, or any, microcode) do most of the sequencing. The various practical uses of microcode and related techniques (such as PLAs) have been numerous over the years, as well as approaches to where, and to which extent, it should be used. It is still used in modern CPU designs.

[edit] Other 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 possible to implement a given instruction set architecture on a wide variety of underlying hardware micro-architectures.

Doing so is important if binary program compatibility is a priority. That way previously existing programs can run on totally new hardware without requiring revision and recompilation. However there may be a performance penalty for this approach. The tradeoffs between application backward compatibility vs CPU performance are hotly debated by CPU design engineers.

The IBM System/360 has a 32-bit architecture with 16 general-purpose registers, but most of the System/360 implementations actually use hardware that implemented a much simpler underlying microarchitecture; for example, the System/360 Model 30 had 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 core memory, and the System/360 Model 40 had 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 Model 50 and Model 65 had full 32-bit data paths and implemented the general-purpose registers in faster transistor circuits. 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 reduced the amount of unique system software that had to be written for each model.

A similar approach was used by Digital Equipment Corporation in their VAX family of computers. Initially a 32-bit TTL processor in conjunction with supporting microcode implemented the programmer-visible architecture. Later VAX versions used different microarchitectures, yet the programmer-visible architecture didn't change.

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

[edit] History

In 1947, the design of the 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 was a two-dimensional lattice: one dimension accepted "control time pulses" from the CPU's internal clock, and the other connected to control signals on gates and other circuits. A "pulse distributor" would take the pulses generated by the CPU clock and break them up into eight separate time pulses, each of which would activate a different row of the lattice. When the row was activated, it would activate the control signals connected to it.

Described another way, the signals transmitted by the control store are being played much like a player piano roll. That is, they are controlled by a sequence of very wide words constructed of bits, and they are "played" sequentially. In a control store, however, the "song" is short and repeated continuously.

In 1951 Maurice Wilkes enhanced this concept by adding conditional execution, a concept akin to a 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, as it were) 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.

[edit] Examples of microprogrammed systems

  • Most models of the IBM System/360 series were microprogrammed:
  • The Model 25 was unique among System/360 models in using the top 16k bytes of core storage to hold the control storage for the microprogram. The 2025 used a 16-bit microarchitecture with seven control words (or microinstructions). At power up, or full system reset, the microcode was loaded from the card reader. The IBM 1410 emulation for this model was loaded this way.
  • The Model 30, the slowest model in the line, used an 8-bit microarchitecture with only a few hardware registers; everything that the programmer saw was emulated by the microprogram. The microcode for this model was also held on special punched cards, which were stored inside the machine in a dedicated reader per card, called "CROS" units (Capacitor Read-Only Storage). A second CROS reader was installed for machines ordered with 1620 emulation.
  • The Model 40 used 56-bit control words. The 2040 box implements both the System/360 main processor and the multiplex channel (the I/O processor). This model used "TROS" dedicated readers similar to "CROS" units, but with an inductive pickup (Transformer Read-only Store).
  • The Model 50 had 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 used 90-bit microinstructions.
  • The Model 85 had separate instruction fetch (I-unit) and execution (E-unit) to provide high performance. The I-unit is hardware controlled. The E-unit is microprogrammed with 108-bit control words.
  • The Digital Equipment Corporation PDP-11 processors, with the exception of the PDP-11/20, were microprogrammed[4].
  • The Burroughs B700 "microprocessor" executed application-level opcodes using sequences of 16-bit microinstructions stored in main memory, each of these was either a register-load operation or mapped to a single 56-bit "nanocode" instruction stored in read-only memory. This allowed comparatively simple hardware to act either as a mainframe peripheral controller or to be packaged as a standalone computer.
  • The Burroughs B1700 was implemented with radically different hardware including bit-addressable main memory but had a similar multi-layer organisation.
  • The NCR 315 was microprogrammed with hand wired ferrite cores (a ROM) pulsed by a sequencer with conditional execution. Wires routed thru the cores were enables for various data and logic elements in the processor.
  • In common with many other complex mechanical devices Charles Babbage's analytical engine used banks of cams to control each operation, i.e. it had a read-only control store. As such it deserves to be recognised as the first microprogrammed computer to be designed, even if it has not yet been realised in hardware.
  • The VU0 and VU1 vector units in the Sony Playstation 2 are microprogrammable; in fact, VU1 was only accessible via microcode for the first several generations of the SDK.

[edit] Implementation

Each microinstruction in a microprogram provides the bits which 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, computers were divided into several parts:

A microsequencer picked 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 register set is a fast memory containing the data of the central processing unit. It may include the program counter, stack pointer, and other numbers 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 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 bought together as a single chip. This chip came in a fixed width which would form a 'slice' through the execution unit. These were known as 'bit slice' chips. The AMD Am2900 family is one of the best known examples of bit slice elements.

The parts of the execution units, and the execution units themselves are interconnected by a bundle of wires called a bus.

Programmers develop microprograms. The basic tools are software: A microassembler allows a programmer to define the table of bits symbolically. A simulator program executes the bits in the same way as the electronics (hopefully), 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. This program is similar to those used to optimize a programmable logic array. No known computer program can produce optimal logic, but even pretty good logic can vastly reduce the number of transistors from the number required for a ROM control store. This reduces the cost and power used by a CPU.

Microcode can be characterized as horizontal or vertical. This refers primarily to whether each microinstruction directly controls CPU elements (horizontal microcode), or requires subsequent decoding by combinational logic before doing so (vertical microcode). Consequently each horizontal microinstruction is wider (contains more bits) and occupies more storage space than a vertical microinstruction.

[edit] Horizontal microcode

Horizontal microcode is typically contained in a fairly wide control store, it is not uncommon for each word to be 56 bits or more. On each tick of a sequencer clock a microcode word is read, decoded, and used to control the functional elements which 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:

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:

   # 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's 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.

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

[edit] Vertical microcode

In vertical microcode, each microinstruction is encoded -- that is, the bit fields may pass through intermediate combinatory logic which in turn generates the actual control signals for internal CPU elements (ALU, registers, etc.). In contrast, with horizontal microcode the bit fields themselves directly produce the control signals. Consequently vertical microcode requires smaller instruction lengths and less storage, but requires more time to decode, resulting in a slower CPU clock.

Some vertical microcodes are just the assembly language of a simple conventional computer that is emulating a more complex computer. This technique was popular in the time of the PDP-8. Another form of vertical microcode has two fields:

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" actually 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 became cheaper, horizontal microcode came to dominate the design of CPUs using microcode, with vertical microcode no longer being used.

[edit] Writable control stores

A few computers were built using "writable microcode" -- rather than storing the microcode in ROM or hard-wired logic, the microcode was stored in a RAM called a Writable Control Store or WCS. Many of these machines were experimental laboratory prototypes, but there were also commercial machines that used writable microcode, such as early Xerox workstations, the DEC VAX 8800 ("Nautilus") family, the Symbolics L- and G-machines, and a number of IBM System/370 implementations. Many more machines offered user-programmable writeable control stores as an option (including the HP 2100 and DEC PDP-11/60 minicomputers). WCS offered several advantages including the ease of patching the microprogram and, for certain hardware generations, faster access than ROMs could provide. User-programmable WCS allowed the user to optimize the machine for specific purposes.

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 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, pipelining.

Several Intel CPUs in the IA32 architecture family have writable microcode[5]. This has allowed bugs in the Intel Core 2 microcode and Intel Xeon microcode to be fixed in software, rather than requiring the entire chip to be replaced. Such fixes can be installed by Linux[6], Microsoft Windows[7], or the motherboard BIOS[8].

[edit] Risks

Linux (on x86 PCs) has a patch program that fixes botched CPU microcode. Of all UNIX (and UNIX-like) operating systems on Intel (and Intel x86-compatible) PCs there has been an ongoing requirement to patch erroneous microcode since the FPU multiplier problem that was endemic to some Pentiums.

  • Microsoft Windows also has similar patches, but does generally not label them as such since Windows XP.
  • So far only x86 CPUs have microcode patches. This is unknown with RISC CPUs as well as general purpose DSPs.


[edit] Microcode versus VLIW and RISC

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. This included the points:

  • Analysis shows complex instructions are rarely used, hence the machine resources devoted to them are largely wasted.
  • Programming has largely moved away from assembly level, so it's no longer worthwhile to provide complex instructions for productivity reasons.
  • The machine resources devoted to rarely-used complex instructions is better used for expediting performance of simpler, commonly-used instructions.
  • Complex microcoded instructions requiring many, varying clock cycles are difficult to pipeline for increased performance.
  • Simpler instruction sets allow direct execution by hardware, avoiding the performance penalty of microcoded execution.

It should be mentioned that there are counter-points as well:

  • The complex instructions in heavily microcoded implementations may not take much extra machine resources (except microcode space); for instance, the same ALU is often used to calculate an effective address as well as computing the result from the actual operands.
  • Non-RISC instructions, i.e. involving direct memory operands 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 (i.e. the "CISC" characteristics), are more difficult to pipeline, it is still fully feasible, clearly exemplified by the Intel 486, Cyrix 6x86, 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.
  • Modern CISC implementations, most notably the x86, implement most instructions and all addressing modes "in hardware"; microcode is still used however, for some really complex, or very special, instructions (such as CPUID), as well as for internal "housekeeping".

Many RISC and 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.

[edit] See also

[edit] References

  1. ^ http://www14.software.ibm.com/webapp/set2/firmware/gjsn IBM "Microcode downloads" (showing use of the term "microcode")
  2. ^ http://download.boulder.ibm.com/ibmdl/pub/software/server/firmware/73lzx.html "Microcode Update for SCSI Hard Disk"
  3. ^ The ultimate extension of this were "Directly Executable High Level Language" designs. In these each statement of a high level language such as PL/I would be entirely and directly executed by microcode, without compilation. The IBM Future Systems project and Data General Fountainhead Processor were examples of this.
  4. ^ Daniel P. Siewiorek, C. Gordon Bell, Allen Newell (1982). Computer Structures: Principles and Examples. New York, NY: McGraw-Hill Book Company. ISBN 0-07-057302-6. 
  5. ^ "Intel(R) 64 and IA-32 Architectures Software Developer’s Manual", chapter 26.4: "Microcode update facility"
  6. ^ "Intel Microcode Update Utility for Linux"
  7. ^ "A microcode reliability update is available that improves the reliability of systems that use Intel processors"
  8. ^ "BIOS Update required when Missing Microcode message is seen during POST"

[edit] External links