[MUSIC PLAYING]
University Video Communications is
pleased to present this edition of the "Distinguished Lecture
Series--
Industry Leaders in Computer Science
and Electrical Engineering."
Today, Sun Microsystems brings us Dr. David Patterson
on the story of SPARC.
As the first person on the Sun RISC Project in 1984,
Dr. Patterson is uniquely qualified
to address this subject.
A professor since 1977 at UC Berkeley,
he led three generations of RISC projects
and, in fact, won the Distinguished Teaching Award
in 1982 for his course series on RISC, where many of the ideas
were constructed and developed.
But first, we're fortunate to have with us Wayne Rosing, vice
president of the Desktop Systems Graphics Group at Sun,
who will provide a background of the business environment
during the development and introduction of SPARC.
Wayne Rosing.
Before Professor Dave Patterson discusses the technical aspects
of SPARC, I'd like to spend a few moments discussing
the context, the business context in which we developed
this architecture.
First of all, it was a very important for Sun
that we implement a computer architecture that was simple.
This system was architected with 14 people.
Five people were involved in the design of the gate arrays.
Two engineers actually design the CPU board.
And approximately five people were involved in the language
development and the OS porting.
So this started out as a very small project
because Sun was only a $30 million company at the time.
And we did not have the resources
to engage in a complex, full custom chip development.
Second, we wanted to have an architecture that
was capable of scaling all the way up from simple gate arrays
to gallium arsenide.
This was a very important focal point for our design.
And I think it was different than the way
many semiconductor companies who developed microprocessors
typically make decisions.
The semiconductor company normally
tends to have one process, like bipolar or CMOS,
or whatever they might have.
And they concentrate all of their energy
on building the best possible part in that process.
And often, these companies compete with each other
on the merits of their semiconductor process.
Since we're fundamentally a systems company,
we felt the need to develop a computer architecture that
would work in technologies that would
be appropriate from inexpensive desktops
all the way up to the implementation
of large supercomputer class machines.
So the architecture had to fit in multiple technologies.
Next, the most important thing really,
from a business consideration, was
to develop an architecture that would quickly
allow us to move the approximately 2,000 software
applications that existed for our Motorola product line
to SPARC.
Bill Gates from Microsoft has said
volume is everything in the software business.
And I think, if we look at the history of computer
architecture development, we've seen
hundreds of very elegant, very technologically
sophisticated computers designed primarily by engineering folks.
But they've mostly been business failures
because these systems were not able to attract
a critical mass of software.
Without software, you don't have customers.
Without customers, you don't have sales.
And until you have profitable sales,
you cannot generate the gross margin dollars to reinvest
in the engineering to make a computer architecture
successful.
So this is very important.
Probably the dominant consideration
in the development of SPARC was that we
do things in a way that allowed absolute, source
compatible, quick porting of applications
over to the SPARC machines.
Next, looking forward to the kinds of software
that people run on Sun systems, which are highly interactive,
typically graphics-oriented software,
even though it may be very computationally intensive
software, we really looked hard at what
is the style of programming that's
typical in this particular application area.
And if you look at Windows systems and graphics systems,
they're dominated by the need to have
dynamically-linked libraries operating all the time.
And this is an important thing.
The classic metrics of computer design
tend to be running Fortran programs, big batch programs,
or running C programs that are classically large batch
programs.
We spent a lot of time thinking about what
it means to have the kernel execution of Unix be efficient,
or what it means to have interactive graphics code
be efficient.
And what this consideration motivated
was the large register file in SPARC,
as opposed to a system that would
be more straightforward, for instance, of just 32
32-bit registers.
And this has been a point of controversy about RISC design.
It's almost one of the few religious points
so associated with the RISC machines.
I'm sure Dave Patterson will discuss this somewhat.
Lastly, needless to say, we wanted to make sure that we had
a system that was going to be efficient as programming styles
shifted more to object oriented programming,
both things like LISP, as well as Smalltalk, and C++.
And the early development that we're now
doing in advanced software in this area
indicates these decisions were correct.
We wanted an open, multi-vendor architecture.
Now, it's easy to say, well, it's open.
But what did we really want here?
Why did we want this?
The most important thing is we, as a company,
wanted to be able to buy the components for our systems
inexpensively.
So it was important to have multiple vendors sourcing
and have competition between multiple vendors.
For instance, in the SPARC Station 1,
we have two sources for the integer unit.
We have two sources for the floating point units.
This is a very important consideration
in order to get the kind of competitive pricing
we need to continue to produce cost effective machines.
Another consideration, a more subtle consideration,
is Sun can invest so many millions of per
year in fundamental R&D of SPARC chips.
And maybe one semiconductor company
could double that investment.
But if you have four or five, all
of a sudden, the total investment dollars going
against SPARC development goes up
to a very significant number.
And we feel that the investment dollars being applied to SPARC
probably far exceed the investment dollars going
into any one of the other competitive CISC or RISC
computer architectures.
And that kind of leveraging of our dollars
with other companies dollars is very, very fundamental.
Now, you might think that there's a zero sum game that's
being violated here.
But remember, the semiconductor companies that work with us
do not have to worry about developing languages, operating
systems, workstations, and development platforms.
So they're able to concentrate on what they do best
and not have to subsidize as part of their computer
R&D all of the other aspects of a complete system development.
And that's been an attractive thing
because we have been able to work with small companies,
for instance like Bipolar Integrated Technology, which
is a startup doing an advanced ECL process.
It would have been impossible for a startup computer
company in the ECL area to ever develop a microprocessor
without the kind of leverage that the Sun business
strategy has provided.
Last and most important, we want the pace of innovation
to SPARC development not to be set by Sun,
not to be set by the business strategy of any one
corporation.
We wanted a consortium to control this.
And SPARC International, which we
have formed with all of the SPARC component licensees
and with the participation of a number of the architecture
licensees, now has effective control
of the SPARC architecture.
We think that's a very important consideration, in terms
of making this rather, if you will,
upstart architecture from a systems company
become one of the major players in the volume microprocessor
business.
So thank you for that.
Are there any questions?
How would you describe the growth and acceptance
of the SPARC processor in terms of time?
And what problems have some of your partners experienced
in porting from the Motorola-based computers
to SPARC processors?
Before the Sun 4 was first introduced, the first SPARC
machine, we had successful instances of 500,000 line
programs coming into the porting center,
being recompiled, and running the first time.
So from the beginning, we often had very successful ports.
There were some areas in the early period
of the architecture where we had some compiler problems.
And we had problems with shared Fortran common
that we had to work out.
So there was about a six month window
there, where we had a little bit of difficulty because
of some data alignment problems that we
had neglected in the software.
Once those problems were overcome,
after that, the porting has been very smooth.
And getting the larger companies to port
has not been a technical issue.
It's typically been a business consideration.
Many of the large software companies
really are not prepared to port their applications to systems
until they see an installed base of a significant enough unit
volumes.
And where SPARC is in very good shape
is, as of I think the end of this summer,
there is no question that SPARC will
have numerically the largest installed base of RISC machines
in the world.
And so that makes the business motivation
for independent software companies very straightforward.
What would you have done differently,
given what you know today?
I think the things we would have done differently,
from a technical point of view, were pretty straightforward.
We would have put integer multiply
and divide full instructions into the architecture.
Second were mostly implementation issues.
We really should have put about twice as many people
on the project.
And we should have developed our own tightly coupled
floating point strategy in the beginning.
And second to that would have been developing an integrated
memory management unit with multiprocessor support
from the beginning.
When we first went out and started talking to companies
about using SPARC, we at Sun, as I think a bunch of gunslinger
engineers, really have no problem
designing memory management units and whatever
else wasn't there.
But we found a lot of companies really
had succumbed to the traditional semiconductor merchant market
strategy of they do everything for you.
And all you have to do is bolt a few chips in.
And it's all over.
And it took us a while to understand
that the other customers really needed a higher level
of integration than Sun did.
And in the last year and a half, those issues
have been overcome, of course, in our design
of subsequent chipsets.
What were the roles of each of the partners
that you worked with in the development of the SPARC
chipset?
For the very first generation, SPARC development
of the Fujitsu gate array, Fujitsu primarily
provided us with technical support in the CAD area.
And they had one engineer who just
was so involved that, at the end of that,
that particular engineer knew how to do SPARC machines as
well as we did.
And then he was able to subsequently do
a second generation standard cell design with himself
and just a few other Fujitsu people.
So they mostly helped us out in the CAD system
and learned the architecture.
In the case of working with Bit, it
was a true joint development, where Bit and Sun engineers
worked together from the beginning of the definition
of how we would approach the design, the pipeline design
through the development of all of the chips.
In the case of the Cyprus CMOS Full Custom,
it was a true 50-50 joint development,
where each company shared half the cost
and put in approximately half of the engineers.
And we put everybody together in a building, filled it up
with workstations.
And they went about their business.
They used to call themselves--
I can't remember-- oh yes, Sunray Semiconductor Inc.
They actually made up a fake company name
and called themselves a company surrounding their project
to get an identity.
And it worked very well.
And now, David Patterson.
I'm delighted to have the opportunity
to communicate with you in this way,
as well as to share this tape with Wayne Rosing.
I first met Wayne almost 10 years ago today.
With this taping, I took a leave of absence from Uc Berkeley
and spent it at Digital Equipment Corporation,
where Wayne was in charge of this division.
And together, we spent time figuring out ways
to try and build faster and better VAXes.
I think my involvement in this reduced instruction set,
or RISC, phenomenon started with that.
It seemed to me the difficulty of building VAXes
and VLSI technology gave rise to my involvement
in trying to build a simpler style of machine.
So what I'm going to do today is give you
some principles of computer performance design
and show how those contrasts between the traditional
approach and the RISC approach talk
some differences about the SPARC architecture
with other RISC architectures, then
give a historical perspective, and then show you
some actual chips and boards that
are using the SPARC architecture,
and then speculate a bit about the future.
What I want to emphasize in this talk today
is a fundamental performance equation
that all computer architects do.
As I go to the first slide, the CPU time today,
or the performance, can be divided into two pieces.
Almost all computers today use a clock,
a standard clock that sets the cycle time of the machine.
It's called the clock cycle time.
Well, then we can divide time into the number of those clock
cycles.
So CPU time is the clock cycles per program
times the clock cycle time.
Well, computer designers have found
it useful to come up with another way of presenting
the same information.
And that is to figure out the a number of clock
cycles per instruction.
So that's simply calculated by the clock cycles per program
divided by the number of instructions
you execute in that program, sometimes called
the instruction count.
And that gives you the average number
of clock cycles per instruction, which is
almost always abbreviated CPI.
So now, we can plug those two things together
into this time equation.
And we end up with the CPU time, which
is equal to the instruction count times the CPI
times the clock cycle time.
So performance is trying to--
you get higher performance by trying
to minimize that product of instruction count, CPI,
and clock cycle time.
So let's see how you take advantage
of that in the two different styles of machine design.
Now, the traditional approach, what they tried to emphasize
was to reduce the instruction count.
That was an interesting figure of merit.
The side effect of that is to increase the CPI.
That wasn't seen as all bad, however.
That was seen as raising the level of the machine,
that you had a higher level, more powerful instruction set.
And in fact, the execute fewer instructions is good.
Higher CPI, well, that wasn't so bad.
And also, it turns out, for that style of machines,
there was an emphasis on reducing
the size of the program, small program size.
Now, in contrast to that is the RISC style design, again trying
to minimize that key performance equation, where with RISC
the emphasis is in reducing the clock cycles per instruction.
And that happens primarily through pipelining,
by having many instructions executing at the same time.
What's this side effect of reducing the CPI?
It's a larger instruction count.
Well, that's considered to be OK because it's
a lot easier to get instruction memory bandwidth
in all computer design.
So that was an acceptable side effect.
The programs are larger as well.
They're larger because of the larger number of instructions
and also because the instructions are
kept in a form that's very easy to get pipelined execution.
And that was OK because, for the last decade,
the DRAMs used to make memory today
are getting cheaper at an incredibly fast rate.
So bigger programs to get better performance
is a tradeoff most people would be happy with.
Now, more perhaps minor or lesser roles
of the reduced instruction set approach
is that given that technology is moving
at an incredibly fast rate, this VLSI technology,
there's an emphasis on simplicity.
Let's try and keep the instruction set simple,
so that we can more closely tracked
the rapid changes in VLSI.
As a benefit of that style of design,
it made it easier to have a faster clock cycle
time by keeping things simple.
And probably the final linchpin of the RISC designs
is the assumption of a much better compiler technology
because there's been advances in compiler design
as well in the last 10 years.
Now, so I talked about the trade off of instruction and CPI
in this equation we're trying to minimize, right?
So what about the clock cycle time?
Well, the clock cycle time is your worst case situation
in computer design.
And there's lots of things that could limit the clock cycle
time.
But with the two different designs--
for the traditional or CISC approach,
they've always been microprogram.
So one of the limits is the time to fetch a microinstruction.
Typical, traditional machines will have between 4K and 16K
of these microinstructions that are very wide.
So you can't run the cycle time faster
than you can access this microprogram memory.
The RISC designs, on the other hand,
are built on a cache model of design.
So the cache you can adjust.
Caches are made to be adjustable.
They're just the highest level of the memory hierarchy.
So depending on what your clock cycle time is,
you can have a smaller instruction cache.
So the RISC designs aren't as limited by the memory size
because it's adjustable, whereas the traditional designs
you pretty much have to have the whole microprogram you're ever
going to use right there.
And that's going to affect the clock cycle time.
So how does that show up I think is shown in the next slide.
What this is, is a plot of the clock cycle
time on a log scale, over time along the bottom here.
So you see the RISC designes really didn't show up
until about 1986.
But the orange line is the minicomputer line
represented by models of the VAX family and the supercomputers
by the Cray.
It's relative.
This is a log scale.
So they are improving relative to the RISC designs
at a slower rate.
And not only is this RISC line somewhat steeper,
you see this sudden hitch in the curve.
And what that is, is the RISC designs changing technology.
In the earlier part, they were all done in some kind of CMOS
usually design.
They were able to use the ECL design.
So they're able to take advantage of the new technology
and change the clock rate.
So that's how the clock rate effects of what's going on.
So let's do a couple of examples.
The first example was 1987.
July 7, 7/7/87, Sun announced the SPARC-based family
of machines.
And so let's compare those figure of merits
for the products of that time.
Sun's traditional line was the Motorola 68000 family,
in particular the 68020.
So if we look at the instruction count, the ratio of those,
it took about 25% more instructions
for the RISC approach, a higher instruction count.
The clock cycle time is--
I'll explain a little bit.
It's a little bit funny for the Motorola design.
The clock cycle time was actually better for the 68000
than it was for the RISC design.
But the average number of clocks per instruction, you can see,
is quite a bit worse, 5 to 7 or 0.32.
When you multiply all those things together,
you get about a ratio factor of 2 to 1.
The RISC machine is twice as fast.
Or the 68000 takes twice as long to execute.
But the difference in price was very small,
about 10% or 20% more.
So you've got a factor of 2 performance for a 10% to 20%
increase in price.
It's a pretty good deal.
Now, when we give these talks to our friends at Motorola,
they will argue some about the clocks per instruction,
clock cycle time.
It turns out the Motorola, the clock rates,
the 25 megahertz turns out to be 40 nanoseconds.
Well, in the Motorola microcode, every single microinstruction
takes two clock ticks.
So I had a hard time deciding how to put this together.
The other way you put this is, with an 80 nanosecond clock
cycle time, then the CPI of 2.5 to 3.5.
It doesn't affect the product down here.
Just depending if you're sensitive about what's
the average number of clock cycles per instruction
of your architecture, you may not
like it characterized this way.
But the machine is advertised with a 25 megahertz 40
millisecond clock.
So that was one example.
This year, there is an example from DEC.
DEC has produced a VAX and RISC line,
in fact announced the very same day, just like Sun
did two years before that.
Now, when compared to the VAX architecture,
their RISC machine that they used almost
executes 80% more instructions.
These are based on benchmarks from a book
that John Hennessey and I are working on.
But it's the new C compiler in the tech programs.
So these are large programs that these numbers are based on.
We took the compilers with DEC chips in them
and did these measurements.
It was 80% more instructions, so much higher instruction count.
VAX is actually much fewer.
But you notice this machine, the clock cycle time
was quite a bit less for the RISC machine.
And there's a huge difference in the average number
of clocks per instruction.
So when you multiply it all together,
depending on the program, you get
a factor of performance improvement of about a 3 to 6.
The VAX takes about three times to six times longer
to execute these large programs than the RISC machine.
But yet, using DEC's prices, their list prices,
it was only 25% more expensive.
So again, something is 3 times 6 times more
expensive to start that--
let's try this again.
3 to 6 times faster--
that's it-- and only 25% more.
So those are a couple of examples of RISC machines
from two different families.
Now, let's talk in a little bit more technical detail.
And there was an interesting study
we did when we measured these large programs.
And this plot is measuring the ratio really
to the amount of instruction traffic on the VAX.
So let's say that the unit is one for the VAX instructions.
That's shown here, orange.
You can see that the number of words for memory for the RISC
machine, in blue, is 1.8.
That's like what we said before.
Now, the question is, what about the rest of the memory traffic?
What about the data accesses.
Well, it turns out that, normalized again to VAX,
it takes 1.7 of these units of the data memory traffic,
where the RISC machine takes only 0.6.
If you add these things all up, the total memory traffic
is that the VAX has about 10% more traffic than the RISC
machine, which is kind of surprising.
I think most computer designers thought
that if you have a higher instruction count, therefore
you're going to have a higher data memory traffic overall.
But it still might be a good tradeoff.
But the most interesting thing about this slide
isn't that there's a 10% reduction.
It's where the differences are.
For a computer designer's perspective,
it's relatively easy to double your bandwidth
with instruction memory because they're largely
sequential accesses.
Most are the next one.
So simply making the port twice as wide
would probably get you about 1.8 increase in the bandwidth.
On the other hand, data memory references
are very random in their very nature.
And so those are great things to get rid of.
So speaking as a computer designer,
if I had a choice of almost doubling my instruction traffic
and reducing my data traffic by a factor of 3,
that's wonderful from my perspective.
So when we're really starting to run real big programs
on these two sides of architectures,
we see some real interesting differences.
To build a much faster VAX, you're
going to have to have a much higher data memory
traffic than you will have for the RISC machines.
Now I'm going to-- before I talk about the differences
in the SPARC architecture, I want
to emphasize that at no time in our history
have we had such similar machines.
The RISC machines are so similar that people sometimes
tend to emphasize the small differences there are.
But let's put this in perspective.
In putting it in perspective, I'm
going to start talking about the traditional microprocessors.
The so-called 16-bit microprocessors
were developed in 1978 to 1980, about eight years
before the RISC machines.
So when we look at these machines--
the Intel 86, the Motorola 68000, and the Z8000--
the first difference is the difference of addressing,
which is a major difference, two of them
using segmented addressing and the Motorola use
of the flat addressing.
That's about as big a difference is
going to get in an architecture because it affects so much
of the system.
There was no protection on the 86.
And it was optional on the other two machines.
And you can see the address size vary.
Even with the segmented architectures,
the address size is varied.
So those affect a lot of the software that runs
on the machine, the addresses.
If we look more inside, the register sizes were different--
16 bits for Zilog and Intel and 32 for Motorola.
The register model was incredibly different.
Maybe that's one of the biggest differences between them.
All the registers were special purpose in 86.
They were divided into eight data
and eight address in the 68000; 16 general-purpose registers
on the Z8000.
The instruction size was variable, either byte variable
in the 86 or 16-bit variable Motorola 68000.
Intel had no data limit restrictions.
And Motorola, on the 68000, Zilog
had required the data to be aligned.
And finally, the input/output was memory map for Motorola,
but were special instructions on the other two machines.
So let's contrast that with the RISC machines,
which were done in 1986, or announced 1986, 1988.
There's the SPARC, the MIPS architecture,
which is being used by DEC in their RISC machine,
and the Motorola 88000, Motorola's RISC machine.
You see the addressing.
All of them use flat addressing.
All of them use page level protection.
All of them have the same address size.
The SPARC-- in terms of what's visible to the programmer,
the--
well, the width of the registers are 32 bits wide.
They're always saying the number available to the programmer.
All of them have 32-bit registers.
The instruction size, they're always all 32 bits.
The data always has to be aligned.
And it's memory mapped.
So in contrast to just a few years ago,
it's incredible agreement on all these basic issues, which
affects why it's so easy to port programs between these RISC
machines.
So keep in mind that the RISC machines are more alike
than any set of machines we've ever seen
in history of computer design.
But let me now talk about a couple
of differences for the SPARC model.
The first is that SPARC allows overlapped execution of integer
and floating point programs.
So what this means is, in the right circumstances,
if you do have floating point instructions,
you can maybe get complete overlap
with energy instructions and the floating point instructions.
How do you support that in an architecture?
You have to allow there to be a mechanism so that when you have
an interrupt, you can back up and find out
what floating point instructions hadn't been finished.
So SPARC provides a queue that contains
a copy of the instruction, the floating point
instruction that's in the middle of execution,
as well as a PC of that instruction.
As Wayne Rosing mentioned, there was an emphasis
in the development of SPARC of support for some of the newer
programming ideas--
the dynamically linked and dynamically typed languages.
That was important in the development of SPARC.
For LISP in particular, it has some interesting requirements,
challenging requirements, for the computer designer.
Just because you see A plus B doesn't
mean that you're adding two numbers or two floating point
numbers.
You could be adding to arrays.
So there has to be the opportunity for the LISP
programmer at runtime to change the Add instruction
to perform these other very complicated things.
So what does a computer designer do about that?
Well, typically, they will tag the data somehow,
some mechanism so that when they're integers,
they'll know they're integers.
And they can do them fast.
And it turns out almost all the time they're integers.
So looking at the slide, SPARC supports
the two least significant bits.
The two least significant bits are
zeros, which indicates these aren't
pointing to something more complicated than just numbers.
They're added together.
And the result is also one of these integers.
So the overflow bit is set on an operation.
If these two least significant bits
are not zeros, and if the result is too big a number
to fit in here, you overflow.
So by having some special instructions,
they do add, subtract--
and because SPARC uses condition codes,
subtract acts as a compare.
So they can do comparisons with support
on a few of the instructions.
The rest of the instructions will ignore the tags.
But there's a few special just to support the LISP
and Smalltalk dynamic timing.
As it shows on the slide next, another very important feature
for one of these experimental architectures
is that you can test for errors because there's
lots of funny things that can happen in dynamic typing.
There's a lot of checking to make sure things are correct.
A very nice instruction for that is a conditional trap
instruction.
If you don't have a conditional trap instruction,
you have to conditionally branch around some subroutine
and pass parameters.
Conditional trap takes only one clock cycle
to perform the test.
It's a nice thing to include.
The final thing is register windows, which Wayne alluded to
in his presentation.
So I'll spend some time showing what that is
and what the implications are.
Register windows are based on an observation about the behavior
of most programs or all programs,
just as caches were invented based
on an observation of the behavior of all programs
towards the locality.
So as you see on the slide, let me-- [? what ?] the axis is--
across is basically time and units
of procedure call and return.
And what goes down the slide is the nesting depth,
so how many levels deep is the subroutine.
And so we get jagged--
basically, these are four or five calls
in a row followed by a return, and a call, and so on.
So we have this pattern.
When I move up, the program is doing returns.
And we moved down, it was doing a series of calls.
Well, the first thing you can observe by this
is that, at least for this program,
we didn't see very jagged lines.
We didn't see programs that are 100 or 1,000 calls followed
by 100 or 1,000 returns.
There's some locality there.
And in fact, if you provided a larger buffer
of registers than just the 32 you need,
that many sets of them on the chip,
the question is, how frequently can you
avoid having to go off chip?
Because if you don't have this on every--
let's see.
On every call, you have to store registers away,
extra store instructions.
And every return, you have to do loads back to bring them back.
So what this shows is if we put a buffer of a size
I think something of some thing like-- let's say it was eight.
These boxes indicate when you do overflow.
So the first several calls and returns all fit on the chip.
And then where this line is, that meant there were too many.
And you did these overflows when you
did have to do memory traffic.
So basically, the success of the buffering scheme
is the number of boxes on this chart.
And you can see, once we get down here,
we're doing lots of calls and returns in a row.
So that's the observation.
But how well does it work in practice?
And in particular, is this something
that only works with C?
Or does it work with other languages?
This chart shows the percentage of the calls, the results,
and overflow.
The percentage of those calls on the previous chart,
they were the lines for the box.
And this is plotted against the number of register banks
that you have on the chip.
OK.
And now, with the plots that are there
for several programs in three different languages, because I
certainly thought that when you got into other languages
the pattern might be quite a bit different.
But as you can see on the slide, they all
have the same kind of shape with the knee of the curve
typically being somewhere between 6 and 8
of these register banks.
So the machines that we developed at Berkeley
had eight.
And then the SPARC machines had either seven or eight,
I think the ones that have been announced so far.
So that technique seems to work.
And then if you have about seven or eight banks,
you can reduce the number of stores
to save registers off the chip and loads coming back.
Now, there's some implications to the register windows.
And let's evaluate those implications
in terms of our basic performance formula.
So first off, instruction count--
running those same programs I alluded to earlier on both
the SPARC machine and the MIPS machine,
MIPS required 40% to 60% more store instructions in only 3$
to 20% more loads.
That's because there's a lot more
loads in the program for other things
than there are simply for saving and restoring registers.
Now, again from a computer design perspective,
your favorite instructions are things that
just add registers together.
You just have to fetch the instruction.
It doesn't bother anything else.
After that, maybe his jumps aren't so great.
But at least they don't access memory.
And after that are loads because at least your reading
instructions and data, it's all coming in the same direction.
But the worst instructions, from my perspective, are the stores.
They're going the wrong way on a one way street.
You have all this data flowing at you.
But instead, what happens is the stores,
you have to send the data the other direction.
So getting rid of stores is a nice thing to get rid of.
The impact on CPI, the average number
of clocks per instruction by your instrument
is basically no impact.
But a lot of people have speculated--
and I was looking forward to see--
what was going to happen to the clock cycle time.
So far in the years that people have been building chips,
the SPARC-based chips with register windows
have been as fast or faster than the competing
chips from Motorola and MIPS, indicating
that the size of the register file
physically on the chip, that's not affecting the clock cycle
time.
Something else must be the bottleneck.
That hasn't been the issue.
The technology it's been built with hasn't been the issue.
So I think a lot of people concerned
would agree about the instruction count, these two
points, but wondered whether or not it wouldn't hurt the cycle
time.
And so far, that hasn't been true
for the commercial machines.
There's a couple other things that people have brought up
about register windows.
What about process switching time
when you're switching from working completely different
programs with more registers?
Well, it turns out that our friends in the operating system
have found so many things to do at process switch time that
actually happened to save two or three times as many registers
isn't a big deal.
And less than 20% of the time in Unix
is the saving of the registers away for the SPARC machine.
Another interesting questions is,
what about-- it takes more resources on the chip.
How's that going to affect the size of the chip?
And the size of this chip is important
because that affects the cost of the chip.
The way they're manufactured today,
it goes way up with the area the chip.
It turns out the cypress die, in part
because they have a nice thin line width, is the smallest
die of all the RISC chips, at the time
of this taping at least.
And then if we looked at that very smallest
die, how much of all that die is dedicated to the register
windows?
We see that it's only 10% of the die or less than that.
Final thing to say about register windows
is that they are optional in the SPARC architecture.
Separate instructions from call and return
invoke the register windows, the save and restore instructions.
So you could take a SPARC architecture
and write a compiler that ignored register windows.
Also, depending on your technology,
big architectures that are variable
have as few as two register banks and as many as 32,
depending on your technology.
So lots to say about register windows.
I want to emphasize one more time
that these machines are so similar,
I've never seen anything like it.
And I don't think these small details
will make the differences in the long term.
But we'll see.
Probably, to me, the most interesting thing
about this SPARC architecture is that, as Wayne Rosing alluded,
they've developed a family of computers.
So they're shown on this slide.
The SPARCstation 1, as they're calling it,
is based on a gate array chip, a 20 megahertz CMOS gate array.
This is the same design that was done in 1987
in a more expensive machine, just upgraded with technology
to the faster clock rate.
After that is the SPARCstation--
I guess it's called 330.
I see.
The 33 from the 33 megahertz.
I was trying to figure out what that number was.
This is a full custom design.
This was done in cooperation with Cypress,
as Wayne alluded to.
This is the traditional approach to designing a microprocessor.
Solbourne, one of the companies in the SPARC international
group, has taken these chips and has built a four-way interleave
multiprocessor--
four processors in the same box--
using, I think, the 25 megahertz version of the gate array.
Bit is the ECL design that Wayne alluded to.
It's been announced that it's 80 megahertz clock.
That's 12 and 1/2 nanoseconds for you
computer historians, the same clock cycle time as the Cray-1.
This hasn't been announced in a Sun product yet.
And then Prisma, which is a startup
company, another startup company, they've announced--
and they've given talks on a 250 megahertz
4 nanosecond second clock version of the SPARC
architecture.
This is being built with lots of gallium arsenide chips.
And it's been announced in the paper
that Sun's trying to convince companies that
have traditionally built PC clones and people building
portable to build something that's
binary compatible to SPARC architecture,
so they can all run the same software.
So these machines-- computer family
means that the same binary runs on them all.
And that's true.
So right now, ignoring the thing--
right now, the things that Sun sells-- and it probably
will change over time-- there's about a factor of-- well, not
Sun, if I include Prisma here.
The range in price and performance
is about a factor of 50 in price and 21 in performance.
The same binary program runs all the way along.
OK.
So let me show you some of the die photos
and then some of the boards for these designs.
So this first die photo is of the good old gate array design.
And although it may be visible, the register file
is this dark area right here.
That's the register file.
And as you can see, that's not much of the chip.
The whole chip would include all the pad array and things
like that.
I think the ALU is over here.
Here's some of the control over--
I guess this is the instruction [INAUDIBLE] unit,
and the control down here.
So that gives you an idea of all the functions
that are involved in the gate array design.
And here's the same picture of the chip
without all the labels on it.
I think this one--
they make this run now at 25 megahertz.
The original SPARC machine was 16.67 megahertz.
This is the picture of the Cypress design.
And the register file has a different orientation.
But this is the register file right here.
And the ALU, I think, is right below this.
And I think this is the bus interface unit over here.
This is a much smaller die.
It's a custom design and is at a higher clock rate.
This is the ECL design, the single chip design.
You see the register file is larger.
It turns out, in this particular technology Bit has,
the RAM cells aren't as dense as they are in the CMOS design.
And the next section is all the arithmetic and logic units.
And then control is laid out over here.
This chip has 125,000 transistors and is very likely
the largest single chip ECL design, at least logic chip,
that's ever been built.
So you've seen the die photographs.
When they're put into the package,
they look something like this.
Those two chips are actually of historical interest,
in that they're the second SPARC chips ever made.
Let me then show you the inside of the chip
bonded against the pads for the Bipolar or ECL
that I just talked about.
So I think you may be able to see that this is the Bipolar
design.
You can see the registrar file on the left-hand side and all
the pins around it.
So this is the package part, 125,000 transistors,
the whole chip running at 12 and 1/2 nanosecond clock cycle
time.
This is a type of perhaps forerunner
of the RISC super microprocessors I'll
mention again in my last slide.
Boards containing the chips that I was just talking about.
You can see those three boards here.
The smaller board refers to the 20 megahertz version
that's in the SPARCstation 1.
The board next to it contains the 33 megahertz version,
the custom chip design.
And over here is a prototype board
running 70 to 80 megahertz.
You can see, just from this perspective,
that the advantage of the slower clock rate
is it allows them to do more highly integrated chips
and have a considerably smaller board design.
This is no bigger than a sheet of notebook paper.
And the others are quite a bit bigger than that.
So let me focus first on this small board that's
in the SPARCstation and identify some of the components.
So in this lower corner of the board,
this is the energy in a chip, which
is this gate array that comes from LSI Logic or Fujitsu.
Unfortunately, this board doesn't have the floating point
chip.
The gate array would be right next to it.
Over here is the cache controller.
And the cache data RAMs are these eight chips.
The cash tag RAMs are those five chips over there.
If we move back, you can see there's
a couple of more gate arrays.
This is the memory management unit.
Here's the DMA chip.
This happens to be the SCSI controller.
Over to the right are the SIM modules.
These SIM modules will stand up.
There's room for 16 of these SIM modules,
which can contain up to 4 megabytes of memory per module
or 64 megabytes on this notebook-sized sheet of paper.
There's actually only 50 chips on this board
using a lot of high integration.
This is actually fewer chips than is in the Macintosh,
for example.
So now, let's go from the small board
to the 33 megahertz design.
This is the board that's based on the 33 megahertz
version, which goes in the SPARCstation 33-0, 330.
Here is the Cypress chip.
It's the custom design.
Next to it is a controller for the floating point, and then
a TI floating point chip.
As we zoom back and see more of the board,
this is the cache controller logic over here.
And the cache chips are nearby.
What's interesting about this design
is that they have a cache strictly
for I/O, which more or less doubles the I/O performance
compared to previous systems without such a cache
and these controllers and these two gate array chips.
Let's go to the final board design next.
Here is the board that contains the ECL chip that I just talked
about earlier in the slide.
I can show the example of the die.
Here is the package that I showed you.
Here's the energy unit.
Next to it is the cache controller unit.
Over here are the registers that are for the floating point
registers, not the energy register file, not the register
windows, but just the 32 32-bit registers for the floating
point unit.
Here is the multiplier.
And here's the floating point adder,
floating point multiplier.
Here are the bus interface units.
Now, what's interesting-- you can't
see from this perspective.
I'll change in a minute.
But these all have heavy metal hats on it
to remove the heat from the chips.
This runs at about 20 watts.
This is around 18.
And the rest of the chips, these ECL chips,
run at about 15 watts.
You'll be able to see the hats as I turn this sideways.
Maybe you can zoom in.
OK.
So there needs to be greater spacing on this board,
as you can see, to contain these heatsinks on the top.
A single board, 70-80 megahertz in this prototype,
machine running close to the speeds of the Cray-1.
So now, I've talked about some of the differences in the SPARC
architectures, where the ideas came from, the technical ideas.
Let me talk about historically where
were these ideas developed.
The first RISC machine was developed at IBM
in the Yorktown division, the IBM [INAUDIBLE]..
This was actually a 24-bit ECL minicomputer led
by John Koch and George Radin.
I think the particular emphasis of that group
was to push the compiler technology.
It turned out that, for the compiler technology,
a fairly simple architecture was a better match for the compiler
technology they were pushing.
Their emphasis was on a subset of PLI1 that they call PLI.8.
They invented a custom operating system.
And their comparisons were always
against the IBM 370 family machines, quite naturally.
The RISC research at Berkeley, which I was involved with,
led to the first two RISC microprocessors.
They were 32-bit microprocessors.
And as I mentioned earlier, the emphasis
was trying to come up with an architecture
to track the rapid changes in VLSI.
And we also gave these family of machines their name.
The emphasis there was on C and Unix running on RISC machines.
And the comparisons were against the VAX and the 68000.
Professor Hennessy at Stanford University
led another RISC effort.
They built the third RISC microprocessor
in pushing compiler technology and trying to track VLSI.
And the emphasis was in Pascal and typical comparisons
against PDP-10.
But I think from a longer term historical perspective that
precedes all of these designs--
and that goes back to Seymour Cray and his classic CDC-6600
and later in his Cray-1 machine.
You can see the same principles, in my perspective, applied.
Now, if you look at--
if you try and find Seymour Cray give a talk, first of all,
go see it.
He does these about once a decade, as far as I can tell.
So I happen to be fumbling through the video library
at Berkeley and find out we had a taping of Seymour Cray
right before the announcement of the Cray-1.
Lawrence Livermore, which always buys the first model
of the supercomputers, I guess could use that against him
to make him give a public talk.
And what this quote is on the slide
is from part of that talk.
And this is, I think, the year before the Cray-1.
So he said, registers-- he was referring to the 6600
when he was talking about it.
Registers made the instructions very simple.
And that thought is still with me
and is very present in the machine I am designing now,
the Cray-1.
That is somewhat unique.
What's left off the slide, he talks
about most machines have very elaborate instructions and more
memory accesses.
Then he concludes with simplicity, I guess,
is a way of saying it.
I am all for simplicity.
If it's very complicated, I can't understand it.
OK.
So what happened to all this research?
Well, it turned out each of those research projects
led to commercial products.
All of them added floating point to the simple integer model.
The IBM 801 led to the IBM RT PC.
But it turned out that was a brand new design.
Or it was a heavily changed design.
They cut the number of registers from 32 to 16.
They introduced 16-bit instructions
and even microcode in that design.
So that was a lot of changes.
The SPARC design this tape's about
is very close to the RISC design.
I'll talk about how it was extended,
but floating point and this LISP support or Smalltalk support.
At Stanford, the MIPS--
Stanford led-- in fact, the name is the name of the company.
But it was really a brand new instruction set design.
Having 2x the number of registers,
having single size instructions, some people
have said that the MIPS design is
closer to the Berkeley design than it
was to the Stanford design.
But I certainly wouldn't say that about my good friend John
Hennesy.
All right.
So there's this work done at Berkeley.
What happened at Sun?
Well, as Wayne mentioned, Sun was a pretty small company
when it decided on this fairly bold venture
as to no longer rely exclusively on this giant semiconductor
house, but to go off on their own.
Starting with the RISC instruction set,
a team of operating system people,
compiler people, and architects and hardware designers
developed the SPARC instruction set.
The emphasis was on simplicity because the importance
of getting this thing to market, the resources
available in a company-- a $30 million 200 person
company-- wasn't that great.
And it needed to be scalable to new technologies.
That was another reason to keep it simple.
And so as a result, the 1987 gate array,
the first time a microprocessor has ever
been built as a gate array, was faster than the custom designs
from Intel or Motorola.
Now, let me spend some time talking a little bit
about the future of design.
So if you get nothing else from this tape,
I'm going to try and burn into your memory
this performance equation that you're trying to minimize
in getting higher performance.
So this slide is about higher performance.
Well, we're going to try and improve the clock cycle
time-- all the RISC machines are--
by going to new technologies.
There's already these custom ECL chips being developed
by Sun and other companies.
There's a lot of interest in the BICMOS, combination Bipolar
and CMOS designs, and interest as well in gallium arsenide
designs, like I mentioned.
And this is all point at the fetch clock cycle time.
The higher integration of trying to get the caches, the memory
management unit, and the floating point
all on the same dye--
this is going to obviously lower costs,
but also allows a faster clock cycle time
because they all fit together.
As you can see on the monitor, what I'm talking about
is combining the integer chip, the floating point
chip, the cache control chip, all of the data cache RAMs,
the tag RAMs, the memory management unit, and--
who knows-- maybe even the DMA, all of those chips into one
die.
That's going to reduce clearly the board area.
And by making things smaller, maybe it'll
have a little faster cycle time.
The area that's probably most novel from a computer
architecture perspective is what's
been called superscalar design.
Rather than fetching one instruction every clock cycle,
the RISC machines are headed towards multiple instructions
per clock cycle, two or three so that if you're
trying to execute two at the same time,
you're going to lower the CPI.
In fact, you're going to lower the CPI below 1 to try
and minimize this formula.
And of course, there's going to be continued effort
on trying to use better technology, better algorithms
to improve compilers so you can lower the instruction count.
So that's, for me, the future direction,
in terms of performance improvements and cost
improvements.
Now, the big limit to any computer architecture
is the size of its address.
The RISC machines came out with 32-bit architectures.
Many people, including Gordon Bell
talked about how the only mistake
that you can't recover from in computer design
is the address size.
So in fact, computer designers have used the addresses
as an excuse to redesign their instruction sets.
The RISC machines at 32 bits are pretty close to those limits.
And so I would expect, in the next few years,
we're going to see proposals for much larger than 32
bits of addressing in probably all computers, not just RISC
designs.
So for my final slide, let me roll the dice here and try
and describe the future under the possibility somebody
might even be seeing the tape at the time I'm predicting.
So let's say that, for some sizable fraction
of the scientific community in the years
1993, 1996, that the hard of almost all
of these systems in this community
is going to be a RISC supermicroprocessor, millions
of transistors on one chip implementing
a RISC-style architecture.
At the low end is the workstation
or the desktop, that you have a single one of these devices
with a fairly simple memory system trying
to get the cost down.
The next step up, the file server
or time-share minicomputer, will see a few of these RISC
supermicroprocessors with a much better memory
system and perhaps a much better I/O system as well.
And at the high end could be the supercomputers with many--
with many maybe measured in thousands-- but many RISC
supermicroprocessors that are going
to have some kind of communication network
to allow them all talk together and a very much larger I/O
system.
Thank you very much.
Are there any questions?
Are there differences in the type
of applications that are suitable for the RISC
versus CIC processor?
And will that change over time?
The RISC machines seem to have spread out pretty widely.
One thing you mentioned in your question
is, well, the example of transaction processing.
Well, one of the leaders in transaction processing, Tandem,
has announced that they are going
to building a line of computers based around the RISC machine
architectures.
It looks like, for transaction processing, which
is something I'm learning something about,
because my current research is involved in higher performance
I/O and that's one of the areas we're looking at,
is it's kind of like operating systems.
It's the same types of instructions.
So from an instruction set perspective, higher
performance, lower cost is very attractive.
There doesn't seem to be anything there.
I think the one area that people believe
that there's some interest is in the traditional business data
processing dealing with the BCD encoding of data.
That's an area where there's still a lot of argument about
whether or not RISC machines are the right thing to do.
I know that the Hewlett-Packard precision architecture,
which was concerned about this, put some support--
but it's a very modest amount of support-- in for the business
data processing.
But I think it'll have to-- that's probably
the one area that's a toss up that you can get good arguments
both ways.
The rest of the areas, by examples of machines,
we seem to see people lining up.
The only other thing I'd say from that perspective,
in terms of what Wayne said once again,
in terms of a software developer's perspective,
is just the number of machines out there.
So even if it's a technically sound instruction set,
the reluctance of porting applications
is simply how many places can they sell the program.
And so that's why I think we'll see
the 8086 family live forever and the IBM 360 live forever, too.
Are the SPARC machines from the different vendors
going to execute the same binaries,
despite the differences in cache and register window size?
The answer is yes.
Now, the thing that was interesting to me
that I really didn't know about the binary compatibility
is it turns out, like every single company,
even though they're binary compatible,
the kernels of the operating systems
are different on all these companies.
I didn't know that.
And because the I/O's are somewhat different,
when you start it, it's somewhat different.
So even though the VAX and the IBM families
are binary compatible, there's some pieces of the operating
system that are different.
And that's true for the RISC machines as well.
There's some details of dealing with the I/O
system, or the buses, or the caches,
because the caches vary, where there'll
be a piece of the operating system that'll
have to be different for every single machine.
But that apparently is what people
call binary compatibility or user binary compatibility.
How do you see distributing processing power through memory
as the memory chips get denser?
There will be a bottleneck at the chip level.
I think, in this one area, the supercomputer designs,
when you're talking about lots of processors--
I think that's an area where it's possible
that, if you're talking about thousands
of processors and thousands of DRAMs
and it's enough of a volume, you might
see some real radical change somewhere down the line
where the processes are placed in the DRAM chips.
That might be a much more economical design.
Right now, that'd be very dangerous
because you're fighting against two strong forces--
a mass produced microprocessor and mass produced memory.
And that has strong economic advantages.
And if you can overcome the potential memory bottlenecks
with your design, you have tremendous economies of scale.
If, on the other hand, you're designing your own custom RAM
with your own custom memory, you're
in jeopardy of being left way behind the technology as well
as the cost performance.
But maybe down the line a little bit,
if you could cooperate with some semiconductor manufacturer
in making DRAM, you're able to put your microprocessor
on there where you have so many thousands of transistors.
There might be just this huge switch in these high-ends.
I think, in the low ends, I wouldn't
expect much of a change, at least
in the time frame on that slide.
Most RISC machines today run the Unix operating system.
Is there anything inherent in SPARC that would make it
unsuitable for other operating systems?
I don't know of anything that we did
in the instruction sets designed that were particularly
for Unix.
Unix enabled the RISC machines because it
was the first portable operating system.
It was all written in C. VMS, in contrast, for example,
or DOS, or OS 2, are all written in assembly language.
So they were an obstacle to RISC machines
because they couldn't be ported.
Unix was portable, which freed instruction set designers
from having to invent new instruction sets.
So the first person--
once that was possible, we were allowed
to change instruction sets and make some economic sense.
So I don't think any operating system written in a high level
language I think would work on any of these RISC processors.
[MUSIC PLAYING]