The Race For A New Game Machine:. David Shippy

The Race For A New Game Machine: - David Shippy


Скачать книгу
of how difficult it was to unseat Intel, the reigning king in the PC business. He stood at Apple’s side for years, loyally working with them to create the perfect product roadmap that would propel them ahead of the competition. It was hard, demanding work, and they had not won yet. Though Apple (with IBM chips) had at times outdistanced Intel in terms of processor performance, they were still behind in terms of raw chip speed. Akrout hoped he might finally have the right ingredients to put both Apple and the STI partners ahead of his old enemy. He was the eternal optimist, and I prayed we wouldn’t disappoint him.

      To get an answer for his concerns about Intel, Akrout enlisted Dr. Peter Hofstee, one of IBM’s top research engineers, to explore the competition for our next-generation microprocessor and help define project goals to ensure a win. Hofstee’s claim to fame came from his involvement in inventing the first chip in the industry to break the one-gigahertz processor speed barrier, the ultimate Mt. Everest challenge to a chip designer pushing the leading edge of technology in the late 1990s. Hofstee, a brilliant researcher, obtained his Ph.D. in computer science from the California Institute of Technology, a school that produces some of the best computer engineers in the country. Originally from the Netherlands, he decided to stay in the United States after he finished his studies and even accepted a faculty position teaching computer science and chip design at CalTech from 1995 to 1996.

      After sending Hofstee off to get the scoop on Intel, Akrout instructed Jim Kahle and me to define what we thought would be the most aggressive design parameters we could possibly achieve, and then to stretch beyond that. He wanted the STI product to beat all existing records, and then when Hofstee returned with his projections for Intel, we would see that our stretch design would trounce the enemy.

      Kahle and I had confronted Intel during our days at the Somerset Design Center. Back then, a new computer architecture referred to as a RISC architecture was the kicker for our product, the thing that made our chip stand out among the competition. Instructions are the fundamental directions, the recipe, that tell the hardware what to do. We all believed a highly efficient RISC machine could be Apple’s wedge into Intel’s domination of the PC market. It was supposed to provide higher performance and higher frequency at a lower cost. Up until that time, Intel retained the top spot with their tried and true X86 Complex Instruction Set Computer (CISC) chips, the brains for virtually all PCs. The RISC approach relied on the fact that most software applications actually use only a small subset of basic instructions. Our work at Somerset focused on optimizing this reduced set of instructions to run faster than the older CISC architecture. The problem was that PC owners needed to port all their old legacy software programs from their old systems to their new ones, giving Intel a definite advantage with every upgrade.

      In my first job assignment at IBM, I got a nice exposure to both the older CISC approach and the newer RISC approach while I cut my teeth on computer architecture and logic design. IBM hired me in June of 1985 in Endicott, New York, the birthplace of the company and much of the corporate tradition. In the 1960s and 1970s, IBM staked its claim to fame on the s/360 and s/370 mainframe computers designed and built in New York. However, in the 1980s, DEC and their popular VAX minicomputers started eating away at the low end of the mainframe market. Endicott’s Glendale Lab was responsible for delivering a crushing response to this threat with a product called the 9370.

      The main central processing unit (CPU) in the 9370 was a complex CISC processor, because they needed something that was code compatible with the mainframe s/370. I landed the job of designing the specialized input/output processor (IOP) that handled all of the traffic in and out of the computer. This IOP was just a very simple RISC design, but I was thrilled to be working on an actual microprocessor core.

      When I signed on with IBM, my buddies laughed at me and said, “Why do you want to go there? They won’t give a rookie like you any good design work.”

      With confidence, I replied, “They will if I’m a good designer.”

      How wrong my buddies were. IBM happened to be in an expansion stage just then and was willing to risk putting new hires into key roles. This product never saw the light of day, but it gave me valuable lessons in computer design.

      I also learned to make homebrew and to snow ski while in Endicott. I sometimes think those skills have served me almost as well as my computer design experience. My cube mate in Endicott was Brice Feal. Brice was a zany bachelor with a wide variety of interests. He invited me over to his house after work and took me to his cellar, where several hundred bottles of beer filled the shelves. He blew the dust off one of them, cracked it open, and filled two frosty mugs.

      “Give it a try,” he said with a smile, and we clinked our mugs together in a silent toast.

      It was the smoothest, best beer I’d ever tasted. “Wow, Brice!” I exclaimed. “Where can I buy this stuff?”

      He replied, “You can’t get this in stores. I make it.”

      His particular brand of beer was really a barley wine with a smooth flavor and high alcohol content. I was hooked, so Brice taught me all of the tricks and soon I was brewing my own beer.

      Brice also introduced me to another passion—snow skiing. There was a local ski resort called Greek Peak. Many Friday afternoons we skipped out of work early and hit the slopes. The ski resort lit the runs with spotlights, so we skied until very late at night.

      RISC computer design, homebrewing, and skiing. Life wasn’t too bad in Endicott for a young engineer. However, I heard about a new development project at the IBM site in Austin, Texas, and the central processor was RISC rather than CISC. From everything I knew, this seemed like the way to go. Exposed to both methods, I could see that the RISC approach would deliver simpler, higher performance hardware. If I stayed in Endicott, the sexier computer design assignments would be on a messy CISC design. I wanted an opportunity to create streamlined fast microprocessors using the RISC techniques.

      So in 1989, I went to the office of my third-line manager, Bobby Dunbar, and told him I was going to Austin to work on a RISC microprocessor. Bobby was just a good ol’ boy, content to ride the success of the s/370 computers he’d come to know and love. He propped his boots on the desk and laughed at me. “Nothing will ever come of that RISC architecture,” he said.

      His predictions did not prove true. Today, the highest volume chips produced at IBM and at Freescale (Motorola’s spin-off) carry the PowerPC RISC architecture. PowerPC is the architecture of choice at IBM for everything from game chips to supercomputer server chips. The PowerPC and Intel’s X86 are the two primary architectures that stood the test of time. I knew a good thing when I saw it.

      Intel stayed with their proven architecture, but they adopted virtually all the RISC techniques developed by our Somerset team. They employed a brute force approach to microprocessor design. They applied a team of thousands of engineers to streamline the instructions, and then to optimize and tweak those X86 microprocessors until they could offer as good or better performance at higher frequencies than we could with our designs.

      Intel capitalized on parallel processing techniques invented by IBM and other companies, such as superscalar and out-of-order processing. A superscalar design gains efficiencies by having multiple parallel execution units that operate in parallel on groups of instructions. It was like the difference between having multiple checkout lines at the grocery store versus a single checkout line. An out-of-order design gains efficiencies by scheduling instructions when they are ready to execute. This meant when even one long instruction stalled, other shorter instructions could be routed around it. Idle time is wasted time.

      Intel remained the only game in town when it came to the PC, in spite of our best efforts at Somerset. Of course, it didn’t help that IBM experienced various software failures around the same time.

      This early defeat at the hands of Intel was in the back of my mind as I walked beside the snazzy glass wall that separated cube-city from the STI war room, the place where Kahle held his daily architecture meetings. Another engineer beat me into the room and snagged the last available Ethernet port for his laptop. There were never enough outlets for everyone at the table, and the security team had recently disabled the wireless capabilities in the building as a defensive security measure. I sat near the back of the


Скачать книгу