Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Microcode
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==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, for instance, the compiler may output instructions to load one of the values into one register, the second into another, call the addition function in the ALU, and then write the result back out to memory.<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 is taking up 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: * 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 * Store the result value in 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.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)