Architecture (ISA) is the software-visible contract — instructions, registers, memory model. Microarchitecture is the hardware implementation — pipelines, caches, branch predictors, ROB. Realization is the physical chip — process node, layout, voltage.

Apple's M-series and Qualcomm's Snapdragon both implement ARMv8 ISA but use entirely different microarchitectures and realizations. This separation is what lets binaries work across decades of chips.

CPU Time = Instruction Count × CPI × Clock Period

Instruction Count depends on ISA and compiler. CPI depends on microarchitecture — pipelining, hazards, cache misses, mispredictions. Clock Period depends on circuit design and process technology.

Likely follow-up: "What happens if you double pipeline depth?" Frequency rises (period drops), but every mispredict costs more cycles, so CPI goes up. The product may not improve. That's the Pentium 4 lesson.

The DSI separates compile-time work from run-time work. It's the design choice of "who finds the parallelism — compiler or hardware?"

VLIW pushes scheduling onto the compiler — works for predictable kernels (DSP), struggles with cache-miss-heavy code. OoO superscalar puts scheduling in hardware — handles dynamic events gracefully but burns transistors. Where you draw the DSI shapes the entire design.

Three walls hit simultaneously:

• Power wall: dynamic power scales with V²f. Past ~3–4 GHz, heat density becomes unmanageable in air-cooled systems.
• ILP wall: sustained ILP in real programs caps around 4–7 even with perfect speculation. More issue width yields diminishing returns.
• Memory wall: DRAM speeds didn't scale with CPU speeds. More frequency just meant more cycles waiting on memory.

Multicore sidestepped all three by exploiting thread-level parallelism instead.

They're reciprocals: IPC = 1/CPI. CPI is more natural for scalar processors where CPI ≥ 1. IPC is more natural for superscalar where IPC > 1 is the goal. Industry talks about IPC because "our IPC is 3.5" is more intuitive than "our CPI is 0.286."

If a fraction f of execution is sped up by factor s, total speedup is 1 / ((1-f) + f/s). The crucial insight: as s → ∞, speedup is bounded by 1/(1-f). The serial portion fundamentally caps parallel speedup.

Why it matters: it's why 64 cores don't make most desktop workloads 64× faster. Serial fractions (file I/O, single-threaded loops, lock contention) dominate real-world gains.

Less than it used to. Modern x86 (CISC) chips internally decode complex instructions into RISC-like uops. Modern ARM (RISC) has accumulated complex instructions for crypto, NEON, etc.

What still matters: encoding density (CISC variable-length hurts fetch bandwidth and complicates decode) and memory operand model (CISC mem-to-mem ops vs RISC load-store). These cause real microarchitectural differences even today — see the M-series's effortless 8-wide decode versus x86's complex multi-decoder front-end.

With infinite resources, perfect alias analysis, and perfect prediction: ILP of 4–7 for integer programs, 10–20+ for numeric/FP. With realistic hardware, sustained IPC is 1.5–3 in modern wide superscalars. This empirical limit is the reason multicore exists.

SPEC defines workload suites. SPECint covers integer-heavy applications (compilers, compression, AI search). SPECfp covers floating-point and scientific code (fluid dynamics, molecular modeling). Both report a geometric mean of speedups vs a reference machine.

Important nuance: SPECint stresses branch prediction and cache; SPECfp stresses memory bandwidth and FPU throughput. A processor optimized for one may not look great at the other.

Trap question — the right answer is "it depends on the baseline." If your CPI is already 0.5 (very wide superscalar), squeezing more ILP costs huge transistors for tiny gain. If your clock is already process-limited, going deeper hurts CPI.

A confident interview answer: "I'd profile first. If branch mispredictions dominate, attack CPI via better prediction. If the workload is memory-bound, invest in cache hierarchy. If it's compute-bound and CPI is near 1, only then consider frequency." Show you think in trade-offs, not absolutes.

Per-instruction latency is determined by total time through every stage. Pipelining doesn't reduce that — it actually adds a tiny bit (pipeline-register delay). Throughput rises because once the pipeline is full, you complete one instruction per cycle instead of one every N cycles. Classic latency-vs-bandwidth trade.

IF — fetch from I-cache using PC. ID — decode opcode, read register file, sign-extend immediate. EX — ALU op, or address compute for loads/stores, or branch comparison. MEM — D-cache access for loads/stores; pass-through for ALU ops. WB — write result to register file.

Bonus: register file is read in ID and written in WB. A back-to-back dependence requires forwarding from EX/MEM/WB back to ID-input or EX-input.

RAW — true data dependence. Consumer reads what producer wrote. WAR — younger instruction writes a register an older one still needs to read. WAW — two writes to the same register; program order must be preserved.

Strict in-order: only RAW exists. Instructions execute in program order, so the read happens before any later write. WAR and WAW emerge with OoO; register renaming makes them disappear.

A load's value is available only at the end of MEM. The instruction immediately after the load is in EX during the load's MEM cycle and needs the data at the start of EX. Forwarding can deliver from MEM-output to EX-input only one cycle later — so you need exactly one bubble between a load and its dependent consumer.

Compilers schedule unrelated instructions into that delay slot when possible.

The penalty equals the number of stages between fetch and branch resolution. In a 5-stage where branches resolve in EX (stage 3), penalty is 2 cycles of squashed instructions. In a 20-stage deep pipeline where branches may not resolve until stage 15+, penalty can be 15–20 cycles.

This is why deep pipelines need very accurate prediction. Pentium 4 had ~20-cycle mispredict penalty — its 95%+ predictor was essential, not optional.

The clock period must accommodate the slowest stage. If one stage takes 4 ns and others take 2 ns, the clock must be ≥4 ns and the fast stages sit idle for half the cycle.

Splitting the 4 ns stage into two 2 ns stages lets you clock at 2 ns. Pipeline depth goes up by one and frequency doubles for that critical path. Real designs spend significant effort identifying critical paths and re-balancing.

Forwarding routes the result of an in-flight instruction directly from a later stage's output back to an earlier stage's input, bypassing the register file. Physically: muxes in front of ALU operand inputs, with control logic detecting when a younger instruction's source register matches an in-flight instruction's destination.

Common forwarding paths in a 5-stage MIPS: EX/MEM → EX-input, MEM/WB → EX-input. Each path is a 32- or 64-bit bus plus comparator logic.

Structural hazard: two stages contend for the same hardware. Classic case: unified memory with one port — IF and MEM collide every cycle a load or store is in flight.

Harvard splits memory (or first-level cache) into separate instruction and data caches with separate ports. IF and MEM access different physical memories simultaneously. Modern CPUs use Harvard at L1 and unified at L2+.

A delayed branch defers its effect by one instruction. The "delay slot" — the instruction immediately after the branch — always executes regardless of outcome. The compiler tries to fill it with useful work.

It worked in early MIPS because the pipeline was shallow and one slot was enough. As pipelines deepened, you'd need 5, 10, 20 delay slots — impractical. Modern ISAs (ARMv8, RISC-V) abandoned delay slots for branch prediction.

Each pipeline register adds clocked flip-flops. More stages = more flops switching every cycle = more dynamic power (P ∝ C·V²·f). Plus, deeper pipelining usually pairs with higher frequency, multiplying power further.

Speculation overhead compounds it — squashed instructions still consumed energy in the front-end. Pentium 4's deep pipeline plus speculation was famously power-hungry. Core deliberately shortened the pipeline to recover power efficiency.

CPI = CPI_ideal + stalls_per_inst

For an in-order MIPS with forwarding: CPI_ideal = 1. Add: load-use stalls (load_freq × dep_consumer_rate × 1), branch mispredicts (branch_freq × mispredict_rate × penalty), cache misses (miss_rate × miss_penalty), structural hazards.

Example: 30% loads, 50% have a dependent next inst, 20% branches at 90% accuracy with 2-cycle penalty: CPI = 1 + (0.3 × 0.5 × 1) + (0.2 × 0.1 × 2) = 1 + 0.15 + 0.04 = 1.19.

An honest answer: depends on the workload bottleneck. The most universally impactful single feature is a branch predictor (a basic 2-bit BHT). Most workloads have ~20% branches; even a simple predictor brings accuracy from ~50% (always-not-taken) to ~85%+, which translates to substantial CPI improvement at 2-cycle mispredict penalty.

Bonus points: "After branch prediction, I'd add a non-blocking cache so loads don't stall the whole pipe on misses." Show layered thinking.

1. Compute virtual address in EX. 2. Look up TLB with virtual page number. On TLB miss, walk page table. 3. Use the resulting physical address to index L1 D-cache (or use VIPT — see next). 4. On L1 hit, return data; on miss, send request to L2. 5. On L2 miss, send to L3 (if present), then memory controller, then DRAM. 6. Data returns up the hierarchy, filling each level on the way back. 7. Forwarding paths deliver the value to the dependent instruction's EX input.

VIPT = Virtually Indexed, Physically Tagged. The cache index uses bits from the virtual address (so TLB lookup and cache index lookup happen in parallel — saves time), but the tag comparison uses the physical address (so aliasing is correct).

This works only if the index bits are entirely within the page offset (which is invariant under translation). Constraint: cache_size / associativity ≤ page_size. For 4 KB pages, an 8-way 32 KB cache fits (each way = 4 KB = page size).

Write-through: writes go to cache and next level on every store. Simpler coherence, but huge bandwidth on the lower level. Used in small L1 caches paired with write buffers, or where simplicity dominates.

Write-back: only updates cache; modified lines tagged dirty, written back on eviction. Massively reduces lower-level bandwidth. Cost: complex coherence and the dirty-bit machinery. Modern L1/L2/L3 are essentially all write-back.

5% miss rate sounds great, but miss penalty matters more. If L1 hit time is 4 cycles and L2 hit time is 15 cycles: AMAT = 0.95×4 + 0.05×15 = 4.55. That's 14% slower than perfect L1 — significant.

If those 5% cascade to DRAM (~250 cycles): AMAT = 4 + 0.05×250 = 16.5. That's 4× slower. Check L2/L3 hit rates and TLB miss rate too. The 95% number is meaningless without the miss-penalty distribution.

TLB caches recent virtual-to-physical page translations. Typically 64–2048 entries, often split ITLB/DTLB plus an L2 TLB. Hit: 1 cycle.

Miss: the MMU walks the page table. On x86 this is hardware-walked (4–5 memory accesses for a 4-level table); on MIPS/RISC-V it can be software-walked (the OS handles it). The walked PTE is inserted into the TLB. If the page isn't in physical memory at all, that's a page fault — a much heavier OS-level event.

A 4 KB TLB entry covers 4 KB. A 2 MB huge page covers 2 MB with the same single TLB entry — 512× more reach. For workloads with huge working sets (databases, JVMs, HPC), huge pages dramatically cut TLB miss rates.

Cost: internal fragmentation (tiny allocations consume 2 MB), more complex memory management, harder page sharing between processes. Linux's transparent huge pages enables them automatically when beneficial.

A small fully-associative buffer (typically 4–16 lines) holding recently evicted lines from a low-associativity cache. On a miss, check the victim cache before the next level. If found, swap the line back.

Effect: gives a direct-mapped cache much of the conflict-miss benefit of a higher-associativity cache, with minimal area overhead. Norm Jouppi's original 1990 paper. Less common today since L1 caches are 8-way associative anyway.

Programmed I/O: CPU repeatedly reads a status register. Wastes cycles, simple, predictable for low-bandwidth.

Interrupt-driven: device raises IRQ when data is ready. CPU does other work in between. Better utilization, but interrupt overhead can dominate at very high event rates.

DMA: dedicated controller copies data between device and memory without CPU. CPU sets up descriptor; DMA does the transfer; one interrupt at completion. Essential for high-bandwidth devices.

Each core has its own L1. If core 0 caches address X, then core 1 writes X, core 0's cache must reflect that change before reading X again. Cache coherence enforces this — typically MESI (Modified, Exclusive, Shared, Invalid) or extensions like MOESI.

The hardware tracks each line's state and uses bus snooping or directory protocols to invalidate or update other caches' copies. Without coherence, parallel programs see stale data and break. (Detailed in Ch 11.)

Hit rate increases (capacity misses drop, conflict misses may drop). But hit time increases — bigger arrays have longer access paths, more decoders, larger tag arrays. May force a slower clock or an extra access cycle.

Empirically, doubling L1 from 32 KB to 64 KB might give +1–2% hit rate but +1 cycle access time. For L1-hit-bound code, this can be a net loss. Modern designers pick L1 size carefully balanced against critical path. This is why L1 hovered at 32 KB for two decades despite Moore's Law — though Apple has since pushed to 192 KB by clever timing.

Inclusive: L2 contains every line in L1. Simplifies coherence (only need to snoop L2). Wastes capacity (L1 contents duplicated). Used by Intel for many years.

Exclusive: a line is in L1 OR L2, never both. Maximum effective capacity. Coherence is harder. Used by AMD historically.

Non-inclusive (NINE): no enforced relationship. Lines may be in both, neither, or one. Compromise. Used by modern Intel after Skylake-X for L2/L3.

Prefetching speculatively fetches cache lines before they're requested. Hardware prefetchers detect patterns (sequential, strided, indirect). Software prefetching uses explicit instructions inserted by the compiler.

Wins: hides latency for predictable patterns. Costs: cache pollution (prefetched lines evict useful ones), bandwidth waste (mispredicted prefetches consume bandwidth), and power. Aggressive prefetchers help streaming benchmarks but can hurt random-access workloads. Tuning the predictor's confidence threshold is where most engineering happens.

In-order superscalar issues multiple instructions per cycle but maintains strict program order at every stage. If instruction N stalls, N+1 cannot pass it. Examples: ARM Cortex-A53, original Pentium.

Out-of-order superscalar can execute instructions in any order their dependencies allow. A stalled load doesn't block independent younger instructions. Hardware re-imposes program order at retirement to keep exceptions precise. Far higher IPC but vastly more complex. Examples: Intel Core, Apple M-series, AMD Zen.

Three reasons all rooted in correctness:

1. Precise exceptions: when instruction N takes an exception, instructions N+1, N+2 already executed must be undone. The ROB tracks them in program order so we can squash everything younger than N.
2. Speculation recovery: on a branch misprediction, all instructions younger than the branch must be squashed. The ROB defines "younger."
3. In-order retirement: stores must commit to memory in program order; register writes must happen in program order. The ROB enforces this.

Different texts use these differently — be ready to clarify. The book's convention (and a common one):

Dispatch: moving an instruction from the in-order front-end into the OoO back-end (allocating a ROB entry, putting it in a reservation station / issue queue). Done in program order.

Issue: sending a ready instruction from the issue queue to a functional unit. Done out of order, based on operand readiness.

Some texts (and Intel docs) use "issue" for what the book calls "dispatch." Always ask the interviewer their convention.

WAR and WAW hazards aren't real data dependences — they're name dependences caused by the small number of architectural registers. add R1,...; add R1,... creates a fake WAW because both write R1, even though the values are unrelated.

Renaming maps each write to a fresh physical register. The two adds now write different physical registers — no false dependence. This unlocks parallelism hidden by ISA register pressure. (Mechanism in Ch 5.)

Front-end: in-order pipeline stages from fetch through dispatch. Concerned with delivering instructions: branch prediction, fetch, decode, rename. Throughput here caps the whole CPU.

Back-end: out-of-order portion — issue queue, functional units, ROB, retirement. Concerned with executing and committing instructions correctly. The back-end can have more capacity than the front-end (an 8-wide back-end can execute 8 uops/cycle even if the front-end only delivers 6, as long as the issue queue is non-empty).

The maximum number of instructions that can pass through a critical pipeline stage per cycle (decode, rename, issue-to-EX). Often quoted as the dispatch or rename width.

Limits: register file ports scale roughly as O(width²) in area (each ALU needs 2 read ports + 1 write; forwarding network grows similarly). Wakeup-select logic in the issue queue is timing-critical and grows with width and queue size. Issue port utilization drops with width because real programs lack the ILP. So 6–8 wide is the sweet spot in 2025.

2024–2025 designs: Intel Skylake ~224, Apple M1 ~630, Apple M3/M4 ~600+, AMD Zen 4 ~320, Zen 5 ~448. The ROB defines the "instruction window" — how far ahead the CPU can look for independent work to overlap with stalls.

A larger ROB hides longer-latency events (DRAM misses ~300 cycles). But the ROB is a CAM-like structure with significant area, power, and timing-critical paths for allocation and retirement. Doubling ROB size doesn't double IPC — diminishing returns again.

Suppose 4-byte instructions, so a cache line holds 16 instructions. The fetch unit reads the whole line, then uses the PC's low bits to extract a contiguous group of up to 4 instructions starting at the PC. If a branch is encountered before the 4th, fetch stops at the branch and the predicted target's first instructions come next cycle (potentially from a different cache line — needing a second fetch port or a 1-cycle stall).

Modern designs use a branch target buffer (BTB) to predict the target during fetch, and may employ a uop cache to deliver decoded sequences regardless of branch location.

A uop cache stores already-decoded micro-operations indexed by instruction address. On a hit, fetch+decode is bypassed entirely — uops flow directly into rename. Saves both latency and power (decoders are expensive in x86 due to variable-length CISC instructions).

For tight loops that fit in the uop cache (~1500 entries on Sandy Bridge, 4K+ on later cores), the front-end runs much faster and the legacy decoders can be clock-gated. Same idea Pentium 4's trace cache attempted, but more conservatively scoped — and it actually worked.

They have to be balanced. ROB size sets the instruction window. PRF size must hold all in-flight architectural and speculative writes — typically ROB_size + arch_reg_count. Issue width sets how many can move per cycle, but if the queue/ROB is undersized you stall front-end before the window fills.

A poorly balanced design (8-wide front-end with a 64-entry ROB) leaves the back-end starved. Modern designs target 60–80 ROB entries per issue slot as a rough heuristic.

Consider: add R1,R2,R3 ; add R4,R1,R5 ; add R1,R6,R7. Architecturally, the third add overwrites R1 — a WAW with the first.

Rename allocates fresh physical registers for each destination: first add → P10, second → P11, third → P12. Source operands look up in the RAT (current arch-to-phys map).

Result: add P10,P2,P3 ; add P11,P10,P5 ; add P12,P6,P7. No false dependence — first and third can execute in parallel. The RAT now maps R1→P12.

On retirement, P10, P11, P12 are committed in order. P10 is freed when a later instruction overwrites R1 architecturally (when the third add retires) — the freelist mechanism.

An instruction is dispatched to a reservation station, which holds either operand values or tags identifying the producer. When all operands arrive, the instruction issues to its FU. The FU computes and broadcasts the result on the Common Data Bus along with the producer tag. All RSes and the register file snoop the CDB; any waiting RS with a matching tag captures the value as one of its operands. This decouples execution from program order while still respecting data dependences.

States: 00 (Strongly NT), 01 (Weakly NT), 10 (Weakly T), 11 (Strongly T). Predict taken if MSB=1. On taken outcome, increment (saturating at 11). On not-taken, decrement (saturating at 00).

Benefit over 1 bit: tolerance to one anomaly. A loop that's taken 99 times and not-taken once stays in state 11 throughout — only momentarily dipping to 10. A 1-bit predictor would mispredict the iteration AFTER the not-taken one too. Empirically: 2-bit is ~85–90% on SPEC, 1-bit is ~70–80%.

gshare uses XOR of the global branch history register and the branch PC to index a table of 2-bit counters. The XOR distributes correlated patterns across the table while still using PC bits to differentiate static branches.

Why it works: many branches correlate with recent control flow ("if (a) {} else { if (b) {} }" — the second branch's behavior depends on the first). Pure per-branch (PAg) misses this. Pure global (gselect/gshare) captures it. gshare's XOR is a cheap way to combine global history with PC for index aliasing reduction.

1. Branch resolves in EX, comparing actual outcome to predicted. 2. Mismatch detected → squash signal asserted. 3. All ROB entries younger than the branch are marked invalid (or the tail pointer is rewound). 4. The rename map is restored from a checkpoint taken at the branch — every later rename is undone in one cycle. 5. Issue queue / RSes flush younger instructions. 6. Fetch is redirected to the correct target PC. 7. Pipeline refills — the misprediction penalty.

Older designs without rename checkpoints walked the ROB backward undoing the RAT, which took many cycles. Modern designs allocate a rename-map checkpoint at every branch.

When a load executes, it must check whether any older un-retired store wrote the same address. If so, the load gets the store's value (which isn't yet in cache). The load-store queue holds pending stores with their addresses and data; loads do an address CAM against pending stores.

Tricky because: (1) addresses may not be known yet when the load executes (must conservatively wait, or speculate); (2) partial overlaps — a 4-byte load that overlaps a 2-byte and a 1-byte store needs partial-data assembly; (3) misaligned cases; (4) on misspeculation, a load that received forwarded data must be replayed. Intel's memory dependence predictor learns which loads can safely speculate past unknown stores.

RAW remains — it's a true value dependence and renaming can't remove it. The consumer must wait for the producer to compute the value.

WAR and WAW vanish. After renaming, the second writer gets a fresh physical register, so there's no shared register name between older and newer writes. The older read targeted the original physical register, which is preserved in the freelist until safely retired.

In ROB-based designs (early P6, original Tomasulo with reorder buffer), values live in the ROB entry until retirement, then are copied to the architectural register file. This means data is moved on retirement (consumes a write port and energy) and consumers must read either ARF or ROB depending on the producer's state — complex.

Unified PRF: values live in physical registers throughout. The RAT maps architectural names to physical registers. On retirement, no data moves — the physical register is simply marked as "the architectural one for now." The previous physical register for that architectural name is freed. Cleaner, less power, but PRF must be larger. Now standard.

Two predictors run in parallel — typically a local (per-branch history) and a global (gshare-style) predictor. A meta-predictor (also a 2-bit counter table) chooses which to trust for each branch based on which has been right more often recently.

Why: different branches favor different predictors. Loop branches with stable per-branch patterns favor local history; branches that correlate with recent control flow favor global. The tournament gets the best of both. Alpha 21264 popularized this; modern designs use even more sophisticated combinations (TAGE, perceptron). Detailed in Ch 9.

Predicts whether a load will alias with an older un-known-address store. If predicted no-alias: load executes early, speculatively. If alias is later detected: load is squashed and re-executed. If predicted alias: load waits for the store address.

Intel's "store sets" implementation (Chrysos & Emer, 1998) learned which loads tend to alias which stores. Without MDP, conservative ordering forces every load to wait — kills IPC. With MDP, loads execute aggressively and only the rare misspeculations replay.

Each entry has tag(s) identifying the producer(s) of its operand(s). When a result is broadcast on the result bus, the entry's CAM compares its source tags against the broadcast tag; a match captures the result and clears the corresponding "ready" bit. When all sources are ready, the entry asserts a request to the selector.

The wakeup-select loop is one of the tightest critical paths in a modern OoO core — broadcast → tag compare → operand capture → ready signal → selector → grant must all happen in one cycle (or two, in a pipelined scheduler). This is why issue queues are typically small (32–100 entries).

An instruction is speculative if it's executing past an unresolved branch or other speculation point. Its result is committed to architectural state only if speculation is verified correct (the branch resolves as predicted, no exception, no memory misorder, etc.).

If speculation is wrong, the instruction and all younger ones are squashed: ROB entries cleared, rename map rolled back, issue queue flushed, store buffer entries cancelled. Side effects on caches and prefetchers usually persist — this is why Spectre attacks work, since speculative loads leak cache state. Architectural state is unaffected.

An exception is "precise" if, when signaled, all instructions before it have completed and none after have any effect — exactly as if the program had executed in strict order. Required for sane OS interrupt handling, debugging, and virtual memory page faults.

Out-of-order execution naturally executes instructions in any order. The ROB enforces in-order retirement: an exception is only delivered when the offending instruction reaches the ROB head. Younger instructions in the ROB (which may have already executed) are squashed. The architectural state matches the precise-exception requirement.

If a 4-byte load reads bytes 0–3 and an older store wrote bytes 1–2, you have a partial overlap. Three policies:

• Forward only on full match: if any partial overlap and not full match, stall the load until the store retires (writes to cache). Simple, often slow.
• Partial forwarding: assemble the load value from store buffer bytes + cache bytes. Complex hardware, faster.
• Replay the load: mark the load to re-execute after the offending store completes.

Modern Intel does limited partial forwarding for aligned cases; misaligned partial overlaps trigger a replay penalty (the famous "store forwarding stall"). Common micro-optimization target in HPC code.

It contains every essential mechanism of a modern OoO superscalar — branch prediction, register renaming, distributed reservation stations, ROB-based retirement, multiple functional units — at a documented, comprehensible scale. The complete microarchitecture and SPEC95 performance data are public. Modern processors hide most internal details, so 620 remains the best end-to-end teaching example.

620 uses distributed RSes — each FU has its own small queue (2–4 entries), 6 RSes total. Pro: small CAMs, fast wakeup. Con: load imbalance — if one integer RS fills while the other is empty, dispatch stalls even though execution capacity exists.

A centralized issue queue (P6, modern Intel/AMD) is one shared queue; instructions select an FU at issue time. Pro: better utilization, no per-FU starvation. Con: bigger CAM, longer wakeup-select path. Modern designs almost universally use centralized.

To stalls. Empirical breakdown roughly:

• ~30–40%: dispatch stalls — small RSes/ROB fill.
• ~20–30%: data-cache misses (loads stall consumers).
• ~10–15%: branch mispredictions.
• ~10%: instruction-cache misses and front-end gaps.
• Rest: serialized dependence chains, structural conflicts.

Notice execution-unit contention is rarely the bottleneck — adding a 5th FU wouldn't help. Wider front-end + bigger window + better predictor would. This guides everything modern CPUs do.

The direction predictor (BHT, gshare, etc.) predicts whether a branch is taken or not — a 1-bit decision.

The BTAC / BTB stores the target address of taken branches, indexed by the branch PC. Without it, fetch must wait for decode to compute the target — too slow at high frequencies. The BTAC delivers the target during fetch itself, enabling back-to-back taken-branch fetch.

Both are needed in a high-performance front-end.

The 620 has 8 GPR rename registers, 8 FPR rename registers, and 16 condition register field rename buffers separate from the architectural file. When an instruction dispatches, a rename register is allocated for its destination; the architectural file is only updated at retirement.

This is the older "ROB + ARF + rename file" style — three separate storage structures. Modern designs collapse this into a unified PRF. The 620's design was conservative for its era; subsequent PowerPCs (G3, G4, G5) moved to unified PRFs.

A store dispatches to the LSU's RS. When its address and data are both ready, it executes — meaning the address translates and the data is held in a store queue entry. The store does NOT modify the cache yet; that would be visible to other observers and break precise exception semantics.

Only when the store reaches the ROB head and retires does it commit from the store queue to the cache. This guarantees that stores from a squashed speculation path never leak to memory. Modern designs work the same way, with the LSQ being a more sophisticated structure that also forwards data to younger loads.

POWER3 (1998) widened the front-end, added more execution units, and refined branch prediction. POWER4 (2001) was a major leap: dual-core (one of the first multicore desktop chips), much wider pipelines, sophisticated branch predictors, and aggressive memory hierarchy.

The 620 → POWER3 → POWER4 trajectory exemplifies what every CPU family does over generations: more issue width, deeper pipelines for higher clocks, better predictors, larger windows, more cores. Same fundamental machinery as 620, just scaled.

An honest interview answer:

1. Bigger ROB and PRF. 16 ROB entries is tiny — exposing more ILP is the cheapest IPC win.
2. Centralized issue queue instead of distributed RSes — eliminates load imbalance.
3. Better branch predictor. A simple BHT was fine for 1995 but TAGE/perceptron buys 5%+ IPC today.
4. Non-blocking caches with prefetching. Modern non-blocking design hides much more memory latency than 620's conservative approach.

What I would NOT do first: increase issue width. The 620's bottleneck wasn't EX bandwidth; it was window size. Going from 4-wide to 6-wide without enlarging the window is wasted silicon.

x86 is irregular: variable-length, complex addressing modes, memory-to-memory ops. Implementing OoO scheduling directly on x86 instructions would mean every instruction is a special case — register port pressure, dependency analysis, exception handling all become combinatorial nightmares.

uops are fixed-format, RISC-like, with a uniform "register-register" structure (memory operands become explicit load+op or op+store sequences). The OoO core is now ISA-agnostic; it just schedules a stream of simple uops. This separation has let Intel keep the same OoO engine architecture across decades while x86 itself accumulated extensions.

P6 had three parallel decoders: D0 (complex, can produce up to 4 uops), D1 and D2 (simple, 1 uop each). The constraint per cycle: D0 can take any instruction; D1/D2 only single-uop instructions. So if an x86 instruction sequence is "complex, complex, simple," only the first complex goes through D0 and the second complex stalls D1, breaking the sequence.

The "4-1-1" name is the per-decoder uop budget per cycle. Compilers tried to schedule x86 sequences to match this pattern. Modern Intel decoders relaxed this with multiple complex decoders and a uop cache that bypasses the legacy decoders entirely.

P6: ROB entries hold uop status AND result data. Architectural state lives in a separate retirement register file (RRF). The RAT maps architectural regs → ROB entries. On retirement, data moves from ROB to RRF — a real data movement.

Sandy Bridge (and modern Intel/AMD): one large physical register file. ROB entries hold metadata only — pointers to PRF entries. RAT maps architectural regs → PRF indices. On retirement, no data moves; the PRF entry simply becomes "the architectural one" and the previous architectural PRF entry is freed.

Unified PRF saves energy (no data copy on retire) and read ports (consumers always read PRF). It needs a bigger PRF to hold all in-flight values, but transistor budgets allow this since 2010.

P6 has one 20-entry RS that can dispatch uops to any of 5 issue ports. 620 has separate small RSes attached to each FU.

Centralized: better utilization (an idle ALU port can grab a ready integer uop regardless of which RS entry it's in). But the wakeup CAM is bigger (more entries × more sources to compare) and the select logic is more complex (must arbitrate across all ports).

Distributed: simpler local hardware. But uneven RS occupancy causes dispatch stalls. P6's choice traded hardware complexity for utilization, which proved correct as silicon budgets grew.

P6 had 5 ports. Port 0: ALU, integer multiplier, FP unit, divider. Port 1: ALU, branch unit, integer shifter. Port 2: load AGU. Port 3: store address AGU. Port 4: store data.

Insight: a store needs both Port 3 AND Port 4 (address compute and data movement) — two slots for what looks like one operation. A load only needs Port 2. Modern Intel has more ports (8–12) and finer specialization, but the same idea — uops are typed by the ports they can use.

The MOB tracks loads and stores specifically — their addresses, data, and ordering. The ROB tracks all uops for retirement and exceptions. They're separate because memory ordering needs different bookkeeping (address CAM, store-load forwarding) that other uops don't.

Load buffer entries CAM against store buffer entries on every load. The store buffer holds data until retirement. Both are sized to match the ROB — every in-flight load/store has a corresponding MOB entry.

NetBurst (P4) bet on extreme pipeline depth (~31 stages effective) and very high frequencies (4+ GHz target). The bet failed because:

• Branch misprediction penalty became enormous (~20 cycles).
• Power scaled badly — leakage at high frequencies hit the wall around 3.8 GHz.
• The trace cache had cold-start and capacity issues.
• Per-cycle work (IPC) dropped because so much logic was bypassed for speed.

The Banias / Pentium-M team (originally building laptop chips) had been quietly evolving P6 with better branch prediction and prefetching. Core (2006) productized this. The 13–14 stage P6-derived pipeline at ~3 GHz beat the 31-stage P4 at 3.8 GHz on real workloads — and used half the power. P6's lineage continues today.

Macro-op fusion: two adjacent x86 instructions are fused into one uop. Classic case: cmp r,r ; jcc target becomes one fused uop that does the compare and conditional jump. Saves a uop in the front-end and the OoO window.

Micro-op fusion: what would be two uops (e.g., load + ALU op) are kept as one uop in the front-end and ROB but issued as two to ports. Saves ROB entries and decode bandwidth.

Both were introduced in Pentium-M / Core era and are now ubiquitous. They effectively widen the pipeline at the front-end and ROB without increasing structural width — a clever trick.

It's microcoded. The decoder recognizes the opcode and triggers the microcode ROM, which generates a sequence of simpler uops (load, store, decrement counter, conditional branch). This sequence may be hundreds of uops for long strings.

Modern x86 has "fast string" optimizations: REP MOVSB on recent CPUs is detected and replaced by a hardware-accelerated bulk copy with magic — bypassing the per-byte microcode loop. Without it, REP MOVSB would be slower than a hand-coded loop. With it, REP MOVSB is often the fastest memcpy implementation.

P6 itself: ~1.5–2.0 sustained IPC on SPEC, peak 3 (decode-limited). Modern P6-derived cores (Skylake-and-later): 2.5–4 IPC typical, peak 5–6 internally. The bottleneck has shifted: P6 was decode-limited; modern chips are usually limited by branch mispredictions and memory latency rather than decode bandwidth (uop cache solved that).

You'd answer in an interview: "It depends heavily on workload. For SPEC-style, ~3. For a memory-bound HPC benchmark, often <1. For tight loops in cache, 4+." Show you know IPC isn't a single number — it's a workload property.

Speed demons aim for extreme clock frequency through deep, simple pipelines (Pentium 4, Alpha 21164). Brainiacs aim for high IPC through wide issue and aggressive OoO (P6, Apple M-series). Both can win on different workloads; the modern industry has converged on brainiac because power and memory walls cap frequency.

Compaq acquired Digital, then HP acquired Compaq. HP had bet on Itanium (jointly developed with Intel). Killing Alpha was politically necessary to commit to Itanium. By the time Itanium failed (it failed badly), Alpha's team and momentum were gone.

Lesson: technical merit doesn't guarantee survival. Business decisions, ecosystem, and strategic alignment matter more. Alpha's engineers ended up driving advances at Intel (Hinton on Core/Nehalem), AMD (Keller on K8/Zen), and Apple (Keller and others on M-series).

It introduced the tournament predictor: a local-history predictor and a global-history predictor running in parallel, with a meta-predictor (also a 2-bit counter table) choosing which to trust per branch. Got the best of both prediction styles.

This design directly inspired later predictors. Modern TAGE and perceptron predictors are descendants of this idea — combining multiple prediction sources adaptively.

Several huge wins beyond just wider addresses:

• Doubled GPR count (8 → 16). x86's 8 GPRs were a massive register-pressure bottleneck. 16 reduced register spilling and improved IPC noticeably.
• Doubled XMM register count (8 → 16). Big win for vectorized code.
• Cleaned up addressing modes for the new RIP-relative mode and removed some legacy.
• NX bit (no-execute) for security.

The register doubling alone bought ~10–20% IPC on integer code. AMD's most strategically important architectural decision.

Same constraints push toward same answers. The ILP wall caps useful issue width around 6–8. The memory wall makes large windows necessary. The power wall caps frequency around 4–5 GHz. Within those bounds, the optimal design is approximately known: wide front-end, large window, sophisticated branch predictor, multi-level cache, SMT, multicore.

You see Apple, AMD, Intel, Qualcomm, ARM, IBM all converge on similar block diagrams not because they copy each other but because the math points there. Differentiation now comes from execution quality, integration (AI accelerators, GPU), and process node — not architectural breakthroughs.

VLIW wins when:

• The workload is regular and predictable (DSP, signal processing, GPU shaders).
• The compiler can fully analyze the program's parallelism.
• You want low power (no OoO bookkeeping).
• You're willing to recompile when the chip changes.

OoO wins for general-purpose code with cache misses, branches, and dynamic library calls — events the compiler can't predict. This is why VLIW thrived in DSPs (TI C6x) and GPUs (NVIDIA pre-Fermi was VLIW-like) but failed for general CPUs (Itanium).

It was the first mainstream dual-core high-performance chip. Two complete OoO cores on one die, with shared L2. This validated multicore as a practical design before the rest of the industry committed (Intel Pentium D came in 2005, AMD Opteron dual-core in 2005). POWER4 also pushed deep OoO with 200+ in-flight instructions, foreshadowing modern chips.

1995 honest answer: speed-demon was a defensible bet. Process scaling was still delivering frequency gains; deep pipelines won linear improvements. Many top engineers picked it (Alpha, P4).

2025: brainiac, no question. The frequency curve flattened around 2004. Power scales badly. Modern workloads (browsers, VMs, ML inference, JIT-compiled code) have unpredictable memory access patterns that punish deep pipelines. Wide OoO with great prediction and large windows is the proven winner.

The interesting modern wrinkle: heterogeneous designs (Apple's E-cores, Intel's E-cores) bring back tiny in-order cores for power-efficient throughput on background tasks. Speed-demon vs brainiac is now a per-core decision in a multi-core SoC, not a single-chip philosophy.

2-bit BHT captures only per-branch local history. It can't see correlations between branches. For example, "if (x > 0) { ... } if (x > 0) { ... }" — the second branch is perfectly correlated with the first, but a per-branch predictor treats them independently. Two-level (gshare) or TAGE captures this.

Also: deep pipelines penalize each percentage point of accuracy heavily. A 92% predictor was fine in 1995 (5-stage). At 20-stage with 4-wide issue, you need ≥97% to keep IPC up.

Lookup: 1) Read the global BHR (e.g., last 12 branch outcomes). 2) XOR with the lower bits of the branch PC. 3) Use the result to index the PHT. 4) Read the 2-bit counter; predict taken if MSB=1.

Update (after branch resolves): 1) Index the PHT the same way (XOR of original BHR with PC). 2) Increment the counter on taken, decrement on not-taken (saturating). 3) Shift the actual outcome into the BHR.

Note: the BHR used at update is the BHR at fetch time, not after — must be saved alongside the in-flight branch.

Concatenation uses BHR bits as high-order index bits and PC bits as low-order (or vice versa). For short BHRs, this clusters all entries from the same branch in nearby table slots — wasting capacity.

XOR mixes BHR and PC bits uniformly across the whole table. Same hardware cost, better aliasing distribution. Empirically gshare wins by 1–2% accuracy at the same table size.

TAGE uses multiple tagged PHT-like tables, each indexed with a progressively longer global-history length (geometric series: e.g., 5, 13, 35, 92, 250 bits). On lookup, all tables are queried in parallel; the table with the longest history that has a matching tag provides the prediction. A bimodal base predictor handles branches with no useful history. Updates allocate new entries when current predictors are wrong, and a "useful" bit prevents thrashing. TAGE picks per-branch the optimal history length, which is why it consistently beats single-history predictors.

Perceptrons scale storage linearly with history length (weights × history bits) instead of exponentially (PHT entries = 2^history). For very long histories (256+ bits), perceptron is cheaper.

Modern designs are often hybrid: TAGE for branches with short-to-medium correlations, perceptron for branches with very long-history dependence. AMD's Zen series is rumored to use this combo.

Limitation: perceptrons can't learn non-linearly-separable patterns (XOR of two history bits). TAGE handles those naturally via tagged exact-match.

A small hardware stack (8–32 entries) that mirrors the software call stack. On every recognized CALL, push the return PC. On every RETURN, pop and use as the predicted target. Indirect branches that are returns hit ~99% accuracy this way.

Failure mode: deep recursion overflows the RAS, causing return mispredictions in the deeply-nested calls. Mitigation: increase RAS size (modern CPUs use 32+) and use a wraparound counter so overflow doesn't corrupt the most-recent entries.

For indirect branches, the issue isn't taken/not-taken — they're always taken. The issue is the target. A simple BTB just remembers the last target; this fails for polymorphic indirect branches that jump to different methods on different calls.

Modern indirect branch predictors index a target table with a hash of the PC and recent branch history (analogous to gshare for targets). This captures that "last time path A led here, the target was X; path B led to target Y." Indirect-branch-heavy code (interpreters, virtual machines) benefits enormously.

BTB miss: the branch's target isn't cached. Fetch can't redirect immediately — it must wait until decode (where the target offset is computed for direct branches) or even execute (for indirect branches). This stalls fetch for several cycles.

BTB miss penalty is smaller than direction misprediction but still significant. Cold code (first-time-executed paths) and indirect branches with new targets are common BTB-miss culprits. Larger BTBs help; multi-level BTBs (small fast L1 BTB + larger slower L2 BTB) are standard in modern CPUs.

Three issues:

• Cold-start: a freshly entered region must first be decoded normally, then traces built. Workloads with poor instruction locality (call-heavy, branch-heavy) never warmed the trace cache.
• Capacity stress: traces are large (decoded uops with prediction state). The trace cache was effectively a much smaller "I-cache" measured in static instructions covered.
• Misprediction nuking: a single misprediction within a trace invalidated the rest. Trace lifetime was short.

The simpler uop cache (Sandy Bridge+) keeps the energy savings of "skip the decoders" while eliminating the trace-construction cost — it just caches decoded uops indexed by static PC, like a regular cache.

The BHR is speculatively updated as branches predict (so dependent predictions can use the latest history). On misprediction, the speculative BHR is rolled back to the version saved at the mispredicted branch's fetch. Without this, all subsequent predictions corrupt their history.

Implementation: a small "rename" of the BHR. Each in-flight branch carries a snapshot of the BHR. On misprediction, the predictor restores that snapshot. Same idea as RAT checkpointing — small storage cost, eliminates rollback walks.

Some predictor entries store only a partial tag (a few bits of PC), accepting that occasional aliasing happens. The tag matches "probably this branch." Partial tags save area at small accuracy cost.

TAGE uses partial tags. Pure tag-less predictors (gshare) accept all aliasing; pure full-tag predictors (BTB) waste storage. Partial tags are the engineering compromise — used widely.

A modern branch predictor can occupy 10–20% of a core's area when you count BTB, BHRs, PHTs, RAS, indirect predictor, and the supporting logic. It's typically the second-largest non-cache structure after the OoO scheduler/RF.

Power is also significant — every fetch cycle queries multiple structures. CPUs gate parts of the predictor when running predictable code (tight loops with one branch direction), but you can't shut it off.

The classic engineering question: "Should we add a 32 KB L2 BTB or a 32 KB more L1 cache?" Answer depends entirely on workload. Branch-heavy code (interpreters, browsers) benefits from BTB; straight-line numerical code benefits from cache.

Mispredicted speculative loads still execute and bring data into the cache before the misprediction is detected. An attacker trains the predictor to mispredict in a way that causes a sensitive load to execute speculatively; the load's address depends on secret data; the cache state after the squash leaks the secret via timing analysis.

The architectural state was protected (speculation was undone). The microarchitectural state (cache) was not. Spectre and its variants exploit this gap. Mitigations: speculation barriers (LFENCE), retpolines (replace indirect branches with non-speculatable returns), and microarchitectural defenses (sanitize speculative loads). All cost performance.

The data flow limit is the minimum cycles needed for the longest chain of true (RAW) dependencies in a program window. Even infinite hardware can't beat it because each instruction must wait for its predecessor's actual result.

Value prediction speculates the predecessor's result before it computes, allowing consumers to execute in parallel. If the prediction is right, the chain is broken. If wrong, the consumer is squashed and re-executed. Net win requires high prediction accuracy.

The empirical observation that a large fraction of instruction results recur during execution. Loop induction variables, loaded addresses, constant-but-non-immediate values, and frequently-called function results all exhibit value locality.

Lipasti et al.'s 1996 study found ~50% of dynamic load values repeated within a small window. Different from temporal/spatial locality, which describe address access patterns; value locality describes the values themselves.

Value prediction is speculative — predict result, execute consumers, verify, squash on miss. Cheaper per attempt; expensive on misprediction.

Instruction reuse is non-speculative — cache (instruction, inputs, output) tuples; on a re-encounter with same inputs, skip the FU and use the cached output. Slower to look up, but no squash penalty.

Reuse is conservative; prediction is aggressive. Both target value locality from different angles.

Multiple compounding issues:

• Accuracy is below the required threshold. 80–90% sounds great, but the squash cost on the 10–20% misses overwhelms the speedup.
• Power. Predictor tables and verification logic burn energy on every instruction.
• Verification complexity. Squashing only the consumers (not all younger instructions) is hard to do correctly.
• Marginal gains. Modern wide OoO already achieves close to 80% of single-thread theoretical limit. The remaining 20% is hard to extract via prediction.
• Spectre-class concerns. Value prediction adds new speculation surfaces.

Move elimination is a real shipped technique: at rename, the renamer recognizes that mov rax, rbx just creates an alias. Instead of dispatching it to an ALU, the renamer simply makes the architectural register rax point to the same physical register as rbx. Zero-latency, zero-FU.

Same idea for zero-idioms: xor rax,rax always produces 0, so the renamer points rax to a "zero" physical register without any FU work. Effectively a 100%-accurate "value predictor" for trivially predictable cases. Modern Intel and AMD both do this.

A predictor table indexed by instruction PC, each entry storing the most recent value and the stride (current_value - previous_value). Prediction = current_value + stride.

Excellent for loop induction variables (i++, addresses incrementing by sizeof(elem)). Not great for irregular values. The "two values + a state machine deciding when stride is reliable" version (confidence counter) is the practical one.

Hardware stride prefetchers (essentially stride predictors for load addresses) are real and shipping in every modern CPU.

Two mechanisms must coexist: the predictor delivers a value to consumers; the actual instruction still executes; on completion, compare predicted vs actual.

On match: nothing extra needed (the prediction was a "shortcut"; the real value was the same). On mismatch: squash the dependent chain (only the consumers, not all younger code), restore state, re-execute consumers with the correct value.

Selective squash is hard — you need to track which instructions consumed the predicted value (transitively!) to know which to squash. This is the major implementation hurdle; most proposals simplify by squashing all instructions younger than the mispredicted producer (overkill but easier).

Long-dependent-chain code with high value locality: pointer-chasing in linked structures (high address locality), cryptographic key schedules (highly regular patterns), interpreter dispatch (repeating sequences), some sparse linear algebra. These have low ILP from data flow alone but predictable values.

Workloads where value prediction would NOT help: random-access code (no value locality), branchy code (mispredictions dominate latency anyway), already-fast straight-line loops (already at IPC limit).

Instruction reuse caches (instruction PC, source operand values, result) tuples. On a re-encounter where source values match, the cached result is used directly — bypassing execution.

Safer because there's no speculation: if the source values match, the result is provably the same (assuming the instruction is deterministic). No squash needed. The cost is the cache lookup itself, which competes with FU latency for trivial instructions; reuse only wins for instructions where the cache lookup is faster than execute (multiplies, loads, divides).

Three reasons:

1. Conceptual completeness. The framework — speculation breaking dependence walls — is correct and elegant.
2. Influence on shipped derivatives. Move elimination, zero-idiom recognition, stride prefetchers, MDP — all are descendants.
3. It might come back. As workloads change (ML inference, JIT-heavy code), the cost-benefit may shift. Recent academic interest in selective value prediction for specific instruction classes is renewed.

Knowing the framework prepares you for whatever shipping descendant exists.

CGMT: switch threads on long stalls (e.g., L2 miss). Simple, hides only big stalls. FGMT: switch every cycle. Hides all stalls, but each thread runs slower; usually paired with in-order pipelines (Niagara, GPUs). SMT: issue from multiple threads simultaneously in an OoO core. Best utilization of wide OoO; small area overhead. Used by Intel HT, IBM POWER, AMD Zen.

Spectrum from coarsest (CGMT) to finest (SMT). Modern high-perf desktops/servers favor SMT because it composes naturally with already-deep OoO.

Roughly 5–15% of core area, depending on what's replicated. You must duplicate per-thread state: PC, ITLB, RAT (rename map), branch predictor history (sometimes shared with thread-tagged tables), and architectural register file (or just PRF entries reserved per thread).

Shared: issue queue, ROB, FUs, L1 caches (with thread tag bits per line), DTLB. The big win: same FUs serve both threads, so issue-port utilization rises substantially without doubling silicon.

Initial: line is in S in caches A and B (both clean). A wants to write.

1. A issues a "bus upgrade" or "RFO" (read-for-ownership) on the bus.
2. B's cache snoops; sees the request for a line it has in S; transitions S → I (invalidate).
3. A's cache transitions S → M; performs the write locally.
4. Memory is now stale (only A has the current value); A's line is in M.
5. If C later reads that line, it issues a bus read; A snoops, supplies the data, transitions M → S; C goes I → S; memory may also be updated (write-back depends on protocol).

In MESI, when a Modified line is read by another cache, the protocol must write back to memory and transition to S. That extra writeback is wasted work if the line is read again before being evicted.

MOESI's Owned state lets the original M-state cache transition to O instead of writing back: the line stays dirty in the O cache; other caches go to S; the O cache "owns" the responsibility of writing back on eviction. Saves a memory transaction. AMD historically favored MOESI for this reason.

Snooping: shared broadcast medium; all caches see all transactions. Latency is fast for the common case (no extra hop). Doesn't scale past ~16 cores because bus bandwidth saturates.

Directory: central or distributed directory tracks which caches share each line. Each transaction is point-to-point. Scales to hundreds of cores. Adds a hop (directory lookup) on the common case. Modern many-core chips (Xeon mesh, EPYC Infinity Fabric, large-core Apple M3 Max/Pro) use directory or hybrid.

Sequential consistency (SC): all memory ops appear in a single total order respecting per-thread program order. Strongest, simplest to reason about, slowest in hardware.

TSO (x86): stores may be buffered; younger loads can complete before older same-thread stores are globally visible. Otherwise SC. Allows store-buffer optimizations.

Weak (ARM, RISC-V, POWER): nearly any reordering is allowed except where program-order data dependences exist. Hardware has maximum freedom; software must use barriers (DMB, fence) for ordering.

On x86, two stores from one thread are observed in program order by all other threads (no store-store reordering across cores). Locks built with two stores work as expected.

On ARM, two stores can be observed in different orders by different cores unless an explicit DMB (data memory barrier) intervenes. Many naive lock implementations break. Compiler atomic intrinsics (std::atomic) emit the right barriers; hand-rolled assembly often doesn't.

This is why porting concurrent code from x86 to ARM frequently surfaces latent bugs that "always worked" on Intel.

Thread T1 reads value A from a memory location and prepares to CAS A→B. Meanwhile T2 changes A→C→A (intermediate value irrelevant). T1's CAS succeeds because it sees A — but the world changed in between.

For lock-free stack/queue using pointers, this is catastrophic: the pointer might be reused for a new node and T1's CAS unwittingly links the stale node into the structure.

Mitigations: tagged pointers (encode an ABA counter alongside the pointer), hazard pointers, epoch-based reclamation, or use LL/SC instead (which detects intervening writes natively).

CAS: single instruction "if mem == expected, set mem = new." Simple, but vulnerable to ABA.

LL/SC: LL reads and marks the address; SC succeeds only if no other write to that address has happened since LL. Allows arbitrary computation between LL and SC. ABA-free because SC fails on any intervening write.

Both implement primitives like atomic increment, compare-and-set, and fetch-and-add. ARM, RISC-V use LL/SC. x86 uses CAS (cmpxchg). C++11 atomics abstract over both.

Two cores writing different variables that happen to live in the same cache line. Each write causes coherence ping-pong: line moves from M in core A → I in A, M in B → I in B, M in A — back and forth, every iteration.

Even though the threads aren't logically sharing data, the cache line is shared. Performance can drop 10–100× compared to having the variables in separate cache lines. Common culprit: per-thread counters laid out as a packed array.

Fix: pad data structures to 64-byte boundaries (cache line size). C++17 has alignas(std::hardware_destructive_interference_size); Linux kernel uses ____cacheline_aligned.

A memory barrier orders memory operations: instructions before the barrier must complete (be globally visible) before instructions after the barrier execute or become visible.

Needed whenever the algorithm relies on ordering that the consistency model doesn't guarantee. Classic case: producer-consumer flag pattern. Producer: write data, set flag. Consumer: spin on flag, read data. On a relaxed-memory ISA, without a barrier between data-write and flag-set, the consumer can see flag set before data — broken. ARM needs DMB; x86 needs MFENCE (or implicit ordering from locked instructions).

M-series chips have P-cores (performance — wide OoO ~8-wide, ~3.5 GHz, large ROB) and E-cores (efficiency — narrower OoO, ~2 GHz, smaller ROB). Both implement the same ISA (ARMv8) so binaries run on either.

macOS scheduler classifies threads by Quality-of-Service (QoS) and dispatches accordingly. Latency-sensitive UI threads → P-cores. Background indexing → E-cores. The cores share unified memory and a coherent fabric. The whole thing yields excellent perf/Watt because most workloads have a mix of latency- and throughput-sensitive work.

Marketing. Hyper-Threading is just Intel's brand for 2-way SMT. The first Intel HT was Pentium 4 (2002); abandoned briefly during NetBurst era; returned in Nehalem (2008) and has shipped continuously since.

Some recent client chips (Lunar Lake P-cores) have removed HT — Intel found that for client workloads, the area saved by removing SMT is better used on the OoO engine itself. Server chips (Xeon) keep HT because server workloads (high-thread-count, latency-tolerant) benefit more.

SMT adds a second thread context to an existing core for ~10% area; gets ~20–30% throughput improvement on parallel workloads. Excellent ratio.

Adding a second physical core: ~100% area; ~80–95% throughput improvement (some shared resources scale less than linearly). Lower ratio per area, but each thread runs at full single-thread speed.

SMT wins on workloads that benefit from thread-level parallelism but don't need full performance per thread (servers, batch processing). Multi-core wins for latency-sensitive parallel workloads. Modern chips do both. The interesting design choice in 2025 is whether to add SMT to a P-core or just add another E-core — Intel and AMD now disagree on this.

The software-visible contract — instruction formats, registers, addressing modes, memory model — that hardware must implement.

CPU Time = Instruction Count × CPI × Clock Period.

Higher branch mispredict penalty; more clock-skew/register overhead per stage; lower IPC because of forwarding gaps and structural conflicts in deeper microarchitecture.

Only RAW. WAR and WAW are name dependences that emerge with out-of-order execution.

Routing the output of an in-flight instruction directly to the input of a younger one, bypassing the register file.

The load's value is available only at end of MEM, but the consumer needs it at start of EX one cycle earlier. Forwarding can't time-travel.

Average Memory Access Time = hit_time + miss_rate × miss_penalty. Recursive across cache levels.

Direct-mapped: each block has exactly one slot. 4-way: each block has 4 candidate slots in its set; less conflict miss.

A small fast cache of virtual-to-physical address translations. Hit: 1 cycle. Miss: page-table walk.

Virtually Indexed, Physically Tagged. Allows TLB lookup and cache index lookup in parallel — saves one cycle on L1 hits.

To eliminate WAR and WAW false dependences caused by limited architectural register count.

Tracks in-flight instructions in program order. Enables in-order retirement, precise exceptions, and speculation rollback.

A buffer holding dispatched-but-not-yet-issued instructions, waiting for their operands. Wakeup via tag broadcast on result bus.

Out-of-order execution with reservation stations, common data bus broadcast, and tag-based renaming.

4 states (Strong NT, Weak NT, Weak T, Strong T). Predict T if MSB=1. Update by ±1 on actual outcome (saturating).

XOR global branch history with branch PC, use as PHT index. Captures cross-branch correlation cheaply.

Multiple tagged tables with geometrically-increasing history lengths; picks the longest matching history per branch dynamically.

Branch Target Buffer. Caches taken-branch targets, indexed by branch PC, so fetch can redirect immediately without waiting for decode.

A small hardware stack mirroring software call/return — push on call, pop on return. Returns predict ~99%.

Cold-start penalty, capacity stress, and traces invalidated by mispredictions. Replaced by the simpler uop cache.

A simple, fixed-format internal operation that x86 instructions decode into. Lets the OoO engine schedule a clean RISC-like stream regardless of x86 complexity.

Per cycle: one complex decoder produces up to 4 uops, two simple decoders produce 1 uop each. Sequence "complex, complex, simple" stalls because only one complex decoder exists.

Speed demons go for max clock with deep simple pipelines (P4, Alpha 21164). Brainiacs go for max IPC with wide complex OoO (P6, modern Apple/Intel/AMD). Brainiacs won.

64-bit addresses, doubled GPR count (8→16), doubled XMM (8→16), NX bit. Register doubling alone bought ~10–20% IPC.

The minimum cycles needed for the longest chain of true dependences. Even infinite hardware can't beat it without speculation.

The empirical observation that instruction results recur frequently. Loads, induction variables, etc. exhibit this pattern.

Verification overhead and squash recovery cost more than the speedup. Move elimination and prefetchers shipped instead.

SMT: simultaneous, multi-thread issue per cycle in OoO core. FGMT: round-robin every cycle (in-order). CGMT: switch on stalls.

Modified (own copy, dirty), Exclusive (own copy, clean), Shared (multiple copies, clean), Invalid (not present).

Snooping: shared bus, all caches see all transactions. Directory: central tracker, point-to-point coherence messages. Directory scales further.

x86 preserves nearly all store-store and store-load orderings without barriers. ARM allows nearly all reorderings; programmers must use DMB or atomics with explicit ordering.

CAS: single instruction, vulnerable to ABA. LL/SC: pair of instructions; SC fails on intervening write, ABA-immune.

Two cores writing different variables in the same cache line, causing coherence ping-pong despite no logical sharing. Fix: pad to cache-line boundaries.

Speculative loads alter cache state before the speculation is squashed. Architectural state is rolled back; cache state isn't. Timing-based side channel leaks the secret.

Power wall (frequency-scaling power becomes infeasible), ILP wall (sustained single-thread parallelism caps at ~4–7), memory wall (DRAM latency in cycles keeps growing).