Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!zog.cs.cmu.edu!tgl
From: tgl@zog.cs.cmu.edu (Tom Lane)
Newsgroups: net.micro.68k
Subject: 68030 data cache vs. IO devices
Message-ID: <1007@zog.cs.cmu.edu>
Date: Mon, 6-Oct-86 08:34:36 EDT
Article-I.D.: zog.1007
Posted: Mon Oct  6 08:34:36 1986
Date-Received: Tue, 7-Oct-86 23:27:00 EDT
Reply-To: tgl@zog.cs.cmu.edu (Tom Lane)
Distribution: net
Organization: Carnegie-Mellon University, CS/RI
Lines: 31
Keywords: Apparent incompatibility

I'm a little disturbed by the reports of the new 68030's on-chip
cache for data accesses.  I'm concerned about accesses to I/O devices,
which are (by necessity) memory-mapped in 68xxx machines.

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.

This problem also applies to shared variables in a multi-CPU, shared
memory machine (which is supposedly a design target for Motorola ...
remember TAS, CAS and them other funny instructions?)

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.

Now I assume that the 68030 group are not fools, and that they
thought about this problem.  What did they do about it?  Is there
a mechanism for keeping certain (ranges of?) addresses from being
cached?  How do they expect software to handle shared variables?

Looking forward to enlightenment...

				tom lane
-----
ARPA: lane@A.CS.CMU.EDU
UUCP: ...!seismo!a.cs.cmu.edu!lane