View source for IBM 801

{{Short description|Experimental minicomputer by IBM}}
{{About|the 1970s IBM CPU|the document processor released in 1934|IBM document processors#IBM 801}}

The '''801''' was an experimental [[central processing unit]] (CPU) design developed by [[IBM]] during the 1970s. It is considered to be the first modern [[RISC]] design, relying on [[processor register]]s for all computations and eliminating the many variant [[addressing mode]]s found in [[Complex instruction set computer|CISC]] designs. Originally developed as the processor for a [[telephone switch]], it was later used as the basis for a [[minicomputer]] and a number of products for their [[mainframe computer|mainframe]] line. The initial design was a [[24-bit]] processor; that was soon replaced by [[32-bit]] implementations of the same concepts and the original 24-bit 801 was used only into the early 1980s.

During the initial design the system was considered as a simple processor with limited functionality that would not compete with IBM's more complex systems like the [[System/370]]. But as they explored the concept using huge amounts of performance data collected from their customers, the team was able to demonstrate that the simple design was able to easily outperform even the most powerful classic CPU designs. Applying these same techniques to existing machines like the S/370, that is, ignoring the many complex [[opcode]]s in favour of doing everything it could in registers, doubled the performance of those systems as well. The complexity of these older designs actually led to slower and much more costly machines, spending considerable complexity implementing codes that were better left unused. This demonstrated the value of the RISC concept, and all of IBM's future systems were based on the principles developed during the 801 project.

For his work on the 801, [[John Cocke (computer scientist)|John Cocke]] was recognized with several awards and medals, including the [[Turing Award]] in 1987, [[National Medal of Technology]] in 1991, and the [[National Medal of Science]] in 1994.

==History==
===Original concept===

In 1974, IBM began examining the possibility of constructing a [[telephone switch]] to handle one million calls an hour, or about 300 calls per second. They calculated that each call would require 20,000 instructions to complete, and when timing overhead and other considerations were added, such a machine required performance of about 12 MIPS.{{sfn|Cocke|Markstein|1990|p=4}} This would require a significant advance in performance; their current top-of-the-line machine, the [[IBM System/370 Model 168]] of late 1972, offered about 3 MIPS.<ref>{{cite web |url=https://alt.folklore.computers.narkive.com/9nl6cj2Q/on-the-370-165-and-the-360-85 |title= On the 370/165 and the 360/85 |first= John |last= Savard}}</ref>

The group working on this project at the [[Thomas J. Watson Research Center]], including [[John Cocke (computer scientist)|John Cocke]], designed a processor for this purpose. To reach the required performance, they considered the sort of operations such a machine required and removed any that were not appropriate. This led to the removal of a [[floating-point unit]] for instance, which would not be needed in this application. More critically, they also removed many of the instructions that worked on data in [[main memory]] and left only those instructions that worked on the internal [[processor register]]s, as these were much faster to use and the simple code in a telephone switch could be written to use only these types of instructions. The result of this work was a conceptual design for a simplified processor with the required performance.{{sfn|Cocke|Markstein|1990|p=4}}

The telephone switch project was canceled in 1975, but the team had made considerable progress on the concept and in October IBM decided to continue it as a general-purpose design. With no obvious project to attach it to, the team decided to call it the "801" after the building they worked in. For the general-purpose role, as opposed to the dedicated telephone system, the team began to consider real-world programs that would be run on a typical [[minicomputer]]. IBM had collected enormous amounts of statistical data on the performance of real-world workloads on their machines and this data demonstrated that over half the time in a typical program was spent performing only five instructions: load value from memory, store value to memory, adding fixed-point numbers, comparing fixed-point numbers, and branching based on the result of those comparisons. This suggested that the same simplified processor design would work just as well for a general-purpose minicomputer as a special-purpose switch.{{sfn|Cocke|Markstein|1990|p=5}}

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

===First implementations===
The initially proposed architecture was a machine with sixteen [[24-bit]] registers and without [[virtual memory]].<ref>{{cite web|url=http://www.bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf|title=The 801 Minicomputer - An Overview|date=October 8, 1976|page=9|access-date=January 16, 2019|archive-date=March 27, 2020|archive-url=https://web.archive.org/web/20200327073130/http://bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf|url-status=dead}}</ref><ref>{{cite web|url=http://www.bitsavers.org/pdf/ibm/system801/System_801_Principles_of_Operation_Jan76.pdf|title=System 801 Principles of Operation|date=January 16, 1976}}</ref> It used a two-operand format in the instruction, so that instructions were generally of the form <code>A = A + B</code>, as opposed to the three-operand format, <code>A = B + C</code>. The resulting CPU was operational by the summer of 1980 and was implemented using Motorola MECL-10K discrete component technology{{sfn|Radin|1982}} on large wire-wrapped custom boards. The CPU was clocked at 66&nbsp;ns cycles (approximately 15.15&nbsp;MHz) and could compute at the fast speed of approximately 15&nbsp;[[million instructions per second|MIPS]].

The 801 architecture was used in a variety of IBM devices, including [[channel controller]]s for their S/370 mainframes (such as the [[IBM 3090]]),<ref name="microprocessors-programmers-view">{{cite book |last1=Dewar |first1=Robert B.K. |last2=Smosna |first2=Matthew |title=Microprocessors: A Programmer's View |url=https://archive.org/details/microprocessorsp00robe |url-access=registration |date=1990 |publisher=McGraw-Hill}}</ref>{{rp|377}} various networking devices, and as a [[vertical microcode]] execution unit in the 9373 and 9375 processors of the [[IBM 9370]] mainframe family.{{sfn|Cocke|Markstein|1990|p=9}}<ref name="Mitchell1988">{{cite journal | last1 = Mitchell | first1 = James | title = Implementing a mainframe architecture in a 9370 processor | journal = ACM SIGMICRO Newsletter | date = September 1988 | volume = 19 | issue = 3 | pages = 3–10 | issn = 1050-916X | doi = 10.1145/62185.62186 | pmid = | s2cid = 14602753 | url = }}</ref> The original version of the 801 architecture was the basis for the architecture of the [[IBM ROMP]] [[microprocessor]]<ref name="microprocessors-programmers-view"/>{{rp|378}} used in the [[IBM RT PC]] [[workstation computer]] and several experimental computers from [[IBM Research]]. A derivative of the 801 architecture with [[32-bit]] addressing named ''Iliad'' was intended to serve as the primary processor of the unsuccessful [[IBM AS/400#Fort Knox|Fort Knox]] midrange system project.<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>

==Later modifications==
Having been originally designed for a limited-function system, the 801 design lacked a number of features seen on larger machines. Notable among these was the lack of hardware support for [[virtual memory]], which was not needed for the controller role and had been implemented in software on early 801 systems that needed it. For more widespread use, hardware support was a must-have feature. Additionally, by the 1980s the computer world as a whole was moving towards [[32-bit]] systems, and there was a desire to do the same with the 801.{{sfn|Cocke|Markstein|1990|p=7}}

Moving to a 32-bit format had another significant advantage. In practice, it was found that the two-operand format was difficult to use in typical math code. Ideally, both input operands would remain in registers where they could be reused in subsequent operations. In the two-operand format, one of the two values was overwritten with the result, and it was often the case that one of the values had to be re-loaded from memory. By moving to a 32-bit format, the extra bits in the instruction words allowed an additional register to be specified, so that the output of such operations could be directed to a separate register. The larger instruction word also allowed the number of registers to be increased from sixteen to thirty-two, a change that had been obvious from the examination of 801 code. Despite the expansion of the instruction words from 24 to 32-bits, programs did not grow by the corresponding 33% due to avoided loads and saves due to these two changes.{{sfn|Cocke|Markstein|1990|p=7}}

Other desirable additions include instructions for working with string data that was encoded in "packed" format with several characters in a single memory word, and additions for working with [[binary-coded decimal]], including an adder that could carry across four-bit decimal numbers.{{sfn|Cocke|Markstein|1990|p=7}}

When the new version of the 801 was run as a simulator on the 370, the team was surprised to find that code compiled to the 801 and run in the simulator would often run faster than the same [[source code]] compiled directly to 370 [[machine code]] using the 370's [[PL/I]] compiler.{{sfn|Cocke|Markstein|1990|p=8}} When they ported their experimental "PL.8" language back to the 370 and compiled applications using it, those applications ran as much as three times as fast as the PL/I versions. This was due to the compiler making RISC-like decisions about how the generated code uses the processor registers, thereby optimizing out as many memory accesses as possible. These were just as expensive on the 370 as the 801, but this cost was normally hidden by the simplicity of a single line of CISC code. The PL.8 compiler was much more aggressive about avoiding loads and saves, thereby resulting in higher performance even on a CISC processor.{{sfn|Cocke|Markstein|1990|p=8}}

==The Cheetah, Panther, and America projects==
In the early 1980s, the lessons learned on the 801 were combined with those from the [[IBM Advanced Computer Systems project|IBM Advanced Computer Systems]] project, resulting in an experimental processor called "Cheetah". Cheetah was a 2-way [[superscalar processor]], which evolved into a processor called "Panther" in 1985, and finally into a 4-way superscalar design called "America" in 1986.<ref>{{Cite book |last1=Shen |first1=John Paul |title=Modern Processor Design: Fundamentals of Superscalar Processors |last2=Lipasti |first2=Mikko H. |publisher=McGraw-Hill |year=2005 |contributor-last=Smotherman |contributor-first=Mark |contribution=Survey of Superscalar Processors}}</ref> This was a three-chip processor set including an instruction processor that fetches and decodes instructions, a fixed-point processor that shares duty with the instruction processor, and a floating-point processor for those systems that require it. Designed by the 801 team, the final design was sent to IBM's Austin office in 1986, where it was developed into the [[IBM RS/6000]] system. The RS/6000 running at 25&nbsp;MHz was one of the fastest machines of its era. It outperformed other RISC machines by two to three times on common tests, and easily outperformed older CISC systems.{{sfn|Cocke|Markstein|1990|p=9}}

After the RS/6000, the company turned its attention to a version of the 801 concepts that could be efficiently fabricated at various scales. The result was the [[IBM POWER instruction set architecture]] and the [[PowerPC]] offshoot.

==Recognition==
For his work on the 801, [[John Cocke (computer scientist)|John Cocke]] was awarded several awards and medals:

* 1985: [[Eckert–Mauchly Award]]<ref>{{Cite web |title=John Cocke |url=https://awards.acm.org/award_winners/cocke_2083115 |access-date=2022-08-29 |website=awards.acm.org |language=en}}</ref>
* 1987: [[A.M. Turing Award]]<ref>{{Cite web |title=John Cocke - A.M. Turing Award Laureate |url=https://amturing.acm.org/award_winners/cocke_2083115.cfm |access-date=2022-08-29 |website=amturing.acm.org}}</ref>
* 1989: [[Computer Pioneer Award]]<ref>{{Cite web |title=IEEE Computer Society Women of ENIAC Computer Pioneer Award |date=9 April 2018 |url=https://www.computer.org/volunteering/awards/pioneer |access-date=2022-08-29 |language=en-US}}</ref>
* 1991: [[National Medal of Technology]]<ref name=":0">{{Cite web|title=NSTMF|url=https://www.nationalmedals.org/laureates/john-cocke|website=NSTMF|access-date=2020-05-12}}</ref>
* 1994: [[John von Neumann Medal|IEEE John von Neumann Medal]]<ref>{{Cite web |title=IEEE John von Neumann Medal Recipients |website=[[Institute of Electrical and Electronics Engineers]] (IEEE) |url=https://corporate-awards.ieee.org/wp-content/uploads/von-neumann-rl.pdf}}</ref>
* 1994: [[National Medal of Science]]<ref name=":0" />
* 2000: [[Benjamin Franklin Medal (Franklin Institute)|Benjamin Franklin Medal]] (The Franklin Institute)<ref>{{Cite web |date=2014-01-10 |title=John Cocke |url=https://www.fi.edu/laureates/john-cocke |access-date=2022-08-29 |website=The Franklin Institute |language=en}}</ref>

[[Michael J. Flynn]] views the 801 as the first RISC.<ref name="Flynn54">{{cite book |title=Computer architecture: pipelined and parallel processor design |author-link=Michael J. Flynn |first=Michael J. |last=Flynn |year=1995 |isbn=0867202041 |pages=54–56 |publisher=Jones & Bartlett Learning }}</ref>

==References==
===Citations===
{{reflist}}

===Bibliography===
* {{Cite journal
 | last1 = Cocke | first1 = John
 | last2 = Markstein | first2 = Victoria
 | doi = 10.1147/rd.341.0004
 | url = https://acg.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
 }}
* {{cite book
 |first=John|last=Cocke
 |chapter=The search for performance in scientific processors
 |title=ACM Turing award lectures
 |volume=31
 |issue=3|page=252
 |date=March 1988
 |doi=10.1145/1283920.1283945
 |isbn=978-1-4503-1049-9
 |doi-access=free
}}
* {{Cite conference
 | doi = 10.1145/800050.801824
 | title = The 801 minicomputer
 | book-title = Proceedings of the first international symposium on Architectural support for programming languages and operating systems
 | conference = [[International Conference on Architectural Support for Programming Languages and Operating Systems|ASPLOS]]-I
 | pages = 39–47
 | year = 1982
 | last1 = Radin | first1 = G. | author-link1 = George Radin
 | isbn = 0-89791-066-4
 }}

==Further reading==
* {{cite magazine |title=Altering Computer Architecture is Way to Raise Throughput, Suggests IBM Researchers |magazine=[[Electronics (magazine)|Electronics]] |volume=49 |number=25 |date=23 December 1976 |pages=0{{ndash}}31}}
* {{cite magazine |first=V. |last=McLellan |title=IBM Mini a Radical Departure |magazine=[[Datamation]] |volume=25 |number=11 |date=October 1979 |pages=53{{ndash}}55}}
* {{cite book |last1=Dewar |first1=Robert B.K. |last2=Smosna |first2=Matthew |title=Microprocessors: A Programmer's View |url=https://archive.org/details/microprocessorsp00robe |url-access=registration |date=1990 |publisher=McGraw-Hill |pages=258{{ndash}}264}}
* {{cite book |last1=Tabak |first1=Daniel |title=RISC Architecture |date=1987 |publisher=Research Studies Press |pages=69{{ndash}}72}}

==External links==
*[http://bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf The 801 Minicomputer - An Overview] {{Webarchive|url=https://web.archive.org/web/20110322222410/http://www.bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf |date=2011-03-22 }}
*[http://bitsavers.org/pdf/ibm/system801/System_801_Principles_of_Operation_Jan76.pdf IBM System 801 Principles of Operation, Version 2]
*[http://bitsavers.org/pdf/ibm/system801/801_IO_Subsystem_Definition_Jan76.pdf 801 I/O Subsystem Definition]
*IBM Archives: {{webarchive |url=https://web.archive.org/web/20060503190348/http://www-03.ibm.com/ibm/history/documents/pdf/rs6000.pdf |date=2006-05-03 |title=A Brief History of RISC, the IBM RS/6000 and the IBM eServer pSeries}}

{{RISC-based processor architectures}}
{{IBM midrange computers}}

[[Category:IBM minicomputers|801]]
[[Category:Minicomputers]]