Try to write the four bytes 0x00000000 to each of the following addresses, in user mode. In each case, explain what happens. You may get page faults, protection violations, TLB misses, TLB hits, cache misses, cache hits.... For each write that actually succeeds, give the new contents of the cache line that is modified.
25cfa3e0
Converting the VPN to binary, gives 0010 0101 1100 1111 1010. Breaking it up for the TLB lookup gives tag 0 0100 1011 1001 1111 and set 010. There is not a hit in the TLB.
Breaking up the VPN for directory and page table lookups and multiplying them by 4 gives 0010 0101 1100 (25c) and 0011 1110 1000 (3e8). The directory entry is at 6c27b25c, and contains 5f238026. Bit 0 contains 0, so there is a page fault.
1902af4c
Converting the VPN to binary gives 0001 1001 0000 0010 1010 Breaking it up for the TLB lookup gives tag 00011001000000101 and set 010; no hit in TLB..
Breaking it up for the directory and page lookups gives 0001 1001 0000 (190) and 0000 1010 1000 (0a8). The directory entry is at 6c27b190, and contains 2b937007. No page fault, no protection violation, so we continue. The page table entry is at 2b9370a8, and contains 35b75046. Bit 0 of the PTE contains a 0, so we have a page fault.
59b4f658
Converting the VPN to binary gives 0101 1001 1011 0100 1111. Breaking it up for the TLB lookup gives a tag of 0 1011 0011 0110 1001 111. No hit in the TLB.
Breaking it up for the directory and page table lookups and multiplying by 4 gives 0101 1001 1000 (598) and 1101 0011 1100 (b3c). The directory entry is at 6c27b598, and contains 235a8005. Bit 1 contains 0; the address is not writeable so we have a protection violation.
214768fc
Converting the VPN to binary gives 0010 0001 0100 0111 0110. Breaking it up for the TLB lookup gives a tag of 0 0100 0010 1000 1110 and set 110. No hit in the TLB
Breaking it up for the directory and page table lookups and multiplying by 4 gives 0010 0001 0100 (214) 0001 1101 1000 (1d8). The directory entry is at 6c27b214 and contains 72727027. No violations here so we go on to the page table; the PTE is at 717171d8 and contains 41bfd063. Bit 2 of the PTE is 0 so the address is not user-accessible; protection violation
2f965440
Converting the VPN to binary gives 0010 1111 1001 0110 0101. Breaking it up for the TLB lookup gives a tag of 0 0101 1111 0010 1100 and a set of 101. We have a hit! (the third translation in set 5). Unfortunately, bit 2 of the translation is a 0; the address is not user-accessible so we have a protection violation.
7d9de000
Converting the VPN to binary gives 0111 1101 1001 1101 1110. Breaking it up for the TLB lookup gives a tag of 0 1111 1011 0011 1011 and set 110. No hit in the TLB
Breaking it up for the directory and page table lookups and multiplying by four gives 0111 1101 1000 (7d8) and 0111 0111 1000 (778). The directory entry is at 6c27b7d8 and contains 68f86027. No faults here, so we go on to the PTE at 68f86778, which contains 30048027. Still no faults, so we have a valid translation! We'll be writing to address 30048000.
We need to enter the translation in the TLB. We'll put it in the unused slot in set 6; its LRU rank will be 0 and the others in the set will all be incremented. The translation will be entered as 30048067 (note bit 6 has been set to true) since the page will now be dirty).
Converting the physical address to binary gives us 0011 0000 0000 0100 1000 0000 0000 0000. Since our cache has a 32 byte line, it has a 5 bit offset. Since it is 8K it has 8K/32 = 256 lines. Since it's four-way set-associative, it has 256/4 = 64 sets, so it has a six bit index. Breaking the address up for a cache lookup gives a tag of 001100000000010010000, index 000000, offset 00000. We have a cache miss.
We need to bring the 32 bytes starting at 30048000 into the cache, putting it in any of the three empty lines in the set. The set becomes both valid and dirty, gets an LRU rank of 0 (so the one that was already in the cache gets an LRU rank of 1), and gets a tag of 060090.
07796d00
Converting the VPN to binary gives us 0000 0111 0111 1001 0110. Breaking it up for the TLB lookup gives a tag of 0 0000 1110 1111 0010 and set of 110. A hit! In the last translation in the set, with a translation of 791e9027. No faults, so our physical address is 791e9d00. We also need to change the translation to 791e9067 (since it's become dirty), and change its LRU rank to 0 (and increment the ranks of the other translations in the set).
Converting this to binary gives 0111 1001 0001 1110 1001 1101 0000 0000, and breaking it up for a cache lookup gives 011110010001111010011 101000 00000. Looking in set 28, we have a cache miss. So... same drill as the last cache miss: bring it into any of the empty lines, set it valid, set it dirty, set its LRU counter to 0 and the one that was already there to an LRU counter of 1.
426847c0
Converting the VPN to binary gives 0100 0010 0110 1000 0100. Breaking it up for a TLB lookup gives a tag of 0 1000 0100 1101 0000 and set of 100. A hit! The translation is 16e3a027, there are no violations, so the physical address is at 16e3a7c0. Once again, we have to update the translation and the LRU rank as before, too.
Converting the physical address to binary gives 0001 0110 1110 0011 1010 0111 1100 0000; breaking this up for the cache lookup gives tag 0 0010 1101 1100 0111 0100, index 111110, offset 00000. Another hit! Our new data goes in the cache line, replacing the string 81bafb6d. We also have to mark the line dirty and update the LRU ranks.
78408bfc
Converting the VPN to binary gives 0111 1000 0100 0000 1000. Breaking it up for the TLB lookup gives a tag of 0 1111 0000 1000 0001 and set 000. We have a tag match, but the entry in the TLB is not valid, so we have a TLB miss.
Breaking it up for the directory and page table lookups and multiplying by four gives 0111 1000 0100 (784) and 0000 0010 0000 (020). The directory entry is at 6c27b784 and contains 47b0b027. No faults here, so we go on to the PTE at 47b0b020, which contains 6329c067. No faults again, so our physical address is 6329cbfc.
We also have to bring the translation into the TLB, as on previous TLB misses that end up with successful translations.
Off to the cache. Breaking up the address for the cache lookup, we get tag 0 1100 0110 0101 0011 1001 index 011111 offset 11100, and a cache miss. Bring the line into any of the empty lines, mark it valid and dirty, set the tag, put the data in the block at the offset.