MIPS MIPS32 74K Series, Руководство по программированию

Страница: 38 / 156

3.4 Caches
Programming the MIPS32® 74K™ Core Family, Revision 02.14 38
execution (it combines a D-cache writeback with an I-cache invalidate). You should use it in preference to the tradi-
tional alternative of a D-cache writeback followed by an I-cache invalidate.
synci
does nothing to an L2 cache — the L2 cache is unified, and there’s no need to do anything special there to
make data visible for instruction fetch.
3.4.9 Cache aliases
The 74K has L1 caches which are virtually indexed but physically tagged. Since it’s quite routine to have multiple
virtual mappings of the same physical data, it’s possible for such a cache to end up with two copies of the same data.
That becomes troublesome:
• When you want to write the data: if a line is stored in two places, you’ll only update one of them and some data
will be lost (at least, there’s a 50% chance it will be lost!) This is obviously disastrous: systems generally work
hard to avoid aliases in the D-cache.
• When you want to invalidate the line in the cache: there’s a danger you might invalidate one copy but not the
other. This (more subtle) problem can affect the I-cache too.
It can be worked around. There’s no problem for different virtual mappings which generate the same cache index;
those lines will all compete for the 4 ways at that index, and then be correctly identified through the physical tag.
The 74K CPU’s smallest page size is 4Kbytes, that’s 2
12
bytes. The paged memory translation means that the low 12
bits of a virtual address is always reproduced in the physical address. Since a 16Kbyte, 4-way set-associative, cache
gets its index from the low 12 bits of the address, the 16Kbyte cache is alias-free. In general, you can’t get aliases if
each cache “way” is no larger than the page size.
In 32Kbyte and 64Kbyte caches, one or two top bits used for the index are not necessarily the same as the correspond-
ing bits of the physical address, and aliases are possible. The value of the one or two critical virtual address bits is
sometimes called the page color.
It’s possible for software to avoid aliases if it can ensure that where multiple virtual mappings to a physical page exist,
they all have the same color. An OS can do that by enforcing virtual-memory alignment rules (to at least a 16Kbyte
boundary) for shareable regions. It turns out this is practicable over a large range of OS activities: sharing code and
libraries, and deliberate interprocess shared memory. It is not so easy to do in other circumstances, particularly when
pages to be mapped start their life as buffers for some disk or network operation
9
...
So the 74K contains logic to make a 32Kbyte or 64Kbyte D-cache alias-free (effectively one or two index bits are
from the physical address, and used late in the cache access process to maintain performance). This logic is a build
option, and
Config7[AR] flag should read 1 if your was built to have an alias-free D-cache.
A 32Kbyte or 64Kbyte I-cache is subject to aliases. It’s not immediately obvious why this matters; you certainly can’t
end up losing writes, as you might in an alias-prone D-cache. But I-cache aliases can lead to unexpected events when
you deliberately invalidate some cache content using the
cache
instruction. An invalidation directed at one virtual
address translated to a particular physical line may leave an undesirable valid copy of the same physical data indexed
by a virtual alias of a different color. To solve this, some 74K s are built to strengthen hit-type I-cache invalidate
instructions (those include hit-type
cache
instructions and the
synci
instruction), so as to guarantee that no copy of
the addressed physical line remains in the cache. This facility is available if the Config7[IAR] bit reads 1; but if it’s
9. There’s a fair amount of rather ugly code in the MIPS Linux kernel to work around aliases. D-cache aliases (in particular) are
dealt with at the cost of quite a large number of extra invalidate operations.