24 April, 2000

I'm not making this up

Suppose a program executes

• y = x * a + b

where x is stored at address 0x345205A8 or binary 00110100010100100000010110101000.

Look in the L1 cache

Cache structure

• cache is 16k bytes
• there are 512 entries
• each cache entry is 32 bytes
  • 5 bits are required to address 32 bytes
  • 27 bits remain for the tag

Cache action

• divide address into tag (27 bits) and offset (5 bits)
  • tag = 001101000101001000000101101
  • offset = 01000
• look for the tag in the cache
• if found
  • retrive the 16 bytes of data
  • use offset to return appropriate 4 bytes of the 16
• if not found
  • look in L2, L3, .... caches

N-way set associative

Most P6 caches are 4-way set associative.

• 512 entries
• 4 entries in each set
• therefore, 128 sets
• covering 9 of the 27 "tag" bits
• divide address into tag (18 bits), set (9 bits), and offset (5 bits)
  • tag = 001101000101001000
  • set = 000101101
  • offset = 01000

Look in the L2 cache

Same idea as the L1 cache.

If address is not in any cache, go the RAM!

Virtual address

Many programs could be using the same address 345205A8.

from Overview of the Protected Mode Operation of the Intel Architecture by Steve Gorman.

Address translation

Compute the page frame as CR3[105][288]

But if CR3[105][288] is "empty", the page must be read in from the disk. This should be an extremely rare occurence.

How about another cache

1 lookup in the page directory + 1 lookup in the page table + 1 access to RAM is two memory accesses too many.

Look up the page number in the TLB. If there, use it. If not there, go to the page tables and add new lookup into the TLB. Cache misses should be rare! Try the command vmstat on your favorite Unix computer.

Out-of-order execution

• Install me first
• Optimizing for Pentium(R) II and Pentium Pro Processors
• Pentium Pro Processor Microarchitecture overview

branch prediction

multiple issue

multimedia extensions

multi-processing