|
Intel iAPX 432
Intel iAPX 432はインテルが設計した32ビットマイクロプロセッサで、極めて複雑な設計のため、性能が非常に低く、商業的には失敗した。 概要インテルにとって初めての32ビットマイクロプロセッサである。開発当時の集積回路技術の制約から、386よりも4年先行していたが、1つのCPUとして機能させるためには3つのチップセットを使用する構成にせざるを得なかった[1]。このプロセッサは1981年に発表された。 iAPX 432は1980年代に向けた重要な設計として位置づけられており、当時のマイクロプロセッサとしては画期的なマルチタスクやメモリ管理機能をハードウェアでサポートしていた。インテルはこのデザインをマイクロメインフレームと宣伝し、x86アーキテクチャを置き換えることを目指していた。 当初、クロック周波数は最大10MHzを予定していたが、実際には4MHz、5MHz、7MHz、8MHzのクロック速度で完成した[2]。 このプロセッサはデータ構造をハードウェアでサポートし、オペレーティングシステムの実装に必要なソースコードの量を削減することが可能だった。オブジェクト指向やガベージコレクションも直接ハードウェアでサポートし、チップのマイクロコードが複雑化していた。 しかし、iAPX 432の設計はあまりにも複雑で、インテルの技術者は効率的な実装ができず、シングルチップで実現する計画は頓挫し、結果的に3つのチップに分割された[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は非常に時間のかかるモジュール間プロシージャコール命令を持っていた[4]が、コンパイラはすべてのサブルーチンコールにそれを使用し、より高速な分岐とリンク命令を使わなかった。また、enter_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上で動作するソフトウェアは、不要となったオブジェクトを明示的に解放する必要がなく、実際解放のための手段も提供されていない。その代わりにエドガー・ダイクストラの並列マーク・アンド・スイープ式ガベージコレクションアルゴリズム[5]のマーク部分をマイクロコードで実装している。システムオブジェクトテーブルの各エントリにはマーク用フラグが用意されていて、スイープ側が使用する情報を提供できる。 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が全メモリ空間に自由にアクセスすることもできる。物理モードはシステム立ち上げ時とデバッガ用に用意されたものである。 脚注・出典
参考文献
外部リンク
|
