4 ms·

This is the first time I've heard i432 described as "great". What parts of that architecture do you think Intel got right?

nickpsecurity 11y ago
- Clean slate attempt to clean up mess that was x86 family - Microcoded for easier updates at ISA level - Scheduling, IPC, and memory/storage management in CPU for acceleration and protection - Dedicated I/O processor like mainframes have - Multiprocessing support early on - CPU-level support for and some enforcement of abstract data types (objects) - Capability-based addressing for its fault-tolerance and security benefits - Segments do POLA at high-speed and fine-granularity - Protected procedures via domains - Garbage collection support - Consistency in hardware and software - OS and apps written mostly in safe, high-level language (Ada) Those are a few. The 75% performance drop due to bad implementation hurt it a lot. However, subsequent papers showed relatively few changes to the design would've eliminated most of its problems. Even calling it overkill, the subsequent i960 incorporated its object-descriptor architecture and fault-tolerance mechanisms into an otherwise RISC CPU. Imagine how much easier correct or secure apps would've been on either vs x86. Yet, market forces ensured x86 won out and became dominant. Long series of problems followed. Yet, compared to its architecture, the iAPX 432 and to a lesser degree the i960 were great.
- PhantomGremlin 11y ago
  The 75% performance drop due to bad implementation hurt it a lot. I know a number of people who were on the team that tried to "implement" that architecture, and it's highly unfair to them to call it "bad implementation". For example, there was this insanity: The instruction set also used bit-aligned variable-length instructions (as opposed to the byte or word-aligned semi-fixed formats used in the majority of computer designs). Instruction decoding was much more complex than in other designs. In the available Intel fab process of the time, just the CPU portion needed to be split into two chips to be "implemented". That's not bad implementation, that's oblivious architects "playing in the sand" without any regard for the practical ramifications of their architectural decisions. There was a reason that the successor i960 was much simpler, and why Glen Myers was brought in from IBM to bring some adult supervision to that architect's sandbox. The point is, it doesn't matter just how forward looking or elegant or innovative the 432 was, if it wasn't possible to build it. https://en.wikipedia.org/wiki/IAPX432#The_project.27s_failures https://en.wikipedia.org/wiki/IAPX432#The_project.27s_failur...
  - nickpsecurity 11y ago
    "I know a number of people who were on the team that tried to "implement" that architecture, and it's highly unfair to them to call it "bad implementation"." "The point is, it doesn't matter just how forward looking or elegant or innovative the 432 was, if it wasn't possible to build it." Let me be clear that I'm talking about the design decisions plus implementation. Subsequent work showed that changes to the design would've greatly boosted performance while keeping the overall scheme of things. Summary in the first link with details in other two. http://people.cs.clemson.edu/~mark/432.html http://people.cs.clemson.edu/~mark/432.html https://dl.acm.org/citation.cfm?id=17367&dl=ACM&coll=DL&CFID=742008315&CFTOKEN=45262120 https://dl.acm.org/citation.cfm?id=17367&dl=ACM&coll=DL&CFID... https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings... What are your thoughts on Colwell et al's analysis and suggestions for improving i432? "There was a reason that the successor i960 was much simpler, and why Glen Myers was brought in from IBM to bring some adult supervision to that architect's sandbox." I agree with you there. Colwell says i432 was a nice experiment with significant contributions that were forgotten as it failed. I can see that except that it was intended to be a product. Myers understood that products and experiments were two, different things. Hence, the better results with i960. Very unfortunate that it was done in by politics like i860, etc. Matter of fact, I saw a writer recently mocking F-35 because it uses obsolete, legacy i960MX's without realizing how much more advanced, reliable, and secure they could be vs 2015 ARM chips. People don't appreciate the wisdom in the past and fail to learn from it. Least SAFE and CHERI are exploring these things among others.
    - PhantomGremlin 11y ago
      What are your thoughts on Colwell et al's analysis and suggestions for improving i432? You're obviously more in tune with the project than I am. I never worked at Intel, but a lot of my friends did (mostly in implementation rather than architecture). As for Colwell's critique, Intel must have liked it so much that they hired him. :) I attended a number of Colwell's public presentations on various x86 chips, and he seemed like a smart, approachable, down-to-earth guy. As for improving the 432, my friends were worn out from struggling with it, so they were overjoyed that the 960 was a relatively simple RISC. The only concession they needed to make to its legacy was the 33rd memory bit, the tag bit. It would have been interesting if i960 had done better. But, even at the time, what I mostly heard about BiiN was "billions invested in nothing". Apparently the Siemens group that was initially involved wasn't their main computer people, it was some other division. So I'm sure there was lots of internal politics going on at Siemens also. One other thing that confuses me with various wiki entries of all this is that Wiki mentions Fred Pollack more prominently, whereas the name I heard more was Justin Rattner. mocking ... i960MX's without realizing how much more advanced, reliable, and secure they could be Now that Intel seems to be struggling to produce meaningful improvements to the x86 (whoopie, 15% faster!), perhaps something more architecturally advanced should be considered. Who cares if it's only 25% of the performance of the x86. The tradeoffs in terms of security etc might make it worth while. At least for high reliability applications. https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/BiiN https://en.wikipedia.org/wiki/BiiN

nickpsecurity 11y ago

- Clean slate attempt to clean up mess that was x86 family - Microcoded for easier updates at ISA level - Scheduling, IPC, and memory/storage management in CPU for acceleration and protection - Dedicated I/O processor like mainframes have - Multiprocessing support early on - CPU-level support for and some enforcement of abstract data types (objects) - Capability-based addressing for its fault-tolerance and security benefits - Segments do POLA at high-speed and fine-granularity - Protected procedures via domains - Garbage collection support - Consistency in hardware and software - OS and apps written mostly in safe, high-level language (Ada) Those are a few. The 75% performance drop due to bad implementation hurt it a lot. However, subsequent papers showed relatively few changes to the design would've eliminated most of its problems. Even calling it overkill, the subsequent i960 incorporated its object-descriptor architecture and fault-tolerance mechanisms into an otherwise RISC CPU. Imagine how much easier correct or secure apps would've been on either vs x86. Yet, market forces ensured x86 won out and became dominant. Long series of problems followed. Yet, compared to its architecture, the iAPX 432 and to a lesser degree the i960 were great.

PhantomGremlin 11y ago
The 75% performance drop due to bad implementation hurt it a lot. I know a number of people who were on the team that tried to "implement" that architecture, and it's highly unfair to them to call it "bad implementation". For example, there was this insanity: The instruction set also used bit-aligned variable-length instructions (as opposed to the byte or word-aligned semi-fixed formats used in the majority of computer designs). Instruction decoding was much more complex than in other designs. In the available Intel fab process of the time, just the CPU portion needed to be split into two chips to be "implemented". That's not bad implementation, that's oblivious architects "playing in the sand" without any regard for the practical ramifications of their architectural decisions. There was a reason that the successor i960 was much simpler, and why Glen Myers was brought in from IBM to bring some adult supervision to that architect's sandbox. The point is, it doesn't matter just how forward looking or elegant or innovative the 432 was, if it wasn't possible to build it. https://en.wikipedia.org/wiki/IAPX432#The_project.27s_failures https://en.wikipedia.org/wiki/IAPX432#The_project.27s_failur...
- nickpsecurity 11y ago
  "I know a number of people who were on the team that tried to "implement" that architecture, and it's highly unfair to them to call it "bad implementation"." "The point is, it doesn't matter just how forward looking or elegant or innovative the 432 was, if it wasn't possible to build it." Let me be clear that I'm talking about the design decisions plus implementation. Subsequent work showed that changes to the design would've greatly boosted performance while keeping the overall scheme of things. Summary in the first link with details in other two. http://people.cs.clemson.edu/~mark/432.html http://people.cs.clemson.edu/~mark/432.html https://dl.acm.org/citation.cfm?id=17367&dl=ACM&coll=DL&CFID=742008315&CFTOKEN=45262120 https://dl.acm.org/citation.cfm?id=17367&dl=ACM&coll=DL&CFID... https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/I432.pdf https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings... What are your thoughts on Colwell et al's analysis and suggestions for improving i432? "There was a reason that the successor i960 was much simpler, and why Glen Myers was brought in from IBM to bring some adult supervision to that architect's sandbox." I agree with you there. Colwell says i432 was a nice experiment with significant contributions that were forgotten as it failed. I can see that except that it was intended to be a product. Myers understood that products and experiments were two, different things. Hence, the better results with i960. Very unfortunate that it was done in by politics like i860, etc. Matter of fact, I saw a writer recently mocking F-35 because it uses obsolete, legacy i960MX's without realizing how much more advanced, reliable, and secure they could be vs 2015 ARM chips. People don't appreciate the wisdom in the past and fail to learn from it. Least SAFE and CHERI are exploring these things among others.
  - PhantomGremlin 11y ago
    What are your thoughts on Colwell et al's analysis and suggestions for improving i432? You're obviously more in tune with the project than I am. I never worked at Intel, but a lot of my friends did (mostly in implementation rather than architecture). As for Colwell's critique, Intel must have liked it so much that they hired him. :) I attended a number of Colwell's public presentations on various x86 chips, and he seemed like a smart, approachable, down-to-earth guy. As for improving the 432, my friends were worn out from struggling with it, so they were overjoyed that the 960 was a relatively simple RISC. The only concession they needed to make to its legacy was the 33rd memory bit, the tag bit. It would have been interesting if i960 had done better. But, even at the time, what I mostly heard about BiiN was "billions invested in nothing". Apparently the Siemens group that was initially involved wasn't their main computer people, it was some other division. So I'm sure there was lots of internal politics going on at Siemens also. One other thing that confuses me with various wiki entries of all this is that Wiki mentions Fred Pollack more prominently, whereas the name I heard more was Justin Rattner. mocking ... i960MX's without realizing how much more advanced, reliable, and secure they could be Now that Intel seems to be struggling to produce meaningful improvements to the x86 (whoopie, 15% faster!), perhaps something more architecturally advanced should be considered. Who cares if it's only 25% of the performance of the x86. The tradeoffs in terms of security etc might make it worth while. At least for high reliability applications. https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_iAPX_432 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/Intel_i960 https://en.wikipedia.org/wiki/BiiN https://en.wikipedia.org/wiki/BiiN