Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 UW 5/3/83; site uw-june
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!vax135!cornell!uw-beaver!uw-june!trow
From: trow@uw-june (Jay Trow)
Newsgroups: net.arch
Subject: Re: 68020 Performance Revisited after reading IEEE Micro
Message-ID: <1925@uw-june>
Date: Sun, 28-Oct-84 20:47:58 EST
Article-I.D.: uw-june.1925
Posted: Sun Oct 28 20:47:58 1984
Date-Received: Tue, 30-Oct-84 00:32:37 EST
References: <4021@decwrl.UUCP>
Reply-To: Deutsch@Xerox.arpa
Organization: U of Washington Computer Science
Lines: 31


Forwarded from 68000Interest^.wbst@Xerox.arpa

----------------------------------------------------------------

From: Deutsch@Xerox.arpa
Date: 28-Oct-84 16:53:10 PST
Subject: Re: 68020 Performance Revisited after reading IEEE Micro
To: ST68KImplementors^, 68000Interest^.wbst

Falcone is setting up something of a "straw man" here.  A conscientious
68020 design MUST use a data cache, and the data cache keys must be
VIRTUAL addresses.  Building a data cache that can cycle in 180 ns is
not a big deal.  Furthermore, a data cache will greatly reduce the bus
load imposed by the processor.

As for MIPS, my own analyses of the 68020 assume the instruction cache
is NEVER valid, except for very small loops, and I still get a figure on
the order of 2.5 (68000) MIPS for a 16.67 MHz 68020.  Rationale: a 10
MHz 68000/68010 executes about 0.7 MIPS and is almost completely memory-
limited.  (Applications of interest to me are NOT multiply/divide
intensive.)  A 68020 can fetch 32 bits in 180 ns instead of 800 ns.
Discounting a little for the fact that the 68020 isn't quite as memory-
limited, but fudging in the other direction for its ability to overlap
writes onto the following instruction, we get about 2.5 MIPS.

As Falcone says, it will be interesting to see what people actually
build around the 68020 and the MicroVAX.

----------------------------------------------------------------