Evolution and revolution in microprocessor technology - speech by Microprocessor Report Pres. Michael Slater at Personal Computing Forum 1990

Esther Dyson, EDventure Holdings: It's peculiarly appropriate to have Michael Slater here because this is the year of the Ben Benediction. Ben really began in the microprocessor end of the world. For several years after he quit the newsletter, nobody with the exception of George Gilder who wrote for Release 1.0 for about one year - covered the semiconductor industry the way Ben had done.

A couple of years ago - four years, two-and-a-half, something like that; memory fails frequently - I ran into Michael at a conference and he told me he was going to start a newsletter on semiconductors. My basic attitude was, "Good luck, you're not competing with me, but you've got to be crazy." He did it anyway and has one of the finest newsletters in the business, which is not competitive... with mine, I mean.

[Laughter]

We're delighted to have him here to give an overview of where microprocessors are going and what they mean to our industry, because they are the stuff on which it all works.

[Applause]

Michael Stater, Microprocessor Report: Thanks very much,

Esther, I'm pleased to have this opportunity.

In 20 minutes this is tough to do, but I'm going to give you a quick overview of what's happened in 20 years of microprocessor developments and where things are going in the next ten years, and address the RISC issue.

There's a tremendous amount of confusion in the microprocessor world these days. A large number of companies are in this business, and of course they all argue that their side is the best.

As you're aH aware, the microprocessor is the engine of the pc; without them, pcs would not exist. From a technology point of view, a microprocessor is a cpu on a chip. The first one was introduced in 1971, which makes them about 20 years old.

As VLSI integrated-circuit technology advanced, it became possible to put more and more transistors on a chip. The question is: What is useful for a huge range of applications?

The main thing that leads semiconductor volume is memory chips. You can use arbitrarily large numbers of transistors on memory chips and they're useful for a wide range of applications. But as soon as you start building anything complex other than memory, it tends to be very specific.

The microprocessor is the only other thing developed so far which is standard but still complex, and is useful in a wide range of applications. From the semiconductor industry point of view, that's why microprocessors are important.

A simple start

I've plotted a number of microprocessors over the last ten years, and a couple of points for the next ten. At the left side is the 4004, the first microprocessor introduced about 1971 with 2300 transistors on it. It was an incredibly simple device.

There has been steady growth and that line - which is supposed to be straight but for reasons unbeknownst to me ended up with all these funny wiggles-is based upon those data points.

Everything fits quite closely on that line; it's been steady incremental growth. At the right side, you see today's state-of-the-art: Intel's 486 and Motorola's 68040 at 1.2 million transistors - about a 500-fold increase in complexity.

The 500-fold increase however means that microprocessors today are about 1 million transistors bigger than they were when they started out. Intel's projection for the 686 places it well above this curve; the reason for this may be that microprocessors more and more are becoming memory chips.

When we have 50 million transistors on microprocessors, 45 million are probably going to be cache memory. Cache memory packs more densely than processor logic, so the rate of increase may increase.

People often miss in looking at this chart - that the vertical scale is a logarithmic scale. From one line to the next of those horizontal lines, there is a ten-times increase in complexity.

That's the same data plotted on a linear scale the way you would normally expect to see it. When you look at it that way, you realize the astounding increase in complexity that's just starting. In 20 years we've gone essentially from zero transistors to 1.2 million transistors.

In another ten years we're going to add another 40 or 50 million transistors - an astounding increase. But the subject of this talk is not where that's going to go, but what's going to happen with these tens of millions of transistors. From the crude to the complex

A lot of you are familiar with the basic background of the microprocessor. While the first microprocessors were 4-bit devices, they were very crude. They were designed not for personal computers but as logic-replacement devices. After a while, the industry moved on to 8-bit microprocessors; in the mid-1970s, these were still designed for logic replacement. They started to get a bit more sophisticated, but had very primitive instruction sets - for example, no multiply or divide instructions.

This natural incremental growth led to 16-bit microprocessors about 1979. The semiconductor companies finally convinced some computer-architect types to work on these microprocessors, so they started getting more sophisticated. We had much more complex instruction sets: complex addressing modes, multiply and divide instructions and lots of data types. We started seeing even more complexity in 1983, 84, with the earliest 32-bit microprocessors. Then we added memory management, floating-point co-processors, but this was a very incremental, evolutionary process.

At each level, the semiconductor companies looked at their old microprocessors before they built a new generation, which essentially was a superset of what they had done before.

Taking a RISC

Where's the revolution? The revolution is called RISC, an approach to technology developed by IBM in the 1970s and pursued by Stanford and Berkeley in the early 1980s. It became a major commercial force by the end of the 1980s.

The key to the RISC revolution was simply not to design the next microprocessor as a superset of the previous microprocessor, but to start over. Make each feature justify itself - don't include it just because it was on the previous generation. Design for today's technology.

Note that the 386 is a 32-bit architecture, but it's a 32-bit architecture that's ugly. It's ugly because it is a superset of a 16-bit architecture which was a superset of an 8-bit architecture which was very similar to a 4-bit architecture.

[Laughter]

So what is RISC? By now, most of you have heard probably more times than you'd like that RISC stands for Reduced-Instruction-Set Computer. But it's important to realize that reducing the instruction set is a side effect, not a goal.

RISC is a nice catchy name, but it refers not only to a simple instruction set but also to a set of characteristics. The 4004 had a very simple instruction set, but that doesn't make it a RISC microprocessor in any meaningful sense of the term.

The real goal of RISC is to optimize system performance. Another shift in technology has occurred as microprocessors develop. Not only do we assume the base architecture is a 32-bit architecture, but we also assume all software is in a high-level language, so RISC processors are designed assuming that the compiler is part of the system. Assembly-language programming is literally discarded.

This adds a whole new idea: Can I push things out of the hardware into the compiler? Can I put in the hardware only things that really belong in the hardware, that really provide performance? If it can be done as well or better in the compiler, I might as well do it in the compiler.

Traditional microprocessors had a lot of microcode, which in a sense was a he because it hides the basic machine from the programmer. The programmer doesn't have access to the processor's fundamental hardware capabilities. All the programmer can really do is call microcode subroutines, which he thinks of as machine-language instructions.

What a programmer thinks of as one instruction is really initiating a microcode subroutine, and writing a program is really stringing together subroutines. The RISC approach says: Let's expose the basic hardware to the compiler; let the compiler look at the hardware's basic capabilities and get rid of the microcode.

Keeping it simple

Why simplify the instructions? Although the instruction-decoding logic does it in fewer transistors in a RISC microprocessor, that's not the most important reason.

The most important reason is that simplifying the instruction decoder is going to allow you to build these chips more quickly and much more error-free. As you're all painfully aware, the 486 has had bugs. These bugs tend to happen in the very complex instructions, things like tangent instructions and in some of the complex interactions that support the multiple addressing modes and the variable-length instructions - all things RISC microprocessors don't have.

With a very simple instruction decoder, if you want to build something in a small number of transistors, you can. Today you could not build a 386 in an exotic technology like ECL or gallium arsenide, but you can build RISC processors in ECL. You can buy an ECL RISC processor, but I think it's going to be a long time before you can buy an ECL 386, 486 or 68040 microprocessor.

That's the scalability people like to talk about. High-level language is an important part of this because the compilers are considered part of the system now, and they can optimize the code. They can put together sequences of simple RISC instructions to do whatever the end program needs to do to generate the high-level language function.

People know how to build good optimizing compilers for simple, consistent instruction sets. People cannot build good optimizing compilers for complex instruction sets. They tend to ignore all the complex instructions anyway and just use a simple subset of the instructions over and over.

Why RISC it?

Another way to look at RISC is to look at the subset of the instructions that the compiler writer wants to see, and provide only those.

Yet another way to look at RISC microprocessors is that they are new designs instead of old designs and take into account more knowledge of computer architecture, starting with 32-bit architectures and so forth.

An old architecture like the 386 architecture is rich in architectural baggage - what you carry along from the previous generation to the new one for software compatibility. But as you develop new implementation techniques - for example highly pipelined microprocessors - this architectural baggage makes that pipeline much harder to design. The pipeline in a 486 is much more complex than the pipeline in a SPARC processor.

You might think that I'm about to say the RISC processors are going to take over the world, but the key thing is that old architectures have software.

The downside of this architectural baggage is it makes it harder to build your new chips, but the upside is lots of people are ready to buy your new chips. The inertia of that DOS/Macintosh software base is incredible, and RISC advocates really underestimate it.

RISC byproducts

New RISC architectures have features that have absolutely nothing to do with reducing the instruction sets, yet are almost always associated with them.

RISC architectures have large register files - at least 32 registers. They have three-address instructions, instead of two-address instructions. They have instruction sets designed for efficient pipelining, the major technique used in the last few years to increase microprocessor performance. That's another hour's talk, but I'll ask you to take it on faith that you can design an instruction set to make it much easier to build a highly pipelined processor.

Getting down to business

Another part of this RISC/CISC battle is the business side.

There are significant shifts in the way that microprocessors are sold, licensed and made. In the early 1980s, system houses like Sun looked at available semiconductor technology, at computer-aided design tools, at computer-architecture knowledge coming out of the RISC work at places like Berkeley.

They said, "Hey, we think that we can design better microprocessors than the semiconductor companies, which aren't going to jump on this RISC technology because they have a vested interest in building chips compatible with what has come before. " Sun also felt frustrated with the slow rate at which Intel and Motorola were adopting this new technology.

Another issue is: They get to buy the RISC chips for the cost of the silicon, not the cost of the intellectual property. The silicon cost of a 486 is nowhere near the $850 price of the chip. Maybe $50 is for the silicon and the packaging, and the rest for the intellectual property.

MIPS - founded by the folks at Stanford who were developing the primary RISC architecture competing with SPARC - is another company founded entirely on a RISC microprocessor design. Both companies have licensed these architectures to multiple semiconductor companies so these are multi-vendor architectures with competitive pricing and multiple implementations. This is in stark contrast to Intel and Motorola which decided they would not license their 32-bit architectures to other companies.

386s, 486s, 68030s and 68040s are all single-sourced devices. As I'm sure many of you are aware, personal computer companies are not very happy with Intel as their only supplier of microprocessors.

RISC vs. CISC

A further advantage of RISC is that given a certain technology or a certain design time, you can build a faster processor using a RISC architecture than a CISC architecture. Not many people who understand the details would seriously disagree with this assertion.

RISC processors may be a more efficient use of silicon; they're going to be faster at any given level of silicon technology. Because of their high performance and the ability to build them in exotic technologies like ECL or gallium arsenide, you win have binary-compatible computers all the way up to the supercomputer level.

The overriding advantage of the CISC processor is the existing software business. There is no way a RISC processor is going to be binary-compatible with the existing CISC software base.

Today, CISC processors have more advanced implementations - the 486 and the 68040 are more sophisticated chip designs than any available SPARC or MIPS chips - but this is temporary. Over the next 18 months, a new generation of RISC microprocessors will have implementations just as highly integrated and more sophisticated.

The latest in buzz words

After RISC, superscalor will be the big buzz word for the next couple of years. Superscalor execution techniques will supplement pipelining, which is about at its limits.

Essentially, instead of fetching one instruction, decoding it and executing it, you fetch several instructions at a time, decode several instructions at a time and then execute several at a time.

Whereas the very best microprocessors today require one-and-a half or two clock cycles for each instruction, in the future we'll have microprocessors doing two or three instructions in one clock cycle. This could buy us another factor of three to five in performance without increasing clock rates.

RISC advocates would like to say that CISC is a dead-end technology. I don't believe that that's true. CISC performance is going to continue to increase - the 68040 has demonstrated that; the 486 has demonstrated that - but there's going to be a lag. Intel and Motorola would like to say, "Look at the 486; look at the 68040; they're just as fast as today's SPARC and MIPS systems so that means CISC has caught up to RISC."

The flaw in this argument is that they're comparing new chips still not in volume production, still not debugged, to RISC processors that have been produced for more than two years, are extremely stable and are about to leapfrog the CISC processors again.

Yes, the 486 has caught up to the performance level of the SPARC processors. But in the next two years you're going to see a new generation of RISC processors which win be a lot faster than the 486 and the 68040. A year or two later, you'll see the 68050 which will be faster than those RISC processors and the leapfrogging will continue. But I believe that at any given point your fastest solution is going to be a RISC processor.

The key advantage of RISC is not going to be smaller chips. If we can build 10-million-transistor microprocessors, who cares if the instruction decoder is 50,000 transistors or 500,000 transistors? You will care, because you'll be able to design these chips faster which means they'll be available sooner and it win be easier to design them bug-free.

And the winner will be?

Superscalor technology is important to this debate because it will be much more difficult to build superscalor implementations of CISC than of RISC microprocessors. To justify that is another 20-minute story, but I do believe that's true. As a result, in five years or six years you're going to see a bigger performance spread between RISC and CISC than you see today.

So who's going to win? RISC is going to dominate in performance-critical applications with easily portable software. Workstations are the primary example; the workstation market almost by definition is a performance-critical market. In UNIX, afl the software is portable and UNIX software vendors are used to having to port from one platform to another.

But CISC processors will continue to dominate business desktop computers, at least for the next five years and perhaps for the rest of the decade. The workstation market will grow and remain RISC-based, but RISC processors will not come anywhere close to the production volume of processors like the 486 and the 68040. RISC processors will not he significant as central processors in business desktop computers simply because of the tremendous inertia of the installed base.

That doesn't mean they aren't going to be important. They're going to be important in workstations and they're going to show up in pcs in sneaky ways like graphics accelerators. For example: You have a personal computer with a library of routines in a ROM on the system board that is used for all the graphics functions. You could build a display card with a RISC microprocessor on it, rewrite those routines in ROM for that RISC microprocessor and dramatically improve your display performance, but still retain compatibility with all the existing software.

You're still going to have a CISC processor as the main microprocessor, but you may have a RISC microprocessor running the display. You may have a RISC microprocessor in the laser printer, in the disk controller, on the LAN card, but I don't believe it will be the central processing unit.

Any questions?

Audience: What year or half-decade, if you will, would you project the crossover win happen?

Slater: I'm not at all sure the crossover of RISC exceeding CISC processor shipments is going to happen in this decade. I would say it's definitely not in the first half of the Nineties and it could easily be the next century.

Audience: What happens if an operating system like OS/2 goes onto RISC?

Slater: It certainly is conceivable to port OS/2 to a RISC microprocessor, but realize that doesn't automatically carry the applications with it. Every single application has to be ported. I don't see that happening in the near term. You can make OS/2 available on a RISC machine, but there's going to have to be the RISC flavor of every OS/2 application. That's going to be a long time coming, and it's not clear it's going to provide enough performance increase to bring the business market along with it.

One point I didn't explicitly make is that the business desktop-computing market is more than willing to lag a few years behind in performance in order to keep all the software.

Audience: Bell Labs this morning announced a chip that uses optical impulses rather than electrical. Any sense when that might be a commercially viable product?

Slater: I don't know enough about that to comment specifically, but I'd be surprised if that's something you're going to see in desktop computers this decade in any volume. You may see it in telephone switching systems.

Okay, thanks very much.

[Applause]

COPYRIGHT 1990 EDventure Holdings, Inc.
COPYRIGHT 2004 Gale Group