Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!bagate!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: The 68050 - end of the 680x0? (was Re: The Amiga's Future)
Message-ID: <22515@cbmvax.commodore.com>
Date: 17 Jun 91 21:11:55 GMT
References: <5068@orbit.cts.com> <16647@darkstar.ucsc.edu> <	<1308@cbmger.UUCP> <28@ryptyde.UUCP> > <rkushner.6517@sycom.UUCP> <01dH!cmr@cs.psu.edu> <1991Jun10.072945.8821@neon.Stanford.EDU> <22365@cbmvax.commodore.com> <1991Jun13.003707.19785@neon.Stanford.EDU> <
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 68

In article <EACHUS.91Jun14181138@largo.mitre.org> eachus@largo.mitre.org (Robert I. Eachus) writes:
>In article <22393@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:

>   Anyway, looking at the Motorola track record, the '050 should be in the 
>   "evolutionary" category, which is tracked more on architectural grounds than
>   performance upgrades:

>	   68000,68010	16 bit
>	   68020,68030	32 bit
>	   68040,68050	Cool 32 bit

>    I don't know what Cool 32 bit is, but I see the splits slightly
>differently.

>    68000, 68010: 24(27)-bit address, 16-bit data
>    68020:        32(36)-bit address, 32-bit data
>    68030, 68040: 32(36)-bit address, 32-bit data with cache fill support
>    68050:        ???-bit address, 64(128-bit) data

If you see things that way, you're ignoring the underlying architecture, for
other than the 68050 (which we don't know about).

The 68020 and the 68030 are extremely similar.  The integration of the MMU 
made for a lower cost and high performance (package to package delays between
the '020 and '851 added a wait state to memory), but it didn't radically change
any of the underlying technology.  And 68030 synchronouy/burst mode as well was 
a very minor change, a simple enhancement of the basic 68020 asynchronous cycle
(eg, you make the external logic responsible for being synchronous and you get
to remove all internal synchronizers, and <poof>, it goes faster).

The 68040, on the other hand, is a whole new ball of wax.  The entire machine
architecture was revised.  Lots of instructions are hard-wired.  The pipeline
is amazingly more complex than on an '020/'030.  There are two MMUs, versus
a single one, and they are programmed differently (the '851 has a few more
instructions than the '030, but they're largely compatible with one another if
you stick to the common instructions; they are logically the same machine).
You went from direct mapped logical caching on the '020/'030 to four set
associative physical caching on the '040.  Even the '040's bus has been 
completely revised.

Really, the architectural difference between the '020/'851 and the '030 is
negligable, all the performance enhancements are simple evolutionary changes
(not to imply they were easy to do, but consider than it was only about a 
year from the time the '851 was shipping to the time we got '030 samples).
The '030 to '040 change was quite revolutionary.

>    The 68050 is of course my WAG, but the easiest way to pump more
>performance out of the architecture without increasing the clock would
>be to add more data lines.  (I'm sure the cache sizes will also
>increase, but the remaining advantage from that is in the noise.)

Of course.  But simply building an external 64 bit bus or larger cache onto
a 68040 architecture doesn't make an architecturally distinct processor.  It
could very well make a processor that goes two or three times faster, and it
could make that happen much sooner than going to some totally new architecture.
So that's a good thing.  And it makes lots of sense, you don't necessarily 
even figure out how to best use a new architecture in its first incarnation.
Also, it takes a Real Long Time to come up with a substantially new machine
architecture.  So, were I Motorola (or anyone else making similar decisions,
for that matter), I would do things much the way Motorola appears to be doing
them.  You build a new architecture, then upgrade it.  At the same time you're
working on that upgrade, you're starting a really advanced architecture.  That
way, even though your architectural improvements take N years to achieve, you
double your performance every N/2 years.
-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
	"This is my mistake.  Let me make it good." -R.E.M.