Content deleted Content added
m sp |
Citation bot (talk | contribs) Alter: url, template type. URLs might have been anonymized. Add: isbn, publisher, date, title. Removed URL that duplicated identifier. Changed bare reference to CS1/2. Removed parameters. | Use this bot. Report bugs. | Suggested by Jay8g | Linked from User:Jay8g/sandbox | #UCB_webform_linked 119/183 |
||
| (47 intermediate revisions by 29 users not shown) | |||
Line 3:
{{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
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''.
Line 9:
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.
Some hardware vendors, notably [[IBM]]
==Overview==
===Instruction sets===
At the hardware level, processors contain a number of separate areas of
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
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
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>{{
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 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 ''
===Microprograms===
Line 44:
* 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|
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.
Line 70:
==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>
Line 76 ⟶ 78:
===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
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/>
Line 83 ⟶ 85:
===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
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
===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
| last1 = Cocke | first1 = John
| last2 = Markstein | first2 = Victoria
Line 107 ⟶ 109:
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
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
==Examples==
Line 130 ⟶ 132:
* [[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=
{{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 [http://www.bitsavers.org/pdf/digitalScientific/ Digital Scientific Corp.] 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]]
* Earlier [[x86]] processors are fully microcoded
*
==Implementation==
Line 223 ⟶ 225:
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
The IBM System/370 includes a facility called ''Initial-Microprogram Load'' (''IML'' or ''IMPL'')<ref>{{cite book
Line 258 ⟶ 260:
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>
==Comparison to VLIW and RISC==
Line 284 ⟶ 286:
==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]].
Line 322 ⟶ 324:
| access-date= June 21, 2006
| doi = 10.1109/MAHC.1988.10039 |s2cid = 16405547
| url-access= subscription
}}
* {{cite web
| author = Smotherman, Mark
Line 340 ⟶ 343:
| 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 =
| 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
}}▼
* {{cite book
| last=Husson |first=S.S.
Line 372 ⟶ 377:
| 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}}
| |||