Just How Bad Was The Intel IAPX432?

I’ve mostly heard about this second hand, but I suspect a pi benchmark is quite misleading because it’s almost entirely a stream of ALU ops, with no memory management. The problem with the 432 was that it was designed to directly support high-level-language constructs without properly engaging with the compiler team. This was the fundamental difference with RISC: rather than trying to accelerate what the language did, RISC provided building blocks that could be combined in efficient ways.

Both extremes had problems. The first problem for RISC was that they replaced microcoded divide with a requirement that the compiler generate the sequence of simpler operations, which was suddenly a mistake when faster hardware divide came along. The 432 had the opposite problem: the compiler couldn’t optimise across any of their complex instructions. A lot of the next decade or so of compiler work was to increase the size of the window across which the compiler optimises. When you’re optimising across several statements, an instruction that does one of them as a microcoded instruction is an obstacle, not an advantage.

Itanium learned this lesson but took it too far. Compilers, by then, could do analysis across a lot of basic blocks, but there was a limit to the usable transforms. The compiler has to work on a static control-flow graph, whereas the CPU can operate on the dynamic one, which gives it more opportunities to optimise. We hit the same problems with EPIC architectures 20 years later.