Translating an address is now simple, and we can amplify the
description above:
CPU generates a program address:
This might be an instruction fetch, a load, or store - and it's onewith
an address that does not lie in the special unmapped regions of the
MIPS address space.
The low 13 bits are separated off, and the resulting VPN2, together
with the current ASID (EntryHi(ASID)), is looked up in the TLB. The
match is affected by the the PageMask and by G fields of the various
TLB entries.
TLB matches key: If
there's no matching entry, we'll take a TLB refill exception. But where
there is a match, that entry is selected. Bit 12 of the virtual address
selects which physical-side half we'll use. The PFN from the TLB is
glued to the low-order bits of the program address to form a complete
physical address.
Valid? The V and D
bits are consulted. If it isn't valid, or a store is being attempted
with D unset, the CPU takes an exception. As with all translation
traps, the BadVAddr register will be filled with the offending program
address; as with any TLB exception, the TLB EntryHi register will be
preloaded with the VPN of the offending address.
The BadVPN2 fields of the convenience registers Context (and
XContext on 64-bit CPUs) will be preloaded (in part, as advertised)
with the appropriate bits of the virtual address we failed to translate
during a TLB refill exception. But the specification is less definite
about how those address fields behave in other exceptions. It's
probably a good idea to stick to BadVAddr in other exceptions.
Cached? If the C bit
is set, the CPU looks in the cache for a copy of the physical
location's data; if it isn't there, it will be fetched from memory and
a copy left in the cache. Where the C bit is clear, the CPU neither
looks in nor refills the cache.
Of course, the number of entries in the TLB permits you to translate
only a relatively small number of program addresses—a few hundred KB
worth. This is far from enough for most systems. The TLB is almost
always going to be used as a software-maintained cache for a much
larger set of translations.
When a program address lookup in the TLB fails, a TLB refill trap is
taken. (Should this be called a "TLB
miss" [which is what just happened] or a "TLB refill" [which is what
we're going to do to sort it out]? I'm afraid we probably use both
terms in MIPS documentation.)
System software has the following sequence of operations to perform:
1) It figures out whether
there is a correct translation; if not, the trap will invoke the
software that handles address errors.
2) If there is a correct
translation, it constructs a TLB entry that will implement it.
3) If the TLB is already
full (and it almost always is full in running systems), the software
selects an entry that can be discarded.
4) The software writes the
new entry into the TLB.
