A Brief and Biased History of Computer Architecture (Part 1)
I’ve always envied my Physics colleagues, because their field has a history rich with heroes and epic stories1I have other reasons for Physics envy—it’s the hardest of the “hard sciences”, one step away from the pure rigor of Mathematics. I worry that CS needs “Science” in its name to bolster its weak science-y-ness. The French term Informatics is much better, as our discipline spans math, science, and engineering. . Newton had his apple (and also found the Calculus). Einstein believed that God did not play dice, and he wrote to Roosevelt about building an atomic bomb. Gauss was the last physicist to know everything. We computer architects might know Shockley , but Bardeen won two Nobels (for the transistor and superconductivity). Every physicist I know tells these stories, which are as much culture and lore of the field as they are part of its history. In contrast, Computer Science is a young field (less than 100 years!), so we have fewer such stories. Turing has gotten biographies and biopics , but The Soul of a New Machine and Fumbling the Future have yet to get their movie treatments.
It’s time we in computer architecture did better. Let’s teach our students our history, not just the famous successes but also the ambitious failures. Beyond the purely technical history (many professors have wonderful reading lists associated with their graduate-level classes), let’s construct our own mythology, with our own set of heroes and their exploits. Along the way, let’s note why each success worked in its age, and what we think caused each failure. A tragic hero is still a hero. As a culture, we celebrate successes and don’t dwell on failures, but this means that we also don’t document failures—I wish there were the equivalent of NTSB accident reports about i860, Itanium, and Haswell’s TSX (to unjustly pick on Intel).2For an example of how to write such a report, see Colwell’s analysis of the Intel iAPX 432. Just reading section 1.1 is like the start of a horror movie. The NOPE workshop is a good start. Such reports would let us better learn from the past—not just to avoid repeating past mistakes, but also to understand their tragic flaws, because a flaw from one technological era can transform into a virtue in the next. As a poor substitute, I’ll offer some of my (brief) opinions about the technical reasons for failure of various projects.
