Managing the Complexity of a New Instruction Set Architecture

Electronic News, June 7, 1999 by Anant Agrawal

Sunnyvale, Calif.

As the size and functionality of processors continue to grow exponentially, the overall microprocessor design effort is starting to spiral out of control.

On the hardware side, the physical design is making quantum jumps in complexity on almost a yearly basis, resulting in the size of design teams expanding by leaps and bounds. But a larger design team does not necessarily mean a better one. Past a certain point, coordinating such a large number of people working on the same design becomes unproductive, making the management task a monumental enterprise. In our experience, the best approach is to have a smaller design team, but one with increased productivity. We have achieved this by investing heavily in hardware as well as software and automating our information management. On large microprocessor designs, predictability can be achieved only through proper complexity management.

It is on the software end, however, that the design effort becomes staggeringly complicated. This is especially true if a new instruction set architecture (ISA) must be developed to accommodate a major innovation in processor hardware capability, e.g. to support new superscalar execution or to move from 32-bit to 64-bit processing. After years of investing in an existing ISA, users find it a painful, difficult process to shift to a new one. More often than not, the transition means adopting new tools, operating systems and a whole new set of applications. Not only is this expensive, it is also extremely risky. This is especially true at the corporate level, where chief information officers are loath to turn their network environment and mission-critical servers into a virtual test site for a new ISA.

To encourage market acceptance of a new ISA, microprocessor companies now strive mightily to provide a complete, proven set of tools, an operating system and applications that support the instruction set. This is what makes a new ISA such a Herculean task. The ISA design itself, while requiring considerable engineering effort, is fairly straightforward to manage. Complicating the situation are the hundreds of other pieces required to successfully implement the ISA. These are created by hundreds of independent developers scattered around the globe.

Coordinating this massive endeavor is next to impossible when the development activity is expanding in all directions simultaneously, most of which is occurring outside the domain of the originating company. Consequently, the responsibility for dealing with the complexity of a new ISA is unfairly forced onto the end users. It is they who are required to eventually tie all the pieces together. And it is also the end users that must take on the risk of working out all the innumerable problems and incompatibilities between the tools, applications, operating systems and processor.

Such a result is, however, avoidable. Our experience at Sun Microsystems has proven that there are effective ways to minimize the complexity of introducing a new ISA, both on the development side and for the end users. At two major inflection points in our SPARC processor architecture, we introduced ISA extensions to accommodate hardware innovations, the first time to support the superscalar capabilities of the 32-bit SuperSPARC and then in 1995 to accommodate the 64-bit UltraSPARC processor. Although these transitions were significant, neither seriously disrupted our development community or end users.

Why? Because when we introduced the original SPARC ISA, we anticipated having to revise it over the years and so designed the original with that in mind. Then, we deliberately structured later ISA extensions to maintain complete upward binary compatibility with that original. As a result, applications written for the first SPARC processor can run in native mode on our latest processor. This unbroken 12-year record of delivering successive generations of ISAs that protect a customer's investment in software has considerably minimized the complexity of the overall ISA development for Sun internally and smoothed the acceptance of the different ISAs with our extensive customer base.

As our history shows, with a little forethought, the complexity of ISAs can be successfully negotiated and managed. But it does take discipline and careful planning on the front end to succeed. The substantial payoff for everyone involved-the microprocessor company, developers and end users-more than justifies this up front investment in time and resources.

Anant Agrawal is vice president of engineering for microelectronics at Sun Microsystems Inc.