Dear Dr. Dobb's,
I think Hal Hardenbergh's heart was in the right place when he wrote his article "Rocket Science Made Simple" (Dr. Dobb's Sourcebook, September/October 1995), but his thesis is about eight years too late and now is more wrong than right.
His article discusses the difference between "computer architects" and "chip designers." The first place where I differ with his viewpoint is on page 53:
The people who designed the Pentium and the P6 and who are currently designing the P7 are not computer architects. But they're pretty good engineers, based on the results I've seen. I call them "chip designers."
There are several things wrong with this paragraph. First, even according to Hal's own definition that only one who creates a new instruction-set architecture from a blank sheet is worthy of the name "architect," the people who designed these machines are architects, whether or not they demonstrated that ability in the machines mentioned. For example, of the three senior architects on the P6, one was a senior architect on the Intel 960 processor, and the other two were senior architects on the Multiflow TRACE VLIW processors. Both of those had new instruction sets.
But that's semantic quibbling. More importantly, the act of creating a new instruction-set architecture is not the most difficult task in designing a computer. It's not easy, but it's easier than realizing that ISA in competitive silicon. At Intel, we call the people who figure out how to do that "microarchitects," because they are responsible for the microarchitecture. I claim that microarchitecture is where the action really is: superscalar, superpipelining, out-of-order execution, speculative execution, dataflow cores--the choices these people make and the balances they strike among the possibilities have a much larger effect on performance than most ISA choices. (Otherwise the x86 performance would have been left behind long ago, and instead it has gradually caught up to the RISC designs.)
Further, these microarchitects cannot possibly do their jobs well without a complete understanding of overall computer-system design and the software that will run in that environment. In other words, they must know at least as much as the "architects" that Hal acknowledges. By putting too much emphasis on clean-sheet design, Hal distracts the reader from the real battleground: implementations and microarchitectures. That's where the real wizardry is being displayed nowadays.
I have no idea where Hal got the number "30" in conjunction with the P6. P6's Reservation Station (RS) has 20 slots, and the Reorder Buffer has 40. Was he trying to blur the two, and therefore averaged between them to characterize the resulting storage capacity? I don't think that abstraction will work; those two structures have much different functions.
For example, he says "A scoreboard keeps track of everything that's going on." It most certainly does not. There is no scoreboard; that's part of the beauty of the design. The micro-ops themselves carry the control flow of the program through the machine. It's fundamental to the way the machine works and facilitates the dataflow mechanism built into the RS. Presumably Hal meant the Reorder Buffer, which collects the speculative state from the dataflow engine and reimposes the original program order onto that state. But that's nothing like scoreboarding, which attempts to track the execution state of a machine. In P6, there is no corresponding execution state; everything is speculative until it is retired.
Suggesting that we got register renaming from a paper on register allocation is very far-fetched. I can state with absolute certainty, having read Chaitin's paper, that there was no connection between that work and the P6 register-renaming facility. The basic idea of doing reg renaming is as old as vector machines, meaning at least 25 years old.
Where did Hal get the idea that P6 only speculatively executes up to five branches? Not true at all. P6 doesn't treat branches any differently from other kinds of mops, meaning it could (in principle) fill the Reorder Buffer with currently resolving jumps. The Reorder Buffer has 40 slots. Therefore, P6 can speculate to that depth. (Granted, beyond 8 or 10, there is little performance advantage to this, but it was cleaner to implement the generalized solution that we did.)
"P6 self-optimizes all shrink-wrapped code"? Not hardly. We designed it to run all code well, but good code can always get better results than poor code, and that's still true with Pentium Pro.
The philosophical design differences underlying the 486, Pentium, and P6 generations have nothing whatever to do with computer architecture and everything to do with chip design.
I submit this is an obsolete view of what CPU designers do nowadays. It has little to do with instruction-set design, but it very much depends on a deep understanding of the entire computer system, and those who perform these tasks deserve the appellation "computer architect" just as much as instruction-set designers.
Bob Colwell
chief architect, Pentium Pro
Intel Corp.
Hal responds: Let's clear the small beer. Along with their C compilers, most readers of this magazine generate code with a conditional branch every seven instructions. With "40 slots," that's five branches, which is what I wrote. People who read publications with "Transactions" in the title might be interested in 40 consecutive conditional branches.
About optimizing code: I did not mean to imply that the P6 could convert a bubble sort to Quicksort (or to my favorite, Knuth's insertion sort). In that sense you're right, the P6 can't fix bad code. What I meant was that the P6 automatically executes small groups of code in the correct order demanded by register and data dependencies, and that the well-known Pentium optimizations of breaking complex instructions into simple ones are done automatically by the P6.
"[The P6 has] nothing like scoreboarding, which attempts to track the execution state of a machine. In P6, there is no corresponding execution state...." Bob, I assumed that information is maintained within the P6 to let the P6 logic know when register conflicts (and such) have been resolved so that speculatively executed instructions can be discarded or completed. I chose to call this information a "scoreboard," since that term has been used previously with respect to maintaining the internal state of a CPU. You're the authority, so if you say the P6 doesn't maintain this information, then the reader should accept your assertion. I don't believe it.
Since writing the DTACK Grounded newsletter in the early '80s, I've asserted that there are no new solutions in the microprocessor world. All the problems, and their solutions, were discovered a dozen or more years ago in the mainframe world, and then again in the minicomputer world eight or so years ago. Now you tell me no, some of the solutions are "at least 25 years old." Thanks, Bob! In the future, I'll quote you often to support a point I thought I was making.
The point of my article "CPU Performance: Where Are We Headed?" (Dr. Dobb's Journal, January 1994) was that the mainframe world never solved the problem of the limit to parallelism in scalar code, so we should not expect the problem to be solved in the microprocessor world either. That article included a graph showing that micros, as exemplified by x86s, were indeed gaining ground on RISCs, just as you state in your letter. Are we having a violent agreement?
I am bemused by your implication that I think the job of computer architect is harder than that of chip designer. I ain't that dumb. When the 8086 ISA was originally developed in 1976 or so, less than a man-year went into that effort. Developing the P6 logic probably required 100 man-years, and that doesn't count the efforts of software folk (for emulation) and process folk.
Now we come to the main point of your letter: Are CPU chip designers "computer architects?" It's well known that garbage collectors prefer to be called "surplus material relocation technicians." I have no problem with this, because the job description of garbage collectors is identical to that of SMRTs.
It's also well known in hardware circles that (CPU) chip designers would rather have a business card describing them as a "computer architect" than an $8000 raise and a business card that says "chip designer."
While you tap-dance all around this issue, I'm pleased that you do not flatly assert that chip designers are computer architects. The job description of a computer architect is quite different from that of a chip designer. That's as true today as it was eight years ago.
A country doctor who spends a few weekends building a gazebo is a carpenter on those weekends. This does not mean doctors are carpenters. A very few computer architects may switch to chip designing (in a desperate search for employment; there are precious few new instruction-set architectures being developed these days) but that doesn't mean, as you seem to imply, that chip designers are therefore computer architects.
But it harms no one to call designers "architects." If it makes the hard-working chip designers happy and saves the company $8000 a head, then by all means give all your chip designers business cards with the title "computer architect." Has Intel done this?
Your use of the word "worthy" is interesting. If some occupations are worthy, then others are unworthy. I thought Thorstein Veblen and his "invidious distinctions" had gone out of style.
All this aside, I'd like to congratulate you and your P6 chip designers for developing a chip that'll run 32-bit x86 code really fast. It's high time we all climbed out of that 640K ghetto (but I wish there were a 32-bit DOS). Since I occasionally do math modeling and such, I'm especially pleased with the P6's FPU performance. I hope--and expect--to see more of the same in the future.
