Oral History of Robert P. Colwell – Chief Architect for Intel's IA32 [pdf] | Hacker News Reader

Oral History of Robert P. Colwell – Chief Architect for Intel's IA32 [pdf]

sigmicro.org

54 pointsareoform10 comments

Bob Colwell is awesome! I remember seeing an online talk he made... must be 25 years ago now. He talked about the development of the out of order architecture at Intel, and in general about engineering. He has some really fun anecdotes!

Honestly he is probably a big reason I switched majors from biotech over to computers, robotics and engineering in general... I even remember sending him an email about it and got a response back, wishing me good luck :) Sadly I can't find the email now, it was pre-gmail.

Some really good columns that he wrote for "Computer" magazine: https://people.computing.clemson.edu/~mark/330/colwell/at_ra...

Highly recommend his book "Pentium Chronicles"

Edit: found the talk! It was ee380 at Stanford 2003/2004. Sadly the video links seem to be broken... https://web.stanford.edu/class/ee380/ay0304.html

He was also at DARPA. There a presentation deck floating around from maybe 10 years ago--maybe HotChips--that, among other things, comes across to me as a rather pessimistic take on the petering out of CMOS process shrinks aka Moore's Law. His take was basically that, sure there are a bunch of other things you can do, but CMOS process shrinks have really been a unique thing in terms of achieving performance increases in the computer industry against which all else pales.

I believe this is the talk from hotchips: https://www.hpcwire.com/2014/05/28/planning-post-moores-law/

Second "Pentium Chronicles." It can be a slog in parts if you're not _really_ into silicon validation, but the anecdotes are worth it.

Some of the stories that Colwell shares are eye opening. BC in this part of the transcript stands for Bob Colwell,

    1:15:56 BC: Yeah. So I've got these notebooks all the way back to the seventies. That's just how I organize my head and I can find things that I want. 
    
    I have lots of pictures from my battles with this problem at Multiflow tracking this down: it has got to be this chip, it is not my design, it has got to be the chip. Eventually, Rich Lethin and I made a pilgrimage down to TI in Richardson, Texas and we said as best as well can tell many of your chips don't work properly. And does this come as a surprise to you?" 
    
    I half expected them to say, "what you are out of your mind! You've done something wrong. Come on, you don't know what you’re doing. Go use somebody else’s chips."
    
    But no, they said "Yeah we know, let me see your list." And they looked at the list and said "here is some more that you don't know about."
    [laughter]

    1:16:39 BC: And we went "Thank you very much. This is what we needed." At lunch I asked them "how did this happen?" and by the way it wasn't just TI. Their parts were no worse than anyone else. Motorola's were no good, Fairchild's were no good, they all had this problem. 
    
    And so I asked TI, "how did the entire industry fall on its face at the same time? We are killing ourselves trying to work around the shortcomings in your silicon."
    
    And the guy said, "the first generation of TTL was done by the old gray beard guys that really know what they are doing. The new generation was done by kids who are straight out of school who didn't know to ask what the change in packaging would do to inductive spikes." 
    
     He pointed out that what had happened was we had gone from 14 pin DIPs, which are small, to 24 pin DIPs which are really long and he said the dies right in the middle of that package and the power and ground have long leads, from the package out to the corner pins. Now if that had used middle pins they would have been short. But at the corners they got really long and therefore power/ground current inductance got really bad. 
    
    I said "that is just wonderful because we picked TTL specifically to try to avoid any such problems with the implementation technology." We said to ourselves, Multiflow machines are going to be such a risk at an architectural level and should pay off so well that we can back off the aggressiveness of the silicon technology, we will make up with it for the compiler. We will take no risks here.
    
    Instead we signed up for this TTL family, and inadvertently just shot ourselves in the foot with it. It took us about a year to work around all the different ways in which it was failing. It was incredible. You learn a lot that way.

> The new generation was done by kids who are straight out of school who didn't know to ask

I wonder how many of those kids would, thirty years later, go on to complain about kids these days.

The kids in question, thirty years later, did know to ask. And the thirty-years-later-just-out-of-school kids didn't.

Because no one and nothing is ever better or worse than others, right?

Statistically, over multiple generations? Not really, no. Outliers exist, but the aggregate rarely varies.

Bob Colwell used to write a column for IEEE Computer (IIRC) that was just awesome reading.

Reply on news.ycombinator.com