Intel iAPX 432: Object Descriptors, the GDP, and an I/O Processor
Read Intel's iAPX 432 manuals as an object-based architecture, from rights-bearing descriptors to its split GDP and separate Interface Processor.
The Intel iAPX 432 is easiest to misunderstand when it is reduced to a slogan such as “an object-oriented processor.” Intel’s own manuals describe something more concrete: a protected object model, processor-recognized descriptors, a two-device General Data Processor (GDP), and a separate Interface Processor (IP) for peripheral subsystems. The architecture tried to make program modules, data, process state, and interprocessor communication part of one system-level contract.
The primary sources also need to be read by release. Intel’s 1981 43201/43202 data sheet describes the original GDP packages and its instruction pipeline. The February 1984 GDP architecture reference manual describes Release 3.2 and explicitly distinguishes architecture from implementation. The differences matter: an iAPX 432 reference is not one unchanging design snapshot.
An object was a protected reference, not just a record
In the GDP manual, objects hold the data and program structures used by the system. An object can contain a data part and an access part. The data part carries ordinary values; the access part carries access descriptors (ADs) that reference other objects. An AD combines an object identifier with rights, so a procedure accesses an object through an authorized descriptor rather than by constructing an arbitrary physical pointer.
That distinction lets the processor check more than address arithmetic. The architecture describes bounds checks for object references and rights checks for operations such as reading or writing. It also defines object types and system objects for contexts, domains, processes, ports, processors, and object tables. A context represents an execution environment, while a domain organizes program modules and the objects they may use. Software-defined object types could be managed through the architecture’s type-control mechanisms; the hardware enforced the access rules that the manager established.
This is why “capability-based” is a useful description, provided it is not taken to mean that the operating system disappeared. The descriptors provide controlled authority to refer to objects. The processor enforces the descriptor and type rules, while system software still creates objects, arranges processes, defines module policy, and handles faults. Intel’s manual lists operating systems and modular programming languages among the architectural goals, not as features that appear automatically when the chip is installed.
The GDP was a two-device pipeline
The February 1981 Intel data sheet identifies the 43201 and 43202 as companion VLSI devices forming the GDP. The 43201 contains the instruction decoder and microinstruction sequencer; the 43202 is the execution unit. The manual describes a three-stage microprogram-controlled pipeline, with the first two stages on the 43201. Its instruction stream could use variable-length fields, and the decoder requested instruction words as required.
This packaging story is distinct from the higher-level object model. The 43201/02 pair is the GDP, not two independent application processors. Their division exposed how much work the design assigned to decoding, sequencing, and execution. The 1981 data sheet presents that organization alongside high-level-language-directed instructions, protected capability addressing, interprocess communication, and multiprocessing support. Those were engineering objectives stated by Intel, not independent measurements of application speed or programmer productivity.
The architecture also defined the 43203 Interface Processor. An IP worked with an attached processor and a peripheral subsystem. Its window mechanism mapped selected peripheral-subsystem accesses into the 432 system’s object space, and its function-request mechanism let the attached side ask the IP to perform operations using the system’s object and protection rules. The interface manual describes interrupts and message-based coordination between these parts. The IP therefore was not merely another name for the GDP’s execution unit or a generic memory-mapped I/O controller.
What the release history changes
Intel’s GDP manual records successive component releases, from Release 1.0 through Release 3.2, and says the later releases modified both architecture and implementation. The Release 3.2 manual separates the architected instruction set, recognized data structures, and fault behavior from details such as chip count, clock speed, signals, and operator execution time. That distinction is valuable in historical reading: a software-visible guarantee belongs to the architecture, while a board-level or timing claim must be tied to the particular component release and system.
It also cautions against importing a simplistic success-or-failure narrative into every technical detail. The manuals establish what Intel designed the system to do and how its interfaces were specified. They do not, by themselves, quantify the performance of a particular application or prove that object checks were free. It is reasonable to infer that descriptor lookup, access validation, and a rich object system moved complexity into hardware, microcode, compilers, and operating-system software. A numerical speed comparison, however, needs measured workloads and a stated release and configuration.
The iAPX 432’s historical interest is therefore broader than an unusual instruction set. It shows Intel exploring a system where authority, data structures, process contexts, and I/O coordination were architected together. Its manuals let us inspect both the ambition and the engineering boundaries: objects and rights were explicit processor concepts, but the software still had to build and govern the system that used them.
Related:
- Intel 8086: Segmented Memory, Prefetching, and the Start of x86
- Intel 8087: ESC Coordination, Numeric Execution, and the Coprocessor Model
Sources: