From: mash@mash.wpd.sgi.com (John R. Mashey)
Newsgroups: comp.arch
Subject: Re: Roger Ross... [really: why there may not be anything after micros]
Date: 1 Oct 92 00:59:21 GMT
Organization: Silicon Graphics, Inc.

In article <BvEro0.9ny@metaflow.com>, rschnapp@metaflow.com (Russ Schnapp)
writes:
|> In article <1671@idacrd.UUCP>, desj@ccr-p.ida.org (David desJardins)
|> writes:
|> |> John R. Mashey <mash@mash.wpd.sgi.com> writes:
|> |> > Since there may not be anything *after* microprocessors, maybe
|> we'll
|> |> > have learned from our previous sins.
 
|> |> I can't tell if this is a joke.  You aren't seriously suggesting
|> that
|> |> modern microprocessor design incorporates all of the design
|> principles
|> |> that will be needed until the end of time??

Of course it's not a joke; it would have a :-) after it if it were.
|> |> I can just imagine those computer designers in the year 2100 or so
|> |> saying, "Yeah, single instruction streams with superscalar
|> execution,
|> |> that's the ticket."  Not.
|> |> 
|> |> I would say that even suggesting that this is a possibility is just
|> |> about the most arrogant thing I have ever heard.
You must not know very many people in the computer business ...

|> Lighten up!  There's plenty of truly arrogant statements around, if
|> you're
|> really looking for them.  This one isn't one of them:
|> 
|>   1) John is talking about *classifications* of processor *scale*.
|>      There was no implication that we have invented everything that
|>      we will ever need. 
\|>   2) ...and even if you did believe that was his implication, there
|>      is always the equivocation (e.g., "Since there _may not be_")
Yes, exactly ...however, if one person misinterpreted it, it may not have
been written clearly enough, so let me expand on the topic a little.

1) There were mainframes, and they had certain Instruction Set
Architectures,
system interfaces, bus sizes, etc.  Some popular ones had wordsizes of
32, 36, 48, and 64 bits.  (1960s)

2) As minicomputers/superminis got built and popular, the available
technology tended to force competitive lower cost designs to:
	a) Have shorter word sizes, such as 12, 16, or 32.
	b) Simplify by reducing address sizes actually supported,
	or leaving instructions out, or simplifying the I/O structure, etc.
	Some of these are invisible to the application, but some aren't.
	Consider that the most cost-effective S/360 for a while, was the
	360/44, built to compete with some of the minis, and omitted
	various instructions.  Consider the Interdata 8/32s, which "felt"
	somewhat like S/360s, but omitted the more complex ops.
	c) In some cases, the cost of memory, and hardware in general, was
	such that you could make a substantially more cost-effective machine
	for the lower part of the product line by creating an ISA that was
	densely packed and gave up the ability to address as much memory.
	Example: PDP-11s.
	d) By the time we got VAXen & other 32-bit superminis, we now did
	have overlap betweeen the mainframes and minis in some ways, in terms
	of available technologies. Maybe if mainframe companies and
	supermini companies had mostly been the same companies, superminis
	would more have been a downward compatible extension of mainframes...
	but they weren't, so they weren't.
	(1960s, 70s).

3) When microprocessors came in, the same thing happened as in 2).  There
were different constraints, and architecures by different people, and
(mostly) neither mainframe nor supermini folks were thinking very hard
of doing microprocessor versions of their architectures, because:
	a) At the beginning (later 70s,early 80s), it wasn't very practical.
	b) Later on, for some, it was too late; the winodw closed down.
	c) For a few (MicroVAX is the most obvious example), it got to be
	possible, although hard work, and they had the resources to do it.

NOTE what happened, in both cases:
	There was oppurtunity, at the *low* end of the price range,
	for somebody to do something different, and establish an
	architecture, and make a business of it.  The oppurtunities
	arose because of changes in technology (hardware or software,
	or both) that opened the possibility of a major discontinuity,
	either in:
		a) Absolute price being lower, hence new markets.
		b) Better price/performance
	(I omit "c) best performance, no matter what the price", as that's the
	supercomputer track explicitly omitted from my list.)

4) That brings me to background of the comment in the original posting.
	a) Looking forward a few years, everybody sees more transistors /
	chip, and/or modest numbers of die packed onto substrates (you can
	argue whether you consider the latter microprocessors or not.
	I do, usually.)  A lot of people analyze what you can get on a
	chip in the next 10 years, and at least one idea is to put
	multiple CPUs on each chip.
	b) To hit lower price points, people aren't designing entire new
	CPUs, they are integrating more functions onto CPU cores.  Software
	is sufficiently more important than in "the old days" that people
	tend to use existing instruction sets, if at all possible.
	People have come to realize that it costs a lot to introduce a new
	one, and very few companies can afford to do it any more.
	c) Micros have mostly wiped out minis and superminis, in the sense
	that even supermini architectures in big boxses have their CPUs
	implemented as microprocessors, not as multiple boards of logic.
	d) Micros have *not* wiped out mainframes in the same way ...
	however, there are quite a few people building systems with micros
	that look more like high-end superminis or low-end mainframes in
	memory sizes, CPU performance, I/O transfer rates ... and working on
	I/O connectivity.	

5) Finally, the comment itself:  
	
|> |> > Since there may not be anything *after* microprocessors, maybe
|> we'll
|> |> > have learned from our previous sins.
	Maybe some technology will emerge that:
		a) Can competitively replace the microprocessor, in the
		way the micro has replaced some of the other implementations.
	AND	b) Has a good reason to prefer different instruction sets
		(there is always strong impetus to be able to run existing
		code).
	AND	c) Will be done by people who haven't been thru this, and
		hence would make the same mistakes the 4th round.
	THEN we'll get something like a 256-bit address system that keeps
	the bits on electron spins :-) where the first system doesn't
	check the high 16 bits...

	As it stands, I don't know what technology that might be, but it is
	preferable to say "may not" rather than "will not".
	1) For example, maybe photonic computers make it, and have some good
	reason to be different ... although, so far, they look expensive,
	and so are likely to be done by companies who've done it before,
	but it's possible somebody else will do it.
	2) Maybe, in going to 64-bits, we discover the old instruction sets
	just don't hack it, and everything should be redone from scratch ...
	we already know the answer to that one. [NO]
	3) Maybe, in going to 128 bits ... every must be redone ...
	maybe [since some of the tricks going 32->64, in practice, aren't
	as convenient].  I'm sure I'll be retired by then...  (32 new bits,
	at 2 bits every 3 years is 3*32/2 = 48 = year 2040 , unless there's some
	real surprise in fast-RAM technology lurking around.)
	4) Maybe there's something with fuzzy logic, or neural nets, or
	really different requirements for better parallelism that cause
	you to do something that doesn't look like a microproicessor,
	but can replace it.
So anything *might* happen ... but it probably won't, at least not soon. 
	
A good source of discussion on technology evolution is the COMPUTER
HARDWARE;
A DEC VIEW OF HARDWARE SYSTEMS DESIGN, Digital Press, 1978, chapters 1 &
2;
although a bit old now, there is still good discussion of evolutionary
patterns.


-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA
94043