Intel iAPX 432

Intel iAPX 432：先進的過ぎたマイクロプロセッサ

Intel iAPX 432は、インテルが開発した32ビットマイクロプロセッサで、同社初の32ビットプロセッサでした。1981年に発表されましたが、その複雑な設計が仇となり、商業的には失敗に終わりました。しかし、その先進的な思想は後のプロセッサ設計に影響を与え、歴史的な意義のあるプロセッサとして知られています。

概要

iAPX 432は、当時としては画期的なマルチタスクやメモリ管理機能をハードウェアでサポートしていました。インテルはこれを「マイクロメインフレーム」と位置づけ、x86アーキテクチャを置き換えることを目指していました。しかし、開発当時の集積回路技術の制約から、3つのチップセットを使用する構成となり、性能面で大きな課題を抱えることになりました。

当初、最大10MHzのクロック周波数が予定されていましたが、実際には4MHzから8MHzのクロック速度で完成しました。このプロセッサはデータ構造をハードウェアでサポートし、オペレーティングシステムの実装に必要なソースコードの量を削減することが可能でした。オブジェクト指向やガベージコレクションも直接ハードウェアでサポートしていましたが、これによりチップのマイクロコードが複雑化しました。

しかし、iAPX 432の設計はあまりにも複雑で、インテルの技術者は効率的な実装ができず、シングルチップで実現する計画は頓挫しました。結果的に3つのチップに分割された構造は取り回しが悪く、性能低下の原因となりました。また、iAPX 432向けの初期Adaコンパイラが最適化されていなかったことも失敗の要因となりました。1982年のベンチマークテストでは、同クロック周波数の80286の約4分の1の性能しか発揮できず、価格は80286よりも高額でした。

歴史

開発

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命令はメモリプロテクションを設定するものでしたが、コンパイラはプログラム内の変数に対してもこの命令を生成し、実際には多くの場合、環境の設定が不要でした。このほか、プロシージャコール時に引数をポインタではなく値で渡すため、多くの場合メモリコピーが大量に発生しました。

影響と類似の設計

432の失敗により、多くのマイクロプロセッサ設計者は、チップ上でオブジェクトをサポートしたことが設計を複雑にし、性能を低下させたと考えるようになりました。432はしばしばRISCの対極にある例として取り上げられます。しかし、前述のように性能低下の要因はオブジェクト指向サポートそのものではなく、実装が不十分であればどのような設計でも同じ問題が生じることを示しています。iAPX 432以降、同様の設計は試みられていませんが、INMOS社のトランスピュータは似た機能をチップ上でサポートし、非常に高速に動作しました。

インテルはこのプロジェクトで多大な時間と資金を費やし、ブランドイメージの低下も招きました。しかし、プロジェクトの失敗後も、これを挽回しようとするチームがありました。新しいアーキテクト、グレンフォード・メイヤーズが指揮を執り、インテルとシーメンスの共同開発プロジェクト (BiiN) に向けた全く新しいアーキテクチャのプロセッサが設計されました。それがi960シリーズです。i960の一部モデルは、組み込みシステム向けプロセッサとして高い人気を誇りましたが、ハイエンドの960MCとタグ付きメモリの960MXは主に軍用にのみ使用され、432よりも少ない出荷数にとどまりました。

アーキテクチャ

オブジェクト指向

iAPX 432はハードウェアとマイクロコードでオブジェクト指向プログラミングをサポートしていました。システムはセグメント方式のメモリを採用し、最大2²⁴個の64Kバイトセグメントを扱うため、仮想空間の合計サイズは2⁴⁰バイトになります。物理アドレス空間は2²⁴バイト（16Mバイト）でした。

プログラムはデータや命令をアドレスで参照することができません。その代わりにセグメントとセグメント内オフセットで指定します。セグメントはアクセスデスクリプタ (AD) で参照されます。ADにはシステムオブジェクトテーブルへのインデックスとそのセグメントへのアクセス権が格納されています。セグメントにはアクセスデスクリプタを格納するアクセスセグメントとデータを格納するデータセグメントがあります。ハードウェアとマイクロコードはこれらを厳密に区別するので、ソフトウェアはデータをアクセスデスクリプタ扱いしたり、その逆をしたりできません。

システム定義オブジェクトはひとつのアクセスセグメントだけか、ひとつのアクセスセグメントとひとつのデータセグメントから成ります。システム定義セグメントはシステム定義データのデータあるいはADを決まったオフセットに格納していますが、OSやユーザソフトウェアはそれを拡張してデータを追加することができます。各システムオブジェクトはマイクロコードがチェックするタイプフィールドを持っていて、たとえばCarrierオブジェクトが必要なところでPortオブジェクトを使うことはできません。ユーザプログラムは新たなオブジェクト型を定義することができ、それについてもタイプ制御オブジェクト (TCO) を使うことでハードウェアによるタイプチェックの恩恵を受けることができます。

iAPX 432のリリース1ではシステム定義オブジェクトは、ひとつのアクセスセグメントと（必要ならば）ひとつのデータセグメントを持っていて、そのデータセグメントはアクセスセグメント内の固定のオフセットにあるADで示されていました。

リリース3では、性能を向上させるためアクセスセグメントとデータセグメントはひとつのセグメントにまとめられて最大128Kバイトになり、その中をふたつに分けて使われました。これによりオブジェクトテーブルの参照が劇的に減りました。また、仮想空間の最大サイズが2倍になりました。

ガベージコレクション

432上で動作するソフトウェアは、不要となったオブジェクトを明示的に解放する必要がなく、実際解放のための手段も提供されていません。その代わりにエドガー・ダイクストラの並列マーク・アンド・スイープ式ガベージコレクションアルゴリズムのマーク部分をマイクロコードで実装しています。システムオブジェクトテーブルの各エントリにはマーク用フラグが用意されていて、スイープ側が使用する情報を提供できます。

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)
A.Patterson, David; L.Hennessy, John (1990). Computer Archtecture A Quantitative Approach. Morgan Kaufmann Publishers. ISBN 1-55860-069-8

外部リンク

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

もう一度検索