Skip to content

Dead End: The Intel iAPX 432

Abstract

The iAPX 432 was supposed to be Intel’s real future: a 32-bit “micromainframe” with object-oriented memory protection and garbage collection built into the silicon, designed from 1975 as the successor to the 8-bit era and meant to be programmed in Ada. It shipped in late 1981 as a set of chips, ran about a quarter as fast as Intel’s own 80286 and five to ten times slower than the Motorola 68000, and was discontinued around 1985–86. Its designers carried the ideas into BiiN, an Intel–Siemens joint venture that spent about $300 million and sold almost nothing, before the processor core lived on as the embedded i960. Meanwhile the 8086, a stopgap Intel had rushed out in 1978 while waiting for the 432, became the x86 architecture that still runs most of the world’s PCs and servers.

Intel 43201 Die
Die of the Intel 43201, the instruction-decoding half of the iAPX 432’s two-chip General Data Processor. Image: John McMaster, CC BY 4.0, via Wikimedia Commons.

The Grand Design

Intel began the project in 1975 under the name 8800, conceived as the company’s leap past the 8080: not another incremental microprocessor but a “micromainframe” that would bring the capabilities of large systems onto chips. In March 1977 the project moved to Portland, Oregon, with 17 engineers under the project manager Bill Lattin; Justin Rattner, later Intel’s chief technology officer, was its lead engineer, and Fred Pollack one of its architects.

The architecture was unusual on almost every axis.

  • No visible registers. It was a stack machine; programmers saw objects and operands, not a register file.
  • Objects and capabilities. Memory was divided into up to 2^24 segments of up to 64 kilobytes, each an object with a type. A program could reach an object only through an access descriptor, an unforgeable reference whose rights the hardware checked on every use. This was capability-based addressing, a protection model academia had explored for years (the Cambridge CAP computer was one example; see Maurice Wilkes and EDSAC), and that high-assurance systems research pursued in software.
  • Garbage collection in hardware. The processor supported a concurrent mark-and-sweep collector, so unused objects could be reclaimed without the programmer freeing them.
  • Bit-aligned instructions. Instructions varied in length from 6 to 321 bits and did not have to start on byte boundaries, to save memory.
  • Ada. The intended programming language was Ada, then being defined for the US Department of Defense and expected to become the dominant language for serious software (see Ada). The operating system, iMAX 432, was written in Ada.

The virtual address space was 2^40 bytes, the physical one 16 megabytes. Multiple processors could share memory transparently, and the hardware dispatched processes among them.

The design was too large for any single chip of the time. The General Data Processor was split across two chips, the 43201 for instruction fetch and decode and the 43202 for execution, with about 97,000 transistors between them; a separate 43203 Interface Processor with about 49,000 transistors handled input and output.

The Placeholder

Intel SBC 432 100
An Intel SBC 432/100 evaluation board with the iAPX 432 chip set. Image: brouhaha, CC BY-SA 2.0, via Wikimedia Commons.

The project ran years late, and the delay produced the twist the 432 is remembered for. Zilog’s Z80, designed by former Intel engineers, was taking Intel’s 8-bit customers, and Intel could not wait for the 432. A separate team produced a quick, conservative 16-bit chip that extended the 8080’s design and could run translated 8080 code. That chip, the 8086, shipped in 1978.

When Motorola’s 68000 began winning designs against the 8086, Intel answered with a sales campaign rather than a new chip. Operation Crush, drawn up in December 1979 and run through 1980, involved more than a thousand employees and an advertising budget of $2 million, far larger than anything Intel had spent before, and it sold the 8086 on Intel’s support, tools and future roadmap rather than on raw specifications. In 1981 IBM chose the 8088, a variant of the 8086, for its personal computer (The IBM PC), and the stopgap became the x86 line. The placeholder was the company’s future, and no one at Intel knew it yet.

The Performance Disaster

The iAPX 432 launched in late 1981 at 4 to 8 MHz, below its 10 MHz design target, with a peak of about two million instructions per second at 8 MHz. Benchmarks published in 1982 put it at roughly a quarter of the speed of the 80286 at the same clock, and five to ten times slower than the Motorola 68000. For a chip set six years in the making and sold as a premium product, the numbers were fatal.

The causes were analyzed in detail. In 1988 Robert Colwell, Edward Gehringer and E. Douglas Jensen published “Performance Effects of Architectural Complexity in the Intel 432” in ACM Transactions on Computer Systems. They found that much of the slowness came from implementation decisions rather than from the object-oriented idea itself:

  • Splitting the processor across two chips limited it to the speed of signals between packages.
  • There were no general data registers and only small caches for the object descriptors that every memory access had to consult, because the transistor budget was consumed by the decoder for the bit-aligned instructions.
  • The early Ada compiler used the most expensive object-oriented instructions for ordinary operations and passed procedure parameters by value-result, so that calls dominated the running time of benchmarks.

With those decisions made differently and somewhat better chip technology, they estimated, the 432 could have been made much faster, but a penalty of a factor of two to three would have remained for its style of object orientation. The paper became a standard reference in the argument between complex instruction sets and RISC, which was at its height in the 1980s.

Intel discontinued the 432 around 1985–86. Andy Grove, running the company’s operations while the project absorbed its research ambitions, admitted in a 2001 interview with Wired that he had been slow to care about microprocessors at all: “I was running an assembly line designed to build memory chips. I saw the microprocessor as a bloody nuisance.”

BiiN

The 432 team did not give up on the ideas. In 1982 Intel and Siemens started a joint research project, first called Gemini, which became the company BiiN. Its goal was a fault-tolerant multiprocessor computer for work that could not be allowed to fail, such as transaction processing and the control of nuclear reactors. Its processor, the 960 XA, kept capability-style protection in the form of tagged memory, and two processors could run in lockstep, checking each other or taking over at once if one failed. All its software, including the operating system BiiN/OS, was written in Ada, one of the largest non-military Ada projects ever undertaken.

BiiN designed two systems, the BiiN 20 with one or two processors and the BiiN 60 with up to eight. The venture spent about $300 million, made no significant sales and was closed in October 1989, folding in April 1990. Inside Intel, the name was said to stand for “Billions Invested In Nothing.”

The i960

Intel i960 PGA
An Intel i960 processor. The BiiN processor core, stripped of its protection features, became one of the most widely used embedded processors of the 1990s. Image: Konstantin Lanzet, CC BY 3.0, via Wikimedia Commons.

The processor survived its system. Intel sold simplified versions of the BiiN core as the i960, a RISC-style embedded processor, beginning with the 80960KA and 80960KB. Without the capability features, it found its way into laser printers, network switches, RAID storage controllers and military equipment, and it was one of Intel’s most popular products until the late 1990s. The protection ideas themselves resurfaced decades later in hardware capability research such as the CHERI project at Cambridge.

Dead End

The 432 failed because every one of its ideas cost silicon and cycles that the technology of 1981 could not supply, and because it asked customers to adopt a new language, a new operating system and a new way of programming at once, with no compatibility with anything they already had. The 8086 asked for none of that, and it won.

Intel repeated the pattern twenty years later, betting on a clean-sheet architecture designed to replace x86 that benchmarks and compatibility then humbled, with Itanium (Dead End: Intel Itanium). Both times, x86, the architecture Intel never planned as its flagship, absorbed the failure and kept the company profitable (Andy Grove and Intel, The Semiconductor Race).

📚 Sources