Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site fortune.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!fortune!wall
From: wall@fortune.UUCP (Jim Wall)
Newsgroups: net.arch
Subject: Re: 68020 Performance Revisited after reading IEEE Micro
Message-ID: <4576@fortune.UUCP>
Date: Wed, 31-Oct-84 11:57:43 EST
Article-I.D.: fortune.4576
Posted: Wed Oct 31 11:57:43 1984
Date-Received: Thu, 1-Nov-84 04:59:10 EST
References: <4021@decwrl.UUCP> <1925@uw-june>
Organization: Fortune Systems, Redwood City, CA
Lines: 28

> 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 Falcone says, it will be interesting to see what people actually
> build around the 68020 and the MicroVAX.
> 
> ----------------------------------------------------------------

	I find it absurd to state that a XXXXX design MUST do YYYYYY.
Let's face it, you have no idea what the goals of anyone elses design
are.   Are we talking cost?  Multiple processors?  Single tasking?

	For some applications, a data cache will be benificial. For 
many other applications, the cost of the hardware, the space penalty,
the software time to purge on a context switch, may all preclude its
use. 

	This is where the system/hardware architects earn their money,
putting aside their own wishes and desires, and building what is 
required by the company.

						-Jim Wall

*** Being a determinist, all the above views are probably the results
of my early childhood.