Intel iAPX 432
Intel iAPX 432はインテルが設計した32ビットマイクロプロセッサである。極めて複雑な設計のため、性能が非常に悪く商業的には惨敗した。
目次
概要
インテルにとって初めての32ビットマイクロプロセッサだが、実際は3つの集積回路がセットとなり1つのCPUとして機能する構成となっていた。1981年に発表された。 iAPX 432は1980年代に向けた重要な設計と位置づけられていた。数々の先進的なマルチタスク機能とメモリ管理機能をハードウェアでサポートし、インテルはこのデザインをマイクロメインフレームと宣伝し、組み込み用チップを起源とする従来のx86アーキテクチャを置き換える事を目論んでいた。
当初のクロック周波数は最高10MHzを予定していたが、実際に完成した際のクロック周波数は 4MHz、5MHz、7MHz、8MHz だった[1]。
プロセッサがデータ構造をサポートすることにより、進んだオペレーティングシステムを少ないプログラムコードで実装できる。 つまり、432は多くの仕事をハードウェア内部で行おうとした。オブジェクト指向とガベージコレクションもチップが直接サポートし、ハードウェア（特にマイクロコード部分）がさらに複雑化した。
しかし、壮大な構想に基づいて設計されたiAPX 432は、当時のマイクロプロセッサとしてはあまりにも複雑すぎ、インテルの技術者はその設計をプロセッサとして効率的に実装することができなかった。この結果、当初はシングルチップCPUとして計画されたはずのこのプロセッサは、実際には複雑な機能を3つの半導体チップに分けて実装する事となり、より煩雑で取り回しが悪く、また性能低下の原因ともなった。さらに、iAPX 432向けに開発された初期のAdaコンパイラが最適化できていなかったことも失敗の大きな要因である。1982年の典型的なベンチマークテストによれば、同一クロック周波数の80286の4分の1程度の性能だった。にも関わらず80286チップより価格は大幅に高かった。このような性能および価格の問題により、インテルが考えていたx86からiAPX 432へのアーキテクチャの転換は達成されなかった。
iAPXという文字列はintel Advanced Processor architectureの略である。Xはギリシャ文字のChi（カイ、Χ）から来ている。
歴史
開発
1975年、432プロジェクトは8800として始まった。つまり8008と8080に続くCPUとして名づけられていた。デザインは当初から完全な32ビットを想定しており、インテルが1980年代に提供するプロセッサの基盤となる予定だった。そのため既存の単純なプロセッサとは較べ物にならないほど複雑で強力なものになると予想された。しかし、その設計では当時の半導体プロセス技術のレベルを超えているため、いくつかのチップに分割して実装する必要があった。
デザインの中核はふたつのチップから成るゼネラルデータプロセッサ (GDP) であり、これがメインプロセッサである。GDPは、命令フェッチとデコードを担当するチップ (43201) と実行するチップ (43202) に分かれている。多くのシステムではこれに43203インタフェースプロセッサ (IP) が追加され入出力のチャネル・コントローラとして動作する。
当時としては最大規模の集積回路設計である。2チップ構成のGDPは合計で約97,000個のトランジスタを集積しており、1チップのIPは約49,000個のトランジスタを集積している。1979年に登場したモトローラのMC68000は、約40,000個のトランジスタを集積していた。
1983年、インテルは追加のチップを2種類リリースした。43204 バスインタフェースユニット (BIU) と43205 メモリコントロールユニット (MCU) である。 これらのチップを使うと63ノードまでのマルチプロセッサシステムを追加の回路をほとんど使わずに構成することができた。
プロジェクトの失敗
いくつかの設計上の特徴により、iAPX 432は予定よりもさらに性能が低下することになった。GDPをふたつのチップで実装したため、マザーボードの電気的な配線のスピードの制約をうけることになったが、これは主要な性能低下要因ではない。キャッシュとレジスタの不足はより深刻な問題であった。命令セットも悪影響を与えた。任意の長さで整列されていない命令なので一般的なワード境界に揃えられた固定長命令に較べるとデコードが複雑で遅くなってしまった。加えてBIUはフォールトトレラントシステムを考慮しているため、バスのオーバーヘッドが極めて大きく、約40%の時間がウェイト状態となってしまった。
後の研究では、もっとも大きな問題はAdaコンパイラにあったと指摘されている。すなわち、コストの低い単純な命令ではなく、コストの高い高機能命令を常に使うようなコードを生成していたからである。たとえばiAPX 432は非常に時間のかかるモジュール間プロシージャコール命令を持っていたが、コンパイラはすべてのサブルーチンコールにそれを用いて、もっと高速な分岐＋リンク命令を用いなかった。もうひとつの時間のかかる命令としてenter_environmentがある。これはメモリプロテクションを設定する命令である。コンパイラはプログラム中の変数ひとつひとつにこの命令を生成したが、ほとんどの場合environmentを設定する必要はなかった。さらに困ったことに、プロシージャコールに際して引数をポインタではなく値で渡していたため、多くの場合メモリコピーが大量に必要となった。
影響と類似の設計
432の失敗によりマイクロプロセッサの多くの設計者はチップでオブジェクトをサポートしたことがデザインを複雑にし性能を低下させたと考えた。432はしばしばRISCの正反対の例として取り上げられる。しかし、上述の性能低下の原因を見てもわかるとおりオブジェクト指向サポートが問題だったのではなく、実装がまずければどんな設計であっても起きうる問題であることを示している。iAPX 432以降、同様の設計が試みられたことはないが、INMOS社のトランスピュータがチップでサポートした機能は似ていて、かつ非常に高速に動作した。
インテルは多大な時間と金を消費し、ブランドイメージの低下も招いてしまった。しかし、市場での失敗の後でこれをなんとかしようとするチームがいた。新しいアーキテクトのグレンフォード・メイヤーズはインテルとシーメンスの共同開発プロジェクト (BiiN) で使われるまったく新しいアーキテクチャのプロセッサの設計と実装を指揮し、i960シリーズを生み出した。i960のサブセット版は組み込み用プロセッサ市場で人気を博した。ただし、ハイエンドの960MCとタグ付メモリの960MXは軍用にのみ使われ、432よりも出荷数は少なかった。
アーキテクチャ
オブジェクト指向
iAPX 432はハードウェアとマイクロコードでオブジェクト指向プログラミングをサポートしている。システムはセグメント方式のメモリを採用し最大224個の64Kバイトセグメントを扱うため、仮想空間の合計サイズは240バイトである。物理アドレス空間は224バイト(16Mバイト)である。
プログラムはデータや命令をアドレスで参照することができない。その代わりにセグメントとセグメント内オフセットで指定する。セグメントはアクセスデスクリプタ (AD) で参照される。ADにはシステムオブジェクトテーブルへのインデックスとそのセグメントへのアクセス権が格納されている。セグメントにはアクセスデスクリプタを格納するアクセスセグメントとデータを格納するデータセグメントがある。ハードウェアとマイクロコードはこれらを厳密に区別するので、ソフトウェアはデータをアクセスデスクリプタ扱いしたり、その逆をしたりできない。
システム定義オブジェクトはひとつのアクセスセグメントだけか、ひとつのアクセスセグメントとひとつのデータセグメントから成る。システム定義セグメントはシステム定義データのデータあるいはADを決まったオフセットに格納しているが、OSやユーザソフトウェアはそれを拡張してデータを追加することができる。各システムオブジェクトはマイクロコードがチェックするタイプフィールドを持っていて、たとえばCarrierオブジェクトが必要なところでPortオブジェクトを使うことはできない。ユーザプログラムは新たなオブジェクト型を定義することができ、それについてもタイプ制御オブジェクト(TCO)を使うことでハードウェアによるタイプチェックの恩恵を受けることができる。
iAPX 432のリリース1ではシステム定義オブジェクトは、ひとつのアクセスセグメントと(必要ならば)ひとつのデータセグメントを持っていて、そのデータセグメントはアクセスセグメント内の固定のオフセットにあるADで示されていた。
リリース3では、性能を向上させるためアクセスセグメントとデータセグメントはひとつのセグメントにまとめられて最大128Kバイトになり、その中をふたつに分けて使われた。これによりオブジェクトテーブルの参照が劇的に減った。また、仮想空間の最大サイズが2倍になった。
ガベージコレクション
432上で動作するソフトウェアは、不要となったオブジェクトを明示的に解放する必要がなく、実際解放のための手段も提供されていない。その代わりにエドガー・ダイクストラの並列マーク・アンド・スイープ式ガベージコレクションアルゴリズム[2]のマーク部分をマイクロコードで実装している。システムオブジェクトテーブルの各エントリにはマーク用フラグが用意されていて、スイープ側が使用する情報を提供できる。
iMAX-432 というOSにはスイープ側がソフトウェアで実装されていた。
マルチタスクとプロセス間通信
iAPX 432のマイクロコードはマルチタスク機能を実装していて、メモリ上のオブジェクトがプロセッサ、プロセス、通信ポート、ディスパッチポートを表現するようになっていた。各プロセッサはディスパッチポートと対応しており、アイドル状態になってプロセスをディスパッチする必要が出てくると、そのディスパッチポートにアクセスする。プロセスがブロックしたり割り当てられた実行時間を使い切るとプロセッサはそのプロセスを自身のディスパッチポートのキューにつなぎ、別の実行可能なプロセスをそのディスパッチポートから取り出す。
プロセス間通信は通信ポートでサポートされる。通信ポートは基本的にはFIFOであり、プロセスはそこにメッセージをキューイングしたり、メッセージの到着を待ったりする。プログラムは送信、受信、条件付送信、条件付受信、代理送信、代理受信といった命令を使い、通信ポートを介して他のプロセスとメッセージを送受信する。通信ポートにメッセージがない場合、通常の受信命令はプロセスをブロックし、メッセージが到着するのを待たせる。同様に通常の送信命令は、通信ポートがメッセージでいっぱいの場合にプロセスをブロックする。条件付送信と条件付受信はブロックせず、送受信が成功したかどうかを示すブーリアン型の値を返す。代理受信と代理送信はCarrierオブジェクトを提供し、それがプロセスの代わりにブロックする。
iAPX 432アーキテクチャのエレガントな点は、ディスパッチポートが実際には単なる通信ポートであって、メッセージとしてプロセスオブジェクトを使っている点である。そのためプロセスのディスパッチとプロセス間通信は処理を共通化でき、それを実現する実装を単純化できる。
マルチプロセッサ対応
iAPX 432はハードウェアでマルチプロセッサをサポートしており、最大64個のプロセッサを扱える(GDPとIPを合わせて64個)。通常、GDPは共通のディスパッチポートを使って負荷分散を図るが、ディスパッチポートを複数用意することでシステムをソフト的に分割することもできる。適切に設計されたハードウェアを使えば、システム動作中でもプロセッサをシステムから取り除いたり追加したりできる。
フォールトトレラント性
当初からiAPX 432はフォールトトレラント性をサポートしている。すべての432チップは二重化することができ、一方をマスターとして正常に動作させ、もう一方をチェッカーとして同時に同じ処理を行って結果をマスターと比較してチェックすることができる、これをFunctional Redundancy Checking (FRC) と言う 。
FRCにより障害を検出できるが、完全なフォールトトレラントにはリカバリ機構が必要である。FRCモジュールをさらに二重に持たせることで自動的な障害リカバリ機能をサポートしている。これをQuad Modular Redundancy (QMR) と言う。QMR構成では、一方のFRCモジュールがプライマリと呼ばれ、もう一方がシャドウと呼ばれる。二つのモジュールは同期して処理を行うが、その役割は定期的に入れ替えて潜在的な障害を発見するように努める。シャドウモジュールはバスをドライブしない。障害がどちらかのFRCモジュールで発見されると、そのモジュールは停止させられて、その間はもう一方のモジュールが処理を続行する。ソフトウェアに障害が通知され、処理を続行するか、スペアのモジュールを使用するか、障害の起きたモジュールを切り離すかを選択できる。
入出力
43203インタフェースプロセッサ (IP) を使って、より一般的なマイクロプロセッサをiAPX 432システムにアタッチドプロセッサ (AP) として接続することができる。APはインテリジェントな入出力コントローラとして動作する。IPはメモリマップドウィンドウを通してAPがメモリ上のiAPX 432のオブジェクトにアクセスできるようにする。ただし、アクセス権はこのときも有効に働く。
IPは5個のメモリウィンドウを提供する。4つは入出力のためにオブジェクトをマップするのに使われ、5番目はAPからの要求（たとえば他のウィンドウのマップを変えるなど）を伝えるための制御ウィンドウとして使う。
IPは特別な物理モードも用意していて、APが全メモリ空間に自由にアクセスすることもできる。物理モードはシステム立ち上げ時とデバッガ用に用意されたものである。
脚注・出典
参考文献
- Levy, Henry M., Capability-Based Computer Systems, 1984, Digital Press. Chapter 9 [1]
- Myers, Glenford J, Advances in Computer Architecture 2nd edition, (1982), J Wiley, ISBN 0-471-07878-6. Section VI An Object-Oriented Microprocessor (pp 335–417)
外部リンク
- Microprocessors: 1976 to 1981 Computer History Museum
- Intel iAPX432 Micromainframe
- Intel iAPX 432 (Computer Science project paper) – By David King, Liang Zhou, Jon Bryson, David Dickson
- ↑ Intel iAPX-432 Micromainframe
- ↑ On-the-fly garbage collection: an exercise in cooperation by Edsger W. Dijkstra and Leslie Lamport and A.J.Martin and C.S.Scholten and E.F.M.Steffens
