Intel iAPX432 [LWN.net]

Intel iAPX432

Posted Oct 8, 2023 8:05 UTC (Sun) by CChittleborough (subscriber, #60775)
In reply to: A local root vulnerability in glibc by shemminger
Parent article: A local root vulnerability in glibc

If you mean the Intel iAPX432, it was created in the 1980s. It was a fairly vertical microprogram with enormous amounts (for the day) of microcode on chip. That microcode provided an ISA which was a superset of what Ada needed: a multitasking operating system with capabilities and concurrent garbage collection in Silicon. One of the superset features was that a called procedure could survive returning to the caller, like call/cc in Lisp. To do this, the microcode had to allocate the frame for each called procedure on the stack. When they got it running, they found that it could do 50 procedure calls per second: a bare procedure call took an average of 20 ms.

Wikipedia has a relatively decent article on this, though it leaves out the 50 calls/sec bit (which I heard in a talk by Prof Ed Gehringer).

Intel iAPX432

Posted Oct 8, 2023 14:03 UTC (Sun) by jem (subscriber, #24231) [Link] (1 responses)

To be precise, the project was started in 1976, and the product was launched in 1981. Meanwhile, to defend against competitors like Motorola and Zilog, Intel introduced the 8086 as a stopgap solution. We all know what happened after that.

From the Wikipedia article: "The iAPX 432 instructions have variable length, between 6 and 321 bits." Maybe partially as a reaction to this madness, something else was emerging from Berkeley: RISC. Roughly at the same time, in popular music, psychedelic progressive rock was replaced by punk rock.

Intel iAPX432

Posted Oct 9, 2023 2:17 UTC (Mon) by CChittleborough (subscriber, #60775) [Link]

Thanks for correcting me about the dates. Thanks also for the memorable, amusing and insightful analogy between RISC and punk rock!

Intel iAPX432

Posted Oct 9, 2023 9:02 UTC (Mon) by james (guest, #1325) [Link]

There is a fascinating oral history interview with Bob Colwell, senior architect on the Pentium Pro and the Pentium 4. He says (PDF, sorry) that in 1984:

...we went up to this bar where I struck up a conversation with some random guy I didn't know sitting next to me. He asked me what I was doing at Intel for the summer. I said "I'm a grad student doing some research on the 432." "Really? What kinds of things are you finding?" I said "Well, I'm finding that there's a huge disconnect between the software and the hardware. I mean the hardware should be capable of doing a procedure call much quicker than it's actually doing, for instance, it's taking many hundreds of clock cycles. And in other places, I'm seeing all kind of wastage from the compiler just setting variables that never get used, classic stuff you just don't do." And the guy said "Really? I mean tell me more about that part."
Eventually, I said "Okay, who are you? You know way too much about this technology." He tells me "I'm the leader of the compiler team." And I said "In that case I probably just fatally offended you." He said "No, not at all because I know we generate bad code and I don't care." He said "We don't like the 432 hardware team." And I thought "Oh my God, there is no hope that this project is going to work when you have the two main casts killing each other." He said "That hardware team never listened to us compiler folks At some point we decided that we'd live up to the letter of the contract but beyond that? No."

and

Well somewhere along the way, they threw away a little bit too much performance, and if they had been paying attention to that aspect of it, I think that they could have fixed those pieces, and if they made peace with the compiler guys they could have fixed that part of it too. They could have actually got within shouting distance of a competitive part. But, as it was, there were so many mistakes that there was no way to recover from them all.

It's a fascinating read.