In 1975 Intel started a project called the 8800. It was not a follow-on to the 8080. It was supposed to obsolete the entire idea of a microprocessor. Six years and hundreds of millions of dollars later it shipped as the iAPX 432, and Intel spent the next five years quietly walking away from every idea in it. In 2026, ARM, Google, and the UK Ministry of Defence are shipping silicon that reinvents those same ideas one at a time.

The 432 was a capability-based, object-oriented processor. Every memory reference went through a hardware-checked capability descriptor — a 128-bit token that named an object, its type, and the operations permitted on it. There were no raw pointers. The CPU enforced type safety, bounds, and access rights on every load. Garbage collection was a hardware primitive. Interprocess communication was a single instruction. Multiprocessor cache coherency was in the ISA. The intended systems language was Ada, which the Department of Defense had just mandated.

The chip set was staggering for 1981: the 43201 instruction decoder and 43202 execution unit formed the General Data Processor, joined by the 43203 Interface Processor for I/O. Roughly 225,000 transistors across two dies in 5-micron NMOS — bigger than a 68000, on a process that could barely hold them. Chief architect Justin Rattner (later Intel CTO) had built a processor that read a program's semantics before it read its bytes.

Then engineers ran benchmarks. The 432 was 5 to 10 times slower than an 8086 running at the same clock. Every instruction paid capability-lookup tax. The compiler couldn't hoist checks the hardware insisted on redoing. Ada was immature and generated bloated code. The two-chip GDP couldn't be pipelined the way Motorola pipelined the 68020. A 1982 New York University study famously showed the 432 losing to a VAX-11/780 by margins so large that Intel's own marketing stopped citing performance.

Meanwhile the IBM PC shipped with an 8088. The 80286 arrived in 1982, the 80386 in 1985. Every dollar of customer demand went to x86 compatibility. Intel officially killed the 432 in 1986 and redirected the team into what became the i960 — a conventional RISC that stripped out every capability feature.

Why it works now. The 432 was crushed by three constraints that no longer bind:

• Silicon budget. A capability tag that cost 40% of a 1981 die costs rounding-error area on a 3nm node. Cambridge's CHERI project (started 2010) added capability enforcement to a MIPS, then RISC-V, then ARMv8 core with ~7% performance overhead — a number Intel would have killed for in 1982.
• Compiler maturity. LLVM can lower C and Rust to capability instructions automatically. The 432 needed hand-written Ada; CHERI-Clang recompiles FreeBSD.
• The threat model changed. In 1982 nobody was chaining ROP gadgets across memory-safety bugs. In 2026 memory-safety CVEs are ~70% of all critical vulnerabilities. Hardware-enforced object bounds and non-forgeable pointers are suddenly worth a 7% tax.

ARM's Morello prototype (2022) is a Neoverse N1 with CHERI capabilities — capability descriptors, sealed objects, hardware type enforcement. It is, feature for feature, an iAPX 432 that happens to be 40 years faster. Google's silicon team has been evaluating CHERI-RISC-V for Android since 2024. The UK's Digital Security by Design programme has committed £70 million to shipping it.

The 432 wasn't wrong. It was early, in the specific technical sense that its per-check overhead was 100x what silicon could hide. That number crossed the viability threshold around 2015. Everyone building "secure processors" now is quietly finishing Justin Rattner's homework.