Difference between revisions of "Microcode"

From Computer History Wiki
Jump to: navigation, search
m (+cat)
m (Further reading: +Microprogram control for System/360)
 
(6 intermediate revisions by the same user not shown)
Line 13: Line 13:
 
==Enhancements==
 
==Enhancements==
  
In 1951, Maurice Wilkes suggested adding [[conditional branch]]ing, to make microcode more flexible. Over time, more concepts from [[higher-level language]]s have been added to microcode, such as [[subroutine]]s.
+
In 1951, [[Maurice Wilkes]] suggested more widespread use of that technique (to get rid of the design burden, and chance of errors, in using un-structured logic aggregations for control); he added [[conditional branch]]ing, to make microcode more flexible. Over time, more concepts from [[higher-level language]]s have been added to microcode, such as [[subroutine]]s.
  
Although early microcode was implemented in read-only memory (the Whirlwind ROM was a diode matrix), some later computers included high-speed [[Random Access Memory|RAM]] for part of the control store, so that the instruction set could be dynamically extended to speed up applications.
+
Although early microcode was implemented in read-only memory (the Whirlwind ROM was a [[diode]] matrix), some later computers included high-speed [[Random Access Memory|RAM]] for part of the control store, so that the instruction set could be dynamically extended to speed up applications.
  
 
Recently, microcode has been augmented with [[programmable logic array]]s, which are usually given the job of decoding instructions (something done more efficiently in combinatorial logic).
 
Recently, microcode has been augmented with [[programmable logic array]]s, which are usually given the job of decoding instructions (something done more efficiently in combinatorial logic).
  
==Other advantages==
+
==Other advantages and uses==
 +
 
 +
Once microprogramming came into more general use, a number of other advantages, and uses, appeared.
  
 
With much of the control for a microprogrammed machine in the microprogram, bugs in the CPU could often be fixed by replacing the microprogram alone, without required hardware changes. (With the coming of the [[microprocessor]], where the microprogram is often in ROM in the chip, this is usually no longer possible.)
 
With much of the control for a microprogrammed machine in the microprogram, bugs in the CPU could often be fixed by replacing the microprogram alone, without required hardware changes. (With the coming of the [[microprocessor]], where the microprogram is often in ROM in the chip, this is usually no longer possible.)
  
Microprogramming also made it possible to offer a range (in performance and cost terms) of machines which all had the same basic architecture, but different internal implementations; microcode could be used to make the different machines all support the same instruction set. This too is now not common, since it is not usual to offer multiple implementations with differing performance at the same time; however, it can be used to meet an analogous goal, making new generations of microprocessors implement the identical instruction set to previous ones.
+
Microprogramming also made it possible to offer a range (in performance and cost terms) of machines which all had the same basic architecture, but different internal implementations; microcode could be used to make the different machines all support the same instruction set. This was originally, and most influentially, displayed by the [[IBM System/360]] line of computers. This too is now not common, since it is not usual to offer multiple implementations with differing performance at the same time; however, it can be used to meet an analogous goal, making new generations of microprocessors implement the identical instruction set to previous ones.
 +
 
 +
The System/360 also showed another use for microcode: System/360 computers included microcode to [[emulate]] earlier IBM computers (such as the [[IBM 1401]]); in an era when most programming was done in [[assembly language]], this allowed people to upgrade to a System/360 machine without discarding their investment in software for the earlier machine.
 +
 
 +
Once a microcoded CPU had been designed, it was relatively easy to expand the [[instruction set]] to include more complex instructions (something whose only per-unit repeated cost was larger microcode memories). For much of the lifetime of computers, the CPU was faster than the main memory; in such an environment, it made sense to make the instructions of the CPU as powerful (complicated) as possible, so a single instruction fetch (which is, of course, pure overhead in terms of the actual computation) does as much as possible. Such complex instructions are more easily implemented with a microcode approach, than with combinatorial logic.
 +
 
 +
==Further reading==
 +
 
 +
* M. V. Wilkes, [https://www.cs.princeton.edu/courses/archive/fall10/cos375/BestWay.pdf The Best Way to Design an Automatic Computing Machine], Report of Manchester University Computer Inaugural Conference, July 1951, pp. 16–18 - Wilkes' original note on microcode
 +
* M. V. Wilkes, J. B. Stringer, [https://ur.booksc.eu/dl/53713365/d07ff7 Microprogramming and the design of the control circuits in an electronic digital computer], Proc. Cambridge Phil. Soc., Part 2, Volume 49, pp. 230-238, April, 1953 - Wilkes' full article on microcode <!-- https://gordonbell.azurewebsites.net/Computer_Structures__Readings_and_Examples/00000355.htm -->
 +
*  S. G. Tucker, [https://dokumen.tips/documents/microprogram-control-for-system360.html ''Microprogram control for System/360''], IBM Systems Journal, Vol. 6, No.4, 1967 - provides a good general overview of the 'state of the art' at the time
 +
 
 +
==External links==
  
For much of the lifetime of computers, the CPU was faster than the main memory; in such an environment, it makes sense to make the instructions of the CPU as high-level as possible, so a single instruction fetch (which is, of course, pure overhead in terms ot the actual computation) does as much as possible. Such complex instructions are more easily implemented with a microcode approach, than with combinatorial logic.
+
* [http://www.edwardbosworth.com/CPSC5155/PH4/Ch04/Ch04_Microprogramming.pdf Control Units: Hardwired & Microprogrammed]
 +
* [https://bitsavers.org/pdf/ibm/370/GF20-0385-0_An_Introduction_to_Microprogramming_Dec71.pdf An Introduction to Microprogramming]
  
[[Category: Hardware Basics‎‎]]
+
[[Category: Hardware Basics]]

Latest revision as of 14:25, 22 January 2024

Microcode (in the form of a microprogram) refers to a technique for implementing the functionality needed to control the internal operation of a CPU.

On each microcycle (analogous, internally, to the cycles of the main CPU), a microinstruction is fetched, and used to control the operation of the CPU's internal hardware elements during that microcycle: routing data out of registers (including internal registers not visible to the programmer) and/or main memory, through the ALU (while selecting which operation is to be performed by it), and then storing the results as apropriate. They are thus analagous to the instructions of the main CPU, but at a much lower level.

Background

The earliest generation of CPU's used collections of gates and flip-flops to implement the functionality of controlling the operation of the internal elements. As the instruction sets and overall architecture of early computers became more complex, the design of those combinatorial logic networks became more challenging.

In 1947, the Whirlwind computer introduced the concept of a control store; a wide read-only memory whose outputs directly controlled internal elements of the CPU. (E.g. one bit in a control word might control the latching of an internal register.)

The CPU cycled through the words in the control store, to execute instructions. Viewing (and implementing) the internal operation of the CPU in this way made the design task easier.

Enhancements

In 1951, Maurice Wilkes suggested more widespread use of that technique (to get rid of the design burden, and chance of errors, in using un-structured logic aggregations for control); he added conditional branching, to make microcode more flexible. Over time, more concepts from higher-level languages have been added to microcode, such as subroutines.

Although early microcode was implemented in read-only memory (the Whirlwind ROM was a diode matrix), some later computers included high-speed RAM for part of the control store, so that the instruction set could be dynamically extended to speed up applications.

Recently, microcode has been augmented with programmable logic arrays, which are usually given the job of decoding instructions (something done more efficiently in combinatorial logic).

Other advantages and uses

Once microprogramming came into more general use, a number of other advantages, and uses, appeared.

With much of the control for a microprogrammed machine in the microprogram, bugs in the CPU could often be fixed by replacing the microprogram alone, without required hardware changes. (With the coming of the microprocessor, where the microprogram is often in ROM in the chip, this is usually no longer possible.)

Microprogramming also made it possible to offer a range (in performance and cost terms) of machines which all had the same basic architecture, but different internal implementations; microcode could be used to make the different machines all support the same instruction set. This was originally, and most influentially, displayed by the IBM System/360 line of computers. This too is now not common, since it is not usual to offer multiple implementations with differing performance at the same time; however, it can be used to meet an analogous goal, making new generations of microprocessors implement the identical instruction set to previous ones.

The System/360 also showed another use for microcode: System/360 computers included microcode to emulate earlier IBM computers (such as the IBM 1401); in an era when most programming was done in assembly language, this allowed people to upgrade to a System/360 machine without discarding their investment in software for the earlier machine.

Once a microcoded CPU had been designed, it was relatively easy to expand the instruction set to include more complex instructions (something whose only per-unit repeated cost was larger microcode memories). For much of the lifetime of computers, the CPU was faster than the main memory; in such an environment, it made sense to make the instructions of the CPU as powerful (complicated) as possible, so a single instruction fetch (which is, of course, pure overhead in terms of the actual computation) does as much as possible. Such complex instructions are more easily implemented with a microcode approach, than with combinatorial logic.

Further reading

External links