Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!caip!think!mit-eddie!genrad!decvax!tektronix!uw-beaver!fluke!witters
From: witters@fluke.UUCP
Newsgroups: net.micro.68k
Subject: Re: 68030 data cache vs. IO devices
Message-ID: <1624@vax1.fluke.UUCP>
Date: Thu, 9-Oct-86 12:37:21 EDT
Article-I.D.: vax1.1624
Posted: Thu Oct  9 12:37:21 1986
Date-Received: Fri, 10-Oct-86 08:47:41 EDT
References: <1007@zog.cs.cmu.edu>
Distribution: net
Organization: John Fluke Mfg. Co., Inc., Everett, WA
Lines: 43

> Problem #1: if the chip decides to cache the value read from an
> I/O device status register, subsequent reads will not produce the
> current contents of that register.
> 

I've read the data sheet for the 68851 PMMU, and the PMMU in the 68030 is
supposed to be a stripped down version of the 68851.  The 68851's translation
descriptor for a page has a cache inhibit bit which, when set, will cause the
CLI* (Cache Load Inhibit) signal to be asserted when the page is accessed.
This signal can be used to inhibit the loading of an external data cache.  I
assume that the PMMU in the 68030 does the same thing internally with it's data
cache as the 68851 would do with an external data cache.

> Problem #2: the caches are apparently built to slurp in 16 bytes
> around any referenced location, on the theory that adjacent words
> may be required soon.  (While this makes good sense for instructions,
> I'm not at all sure that I buy it for data.)  This is *extremely
> dangerous* for I/O devices, as adjacent locations (1) may not exist,
> or (2) may have some active response to being read ... e.g. clearing
> an interrupt request.

Well, I would guess that the cache load inhibit bit would prevent this if it is
set.  I assume that it is the cache management hardware in the 68030 which does
the 'slurping', and not the CPU.  There isn't an analog to this in the
68020/68851 combination, so I can't speak with authority here.  Anyone from
Motorola care to comment?

Your second problem raises another question.  What happens if one of the 16
bytes crosses a page boundary?  Does the slurping stop at the page boundary,
or does the 68030 try to read from the next page?  Without thinking about it
deeply, it seems possible that this could cause problems if the next page isn't
mapped, or is mapped to an I/O device.

-- 
						I'm not a lumberjack
						and I'm not O.K.

						John Witters
						John Fluke Mfg. Co.  Inc.
						P.O.B. C9090 M/S 245F
						Everett, Washington  98206

						(206) 356-5274