Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!columbia!rutgers!caip!clyde!burl!codas!peora!pesnta!valid!markp From: markp@valid.UUCP (Mark P.) Newsgroups: net.micro.68k Subject: Re: 68030 data cache vs. IO devices Message-ID: <701@valid.UUCP> Date: Thu, 9-Oct-86 16:25:40 EDT Article-I.D.: valid.701 Posted: Thu Oct 9 16:25:40 1986 Date-Received: Fri, 10-Oct-86 05:15:00 EDT References: <1007@zog.cs.cmu.edu> Distribution: net Organization: Valid Logic, San Jose, CA Lines: 69 > 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?"