Editing Microcode (section)

===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. This defeated the purpose of using microcode in the first place, which was to hide these distinctions.<ref name=risc>{{Cite journal
 | last1 = Cocke | first1 = John
 | last2 = Markstein | first2 = Victoria
 | doi = 10.1147/rd.341.0004
 | url = https://www.cis.upenn.edu/~milom/cis501-Fall11/papers/cocke-RISC.pdf
 | title = The evolution of RISC technology at IBM
 | journal = IBM Journal of Research and Development
 | volume = 34| issue = 1
 | pages = 4–11
 | date=January 1990
 }}</ref>

The team came to a radical conclusion: "Imposing microcode between a computer and its users imposes an expensive overhead in performing the most frequently executed instructions."<ref name=risc/>

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>