7 ms·

Revisiting the Intel 432 (2008)

85 points by jsnell 12y ago

ChuckMcM 12y ago
The Colwell paper really is excellent. And given feature sizes of chips today it would be fascinating to see a 432 implemented as envisioned, rather than as possible given transistor counts of the day. It was going to be the microprocessor version of the MULTICs system and much of what it imagined doing in hardware (capabilities) would make for secure environments that you could reason about more effectively. Probably make for a great FPGA project now.
- willvarfar 12y ago
  CHERI. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
  - ChuckMcM 12y ago
    Thank you! Those are awesome. Downloaded all the papers to my iPad for perusal.
    - willvarfar 12y ago
      This is the newest (and my favourite) paper http://www.csl.sri.com/users/neumann/2015oak.pdf http://www.csl.sri.com/users/neumann/2015oak.pdf Another chip that is better supporting privilege separation (but not using Capability-based addressing) is the Mill. (disclosure: I'm on the Mill team).
- rdc12 12y ago
  lowRISC (an open SoC effort for the RISC-V arch) has a form of tagged memory, that among other things can be used for capabilities. [0] http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-cores/ http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-... [1] http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/lowrisc http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-pr...
EdSharkey 12y ago
Are there any parallels worth observing between the Intel 432 history and the Itanium history? I was always enthusiastic about Itanium when it was announced and sad when it didn't unseat the x86.
- scott_s 12y ago
  I immediately made the connection, too. Itanium pushed a lot of complexity up into the compiler. The performance gains were supposed to come from the Itanium's wide-issue instructions, where one would issue multiple instructions at once. But that requires the compiler to do the necessary analysis to know which instructions can be executed at the same time. Typical out-of-order processors figure this out at runtime. My understanding is that in practice, the Itanium compiler was not able to do this well enough to justify the architectural decisions. That, though, is still far less radical than the design presented in this article.
- kps 12y ago
  I think of Itanium as the i860¹ redux. Andy Glew et al had some interesting discussion on comp.sys.arch² about MPX³ as an emasculated descendant of a capability system. ¹ http://en.wikipedia.org/wiki/Intel_i860 http://en.wikipedia.org/wiki/Intel_i860 ² which this www is too small to contain ³ http://en.wikipedia.org/wiki/Intel_MPX http://en.wikipedia.org/wiki/Intel_MPX
SixSigma 12y ago
Since learning of it, I have always been disappointed that I was not able to write and run software for a Burroughs machine running the MCP http://en.wikipedia.org/wiki/Burroughs_MCP http://en.wikipedia.org/wiki/Burroughs_MCP "the first operating system to manage multiple processors, the first commercial implementation of virtual memory, and the first OS written exclusively in a high-level language." using the Work Flow Language http://en.wikipedia.org/wiki/Work_Flow_Language http://en.wikipedia.org/wiki/Work_Flow_Language Like the success the 432 could have been I feel that the Burroughs architecture was prematurely abandoned and at modern speeds would have plenty to offer.
- skissane 12y ago
  Burroughs MCP still exists, so I am not sure how true your statement that it was "prematurely abandoned" is. Burroughs became (through a series of M&As) Unisys, and Unisys still supports MCP and is updating it with new versions. It runs on Unisys Clearpath mainframes. Unisys has moved away from their distinctive physical hardware to software emulation on an x86 platform. x86 has improved so dramatically, that even given the emulation overhead, it still is faster than the old physical mainframe CPUs. There is also an emulator which runs an old (1970s) version of MCP, not the current (2010s) version - http://www.phkimpel.us/B5500/ http://www.phkimpel.us/B5500/
  - SixSigma 12y ago
    Thank you, your response was partly what I was hoping to get by saying it.
- Taniwha 12y ago
  (As an old time B6700 hack ...) I think there were two main architectural problems with the Burroughs architecture: - it depended on compilers making safe code for both its system security and system integrity - this mean that you couldn't write your own compiler without being the equivalent of root, and you couldn't test it without potentially taking down the system - there was no hard memory protection between processes -memory descriptors contained both lengths and pointers - that limited memory size to 2^^((wordsize-overhead)/2) words - in Burroughs case it was 6Mb (6 byte words) huge at the time, tiny today The 432 had it's own issues - I think it designed itself into a corner at a time when memory speeds were very low so tight instruction coding was important, microcode was where you got your speed - the problem with that is of course that buggy microcode is hard to fix - cheaper/faster memory made the risc revolution possible and now we look at different bottlenecks
scott_s 12y ago
I want to call this text out, because I nearly did a spit-take when I saw it, and someone skimming the post may miss it: The mortally wounded features included a data cache (!), an instruction cache (!!) and registers (!!!). Yes, you read correctly: this machine had no data cache, no instruction cache and no registers — it was exclusively memory-memory. No. Registers. I would love to know what discussions they had, and what arguments were made, to come to that decision. That point alone has made me re-open the paper to take a closer look.
- JoeAltmaier 12y ago
  I recall it was a microprogrammed processor - a set of chips including a rom 'executed' the instruction set. More of an emulator than a processor. So maybe nowhere in that design for a cache?
  - scott_s 12y ago
    Possibly - the design started back in 1975, which is when we were still figuring out a lot of how processors should be designed. That's also far back enough that, frankly, I don't have much of an intuition for what people were thinking. By the way, I am struck by how close their object model sounds like the JVM. A major difference, though, is that the JVM can do some extra work at runtime to figure out when it is profitable and safe to throw away the overhead causes by safety and isolation - JITing. Then it can just execute instructions optimized for the hardware, not constrained by the object model. When your hardware maps to your object model, you can't do that.
    - wmf 12y ago
      The IBM 801 project started around the same time but its proto-RISC approach was kind of the anti-432. The 801 papers give a pretty readable explanation for "why we are proposing the opposite of what everyone else is doing".
      - twoodfin 12y ago
        Do you have links for any of these? I love reading historical rationale papers.
orionblastar 12y ago
http://en.wikipedia.org/wiki/Intel_iAPX_432 http://en.wikipedia.org/wiki/Intel_iAPX_432 Intel's first 32 bit processor. Tried to get away from the 8008 and 8080 and be like the 8800. Was more like a micromainframe in design. It was a stack machine with no registers.
pavlov 12y ago
This post could have its publishing year 2008 included in the HN title. Seven years later, we have some perspective on the author's prediction: "Indeed, like an apparition from beyond the grave, the Intel 432 story should serve as a chilling warning to those working on transactional memory today." Intel's transactional memory implementation TSX was famously broken in its initial incarnations in Haswell/Broadwell. [1] [1] http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions http://en.wikipedia.org/wiki/Transactional_Synchronization_E...
- bcantrill 12y ago
  And a few months after that, the gloves really came off.[1] [1] http://dtrace.org/blogs/bmc/2008/11/03/concurrencys-shysters/ http://dtrace.org/blogs/bmc/2008/11/03/concurrencys-shysters...
  - acqq 12y ago
    Thanks! The link to the article in ACM Queue (October 24, 2008) which is a deadlink on that page at the noment is now: http://queue.acm.org/detail.cfm?id=1454462 http://queue.acm.org/detail.cfm?id=1454462 "Real-world Concurrency, Bryan Cantrill and Jeff Bonwick, Sun Microsystems" It's sad that ACM is not able to redirect their old links properly. The other article mentioned is probably: http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 "Software Transactional Memory: Why is it only a Research Toy?" I'm actually searching for the analysis of the Intel's implementation.
    - bcantrill 12y ago
      Argh -- my apologies for the dead links! I have updated all of them, with my apologies again for the apparent inability of the ACM to honor old links.
  - willvarfar 12y ago
    (There is a distinction to be made between STM and HTM)
acqq 12y ago
Reading about 432, I didn't expect: "Instructions are bit variable covering a range from 6 up to and beyond 300 bits in length using Huffman encoding (I, 171)." Huffman compressed instructions. Wow. http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/cs460/ http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/c...
zackmorris 12y ago
"every function was implemented in its own environment, meaning that every function was in its own context, and that every function call was therefore a context switch!. As Colwell explains, this software failing was the greatest single inhibitor to performance, costing some 25-35 percent on the benchmarks that he examined." It's too bad because this is the future of computing. Or more precisely - rather than having a "process" that owns child data and functions, future processors will default to every function running in its own isolated environment, defaulting to no shared state. There will be a more advanced copy-on-write permissions model that determines what's shared (if anything), more like shell processes or channels in languages like Go. To have that kind of scalability (with respect to future goals like multiprocessing) and security at only a 35% performance cost would certainly have been compelling, especially in the 1970s. It's too bad that they didn't understand the physical limitations that make registers and caching basically a necessity, because it might have saved them. These things are only optimizations, so with today's available chip area and place and route techniques, they could be wedged into a conceptually correct architecture without much trouble. In short, I would take these findings with a grain of salt and consider how technology has advanced to the point where yesterday's blunders might be tomorrow's breakthroughs.

85 points by jsnell 12y ago

The Colwell paper really is excellent. And given feature sizes of chips today it would be fascinating to see a 432 implemented as envisioned, rather than as possible given transistor counts of the day. It was going to be the microprocessor version of the MULTICs system and much of what it imagined doing in hardware (capabilities) would make for secure environments that you could reason about more effectively. Probably make for a great FPGA project now.

willvarfar 12y ago
CHERI. http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/
- ChuckMcM 12y ago
  Thank you! Those are awesome. Downloaded all the papers to my iPad for perusal.
  - willvarfar 12y ago
    This is the newest (and my favourite) paper http://www.csl.sri.com/users/neumann/2015oak.pdf http://www.csl.sri.com/users/neumann/2015oak.pdf Another chip that is better supporting privilege separation (but not using Capability-based addressing) is the Mill. (disclosure: I'm on the Mill team).
rdc12 12y ago
lowRISC (an open SoC effort for the RISC-V arch) has a form of tagged memory, that among other things can be used for capabilities. [0] http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-cores/ http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-... [1] http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-preview-release/lowrisc http://www.lowrisc.org/blog/2015/04/lowrisc-tagged-memory-pr...

EdSharkey 12y ago

Are there any parallels worth observing between the Intel 432 history and the Itanium history? I was always enthusiastic about Itanium when it was announced and sad when it didn't unseat the x86.

scott_s 12y ago
I immediately made the connection, too. Itanium pushed a lot of complexity up into the compiler. The performance gains were supposed to come from the Itanium's wide-issue instructions, where one would issue multiple instructions at once. But that requires the compiler to do the necessary analysis to know which instructions can be executed at the same time. Typical out-of-order processors figure this out at runtime. My understanding is that in practice, the Itanium compiler was not able to do this well enough to justify the architectural decisions. That, though, is still far less radical than the design presented in this article.
kps 12y ago
I think of Itanium as the i860¹ redux. Andy Glew et al had some interesting discussion on comp.sys.arch² about MPX³ as an emasculated descendant of a capability system. ¹ http://en.wikipedia.org/wiki/Intel_i860 http://en.wikipedia.org/wiki/Intel_i860 ² which this www is too small to contain ³ http://en.wikipedia.org/wiki/Intel_MPX http://en.wikipedia.org/wiki/Intel_MPX

SixSigma 12y ago

Since learning of it, I have always been disappointed that I was not able to write and run software for a Burroughs machine running the MCP http://en.wikipedia.org/wiki/Burroughs_MCP http://en.wikipedia.org/wiki/Burroughs_MCP "the first operating system to manage multiple processors, the first commercial implementation of virtual memory, and the first OS written exclusively in a high-level language." using the Work Flow Language http://en.wikipedia.org/wiki/Work_Flow_Language http://en.wikipedia.org/wiki/Work_Flow_Language Like the success the 432 could have been I feel that the Burroughs architecture was prematurely abandoned and at modern speeds would have plenty to offer.

skissane 12y ago
Burroughs MCP still exists, so I am not sure how true your statement that it was "prematurely abandoned" is. Burroughs became (through a series of M&As) Unisys, and Unisys still supports MCP and is updating it with new versions. It runs on Unisys Clearpath mainframes. Unisys has moved away from their distinctive physical hardware to software emulation on an x86 platform. x86 has improved so dramatically, that even given the emulation overhead, it still is faster than the old physical mainframe CPUs. There is also an emulator which runs an old (1970s) version of MCP, not the current (2010s) version - http://www.phkimpel.us/B5500/ http://www.phkimpel.us/B5500/
- SixSigma 12y ago
  Thank you, your response was partly what I was hoping to get by saying it.
Taniwha 12y ago
(As an old time B6700 hack ...) I think there were two main architectural problems with the Burroughs architecture: - it depended on compilers making safe code for both its system security and system integrity - this mean that you couldn't write your own compiler without being the equivalent of root, and you couldn't test it without potentially taking down the system - there was no hard memory protection between processes -memory descriptors contained both lengths and pointers - that limited memory size to 2^^((wordsize-overhead)/2) words - in Burroughs case it was 6Mb (6 byte words) huge at the time, tiny today The 432 had it's own issues - I think it designed itself into a corner at a time when memory speeds were very low so tight instruction coding was important, microcode was where you got your speed - the problem with that is of course that buggy microcode is hard to fix - cheaper/faster memory made the risc revolution possible and now we look at different bottlenecks

scott_s 12y ago

I want to call this text out, because I nearly did a spit-take when I saw it, and someone skimming the post may miss it: The mortally wounded features included a data cache (!), an instruction cache (!!) and registers (!!!). Yes, you read correctly: this machine had no data cache, no instruction cache and no registers — it was exclusively memory-memory. No. Registers. I would love to know what discussions they had, and what arguments were made, to come to that decision. That point alone has made me re-open the paper to take a closer look.

JoeAltmaier 12y ago
I recall it was a microprogrammed processor - a set of chips including a rom 'executed' the instruction set. More of an emulator than a processor. So maybe nowhere in that design for a cache?
- scott_s 12y ago
  Possibly - the design started back in 1975, which is when we were still figuring out a lot of how processors should be designed. That's also far back enough that, frankly, I don't have much of an intuition for what people were thinking. By the way, I am struck by how close their object model sounds like the JVM. A major difference, though, is that the JVM can do some extra work at runtime to figure out when it is profitable and safe to throw away the overhead causes by safety and isolation - JITing. Then it can just execute instructions optimized for the hardware, not constrained by the object model. When your hardware maps to your object model, you can't do that.
  - wmf 12y ago
    The IBM 801 project started around the same time but its proto-RISC approach was kind of the anti-432. The 801 papers give a pretty readable explanation for "why we are proposing the opposite of what everyone else is doing".
    - twoodfin 12y ago
      Do you have links for any of these? I love reading historical rationale papers.

orionblastar 12y ago

http://en.wikipedia.org/wiki/Intel_iAPX_432 http://en.wikipedia.org/wiki/Intel_iAPX_432 Intel's first 32 bit processor. Tried to get away from the 8008 and 8080 and be like the 8800. Was more like a micromainframe in design. It was a stack machine with no registers.

pavlov 12y ago

This post could have its publishing year 2008 included in the HN title. Seven years later, we have some perspective on the author's prediction: "Indeed, like an apparition from beyond the grave, the Intel 432 story should serve as a chilling warning to those working on transactional memory today." Intel's transactional memory implementation TSX was famously broken in its initial incarnations in Haswell/Broadwell. [1] [1] http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions http://en.wikipedia.org/wiki/Transactional_Synchronization_E...

bcantrill 12y ago
And a few months after that, the gloves really came off.[1] [1] http://dtrace.org/blogs/bmc/2008/11/03/concurrencys-shysters/ http://dtrace.org/blogs/bmc/2008/11/03/concurrencys-shysters...
- acqq 12y ago
  Thanks! The link to the article in ACM Queue (October 24, 2008) which is a deadlink on that page at the noment is now: http://queue.acm.org/detail.cfm?id=1454462 http://queue.acm.org/detail.cfm?id=1454462 "Real-world Concurrency, Bryan Cantrill and Jeff Bonwick, Sun Microsystems" It's sad that ACM is not able to redirect their old links properly. The other article mentioned is probably: http://queue.acm.org/detail.cfm?id=1454466 http://queue.acm.org/detail.cfm?id=1454466 "Software Transactional Memory: Why is it only a Research Toy?" I'm actually searching for the analysis of the Intel's implementation.
  - bcantrill 12y ago
    Argh -- my apologies for the dead links! I have updated all of them, with my apologies again for the apparent inability of the ACM to honor old links.
- willvarfar 12y ago
  (There is a distinction to be made between STM and HTM)

acqq 12y ago

Reading about 432, I didn't expect: "Instructions are bit variable covering a range from 6 up to and beyond 300 bits in length using Huffman encoding (I, 171)." Huffman compressed instructions. Wow. http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/cs460/ http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/c...

zackmorris 12y ago

"every function was implemented in its own environment, meaning that every function was in its own context, and that every function call was therefore a context switch!. As Colwell explains, this software failing was the greatest single inhibitor to performance, costing some 25-35 percent on the benchmarks that he examined." It's too bad because this is the future of computing. Or more precisely - rather than having a "process" that owns child data and functions, future processors will default to every function running in its own isolated environment, defaulting to no shared state. There will be a more advanced copy-on-write permissions model that determines what's shared (if anything), more like shell processes or channels in languages like Go. To have that kind of scalability (with respect to future goals like multiprocessing) and security at only a 35% performance cost would certainly have been compelling, especially in the 1970s. It's too bad that they didn't understand the physical limitations that make registers and caching basically a necessity, because it might have saved them. These things are only optimizations, so with today's available chip area and place and route techniques, they could be wedged into a conceptually correct architecture without much trouble. In short, I would take these findings with a grain of salt and consider how technology has advanced to the point where yesterday's blunders might be tomorrow's breakthroughs.