Hacker News new | ask | show | jobs
by kens 4064 days ago
The architecture manual for the Intel iAPX 432 processor reads like alternate-world science fiction. [1] This processor came out in 1981 and was supposed to be the revolutionary new thing in computers. It failed and was mostly forgotten, but the world would be very different if it had replaced x86.

The 432 had incredible hype: "The vacuum tube, the transistor, the microprocessor - at least once in a generation an electronic device arises to shock and strain designers' understanding. The latest such device is the iAPX 432 micromainframe processor, a processor as different from the current crop of microprocessors (and indeed, mainframes) as those devices are from the early electromechanical analog computers of the 1940's." [2]

This 32-bit machine had some very unusual features. It implemented support for objects at the hardware level, with access protection for on a per-object basis. Even the kernel doesn't have access to everything. The world would be much more secure with no more buffer-overflow exploits.

This chip was started before the 8086 and included a virtual address space of 2^48 bytes. It was designed to be programmed entirely in high-level languages.The processor also included garbage collection in hardware. It also supported floating point and multi-processor operation, well before x86 did. Part of the operating system was built into the chip; the policies were defined in software, but the implementation was on the chip.

It's interesting to think what computers and programming would be like if the Intel 432 had succeeded instead of x86. We'd probably have super-secure computers and be programming in Ada.

[1] http://bitsavers.org/pdf/intel/iAPX_432/171821-001_Introduct...

[2] https://archive.org/stream/Intel-AR-166UnderstandTheNewestPr...

5 comments

The iAPX 432 failed for a very good reason: its performance was infamously abysmal. The performance of the iAPX 432 is actually the subject of one of my favorite systems paper of all time: Robert Colwell's "Performance Effects of Architectural Complexity in the Intel 432"[1] -- a paper that I love so much that I wrote a reasonably detailed review of it decades after it was published.[2]

[1] http://us-east.manta.joyent.com/bcantrill/public/colwell-432...

[2] http://dtrace.org/blogs/bmc/2008/07/18/revisiting-the-intel-...

I love studying failure, or at least when systems break. Please do a follow up that addresses Itanium and the P4.

The failures you describe in the post were technical manifestations of an operational failure in bringing an engineering project to completion. The scope was too large, with too many unknowns. Had they scheduled their project relative to Moore's Law, they could have kept the team smaller until they had the transistor budget to ship the chip they designed. You should read about how the Aztek was made [1]

[1] http://www.roadandtrack.com/car-culture/a6357/bob-lutz-tells...

> The iAPX 432 failed for a very good reason

From my point of view I guess it actually seems like a terrible reason in the long run, given that even something as widely derided as the x86 architecture has, over time, been made to perform.

Ideas fail and succeed for reasons that are totally unrelated to their "goodness". X86, JavaScript, trains, the bicycle.
Please expand on the bicycle.
The bicycle is an excellent technology that has largely failed in western world, but not because it is a bad idea. The car economy has more money and more political power, allowing it to displace the bicycle.
The bicycle is doing fine in the western world, it's the transportation of choice for just about every kid and plenty of adults too.
Interesting, looking forward to reading them.

But certainly processors can do more than they do. For example, doesn't x86 offer a memcpy or memmove instruction and just decode it as the right "fast" way, versus making people update their stdlib with complicated code?

I don't really know what I'm talking about, but it seems I often run across long discussions where people are trying all sorts of instruction sequences and they're model-specific and it just seems like there should be a few more higher-level instructions exposed. (Well perhaps that's the point of all the SSE and AVX instructions.)

Talking of alternative-world: I think anything by Chuck Moore falls in its own world (http://www.colorforth.com).

He even wrote an (unpublished) book about programming with as third basic principle "Do It Yourself!" (Aka "Invent The Wheel!"; http://www.colorforth.com/POL.htm). That alone moves it into its own universe. If you don't think so, read on to "Make variables as GLOBAL as possible. Why not? You can save some space and clarify your requirements"

But programs in the Chuck Moore universe have a total size measured in hundreds of words, globals are like function level scope. To go the other direction is code in a purely https://wiki.haskell.org/Pointfree style.

  > It implemented support for objects at the hardware level,
  > with access protection for on a per-object basis.
Periodic reminder that Henry Levy's Capability-Based Computer Systems is available in PDF form for free¹.

The 432 was slow, but the i960² was a clean RISC that could have had a future.

¹ http://homes.cs.washington.edu/~levy/capabook/

² https://en.wikipedia.org/wiki/Intel_i960

Allow me to add the http://en.wikipedia.org/wiki/Rekursiv

Another weird attempt of the early 80s. Similar fate. Very surprising company though.

The 8086 processor was multi-processor capable!