Microcode: Difference between revisions

Revision as of 00:20, 2 May 2025

Revision as of 17:41, 23 May 2025

Line 107:

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 Computer" |first1=Douglas |last1=Clark |first2=William |last2=Strecker |date=September 1980 |journal=ACM|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|url=https://ieeexplore.ieee.org/document/63682|title=The execution pipeline of the Intel i486 CPU|book-title= Digest of Papers Compcon Spring '90. Thirty-Fifth IEEE Computer Society International Conference on Intellectual Leverage|publisher=[[IEEE]]|isbn=0-8186-2028-5|___location=San Francisco, CA|doi=10.1109/CMPCON.1990.63682|url-access=subscription}}</ref> The [[Pentium Pro]]'s fetch and decode hardware fetches instructions and decodes them into series of micro-operations that are passed on to the execution unit, which schedules and executes the micro-operations, possibly doing so [[out-of-order execution|out-of-order]]. Complex instructions are implemented by microcode that consists of predefined sequences of micro-operations.<ref>{{cite web|url=http://stffrdhrn.github.io/content/2019/Intel_PentiumPro.pdf|title=Pentium Pro Processor At 150, 166, 180, and 200 MHz|publisher=[[Intel]]|date=November 1995|type=Datasheet}}</ref>

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 access that are similar to instructions provided by the [[VAX]] architecture.<ref name="axp-architecture-manual" /> CMOS [[IBM System/390]] CPUs, starting with the G4 processor, and [[z/Architecture]] CPUs use [[millicode]] to implement some instructions.<ref>{{cite journal|last=Rogers|first=Bob|title=The What and Why of zEnterprise Millicode|journal=IBM Systems Magazine|date=Sep–Oct 2012|url=http://www.ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/|archive-url=https://web.archive.org/web/20121009085728/http://www.ibmsystemsmag.com/mainframe/administrator/performance/millicode_rogers/|archive-date=October 9, 2012|url-status=dead}}</ref>

Line 130:

* [[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=dead |archive-url=https://web.archive.org/web/20121021070818/http://www.gamasutra.com/view/feature/3148/postmortem_angel_studios_.php |archive-date=October 21, 2012}}</ref>

{{Further|topic=Nintendo 64 microcode|Nintendo 64 programming characteristics|Nintendo 64 Game Pak}}

Line 322:

| access-date= June 21, 2006

| doi = 10.1109/MAHC.1988.10039 |s2cid = 16405547

| url-access= subscription

}}

* {{cite web

| author = Smotherman, Mark

Line 340 ⟶ 341:

| 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

Line 352 ⟶ 354:

| access-date = August 23, 2006

| doi = 10.1017/S0305004100028322| bibcode = 1953PCPS...49..230W

|s2cid=62230627 }}| url-access= subscription

}}

* {{cite book

| last=Husson |first=S.S.

Line 372 ⟶ 375:

| 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}}