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

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

Memory map, caching, reads, writes and translation
51 Programming the MIPS32® 74K™ Core Family, Revision 02.14
damage from duplicates. Because of the need to avoid duplicates, even initialization code ought to use a different vir-
tual address for each invalid entry; it’s common practice to use “kseg0” virtual addresses for the initial all-invalid
entries.
Most MIPS Technologies cores protect themselves and you by taking a “machine check” exception if a TLB update
would have created a duplicate entry Some earlier MIPS Technologies cores suffer a machine check even if duplicate
entries are both invalid. That can happen when initializing. For example, when an OS is initializing the TLB it may
well re-use the same entries as already exist - perhaps the ROM monitor already initialized the TLB, and (derived
from the same source code) happened to use the same dummy addresses. If you do that, your second initialization run
will cause a machine check exception. The solution is for the initializing routine to check the TLB for a matching
entry (using the
tlbp
instruction) before each update.
For portability you should probably include the probe step in initialization routines: it’s not essential on the 74K core,
where we repeat that the machine check exception doesn’t happen.
3.8.6 TLB exception handlers — BadVaddr, Context, and ContextConfig registers
These three registers are provided mainly to simplify TLB refill handlers.
BadVAddr is a plain 32-bit register which holds the virtual address which caused the last address-related exception,
and is read-only. It is set for the following exception types only: Address error (AdEL or AdES), TLB/XTLB Refill,
TLB Invalid (TLBL, TLBS) and TLB Modified (for more on exception codes in
Cause[ExcCode] , see the notes to
Table B.5 .)
Context contains the useful mix of pre-programmed and borrowed-from- BadVAddr bits shown in Figure 3.14 .
Figure 3.14 Fields in the Context register when Config3
CTXTC
=0 and Config3
SM
=0
Context[PTEBase,BadVPN2]
: the
PTEBase
field is just software-writable and readable, with no hardware effect.
The
PTEBase
field is for use by the operating system and is normally written with a value that allows the operating
system to use the
Context
Register as a pointer into the current PTE array in memory. The field has no direct hardware
effect. The
BadVPN2
field is written by hardware on a TLB exception. It contains bits VA
31..13
of the virtual address
that caused the exception.
In a preferred scheme for software management of page tables,
PTEBase
can be set to the base address of a (suitably
aligned) page table in memory; then the
BadVPN2
number (see below) comes from the virtual address associated
with the exception—-it’s just bits from
BadVAddr
, repackaged. In this case the virtual address bits are shifted such
that each ascending 8Kbyte translation unit generates another step through a page table (assuming that each entry is
2 x 32-bit words in size — reasonable since you need to store at least the two candidate
EntryLo0-1
values in it).
An OS which can accept a page table in this format can contrive that in the time-critical simple TLB refill exception,
Context
automagically points to the right page table entry for the new translation.
This is a great idea, but modern OS’ tend not to use it — the demands of portability mean it’s too much of a stretch to
bend the page table information to fit this model.
31 23 22 4 3 0
PTEBase BadVPN2 0