🚀 go-pugleaf

> 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

In a virtual memory system, the solution is easy.  The 68851 provided
a bit in the page descriptor called CI (cache inhibit).  When a reference
is made to a page with CI set, a pin CLI/ is asserted by the 68851,
indicating to an external data cache that it should bypass.  The 68030
MMU is said to be compatible with the 68851, so one assumes that a
similar (i.e. identical) arrangement exists.  What this means to a Unix
implementation is that, upon initialization of the I/O devices, these
bits must be selectively be set for the noncacheable areas of the memory
map.  Of course, it undoubtedly involves more, but I am not a wizard.

The solution is somewhat harder when you are not using virtual memory--
in essence you must surround the possibly offending accesses by instructions
to disable operation of the data cache.  This would be done by a bit
similar to the freeze-I-cache bit in the CACR (cache control register) of
the 68020.

Similar arguments apply to software semaphores-- i.e. they must be
either placed in a non-cacheable region of memory or accessed without
fear of intervention by the data cache.  Presumably, Motorola was
intelligent enough to force read-modify-write cycles (i.e. TAS/CAS) to
ALWAYS bypass cache, though.  Motorola appears to have ignored the cache
consistency issue, with no apparent support for external invalidations.
This will, of course, delight those who would exploit the 68030 in
multiprocessor shared-memory systems by the added gaggage which programming
requires.

You have brought out a very important point here, that the data cache is
undoubtedly the most severe source of potential incompatibility between
the 68030 and the 68020.  However, as most systems using it will use
virtual memory (due to its price placing it in that market), such
incompatibility will be hidden from the application level, and require
only changes to the kernel/device drivers.

Always glad to enlighten... :-)

	Mark Papamarcos
	Valid Logic Systems
	hplabs!ridge!valid!markp

"Have you hugged your Futurebus today?"