Intel iAPX 432
↑ 一般に遅延やパワーなどの都合から、コンピュータのプロセッサは、できるなら1個のチップにまとめたい。
↑ 後述する「マイクロメインフレーム」という語が示唆するように、大型汎用機(メインフレーム)では1970年代には既に当然の機能である
↑ Intel iAPX-432 Micromainframe
↑ 川村 清『プログラミング言語の世界』共同印刷株式会社、1985年10月24日、36-37頁。ISBN 4-87966-063-9。
↑ A.Patterson,L.Hennessy 1990, p. 125.
↑ 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
システム定義セグメントはシステム定義データのデータあるいはADを決まったオフセットに格納しているが、OSやユーザソフトウェアはそれを拡張してデータを追加することができる。各システムオブジェクトはマイクロコードがチェックするタイプフィールドを持っていて、たとえばCarrierオブジェクトが必要なところでPortオブジェクトを使うことはできない。ユーザプログラムは新たなオブジェクト型を定義することができ、それについてもタイプ制御オブジェクト(TCO)を使うことでハードウェアによるタイプチェックの恩恵を受けることができる。
iAPX 432のリリース1ではシステム定義オブジェクトは、ひとつのアクセスセグメントと(必要ならば)ひとつのデータセグメントを持っていて、そのデータセグメントはアクセスセグメント内の固定のオフセットにあるADで示されていた。
リリース3では、性能を向上させるためアクセスセグメントとデータセグメントはひとつのセグメントにまとめられて最大128Kバイトになり、その中をふたつに分けて使われた。これによりオブジェクトテーブルの参照が劇的に減った。また、仮想空間の最大サイズが2倍になった。
iAPX 432のマイクロコードはマルチタスク機能を実装していて、メモリ上のオブジェクトがプロセッサ、プロセス、通信ポート、ディスパッチポートを表現するようになっていた。各プロセッサはディスパッチポートと対応しており、アイドル状態になってプロセスをディスパッチする必要が出てくると、そのディスパッチポートにアクセスする。プロセスがブロックしたり割り当てられた実行時間を使い切るとプロセッサはそのプロセスを自身のディスパッチポートのキューにつなぎ、別の実行可能なプロセスをそのディスパッチポートから取り出す。
プロセス間通信は通信ポートでサポートされる。通信ポートは基本的にはFIFOであり、プロセスはそこにメッセージをキューイングしたり、メッセージの到着を待ったりする。プログラムは送信、受信、条件付送信、条件付受信、代理送信、代理受信といった命令を使い、通信ポートを介して他のプロセスとメッセージを送受信する。通信ポートにメッセージがない場合、通常の受信命令はプロセスをブロックし、メッセージが到着するのを待たせる。同様に通常の送信命令は、通信ポートがメッセージでいっぱいの場合にプロセスをブロックする。条件付送信と条件付受信はブロックせず、送受信が成功したかどうかを示すブーリアン型の値を返す。代理受信と代理送信はCarrierオブジェクトを提供し、それがプロセスの代わりにブロックする。
iAPX 432アーキテクチャのエレガントな点は、ディスパッチポートが実際には単なる通信ポートであって、メッセージとしてプロセスオブジェクトを使っている点である。そのためプロセスのディスパッチとプロセス間通信は処理を共通化でき、それを実現する実装を単純化できる。