I had a Eureka! moment last night about MMU caching, but it all came tumbling down this morning.
My realization was that the Segment Descriptors are 8 bytes long, and that Page Descriptors are 4 bytes long. So, if we assume that the virtual address encodes the addresses of the SDs and PDs on word-aligned boundaries (and SDs and PDs are indeed word-aligned in memory), then you don’t need the bottom three bits for SD addresses, nor do you need the bottom two bits for PD addresses. Voila!
But this morning, I remembered two very important facts:
- The SSL field in the virtual address is an index into the table of SDs, not an address offset.
- Likewise, the PSL field is an index into the table of PDs, not an address offset.
From the WE32100 manual, here’s a pictorial representation of how an address is translated when using contiguous segments.
And here’s a concrete example. Immediately after the MMU is turned on in the 3B2/400 boot process, it translates the virtual address 0x40060f8c. Let’s break that down.
Addr: 0x40060f8c
Contiguous Segment Fields
-------------------------
SID: 0x1
SSL: 0x3
SOT: 0xf8c
The SSL, bits 17–29 of the address, is 3 (b0000000000011
). This is an
index into a table, so to find SD number 3 in section 1, you take a base
address for section 1 and add (3 * 8), since each SD is eight bytes
long—two words.
So now I’m right back at square one. How does caching work if these are table offsets instead of address offsets? If the TAG field of an SD cache entry only holds bits 20–29, I don’t yet grok how it uniquely identifies an SD.
For further reading, you can check out The WE32100 Microprocessor Information Manual pages 308–315, and The WE32101 MMU Datasheet pages 164–175.
Comments