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.