この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方）
出典検索?: "Intel iAPX 432" ? ニュース ・ 書籍 ・ スカラー ・ CiNii ・ J-STAGE ・ NDL ・ dlib.jp ・ ジャパンサーチ ・ TWL（2023年12月）

Intel iAPX 432生産時期1981年から
生産者インテル
CPU周波数5 MHz から 8 MHz
テンプレートを表示

Intel iAPX 432はインテルが設計した32ビットマイクロプロセッサである。極めて複雑な設計のため、性能が非常に悪く商業的には惨敗した。
概要

インテルにとって初めての32ビットマイクロプロセッサである。開発時点での集積回路技術の限界から（発表時期で比較して、386よりも4年の先行）、3個のチップのセットで1つのCPUとして機能するプロセッサになる、という構成とせざるをえなかった[1]。1981年の発表。

iAPX 432は1980年代に向けた重要な設計と位置づけられていた。数々の（当時のマイクロプロセッサとしては[2]）先進的なマルチタスク機能とメモリ管理機能をハードウェアでサポートし、インテルはこのデザインをマイクロメインフレームと宣伝し、組み込み用チップを起源とする従来のx86アーキテクチャを置き換える事を目論んでいた。

当初のクロック周波数は最高10MHzを予定していたが、実際に完成した際のクロック周波数は 4MHz、5MHz、7MHz、8MHz だった[3]。

プロセッサがデータ構造をサポートすることにより、進んだオペレーティングシステムを少ないプログラムコードで実装できる。つまり、432は多くの仕事をハードウェア内部で行おうとした。オブジェクト指向とガベージコレクションもチップが直接サポートし、ハードウェア（特にマイクロコード部分）がさらに複雑化した。

しかし、壮大な構想に基づいて設計されたiAPX 432は、当時のマイクロプロセッサとしてはあまりにも複雑すぎ、インテルの技術者はその設計をプロセッサとして効率的に実装することができなかった。この結果、当初はシングルチップCPUとして計画されたはずのこのプロセッサは、実際には複雑な機能を3つの半導体チップに分けて実装する事となり[4]、より煩雑で取り回しが悪く、また性能低下の原因ともなった。さらに、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は非常に時間のかかるモジュール間プロシージャコール命令を持っていた[5]が、コンパイラはすべてのサブルーチンコールにそれを用いて、もっと高速な分岐＋リンク命令を用いなかった。もうひとつの時間のかかる命令として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上で動作するソフトウェアは、不要となったオブジェクトを明示的に解放する必要がなく、実際解放のための手段も提供されていない。その代わりにエドガー・ダイクストラの並列マーク・アンド・スイープ式ガベージコレクションアルゴリズム[6]のマーク部分をマイクロコードで実装している。