iAPX 432 was sort of a different failure from i860 and Itanium, no? My understanding is that the issue with iAPX 432 was that the architecture provided object-o

iAPX 432 was sort of a different failure from i860 and Itanium, no? My understanding is that the issue with iAPX 432 was that the architecture provided object-oriented instructions, but they turned out to be slow in practice, and the compiler didn't know how slow they were, so it abused them in situations where they should have used scalar ops instead, and that in tandem, the ABI relied too heavily on pass-by-value. Basically, that the iAPX was explained to compiler authors as an object-oriented CPU, when it should have been treated as a CPU with object-oriented extensions. Whereas i860 and Itanium were just trying to shoehorn VLIW into general-purpose computing, which is generally incredibly challenging. VLIW is great for places like DSP, where you have a defined real-time stream of data and limited context switching. In this case, you can use the spare die space you didn't spend on dispatch, prediction, and retirement on more MACs or ALUs or vectors, and the compiler can accurately predict the latency of a given operation because the source is defined. Fundamentally, compiler scheduling is intractable in a multiuser or task switching environment, because you have _no idea_ what will be in cache ahead of runtime and always end up with the i860/Itanium problem, where you stall your entire execution pipeline every time you miss cache unexpectedly.