IBM 801

801は、 1970 年代にIBMが開発した実験的な中央処理装置(CPU) 設計でした。これは、すべての計算をプロセッサ レジスタに依存し、 CISC設計に見られる多くのバリアントアドレス指定モードを排除した、最初の現代的なRISC設計であると考えられています。もともと電話交換機用のプロセッサとして開発されたこのプロセッサは、後にミニコンピュータやメインフレームラインの多数の製品のベースとして使用されました。最初の設計は24 ビットプロセッサでしたが、すぐに同じコンセプトの32 ビット実装に置き換えられ、元の 24 ビット 801 は 1980 年代初頭までしか使用されませんでした。

801 はコンピュータ市場に非常に大きな影響力を持っていました。^[要出典]膨大な量のパフォーマンス データを備えた IBM は、シンプルな設計でも最も強力な従来の CPU 設計よりも簡単にパフォーマンスが優れていることを実証することができました。同時に、高度に最適化された CISC 命令よりもわずかに大きいだけのマシン コードを生成することができました。同じ手法をSystem/370などの既存のプロセッサに適用すると、それらのシステムのパフォーマンスも通常 2 倍になりました。これにより RISC コンセプトの価値が実証され、IBM の将来のシステムはすべて 801 プロジェクトで開発された原理に基づいていました。

ジョン・コックは、801 に関する研究により、1987 年のチューリング賞、1991 年の全米技術賞、 1994 年の全米科学賞など、数々の賞やメダルを受賞しました。

1974 年、IBM は1 時間あたり 100 万件の通話、つまり 1 秒あたり約 300 件の通話を処理できる電話交換機の構築の可能性を検討し始めました。IBM は、各通話を完了するには 20,000 の命令が必要であり、タイミングのオーバーヘッドやその他の考慮事項が加わると、そのようなマシンには約 12 MIPS のパフォーマンスが必要であると計算しました。 ^[1]これはパフォーマンスの大幅な向上を必要とします。当時の最高級マシンである1972 年後半のIBM System/370 モデル 168 は、約 3 MIPS を提供していました。^[2]

トーマス・J・ワトソン研究センターでこのプロジェクトに取り組んでいたグループ（ジョン・コックを含む）は、この目的のためにプロセッサを設計した。必要な性能を達成するために、彼らはそのようなマシンに必要な操作の種類を考慮し、不適当なものをすべて削除した。これにより、たとえば、このアプリケーションでは必要のない浮動小数点ユニットが削除された。さらに重要なことに、彼らはメインメモリ内のデータに対して機能する命令の多くも削除し、内部プロセッサレジスタに対して機能する命令のみを残した。これらの命令の方がはるかに高速であり、電話交換機の簡単なコードはこれらのタイプの命令だけを使用するように記述できるためである。この作業の結果、必要な性能を備えた簡素化されたプロセッサの概念設計が生まれた。^[1]

電話交換機プロジェクトは 1975 年に中止されましたが、チームはコンセプトに関してかなりの進歩を遂げており、10 月に IBM はそれを汎用設計として継続することを決定しました。明確なプロジェクトがないため、チームは作業していた建物にちなんで「801」と呼ぶことにしました。汎用の役割については、チームは一般的なミニコンピュータで実行される実際のプログラムを検討し始めました。IBM は、マシン上の実際のワークロードのパフォーマンスに関する膨大な統計データを収集しており、このデータにより、一般的なプログラムの半分以上の時間は、メモリからの値のロード、メモリへの値の保存、分岐、固定小数点数の比較、および固定小数点数の加算という 5 つの命令の実行に費やされていることが示されました。これは、同じ簡素化されたプロセッサ設計が、汎用ミニコンピュータでも専用交換機と同様に機能することを示唆していました。^[3]

この結論は、マイクロコードを使用するという概念に基づいた当時のプロセッサ設計とは正反対だった。IBMは、 System/360シリーズの一部としてこの技術を広く採用した最初の企業の1つだった。360と370にはさまざまなパフォーマンスレベルがあり、すべて同じマシン言語コードを実行した。ハイエンドマシンでは、これらの命令の多くは浮動小数点ユニットのようにハードウェアに直接実装されていたが、ローエンドマシンではマイクロコードでエンコードされた他の命令のシーケンスを使用してこれらの命令をシミュレートすることができた。これにより、単一のアプリケーションバイナリインターフェイスを全ラインナップで実行でき、顧客は、より高いパフォーマンスが必要になった場合に、他の変更を加えることなくより高速なマシンに移行できるという自信を持つことができた。^[4]

マイクロコードにより、単純なプロセッサで多くの命令を提供できるようになり、設計者はそれを使用してさまざまなアドレッシング モードを実装しました。たとえば、のような命令ADDには 12 のバージョンがあり、内部レジスタで 2 つの数値を加算するもの、レジスタをメモリ内の値に加算するもの、メモリから 2 つの値を加算するものなどがあります。これにより、プログラマは特定のタスクに必要なバリエーションを正確に選択できます。プロセッサはその命令を読み取り、マイクロコードを使用して一連の内部命令に分解します。たとえば、メモリ内の 2 つの数値を加算する場合は、その 2 つの数値をレジスタにロードし、加算してから、その合計をメモリに格納することで実装できます。^[3]すべての命令にすべての可能なアドレッシング モードを提供するという考えは、プロセッサ設計者の目標となり、この概念は直交命令セットとして知られるようになりました。

801 チームはこの概念の副作用に気付きました。特定の命令の可能なバージョンが多すぎる場合、コンパイラの作者は通常 1 つのバージョンを選択します。これは通常、ローエンド マシンのハードウェアに実装されているバージョンです。これにより、コンパイラによって生成されたマシン コードは、ラインナップ全体で可能な限り高速に実行されます。命令の他のバージョンを使用すると、ハードウェアに実装されているマシンでさらに高速に実行される可能性がありますが、常に変化するマシンのリストでどれを選択するかを知る複雑さにより、これは非常に魅力的ではなく、コンパイラの作者はこれらの可能性をほとんど無視しました。^[3]

その結果、命令セットで利用可能な命令の大部分は、コンパイルされたプログラムでは使用されませんでした。そして、ここでチームは 801 プロジェクトの重要な実現を実現しました。

コンピュータとそのユーザーの間にマイクロコードを強制すると、最も頻繁に実行される命令を実行する際にコストのかかるオーバーヘッドが発生します。^[3]

マイクロコードは、命令を実行する前にその命令を調べるのにゼロではない時間がかかります。マイクロコードを削除した同じプロセッサでは、このオーバーヘッドがなくなり、命令の実行速度が速くなります。マイクロコードは基本的に特定のハードウェア実装専用の小さなサブルーチンを実行するため、最終的にはコンパイラと同じ基本的なタスクを実行し、マシン固有の命令のシーケンスとして高レベルの命令を実装していました。マイクロコードを削除してコンパイラに実装するだけで、マシンの速度が速くなる可能性があります。^[3]

懸念事項の 1 つは、このようなマシン用に書かれたプログラムはより多くのメモリを消費することだった。370 では 1 つの命令で実行できたタスクも、801 では複数の命令で表現しなければならない。たとえば、メモリから 2 つの数値を加算するには、レジスタへのロード命令が 2 つ、レジスタ間の加算命令が 1 つ、メモリへのストア命令が 1 つ必要になる。メモリから命令を読み込むのに、デコードに要していた時間よりも長い時間がかかると、システム全体の速度が低下する可能性がある。設計作業を続け、コンパイラを改良していくうちに、プログラム全体の長さは減少し続け、最終的には 370 用に書かれたものとほぼ同じ長さになった。^[5]

当初提案されたアーキテクチャは、16個の24ビットレジスタを持ち、仮想メモリを持たないマシンでした。^{[6] [7]}このマシンでは、命令に2オペランド形式が使用されていたため、命令は一般に の形式でありA = A + B、3オペランド形式の とは対照的でしたA = B + C。結果として得られたCPUは1980年の夏までに動作可能となり、モトローラMECL-10Kディスクリートコンポーネント技術^{[8]を使用して、大型のワイヤラップカスタムボード上に実装されました。CPUは66nsサイクル（約15.15MHz）でクロックされ、約}15MIPSの高速で計算を行うことができました 。

801アーキテクチャは、IBMのさまざまなデバイスで使用されました。これには、 S/370メインフレーム（ IBM 3090など）のチャネルコントローラ、 ^{[9] : 377}、さまざまなネットワークデバイス、IBM 9370メインフレームファミリの9373および9375プロセッサの垂直マイクロコード実行ユニットが含まれます。^{[10] [11]} 801アーキテクチャのオリジナルバージョンは、IBM RT PCワークステーションコンピュータとIBMリサーチのいくつかの実験用コンピュータで使用されるIBM ROMPマイクロプロセッサ^{[9] : 378}のアーキテクチャの基礎となりました。32ビットアドレス指定を備えた801アーキテクチャの派生であるIliadは、失敗に終わったフォートノックスミッドレンジシステムプロジェクトの主要プロセッサとして機能することが意図されていました。^[12]

801 はもともと機能が限定されたシステム向けに設計されたため、大型マシンに見られるような多くの機能が欠けていた。その中でも特に注目すべきは、仮想メモリのハードウェアサポートが欠けていたことである。仮想メモリはコントローラの役割には不要であり、それを必要とする初期の 801 システムではソフトウェアで実装されていた。より広範囲に使用するには、ハードウェアサポートは必須の機能であった。さらに、1980 年代までにコンピュータの世界全体が32 ビットシステムへと移行しており、801 でも同じことを行いたいという要望があった。^[13]

32 ビット形式への移行には、もう 1 つの大きな利点がありました。実際には、2 つのオペランド形式は、一般的な数学コードでは使いにくいことがわかりました。理想的には、両方の入力オペランドがレジスタに残り、後続の演算で再利用できます。2 つのオペランド形式では、2 つの値のうちの 1 つが結果で上書きされ、値の 1 つをメモリから再ロードする必要がある場合がよくありました。32 ビット形式に移行することで、命令語の追加ビットによって追加のレジスタを指定できるようになり、このような演算の出力を別のレジスタに送ることができるようになりました。命令語が大きくなったことで、レジスタの数も 16 から 32 に増えました。これは、801 コードの調査から明らかでした。命令語が 24 ビットから 32 ビットに拡張されたにもかかわらず、この 2 つの変更によりロードと保存が回避されたため、プログラムは対応する 33% 増加しませんでした。^[13]

その他の望ましい追加機能としては、1つのメモリワードに複数の文字を含む「パック」形式でエンコードされた文字列データを操作するための命令や、4ビットの10進数をまたいで計算できる加算器を含む2進化10進数を操作するための追加機能などがある。 ^[13]

801 の新バージョンを 370 のシミュレータとして実行したところ、801 にコンパイルされシミュレータで実行されたコードが、370 のPL/Iコンパイラを使用して 370マシン コードに直接コンパイルされた同じソース コードよりも高速に実行されることがよくあることに、チームは驚きました。 ^[14]実験的な「PL.8」言語を 370 に移植し、それを使用してアプリケーションをコンパイルしたところ、それらのアプリケーションは PL/I バージョンよりも 3 倍も高速に実行されました。これは、生成されたコードがプロセッサ レジスタを使用する方法についてコンパイラが RISC のような決定を下し、可能な限り多くのメモリ アクセスを最適化したためです。これらは 370 でも 801 でも同様にコストがかかりましたが、このコストは通常​​、1 行の CISC コードという単純さによって隠されていました。PL.8 コンパイラは、ロードとセーブを回避することにはるかに積極的であり、その結果、CISC プロセッサでもパフォーマンスが向上しました。^[14]

1980年代初頭、801で学んだ教訓はIBM Advanced Computer Systemsプロジェクトから得た教訓と組み合わされ、「Cheetah」と呼ばれる実験的なプロセッサが誕生した。Cheetahは2ウェイスーパースカラープロセッサで、1985年に「Panther」と呼ばれるプロセッサに進化し、最終的に1986年には「America」と呼ばれる4ウェイスーパースカラー設計に進化した。 ^[15]これは、命令をフェッチしてデコードする命令プロセッサ、命令プロセッサと役割を共有する固定小数点プロセッサ、およびそれを必要とするシステム用の浮動小数点プロセッサを含む3チッププロセッサセットであった。801チームによって設計された最終設計は、1986年にIBMのオースティンオフィスに送られ、そこでIBM RS/6000システムに開発された。25MHzで動作するRS/6000は、当時最速のマシンの1つであった。一般的なテストでは他のRISCマシンの2～3倍の性能を誇り、古いCISCシステムよりも簡単に上回った。^[10]

RS/6000 の後、同社はさまざまな規模で効率的に製造できる 801 コンセプトのバージョンに注目しました。その結果、IBM POWER 命令セット アーキテクチャとPowerPC派生製品が誕生しました。

ジョン・コックは、801 での功績により、数々の賞やメダルを受賞しました。

• 1985年:エッカート・モークリー賞^[16]
• 1987年: AMチューリング賞^[17]
• 1989年:コンピュータパイオニア賞^[18]
• 1991年:国家技術賞^[19]
• 1994年: IEEE ジョン・フォン・ノイマンメダル^[20]
• 1994年:アメリカ国家科学賞^[19]
• 2000年：ベンジャミン・フランクリン・メダル（フランクリン協会）^[21]

マイケル・J・フリンは801を最初のRISCと見なしている。^[22]

• Cocke, John; Markstein , Victoria ( 1990年 1 月)。「IBM における RISC テクノロジの進化」(PDF)。IBM Journal of Research and Development。34 ( 1): 4–11。doi :10.1147/rd.341.0004。
• コック、ジョン ( 1988年 3 月)。 「科学プロセッサのパフォーマンスの探求」。ACMチューリング賞講演。第 31 巻。p. 252。doi : 10.1145/ 1283920.1283945。ISBN 978-1-4503-1049-9。
• Radin, G. (1982) 。「801 ミニコンピュータ」。プログラミング言語とオペレーティング システムのアーキテクチャ サポートに関する第 1 回国際シンポジウムの議事録。ASPLOS -I。pp. 39–47。doi :10.1145 / 800050.801824。ISBN 0-89791-066-4。

• 「コンピュータ アーキテクチャの変更はスループットを向上させる方法であると IBM 研究者が提案」。エレクトロニクス。第 49 巻、第 25 号。1976 年 12 月 23 日。0 ～ 31 ページ。
• McLellan, V. (1979 年 10 月)。「IBM Mini の根本的な変化」。Datamation 誌、第 25 巻、第 11 号、53 ～ 55 ページ。
• Dewar, Robert BK; Smosna, Matthew (1990)。『マイクロプロセッサ: プログラマの視点』McGraw-Hill。pp. 258–264。
• Tabak, Daniel (1987). RISCアーキテクチャ. Research Studies Press. pp. 69–72.

• 801 ミニコンピュータ - 概要
• IBM システム 801 動作原理、バージョン 2
• 801 I/Oサブシステムの定義
• IBM アーカイブ: Wayback Machineの RISC、IBM RS/6000、IBM eServer pSeries の簡単な歴史(2006-05-03 アーカイブ)