Editing IBM 801 (section)

===Rationale against use of microcode===
This conclusion flew in the face of contemporary processor design, which was based on the concept of using [[microcode]]. IBM had been among the first to make widespread use of this technique as part of their [[System/360]] series. The 360s, and later the 370s, came in a variety of performance levels that all ran the same [[machine language]] code. On the high-end machines, many of these instructions were implemented directly in hardware, like a [[floating point unit]], while low-end machines could instead simulate those instructions using a sequence of other instructions encoded in microcode. This allowed a single [[application binary interface]] to run across the entire lineup and allowed the customers to feel confident that if more performance was ever needed they could move up to a faster machine without any other changes.<ref>{{cite web <!--Deny Citation Bot--> | title=The IBM System/360 and the Use of Microcode |url=http://scihi.org/ibm-system360-microcode/ |website=SciHub |first=Harald |last=Sack |date= 7 April 2016}}</ref>

Microcode allowed a simple processor to offer many instructions, which had been used by the designers to implement a wide variety of [[addressing mode]]s. For instance, an instruction like <code>ADD</code> might have a dozen variations, one that adds two numbers in internal registers, one that adds a register to a value in memory, one that adds two values from memory, etc. This allowed the programmer to select the exact version they needed for any particular task. The processor would read that instruction and use microcode to break it into a series of internal instructions. For instance, adding two numbers in memory might be implemented by loading those two numbers from memory into registers, adding them, and then storing the sum back to memory.{{sfn|Cocke|Markstein|1990|p=5}} The idea of offering all possible addressing modes for all instructions became a goal of processor designers, the concept becoming known as an [[orthogonal instruction set]].

The 801 team noticed a side-effect of this concept; when faced with the plethora of possible versions of a given instruction, [[compiler]] authors would usually pick a single version. This was typically the one that was implemented in hardware on the low-end machines. That ensured that the machine code generated by the compiler would run as fast as possible on the entire lineup. While using other versions of instructions might run even faster on a machine that implemented them in hardware, the complexity of knowing which one to pick on an ever-changing list of machines made this extremely unattractive, and compiler authors largely ignored these possibilities.{{sfn|Cocke|Markstein|1990|p=5}}

As a result, the majority of the instructions available in the instruction set were never used in compiled programs. And it was here that the team made the key realization of the 801 project:

<blockquote>Imposing microcode between a computer and its users imposes an expensive overhead in performing the most frequently executed instructions.{{sfn|Cocke|Markstein|1990|p=5}}</blockquote>

Microcode takes a non-zero time to examine the instruction before it is performed. The same underlying processor with the microcode removed would eliminate this overhead and run those instructions faster. Since microcode essentially ran small [[subroutine]]s dedicated to a particular hardware implementation, it was ultimately performing the same basic task that the compiler was, implementing higher-level instructions as a sequence of machine-specific instructions. Simply removing the microcode and implementing that in the compiler could result in a faster machine.{{sfn|Cocke|Markstein|1990|p=5}}

One concern was that programs written for such a machine would take up more memory; some tasks that could be accomplished with a single instruction on the 370 would have to be expressed as multiple instructions on the 801. For instance, adding two numbers from memory would require two load-to-register instructions, a register-to-register add, and then a store-to-memory. This could potentially slow the system overall if it had to spend more time reading instructions from memory than it formerly took to decode them. As they continued work on the design and improved their compilers, they found that overall program length continued to fall, eventually becoming roughly the same length as those written for the 370.{{sfn|Cocke|Markstein|1990|pp=6-7}}