implementing multiple MC68040s as bus masters, shared data should be stored in write-
through pages. This procedure allows each processor to cache shared data for read
access while forcing a processor write to shared data to appear as an external write to
memory, which the other processors can snoop.
If shared data is stored in copyback pages, only one processor at a time can cache the
data since writes to copyback pages do not access the external bus. If a processor
accesses shared data cached by another processor, the slave can source the data to the
master without invalidating its own copy only if the transfer to the master is cache
inhibited. For the master processor to cache the data, it must force invalidation of the
slave processor’s copy of the data (by specifying mark invalid for the snoop operation),
and the memory controller must monitor the data transfer between the processors and
update memory with the transferred data. The memory update is required since the
master processor is unaware of the sourced data (valid data from memory or dirty data
from a snooping processor) and initially creates a valid cache line, losing dirty status if a
snooping processor supplies the data.
Coherency between the instruction cache and the data cache must be maintained in
software since the instruction cache does not monitor data accesses. Processor writes
that modify code segments (i.e., resulting from self-modifying code or from code executed
to load a new page from disk) access memory through the data memory unit. Because the
instruction cache does not monitor these data accesses, stale data occurs in the
instruction cache if the corresponding data in memory is modified. Invalidating instruction
cache lines before writing to the corresponding memory lines can prevent this coherency
problem, but only if the data cache line is in write-through mode and the page is marked
serialized. A cache coherency problem could arise if the data cache line is configured as
copyback and no serialization is done.
To fully support self-modifying code in any situation, it is imperative that a CPUSHA
instruction be executed before the execution of the first self-modified instruction. The
CPUSHA instruction has the effect of ensuring that there is no stale data in memory, the
pipeline is flushed, and instruction prefetches are repeated and taken from external
Another potential coherency problem exists due to the relationship between the cache
state information and the translation table descriptors. Because each cache line reflects
page state information, a page should be flushed from the cache before any of the page
attributes are changed. The presence of a valid or dirty cache line implicitly indicates that
accesses to the page containing the line are cachable. The presence of a dirty cache line
implies that the page is not write protected and that writes to the page are in copyback
mode. A system programming error occurs when page attributes are changed without
flushing the corresponding page from the cache, resulting in cache line states inconsistent
with their page definitions. Even with these inconsistencies, the cache is defined and
Terms of Use | Privacy Policy | DMCA Policy
2006-2020 Rsmanuals.com