Intel iAPX 432
出典: フリー百科事典『ウィキペディア（Wikipedia）』
iAPX 432はインテルが設計した初めての32ビットマイクロプロセッサであり、3つの集積回路のセットとして1981年に発表された。 iAPX 432は1980年代に向けた重要な設計と位置づけられていた。 数々の先進的なマルチタスク機能とメモリ管理機能をハードウェアでサポートし、インテルはこのデザインをマイクロメインフレームとも呼んだ。
プロセッサがデータ構造をサポートすることにより、進んだオペレーティングシステムを少ないプログラムコードで実装できる。 つまり、432は多くの仕事をハードウェア内部で行おうとした。 しかし、その設計は当時の他のマイクロプロセッサと比較してあまりにも複雑すぎ、インテルの技術者はその設計を当時の半導体技術を使った効率的な実装に翻訳することができなかった。 結果としてCPUは非常に高価で低速になり、インテルが考えていたx86からiAPX 432へのアーキテクチャの転換は達成されなかった。
iAPXという文字列はintel Advanced Processor architectureの略である。Xはギリシャ文字のChi(カイ、Χ)から来ている。
目次 |
[編集] 歴史
[編集] 開発
1975年、432プロジェクトは8800として始まった。つまり8008と8080に続くCPUとして名づけられていたのである。 デザインは当初から完全な32ビットを想定しており、インテルが1980年代に提供するプロセッサの基盤となる予定だった。 そのため既存の単純なプロセッサとは較べ物にならないほど複雑で強力なものになると予想された。しかし、その設計では当時の半導体プロセス技術のレベルを超えているため、いくつかのチップに分割して実装する必要があった。
デザインの中核はふたつのチップから成るゼネラルデータプロセッサ(GDP)であり、これがメインプロセッサである。 GDPは、命令フェッチとデコードを担当するチップ(43201)と実行するチップ(43202)に分かれている。 多くのシステムではこれに43203インターフェイスプロセッサ(IP)が追加され入出力のチャネル・コントローラとして動作する。 3つのチップを合わせたゲート数は250,000であり、当時最も大きな回路設計のひとつと言える。当時のモトローラのMC68000は68,000ゲートだった。
1983年、インテルは追加のチップを2種類リリースした。43204 バスインターフェイスユニット(BIU)と43205 メモリコントロールユニット(MCU)である。 これらのチップを使うと63ノードまでのマルチプロセッサシステムを追加の回路をほとんど使わずに構成することができた。
[編集] プロジェクトの失敗
いくつかの設計上の特徴により、iAPX 432は予定よりもさらに性能が低下することになった。 GDPをふたつのチップで実装したため、マザーボードの電気的な配線のスピードに支配されることになったが、これは主要な性能低下要因ではない。 キャッシュとレジスタの不足はより深刻な問題であった。 命令セットも悪影響を与えた。任意の長さで整列されていない命令なので一般的なワード境界に揃えられた固定長命令に較べるとデコードが複雑で遅くなってしまった。 加えてBIUはフォールトトレラントシステムを考慮しているため、バスのオーバーヘッドが極めて大きく、約40%の時間がウェイト状態となってしまった。
後の研究では、もっとも大きな問題はコンパイラにあったと指摘されている。 というのも高性能の単純な命令ではなく、コストの高い高機能命令を常に使うようなコードを生成していたからである。 たとえばiAPX 432は非常に時間のかかるモジュール間プロシージャコール命令を持っていたが、コンパイラはすべてのサブルーチンコールでそれを使っていて、もっと高速な分岐＋リンク命令は無視されていた。 もうひとつの時間のかかる命令としてenter_environmentがある。これはメモリプロテクションを設定する命令である。 コンパイラはプログラム中の変数ひとつひとつにこの命令を生成したが、ほとんどの場合environmentを設定する必要はなかった。 さらに困ったことに、プロシージャコールに際して引数をポインタではなく値で渡していたため、多くの場合メモリコピーが大量に必要となった。
[編集] 影響と類似の設計
432の失敗によりマイクロプロセッサの多くの設計者はチップでオブジェクトをサポートしたことがデザインを複雑にし性能を低下させたと考えた。 432はしばしばRISCの正反対の例として取り上げられる。 しかし、上述の性能低下の原因を見てもわかるとおりオブジェクト指向サポートが問題だったのではなく、実装がまずければどんな設計であっても起きうる問題であることを示している。 iAPX 432以降、同様の設計が試みられたことはないが、INMOS社のトランスピュータがチップでサポートした機能は似ていて、かつ非常に高速に動作した。
インテルは多大な時間と金を消費し、ブランドイメージの低下も招いてしまった。 しかし、市場での失敗の後でこれをなんとかしようとするチームがいた。 新しいアーキテクトのGlenfold Myersはインテルとシーメンスの共同開発プロジェクト(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倍になった。
[編集] マルチタスクとプロセス間通信
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が全メモリ空間に自由にアクセスすることもできる。 物理モードはシステム立ち上げ時とデバッガ用に用意されたものである。
| インテルのプロセッサ一覧 |
|---|
|
4004 | 4040 | 8008 | 8080 | 8085 | 8086 | 8088 | iAPX 432 | 80186 | 80188 | 80286 | 80386 | i486 | i860 | i960 | Pentium | Pentium Pro | Pentium II | Celeron | Pentium III | XScale | Pentium 4 | Pentium M | Pentium D | Pentium E | Pentium Extreme Edition | Xeon | Core | Core 2 | Itanium | Itanium 2 (x86プロセッサ以外は斜体です) |
