20 Sep 2026
CPU Microarchitecture
Some handwritten, cursorily commentated notes on Denis Bakhvalov's Performance Analysis and Tuning on Modern CPUs. Chapter 3.
Glossary
BTB: Branch Translation Buffer
DSB: Data stream buffer
MSROM : Microcode Sequencer
IDQ: Insutrction Decode Queue
PRF: Physical Register File
RAT: Register Alias Table
LSU: Load Store Unit
SQ: Super Queue
AGU: Address Generation Unit
PMU: Performance Monitoring Unit
Triple O
Pipelines, Data Hazards (RAW, WAR, WAW, former pipe the write directly to the read and WAR and WAW involve using different physical registers for the same logical register), OOO and ROBuffer retirement order, Reservation Station, Speculatino techniques, Superscalarity
Tomasulo's algorithm is a computer architecture hardware algorithm for dynamic scheduling of instructions that allows out-of-order execution and enables more efficient use of multiple execution units. It was developed by Robert Tomasulo at IBM in 1967 and was first implemented in the IBM System/360 Model 91's floating-point unit.[1] The major innovations of Tomasulo's algorithm include register renaming in hardware, reservation stations for all execution units, and a common data bus (CDB) on which computed values broadcast to all reservation stations that may need them. These developments allow for improved parallel execution of instructions that would otherwise stall under the use of scoreboarding or other earlier algorithms.
In concrete terms, it accomplishes this through three core mechanisms:Eliminates False Dependencies (WAR & WAW): By dynamically renaming architectural registers to internal hardware tags (reservation stations), subsequent instructions that overwrite registers can issue and run without waiting for earlier instructions to read the old values.Decouples Issue from Execution: Instructions are fetched and decoded sequentially into temporary holding buffers (Reservation Stations). As long as a station is free, instructions can issue even if their operands are not ready, preventing the front-end from stalling.Event-Driven Distributed Execution: Instead of waiting for a centralized register file, functional units execute as soon as all operands arrive. When a unit finishes, it broadcasts the result and its tag over the Common Data Bus (CDB); any reservation station waiting on that tag captures the value in parallel.
Core Hardware Stuff
SIMD, thread level parallelism, simultanaeous multi threading where each physical core is mapped to 2 logical cores both available for both processes. context switching due to sharing of L1, and L2 caches for both logical cores. each logical core has its own PC and registers. ROB and RS can be replicated or partitioned.
Caches (direct, associative, set-associative)
Write Policies
Memory Management Unit
Virtual Memory
Virtual Memory vs Physical Memory:
| Quantity | Formula |
|---|---|
| Number of physical frames | physical_memory_size / page_size |
| Number of virtual pages | virtual_address_space_size / page_size = 2^(address bits) / page_size |
Both divide a total size by the page size — that consistency is a good way to remember it. The only asymmetry is where the size comes from: physical memory size is a hardware fact (how much RAM you installed), while virtual address space size is an architectural fact (how many bits the CPU dedicates to addresses).
Also note you still need to finish getting the TLB entry before you can do your set associative cache check.
L1 is VIPT (Virtually indexed, physically tagged). L2 is PIPT (Physically indexed, physically tagged)
In the case of L1 cache, the block offset is small enough that it fits inside the page offset. This means this value can be used to find the cache (& % number_of_sets), and you can begin searching for the value
Page Walking
If STLB miss then a page walk is inevitable. But since
STLB miss → walk is triggered (unavoidable)
→ Step 1: read PTE at physical addr from Control Register 3 (CR3) → check L1/L2/L3 cache (physically addressed) → hit or DRAM
→ Step 2: read PTE at physical addr from Step 1's result → check cache → hit or DRAM
→ Step 3: same
→ Step 4: same → get final physical frame → translation complete → store in TLB/STLB
Golden Cove Microarchitecture
In the CPU frontend takes place in order. Once its out of here it enter OOO land
Actually: BPU has an intimate connection to the Program Counter because it reads the current PC and uses its BTB and directional predictors to add the next address to the Program Counter. This address stored in the PC is the address we use to find the instructions for iTLB and the L1 I cache (recall VIPT and PIPT).
write to fill buffer would glue data returned from either L2 or L3
Regarding streaming stores:
Normally, standard stores execute a Read-For-Ownership (RFO) request, fetching the entire cache line into L1/L2/L3 before modifying it. In contrast, streaming stores write into dedicated hardware Write-Combining Buffers (WC buffers) instead of pulling the line into cache. Once a full cache-line-sized chunk accumulates in the buffer, the processor pushes it directly to DRAM via a burst write. This technique eliminates unnecessary read traffic and prevents bulk data transfers from evicting useful cached working sets (cache pollution).
Streaming stores negate Read-For-Ownership (RFO) penalty.
In a normal store, if you write fewer bytes than a full cache line (e.g., 8 bytes on a 64-byte line), the CPU must first read the entire line from memory into the cache so the untouched bytes aren't lost.
Because streaming stores accumulate an entire 64-byte cache line in the write-combining buffer, the CPU guarantees that every byte will be overwritten. Consequently, the CPU never needs to fetch or read the original line from RAM first, saving precious memory bandwidth and removing a major read latency bottleneck.