Nothing much changes in computer and processor design

Fred Brooks, who wrote The Mythical Man Month and who worked as an architect on several important IBM computers, recently published an article about the IBM Stretch computer. Not many people know about Stretch (there’s a piece of Stretch in the Computer History Museum in Mountain View, California). However, the Stretch project in the late 1950s took IBM from vacuum tubes to transistors and laid many architectural and technical foundations for the immensely successful IBM 360 mainframe series of computers. The fundamental design concepts developed for the Stretch machine profoundly influence design today, so it’s worth 15 minutes or so to read the article. I’ll summarize two important developments here, just in case you lack the 15 minutes.

First, Stretch pioneered pipelined instruction execution. It had to do so, because the primary goal of Stretch was to be 100x faster than IBM’s latest scientific computer, the 709. Even with the jump from tubes to transistors, there was no way to reach that goal without coming up with a way to execute multiple instructions in parallel and pipelining is an excellent way to do just that. Brook’s remembers that the Stretch computer could have as many as 11 instructions in various stages of execution at one time. Today, most embedded microprocessors have three, five, or perhaps eight pipeline stages, so the Stretch architecture was quite a (er) stretch for the discrete-transistor era.

The second familiar problem is one of memory integrity. Stretch used ferrite-core memory. The cores measured 50 mils in diameter. They were small so that the memory could be fast. The goal was 2 microseconds. Brooks recalls that Stretch’s core memory ran hot and the heat-removal problem was eventually solved by immersing the memory planes in an oil bath. However, the really familiar problem with Stretch’s memory was data integrity. Stretch’s customers (nuclear weapons developers and cryptographers) needed highly reliable memory and ferrite cores pushed to the speed limits by the Stretch design team could not deliver that reliability without error detection and correction. Without it, the memory could deliver only minutes of error-free operation. Brooks writes: “Sometimes it is as important to be lucky as it is to be wise. One of the luckiest decisions was to put single-error correction, double-error detection on that memory.”

He goes on to explain why that decision was so fortuitous:

“The contract required that Stretch run for a month with better than 90% availability. The machine chugged along great and was hovering right above the 90% line when one bit driver, or else one sense amplifier, failed completely! For the rest of the acceptance test, the IBM team just ran it the way it was. There was not time to stop and fix it; stopping would have ruined the statistics. So the Stretch ran along to the end of the month single-error correcting every memory access from that box.”

In the 21^st century, we’re fortunate to have far more reliable semiconductor memory, but the relentless pace of Moore’s Law is taking us right back to the territory where memory isn’t so reliable. Error-correction and –detection circuits are returning to their place of importance for all types of semiconductor memory including both DRAM and Flash.

Again, Brook’s article is a worthwhile read. Highly recommended.