[Source](http://dtrace.org/blogs/bmc/2008/07/18/revisiting-the-intel-432/ "Permalink to The Observation Deck » Revisiting the Intel 432") # The Observation Deck » Revisiting the Intel 432  ## Views on software from Bryan Cantrill's deck chair ## * [Home][1] * [About][2] ![Subscribe to the Blog Feed \(RSS\)][3] # [The Observation Deck][4] # Revisiting the Intel 432 As [I have discussed before][5], I strongly believe that to understand systems, you must understand their pathologies — systems are most instructive when they fail. Unfortunately, we in computing systems do not have a strong history of studying pathology: despite the fact that failure in our domain can be every bit as expensive (if not more so) than in traditional engineering domains, our failures do not (usually) involve loss of life or physical property and there is thus little public demand for us to study them — and a tremendous industrial bias for us to forget them as much and as quickly as possible. The result is that our many failures go largely unstudied — and the rich veins of wisdom that these failures generate live on only in oral tradition passed down by the perps (occasionally) and the victims (more often). A counterexample to this — and one of my favorite systems papers of all time — is [Robert Colwell][6]‘s brilliant [Performance Effects of Architectural Complexity in the Intel 432][7]. This paper, which dissects the abysmal performance of Intel’s infamous 432, practically drips with wisdom, and is just as relevant today as it was when the paper was originally published nearly twenty years ago. For those who have never heard of the [Intel 432][8], it was a microprocessor conceived of in the mid-1970s to be the dawn of a new era in computing, incorporating many of the latest notions of the day. But despite its lofty ambitions, the 432 was an unmitigated disaster both from an engineering perspective (the performance was absolutely atrocious) and from a commercial perspective (it did not sell — a fact presumably not unrelated to its terrible performance). To add insult to injury, the 432 became a sort of punching bag for researchers, becoming, as Colwell described, “the favorite target for whatever point a researcher wanted to make.” But as Colwell et al. reveal, the truth behind the 432 is a little more complicated than trendy ideas gone awry; the microprocessor suffered from not only untested ideas, but also terrible execution. For example, one of the core ideas of the 432 is that it was a [capability-based][9] system, implemented with a rich hardware-based object model. This model had many ramifications for the hardware, but it also introduced a dangerous dependency on software: the hardware was implicitly dependent on system software (namely, the compiler) for efficient management of protected object contexts (“environments” in 432 parlance). As it happened, the needed compiler work was not done, and the Ada compiler as delivered was pessimal: 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. If the story ended there, the tale of the 432 would be plenty instructive — but the story takes another series of interesting twists: because the object model consumed a bunch of chip real estate (and presumably a proportional amount of brain power and department budget), other (more traditional) microprocessor features were either pruned or eliminated. 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. And if that weren’t enough to assure awful performance: despite having 200 instructions (and about a zillion addressing modes), _the 432 had no notion of immediate values other than 0 or 1_. Stunningly, Intel designers believed that 0 and 1 “would cover nearly all the need for constants”, a conclusion that Colwell (generously) describes as “almost certainly in error.” The upshot of these decisions is that you have more code (because you have no immediates) accessing more memory (because you have no registers) that is dog-slow (because you have no data cache) that itself is not cached (because you have no instruction cache). Yee haw! Colwell’s work builds to crescendo as it methodically takes apart each of these architectural issues — and then attempts to model what the microprocessor would look like were it properly implemented. The conclusion he comes to is the object model — long thought to be the 432′s singular flaw — was only one part of a more complicated picture, and that its performance was “dominated, in large part, by artifacts and not by concepts.” If there’s one imperfection with Colwell’s work, it’s that he doesn’t realize how convincingly he’s made the case that these artifacts were induced by a rigid and foolish adherence to the concepts. So what is the relevance of Colwell’s paper now, 20 years later? One of the principal problems that Colwell describes is the disconnect between innovation at the hardware and software levels. This disconnect continues to be a theme, and can be seen in current controversies in networking (TOE or no?), in virtualization (just how much microprocessor support do we want/need — and at what price?), and (most clearly, in my opinion) in hardware transactional memory. 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: like the 432 object model, hardware transactional memory requires both novel microprocessor architecture and significant new system software. And like the 432 object model, hardware transactional memory has been touted more for its putative programmer productivity than for its potential performance gains. This is not to say that hardware transactional memory is not an appropriate direction for a microprocessor, just that its advocates should not so stubbornly adhere to their novelty that they lose sight of the larger system. To me, that is the lesson of the Intel 432 — and thanks to Colwell’s work, that lesson is available to all who wish to learn it. Posted on July 18, 2008 at 2:11 pm by [bmc][10] · [Permalink][11] In: [Solaris][12] ## 5 Responses ### [Subscribe to comments via RSS][13] 1. Written by Dimitar on July 18, 2008 at 5:05 pm [Permalink][14] Bryan, is Rock really in that much trouble? 2. Written by Andrew on July 18, 2008 at 5:24 pm [Permalink][15] Fascinating stuff. Computer history in general is not recorded, which is a shame. There are a few populist books around, like "Soul of a New Machine" and "Showstopper!" that are entertaining but hardly insightful. Contemporary magazines describe the new hotness in great detail but any historical examination is typically a cursory adjunct. I’ve been somewhat encouraged by the appearance of books that describe the internal design of operating systems (like Windows Internals and Solaris Internals) in a way that is accessible without sacrificing necessary detail. These fascinating books offer a real way for engineers to learn how other engineers have tackled some very complex system problems without having to grok an entire code base. 3. Written by Michael on July 20, 2008 at 2:25 pm [Permalink][16] Hi Bryan. I can say that I was one of the folks working on the iAPX432 project (on systems-level design). The real problems with the 432 project was that it in production at a time when Intel was only beginning to ship the 80286! Can you see the disconnect here? Yes, the design team made some unfortunate choices, but they had not even begun to design the workhorse processors that would become the foundation for our current CISC/RISC processors, and even those processors (80386, Pentium, et al) are considered relics now. More than just being ahead of its time, even the semiconductor processes needed to make such a design plausible did not yet exist. The ‘commercial’ product which rolled over the 432, the 80286, did not have any cache either. And so on. While you can fault the project and team for trying to put jet engines on a primitive biplane, the 432 endeavor has directly influenced the design of modern microprocessors, not to mention adding further legitimacy to the OO software concept – another idea that was considered ill-conceived at that time. I am writing to say that taking potshots at the 432 is in itself ill-considered, except in a superficial sense. In reference to your main point, I would point out that the 432 was an OO design through and through. All code was executed on behalf of objects, and all objects ran somewhat asynchronously. Interesting, one of the hottest topics in OO design today. Transactional memory was the only way of dealing with such a paradigm at the time. The real question is "what do you hope to accomplish?" I will agree that there is a growing discontinuity between processor platforms/capabilities and the software developed on top of such hardware implementations. In my mind, the relevant question is one of whether we will continue as in the past, with various approaches in the microprocessor realm doomed to failure as they find little to no software embracing those features. And conversely, software continuing to gain what could be key hardware features for functionality and performance due to intransigence on the part of commercial software and hardware interests? 4. Written by [Bryan Cantrill][17] on July 20, 2008 at 6:58 pm [Permalink][18] Michael, Interesting to know that this is still a hot topic over 20 years after the fact! As for what I hope to accomplish, I just want to bring attention to what I believe is a superlative systems paper. And indeed, the thoughts on the 432 here are largely just summarizing Colwell’s paper; do you disagree with its findings as well? I don’t think Colwell’s work or my summary are taking "potshots" at the 432, but rather trying to better understand its performance and learn from its design decisions — part of the reason that we tend to repeat mistakes in our industry is that we don’t stop frequently enough to look back at the ramifications of our past decisions… 5. Written by [orlando seo][19] on August 5, 2010 at 12:29 am [Permalink][20] This is two times now that i've come on your website in the last three days while searching Yahoo for absolutely unrelated things. Kinda weird. Keep up the good blogging! ### [Subscribe to comments via RSS][13] «[ Previous post][21] [Next post »][22] * ## Recent Posts * [Talks I have given][23] * [The sudden death and eternal life of Solaris][24] * [Reflections on Systems We Love][25] * [Submitting to Systems We Love][26] * [Systems We Love][27] * [Hacked by a bug?][28] * [dtrace.conf(16) wrap-up][29] * [Unikernels are unfit for production][30] * [Bringing clarity to containers][31] * [Requests for discussion][32] * [Software: Immaculate, fetid and grimy][33] * [The foundation of cloud-native computing][34] * [Triton: Docker and the “best of all worlds”][35] * [SmartDataCenter and the merits of being opinionated][36] * [Predicteria 2015][37] * [2014 in review: Docker rising][38] * [SmartDataCenter and Manta are now open source][39] * [Broadening node.js contributions][40] * [From VP of Engineering to CTO][41] * [agghist, aggzoom and aggpack][42] * [Happy 10th Birthday, DTrace!][43] * [Serving up disaster porn with Manta][44] * [Manta: From revelation to product][45] * [A systems software double-header: Surge and GOTO][46] * [Post-revolutionary open source][47] * ## Archives * [February 2018][48] * [September 2017][49] * [December 2016][50] * [September 2016][51] * [July 2016][52] * [January 2016][53] * [December 2015][54] * [September 2015][55] * [July 2015][56] * [March 2015][57] * [February 2015][58] * [January 2015][59] * [November 2014][60] * [June 2014][61] * [April 2014][62] * [November 2013][63] * [September 2013][64] * [July 2013][65] * [June 2013][66] * [October 2012][67] * [August 2012][68] * [June 2012][69] * [May 2012][70] * [September 2011][71] * [August 2011][72] * [July 2011][73] * [March 2011][74] * [February 2011][75] * [October 2010][76] * [September 2010][77] * [August 2010][78] * [July 2010][79] * [March 2010][80] * [November 2009][81] * [May 2009][82] * [February 2009][83] * [January 2009][84] * [December 2008][85] * [November 2008][86] * [September 2008][87] * [July 2008][88] * [June 2008][89] * [May 2008][90] * [March 2008][91] * [December 2007][92] * [November 2007][93] * [October 2007][94] * [September 2007][95] * [August 2007][96] * [July 2007][97] * [June 2007][98] * [May 2007][99] * [March 2007][100] * [October 2006][101] * [August 2006][102] * [May 2006][103] * [December 2005][104] * [November 2005][105] * [September 2005][106] * [August 2005][107] * [July 2005][108] * [June 2005][109] * [May 2005][110] * [April 2005][111] * [March 2005][112] * [February 2005][113] * [January 2005][114] * [December 2004][115] * [November 2004][116] * [October 2004][117] * [September 2004][118] * [August 2004][119] * [July 2004][120] * [June 2004][121] © [The Observation Deck][4]. Powered by [WordPress][122] and [Grey Matter][123]. [1]: http://dtrace.org/blogs/bmc "The Observation Deck" [2]: http://dtrace.org/blogs/bmc/about/ [3]: http://dtrace.org/blogs/bmc/wp-content/themes/grey-matter/img/rss_logo.png [4]: http://dtrace.org/blogs/bmc [5]: http://dtrace.org/blogs/bmc/2007/05/06/the-inculcation-of-systems-thinking/ [6]: http://en.wikipedia.org/wiki/Robert_Colwell [7]: http://us-east.manta.joyent.com/bcantrill/public/colwell-432.pdf [8]: http://en.wikipedia.org/wiki/Intel_iAPX_432 [9]: http://en.wikipedia.org/wiki/Capability-based_security [10]: http://dtrace.org/blogs/bmc "Visit bmc’s website" [11]: http://dtrace.org/blogs/bmc/2008/07/18/revisiting-the-intel-432/ "Permanent link to this post" [12]: http://dtrace.org/blogs/bmc/category/solaris/ "View all posts in Solaris" [13]: http://dtrace.org/blogs/bmc/2008/07/18/revisiting-the-intel-432/feed/ [14]: http://dtrace.org#comment-172 "Permanent link to this comment" [15]: http://dtrace.org#comment-173 "Permanent link to this comment" [16]: http://dtrace.org#comment-174 "Permanent link to this comment" [17]: http://blogs.sun.com/bmc [18]: http://dtrace.org#comment-175 "Permanent link to this comment" [19]: http://volvemedia.com/seo [20]: http://dtrace.org#comment-939 "Permanent link to this comment" [21]: http://dtrace.org/blogs/bmc/2008/06/30/dtrace-on-linux/ [22]: http://dtrace.org/blogs/bmc/2008/07/29/dtrace-and-the-palisades-interstate-parkway/ [23]: http://dtrace.org/blogs/bmc/2018/02/03/talks/ "Talks I have given" [24]: http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/ "The sudden death and eternal life of Solaris" [25]: http://dtrace.org/blogs/bmc/2016/12/21/reflections-on-systems-we-love/ "Reflections on Systems We Love" [26]: http://dtrace.org/blogs/bmc/2016/09/30/submitting-to-systems-we-love/ "Submitting to Systems We Love" [27]: http://dtrace.org/blogs/bmc/2016/09/26/systems-we-love/ "Systems We Love" [28]: http://dtrace.org/blogs/bmc/2016/09/13/hacked-by-a-bug/ "Hacked by a bug?" [29]: http://dtrace.org/blogs/bmc/2016/07/29/dtrace-conf16-wrap-up/ "dtrace.conf(16) wrap-up" [30]: http://dtrace.org/blogs/bmc/2016/01/22/unikernels-are-unfit-for-production/ "Unikernels are unfit for production" [31]: http://dtrace.org/blogs/bmc/2015/12/17/bringing-clarity-to-containers/ "Bringing clarity to containers" [32]: http://dtrace.org/blogs/bmc/2015/09/16/requests-for-discussion/ "Requests for discussion" [33]: http://dtrace.org/blogs/bmc/2015/09/03/software-immaculate-fetid-and-grimy/ "Software: Immaculate, fetid and grimy" [34]: http://dtrace.org/blogs/bmc/2015/07/21/the-foundation-of-cloud-native-computing/ "The foundation of cloud-native computing" [35]: http://dtrace.org/blogs/bmc/2015/03/24/triton-docker-and-the-best-of-all-worlds/ "Triton: Docker and the “best of all worlds”" [36]: http://dtrace.org/blogs/bmc/2015/02/05/opinionated-smartdatacente/ "SmartDataCenter and the merits of being opinionated" [37]: http://dtrace.org/blogs/bmc/2015/01/06/predicteria-2015/ "Predicteria 2015" [38]: http://dtrace.org/blogs/bmc/2015/01/02/2014-in-review-docker-rising/ "2014 in review: Docker rising" [39]: http://dtrace.org/blogs/bmc/2014/11/03/smartdatacenter-and-manta-are-now-open-source/ "SmartDataCenter and Manta are now open source" [40]: http://dtrace.org/blogs/bmc/2014/06/11/broadening-nodejs/ "Broadening node.js contributions" [41]: http://dtrace.org/blogs/bmc/2014/04/15/from-vp-of-engineering-to-cto/ "From VP of Engineering to CTO" [42]: http://dtrace.org/blogs/bmc/2013/11/10/agghist-aggzoom-and-aggpack/ "agghist, aggzoom and aggpack" [43]: http://dtrace.org/blogs/bmc/2013/09/03/happy-10th-birthday-dtrace/ "Happy 10th Birthday, DTrace!" [44]: http://dtrace.org/blogs/bmc/2013/07/23/serving-up-disaster-porn-with-manta/ "Serving up disaster porn with Manta" [45]: http://dtrace.org/blogs/bmc/2013/06/25/manta-from-revelation-to-product/ "Manta: From revelation to product" [46]: http://dtrace.org/blogs/bmc/2012/10/08/a-systems-software-double-header-surge-and-goto/ "A systems software double-header: Surge and GOTO" [47]: http://dtrace.org/blogs/bmc/2012/08/01/post-revolutionary-open-source/ "Post-revolutionary open source" [48]: http://dtrace.org/blogs/bmc/2018/02/ "February 2018" [49]: http://dtrace.org/blogs/bmc/2017/09/ "September 2017" [50]: http://dtrace.org/blogs/bmc/2016/12/ "December 2016" [51]: http://dtrace.org/blogs/bmc/2016/09/ "September 2016" [52]: http://dtrace.org/blogs/bmc/2016/07/ "July 2016" [53]: http://dtrace.org/blogs/bmc/2016/01/ "January 2016" [54]: http://dtrace.org/blogs/bmc/2015/12/ "December 2015" [55]: http://dtrace.org/blogs/bmc/2015/09/ "September 2015" [56]: http://dtrace.org/blogs/bmc/2015/07/ "July 2015" [57]: http://dtrace.org/blogs/bmc/2015/03/ "March 2015" [58]: http://dtrace.org/blogs/bmc/2015/02/ "February 2015" [59]: http://dtrace.org/blogs/bmc/2015/01/ "January 2015" [60]: http://dtrace.org/blogs/bmc/2014/11/ "November 2014" [61]: http://dtrace.org/blogs/bmc/2014/06/ "June 2014" [62]: http://dtrace.org/blogs/bmc/2014/04/ "April 2014" [63]: http://dtrace.org/blogs/bmc/2013/11/ "November 2013" [64]: http://dtrace.org/blogs/bmc/2013/09/ "September 2013" [65]: http://dtrace.org/blogs/bmc/2013/07/ "July 2013" [66]: http://dtrace.org/blogs/bmc/2013/06/ "June 2013" [67]: http://dtrace.org/blogs/bmc/2012/10/ "October 2012" [68]: http://dtrace.org/blogs/bmc/2012/08/ "August 2012" [69]: http://dtrace.org/blogs/bmc/2012/06/ "June 2012" [70]: http://dtrace.org/blogs/bmc/2012/05/ "May 2012" [71]: http://dtrace.org/blogs/bmc/2011/09/ "September 2011" [72]: http://dtrace.org/blogs/bmc/2011/08/ "August 2011" [73]: http://dtrace.org/blogs/bmc/2011/07/ "July 2011" [74]: http://dtrace.org/blogs/bmc/2011/03/ "March 2011" [75]: http://dtrace.org/blogs/bmc/2011/02/ "February 2011" [76]: http://dtrace.org/blogs/bmc/2010/10/ "October 2010" [77]: http://dtrace.org/blogs/bmc/2010/09/ "September 2010" [78]: http://dtrace.org/blogs/bmc/2010/08/ "August 2010" [79]: http://dtrace.org/blogs/bmc/2010/07/ "July 2010" [80]: http://dtrace.org/blogs/bmc/2010/03/ "March 2010" [81]: http://dtrace.org/blogs/bmc/2009/11/ "November 2009" [82]: http://dtrace.org/blogs/bmc/2009/05/ "May 2009" [83]: http://dtrace.org/blogs/bmc/2009/02/ "February 2009" [84]: http://dtrace.org/blogs/bmc/2009/01/ "January 2009" [85]: http://dtrace.org/blogs/bmc/2008/12/ "December 2008" [86]: http://dtrace.org/blogs/bmc/2008/11/ "November 2008" [87]: http://dtrace.org/blogs/bmc/2008/09/ "September 2008" [88]: http://dtrace.org/blogs/bmc/2008/07/ "July 2008" [89]: http://dtrace.org/blogs/bmc/2008/06/ "June 2008" [90]: http://dtrace.org/blogs/bmc/2008/05/ "May 2008" [91]: http://dtrace.org/blogs/bmc/2008/03/ "March 2008" [92]: http://dtrace.org/blogs/bmc/2007/12/ "December 2007" [93]: http://dtrace.org/blogs/bmc/2007/11/ "November 2007" [94]: http://dtrace.org/blogs/bmc/2007/10/ "October 2007" [95]: http://dtrace.org/blogs/bmc/2007/09/ "September 2007" [96]: http://dtrace.org/blogs/bmc/2007/08/ "August 2007" [97]: http://dtrace.org/blogs/bmc/2007/07/ "July 2007" [98]: http://dtrace.org/blogs/bmc/2007/06/ "June 2007" [99]: http://dtrace.org/blogs/bmc/2007/05/ "May 2007" [100]: http://dtrace.org/blogs/bmc/2007/03/ "March 2007" [101]: http://dtrace.org/blogs/bmc/2006/10/ "October 2006" [102]: http://dtrace.org/blogs/bmc/2006/08/ "August 2006" [103]: http://dtrace.org/blogs/bmc/2006/05/ "May 2006" [104]: http://dtrace.org/blogs/bmc/2005/12/ "December 2005" [105]: http://dtrace.org/blogs/bmc/2005/11/ "November 2005" [106]: http://dtrace.org/blogs/bmc/2005/09/ "September 2005" [107]: http://dtrace.org/blogs/bmc/2005/08/ "August 2005" [108]: http://dtrace.org/blogs/bmc/2005/07/ "July 2005" [109]: http://dtrace.org/blogs/bmc/2005/06/ "June 2005" [110]: http://dtrace.org/blogs/bmc/2005/05/ "May 2005" [111]: http://dtrace.org/blogs/bmc/2005/04/ "April 2005" [112]: http://dtrace.org/blogs/bmc/2005/03/ "March 2005" [113]: http://dtrace.org/blogs/bmc/2005/02/ "February 2005" [114]: http://dtrace.org/blogs/bmc/2005/01/ "January 2005" [115]: http://dtrace.org/blogs/bmc/2004/12/ "December 2004" [116]: http://dtrace.org/blogs/bmc/2004/11/ "November 2004" [117]: http://dtrace.org/blogs/bmc/2004/10/ "October 2004" [118]: http://dtrace.org/blogs/bmc/2004/09/ "September 2004" [119]: http://dtrace.org/blogs/bmc/2004/08/ "August 2004" [120]: http://dtrace.org/blogs/bmc/2004/07/ "July 2004" [121]: http://dtrace.org/blogs/bmc/2004/06/ "June 2004" [122]: http://wordpress.org "wordpress.org" [123]: http://masnikov.com/grey_matter