123 Computer Architecture Interview Questions and Answers (2026)

Moore's Law is the observation (not a physical law) that the number of transistors on an integrated circuit roughly doubles about every two years at comparable cost. It historically tracked exponential gains in compute, but transistor scaling has slowed as devices approach atomic limits, so its literal form is fading while its spirit continues through other means.

• What it actually says:

  • Transistor density (count per chip) doubles roughly every ~2 years, driving cost-per-transistor down.

  • It is an economic/empirical trend, not a guarantee of speed doubling.

• Common misconception: It is about transistor count, not clock speed; single-thread performance stalled once Dennard scaling (power staying constant as transistors shrink) ended around the mid-2000s.

• Why it's slowing: Physical limits (leakage, heat, atomic-scale features) and skyrocketing fab costs make further shrinks harder.

• How progress continues: Multicore, specialized accelerators (GPUs, TPUs), chiplets, and 3D stacking sustain compute growth even as classic scaling slows.

A '64-bit' processor works with 64-bit-wide data natively: its general-purpose registers, integer ALU, and virtual address/pointer width are 64 bits. It is defined by the width of these architectural resources, not necessarily by the physical bus width.

• General-purpose registers: Each holds a 64-bit value, so integer operands and results are 64 bits wide in one instruction.

• ALU / integer datapath: Performs 64-bit arithmetic and logic in a single operation.

• Virtual addresses and pointers: Addresses are 64 bits wide (though CPUs typically implement only ~48 bits of that today), giving a huge address space.

• What is NOT necessarily 64 bits:

  • The physical memory bus, cache line, and instruction length can differ; SIMD registers are often wider (128/256/512-bit).

  • So '64-bit' refers to the architectural word/pointer size, not every wire in the chip.

The stored-program concept means that both program instructions and data live in the same read/write memory, so a computer can fetch instructions as easily as it reads data. This turned computers from fixed-function machines into general-purpose ones that could be reprogrammed simply by loading new instructions.

• Instructions and data share one memory:

  • The CPU fetches an instruction, decodes it, executes it, then moves to the next: the fetch-decode-execute cycle.

  • Associated with the von Neumann model (single memory/bus for both).

• Why it was foundational:

  • Earlier machines were rewired or physically reconfigured to change tasks; storing programs made software the flexible part.

  • Programs are data, so software can generate or modify code (compilers, loaders, self-modifying code).

• Trade-off it introduced: The von Neumann bottleneck: a single path to memory serializes instruction and data traffic, which Harvard/split caches later mitigate.

An Instruction Set Architecture (ISA) is the abstract specification of what a processor does: its instructions, registers, data types, memory model, and addressing modes. It is called a contract because it defines exactly what software can rely on and what hardware must implement, letting each side evolve independently as long as both honor the same interface.

• What the ISA defines:

  • The instruction set (opcodes), register file, data types, memory addressing, and exception/interrupt behavior.

  • Examples: x86-64, ARM, RISC-V.

• Why it is a contract:

  • Software (compilers, OS) targets the ISA, not a specific chip, so a binary runs on any compliant implementation.

  • Hardware designers can change the microarchitecture (pipeline depth, cache sizes, out-of-order execution) freely as long as ISA behavior is preserved.

• ISA vs microarchitecture:

  • ISA = the visible interface (what); microarchitecture = the internal implementation (how).

  • Many microarchitectures can implement one ISA (e.g. different Intel and AMD cores both run x86-64).

The memory hierarchy stacks progressively larger but slower and cheaper storage, exploiting locality so that most accesses hit the fast top levels. As you move down (registers to cache to main memory to disk), capacity and cost-per-bit grow while speed drops by orders of magnitude.

• Registers: Fastest (sub-nanosecond, ~1 cycle), tiny (dozens to a few hundred bytes), most expensive per bit; hold operands the ALU works on now.

• Cache (L1/L2/L3, SRAM): L1 ~1 ns / few KB, L3 ~10 ns / tens of MB; holds recently/likely-used data to hide main-memory latency.

• Main memory (DRAM): ~50 - 100 ns, GBs in size, much cheaper per bit; the working set of running programs lives here.

• Secondary storage (SSD/HDD): SSD ~tens of microseconds, HDD ~milliseconds; TBs, cheapest per bit, non-volatile (persists without power).

• Why the hierarchy works:

  • Locality: temporal (reuse soon) and spatial (nearby addresses) mean small fast levels capture most accesses.

  • The goal: near-register speed at near-disk cost, on average.

A word is the natural unit of data a processor is designed to handle in one operation, typically the width of its registers and integer ALU. Word size sets how much data moves and is computed together, and it strongly influences register width, ALU width, and often the data bus width.

• What a word is:

  • A fixed number of bits (e.g. 32 or 64) treated as a unit; a 64-bit CPU has a 64-bit word.

  • It usually equals the general-purpose register width and the size of a memory address (defining addressable space).

• Relation to the ALU and registers:

  • The ALU processes one word per operation, so a 64-bit ALU adds two 64-bit values in one step.

  • Registers are sized to hold a word, so operands fit naturally.

• Relation to the data bus:

  • A data bus as wide as a word moves one word per transfer; a narrower bus needs multiple transfers per word.

  • Caveat: bus and word width aren't always identical (cost or packaging can make the bus narrower or, with cache lines, effectively wider).

Most ISAs group instructions into three broad functional categories: those that compute, those that move data, and those that alter control flow. Some ISAs add a fourth for special/system operations.

• Arithmetic/logic (data processing):

  • Integer/floating-point math (ADD, SUB, MUL), bitwise logic (AND, OR, XOR), and shifts/rotates.

  • They typically read source registers and write a result register, often setting condition flags.

• Data movement:

  • Transfer data between registers and memory (LOAD, STORE), register-to-register moves, and stack ops (PUSH/POP).

  • In load/store RISC machines, only these instructions touch memory.

• Control flow:

  • Change the program counter: unconditional jumps, conditional branches (BEQ, BNE), and calls/returns.

  • They enable loops, if/else, and procedures.

• Often a fourth: system/special: Traps/syscalls, interrupts, memory barriers, and privileged control-register access.

Endianness is the byte order used to store a multi-byte value in memory. Big-endian stores the most significant byte at the lowest address; little-endian stores the least significant byte first. A programmer must care whenever bytes cross a boundary between systems that may disagree: networking, binary file formats, and raw memory reinterpretation.

• Big-endian:

  • Most significant byte at the lowest address ("natural" reading order).

  • The value 0x12345678 is stored as bytes 12 34 56 78. Used by network protocols ("network byte order").

• Little-endian:

  • Least significant byte at the lowest address.

  • Same value stored as 78 56 34 12. Used by x86 and most ARM configs.

• When you must be aware:

  1. Networking: convert with htons/ntohl so a little-endian host and a big-endian peer agree.

  2. Binary file formats and serialization read/written on one machine and consumed on another.

  3. Type punning: casting a char* buffer to an int*, or using unions, exposes raw byte order.

  4. Cross-compilation and reading hardware/DMA buffers.

• Not an issue when: You only do arithmetic on values within one machine: the CPU handles byte order transparently.

Two's complement represents a signed integer such that the negative of a number is formed by inverting all bits and adding one; the most significant bit carries negative weight. It's preferred because it has a single representation of zero and lets the same adder hardware handle both signed and unsigned addition and subtraction with no special cases.

• How it works:

  • For N bits, the top bit has weight -2^(N-1); the rest are positive as usual.

  • To negate: flip all bits, add 1. Example (8-bit): +5 = 00000101, -5 = 11111011.

  • Range is asymmetric: -128 to +127 for 8 bits.

• Why it beats sign-magnitude:

  1. Single zero: sign-magnitude has +0 and -0, wasting a pattern and complicating comparisons.

  2. Unified arithmetic: addition and subtraction use one ordinary binary adder; no branch on the sign bit.

  3. Subtraction is just adding the negation, so hardware reuses the adder.

  4. Overflow detection is simple (carry into vs. out of the sign bit).

• Net result: Less hardware and fewer edge cases, which is why virtually all modern CPUs use it for integers.

Integer overflow occurs when the result of an operation exceeds the range representable by the fixed number of bits, so the value wraps around modulo 2^n. At the hardware level the ALU still produces the correct low n bits, but the true result no longer fits, so the sign or magnitude is wrong.

• Fixed width means modular arithmetic: An n-bit register holds results modulo 2^n; a signed 8-bit range is -128..127, so 127+1 wraps to -128.

• What the ALU actually does:

  • Two's complement addition is bitwise identical for signed and unsigned; the adder just adds the bits.

  • Signed overflow is detected when the carry into the sign bit differs from the carry out of it.

• Flags are set: The Overflow (V/OF) flag signals signed overflow; the Carry (C/CF) flag signals unsigned overflow.

• Consequence for software: Hardware does not trap by default; the wrapped value silently propagates. In C, signed overflow is undefined behavior, so compilers may assume it never happens.

Both represent negative numbers by inverting bits, but one's complement negates by flipping every bit while two's complement flips every bit and adds one. Two's complement is universally used because it has a single zero and lets one adder handle both signs.

• One's complement:

  • Negate by flipping all bits; -5 in 8 bits is the bitwise NOT of 5.

  • Has two zeros: +0 (all 0s) and -0 (all 1s), which complicates comparisons.

  • Addition needs an end-around carry (add the carry-out back into the LSB).

• Two's complement:

  • Negate by flipping all bits then adding 1.

  • Single zero, and an asymmetric range (one extra negative value, e.g. -128..127 in 8 bits).

  • Addition and subtraction use the same hardware as unsigned, with no special carry handling.

• Why two's complement won: One zero, one adder circuit, and natural wraparound make it simpler and cheaper.

Latency is how long a single operation takes from start to finish; throughput is how many operations complete per unit time. They are related but distinct: you can raise throughput by processing more work in parallel even while each individual item takes longer, which is why optimizing one can hurt the other.

• Latency: Time per task (e.g. nanoseconds per instruction, milliseconds per request). Cares about the individual.

• Throughput: Tasks per second (e.g. instructions retired per cycle, requests per second). Cares about aggregate rate.

• Why the tradeoff exists:

  • Pipelining and batching overlap work: deeper pipelines raise clock throughput but add stages, so one instruction's latency grows.

  • Buffering/queuing to keep units busy improves throughput but makes individual items wait longer.

• Analogy: An assembly line: each car still takes hours to build (latency), but a finished car rolls off every minute (throughput).

Combinational logic produces outputs that depend only on the current inputs, with no memory; sequential logic depends on both current inputs and stored past state, so it needs memory elements and usually a clock.

• Combinational:

  • Output is a pure function of present inputs (adders, multiplexers, decoders, ALUs).

  • No feedback or storage; ideally acyclic gate networks.

• Sequential:

  • Output depends on current inputs plus internal state held in flip-flops or latches (registers, counters, FSMs, memory).

  • Usually clocked so state updates synchronously on a clock edge.

• Key distinction:

  • Memory: combinational forgets instantly, sequential remembers via feedback and storage.

  • A real CPU combines both: combinational logic computes next state, registers hold current state between clock edges.

A multiplexer (mux) is a combinational circuit that selects one of several input signals to pass to its output, chosen by a set of select lines. In a CPU datapath it is the basic steering element: control signals drive mux selects to route the right value into each stage.

• Basic function:

  • An N-to-1 mux uses log2(N) select bits to pick one of N inputs.

  • Purely combinational: output = selected input, no state.

• Uses in the datapath:

  • ALU source select: choose between a register value and an immediate for the second ALU operand.

  • Write-back select: choose whether a register gets the ALU result or data loaded from memory.

  • PC source select: choose the next PC among PC+4, a branch target, or a jump target.

• Control connection: The control unit decodes the instruction and drives each mux's select line, so muxes are how control reconfigures one datapath for many instructions.

An ALU (Arithmetic Logic Unit) is the combinational block that performs the arithmetic and logical operations of the processor. In the datapath it takes two operands and an operation-select control input, and produces a result plus status flags.

• Operations it performs:

  • Arithmetic: add, subtract (and increment/compare, often reusing the adder).

  • Logic: AND, OR, XOR, NOT.

  • Shifts: left/right, logical or arithmetic (sometimes in a separate shifter).

• Inputs and outputs:

  • Two data operands and an ALU control/opcode field selecting the operation.

  • Result output plus condition flags: zero, carry, negative, overflow.

• Role in the datapath: Computes register-to-register results, effective memory addresses (base + offset), and branch comparisons (its zero flag drives branch decisions).

A register file is a small, fast array of the CPU's general-purpose registers with multiple access ports. During execution it supplies operands to the ALU and receives results, and it is accessed by register number rather than memory address.

• Structure:

  • A set of registers (e.g. 32) addressed by a small index field from the instruction.

  • Typically two read ports and one write port so a two-operand instruction can read both sources at once.

• How it is accessed per instruction:

  • Read: the source register numbers select the two read ports, and the data appears combinationally (asynchronous read).

  • Write: the destination number, write data, and a write-enable are applied; the write commits on the clock edge (synchronous write).

• Why it matters: Reading before writing within a cycle (read then edge-write) is the natural ordering; when the same register is read and written in one cycle, forwarding or read-during-write policy resolves it.

The classic 5-stage RISC pipeline breaks each instruction into Instruction Fetch, Decode, Execute, Memory, and Write-back, with pipeline registers between stages holding intermediate state. In steady state five instructions are in flight at once, one in each stage.

1. IF (Instruction Fetch): Read the instruction from the instruction cache at the address in the PC, then increment PC.

2. ID (Decode / Register read): Decode the opcode, read source operands from the register file, and sign-extend immediates.

3. EX (Execute): The ALU computes arithmetic/logic results, effective memory addresses, or evaluates branch conditions.

4. MEM (Memory access): Load reads from data cache; store writes to it. Non-memory instructions just pass through.

5. WB (Write-back): Write the ALU result or loaded value back into the destination register.

The register file is often written in the first half of a cycle and read in the second half, which lets a Decode read pick up a value being written back in the same cycle.

The principle of locality observes that programs tend to reuse data and instructions that are close in time or address. Temporal locality (recently used data is likely reused soon) and spatial locality (data near recently used addresses is likely accessed soon) are why small, fast caches capture most accesses and make the memory hierarchy effective.

• Temporal locality:

  • Recently accessed items are likely to be accessed again (loop variables, hot functions).

  • Design response: keep recently used data resident via replacement policies like LRU.

• Spatial locality:

  • Nearby addresses tend to be accessed together (array traversal, sequential code).

  • Design response: fetch multi-word cache lines (blocks) and use hardware prefetching.

• Why it matters:

  • Locality is what makes a small cache achieve a high hit rate, giving near-SRAM speed at near-DRAM capacity.

  • Poor locality (e.g. large random strides) defeats caches and causes thrashing.

A cache line (block) is the fixed-size chunk the cache moves between levels of the hierarchy: you never fetch a single byte, you fetch the whole line. 64 bytes is a sweet spot that exploits spatial locality while limiting wasted bandwidth and false sharing.

• Definition: The unit of allocation, transfer, and coherence: a miss loads one whole line and the tag/valid bits track it.

• Why bigger than one word:

  • Spatial locality: nearby data is usually accessed soon, so fetching neighbors amortizes the miss.

  • DRAM is efficient in bursts: transferring 64 bytes costs little more than 8 bytes once the row is open.

  • Fewer tags: one tag per 64 bytes is far cheaper than a tag per word.

• Why not much bigger:

  • Larger lines waste bandwidth on unused bytes and increase capacity/conflict pressure.

  • Coherence granularity: bigger lines worsen false sharing (two cores touching different variables in the same line ping-pong ownership).

All are non-volatile memory, but they differ in how (and how many times) they can be written and erased, moving from write-once at manufacture to fully in-system reprogrammable.

• ROM (mask ROM): Contents fixed during chip fabrication; cannot be changed. Cheapest at volume.

• PROM: Programmable once by the user (burning fuses/antifuses), then permanent.

• EPROM: Erasable with ultraviolet light through a quartz window, then reprogrammed; erase is whole-chip and slow.

• EEPROM: Electrically erasable and writable byte-by-byte, in-system, no UV needed. Flexible but low density and slower writes.

• Flash:

  • An EEPROM variant erased in large blocks (not per byte), giving much higher density and lower cost: used in SSDs, USB drives, firmware.

  • Finite write/erase endurance (wear), so it uses wear leveling.

The system bus is the shared set of parallel wires connecting the CPU, memory, and I/O devices; it is logically split into three groups by function: address, data, and control.

• Address bus (where):

  • Carries the memory or I/O location being accessed; unidirectional (CPU drives it).

  • Its width sets the addressable range: n lines address 2^n locations.

• Data bus (what):

  • Carries the actual value read or written; bidirectional.

  • Its width (e.g. 32/64 bits) sets how many bits move per transfer, affecting throughput.

• Control bus (how/when):

  • Carries command and timing signals: read/write, clock, bus request/grant, interrupt lines.

  • Coordinates who drives the bus and whether the operation is a read or a write.

• Together they define one transaction: control says read, address says which location, data carries the result.

Flynn's Taxonomy classifies architectures by how many instruction streams and data streams a machine processes simultaneously, giving four combinations.

• SISD (Single Instruction, Single Data): A classic sequential uniprocessor: one instruction operates on one data item at a time.

• SIMD (Single Instruction, Multiple Data): One instruction is applied to many data elements in lockstep (vector units, GPUs, SSE/AVX).

• MISD (Multiple Instruction, Single Data): Many instructions on the same data stream: rare and mostly theoretical, sometimes cited for fault-tolerant/redundant systems.

• MIMD (Multiple Instruction, Multiple Data): Independent cores each run their own instructions on their own data: multicore CPUs and clusters.

A multicore processor places multiple cores on a single chip (one socket); a multiprocessor system uses multiple separate physical chips (multiple sockets) on one board. Both are MIMD shared-memory machines, but they differ in integration and communication cost.

• Multicore (single socket):

  • Cores share on-chip resources: often a shared last-level cache, on-chip interconnect, and one memory controller path.

  • Inter-core communication is fast because it stays on-die.

• Multiprocessor (multi-socket):

  • Separate packages connected by an inter-socket link (e.g. Intel UPI, AMD Infinity Fabric).

  • Typically NUMA: each socket has its own local memory, and accessing another socket's memory is slower.

• They compose: A real server is often a multiprocessor of multicore chips, so both layers of coherence and NUMA effects apply.

The Program Counter (PC) holds the address of the next instruction to fetch, and the Instruction Register (IR) holds the instruction currently being decoded and executed. Together they drive the fetch-decode-execute cycle: the PC points, the IR processes.

• Fetch:

  • The address in the PC is sent to memory; the returned instruction is loaded into the IR.

  • The PC is then incremented to point at the following instruction (sequential flow).

• Decode: Control logic reads the opcode and operand fields held in the IR to determine what to do and which registers/operands are involved.

• Execute: The ALU/memory operation runs; results are written back to registers or memory.

• Branches change the PC: A taken branch/jump overwrites the PC with the target address instead of the incremented value, redirecting the next fetch.

An HDD stores data magnetically on spinning platters read by a moving mechanical head, while an SSD stores it electronically in NAND flash with no moving parts. The SSD is far faster (especially for random access) and more durable; the HDD is cheaper per gigabyte.

• Mechanics:

  • HDD: platters spin (e.g. 7200 RPM) and an actuator arm seeks the right track, so access involves physical latency.

  • SSD: electrical access to flash cells, no seek or rotational delay.

• Performance:

  • HDD random access is slow (milliseconds) because of seek + rotational latency.

  • SSD access is microseconds; random I/O advantage is dramatic since there's nothing to move.

  • Sequential throughput gap is smaller than the random gap, but SSDs still win.

• Durability and power:

  • SSDs tolerate shock and vibration and use less power; HDDs are vulnerable to physical damage.

  • SSD flash cells have limited write endurance, managed by wear leveling.

• Cost: HDDs offer more capacity per dollar, so they still suit bulk/archival storage.

A parity bit is a single bit added to make the number of 1s in a group even or odd, catching any single-bit flip. A checksum is a wider value computed over a whole block of data, catching many more error patterns. Parity is minimal and cheap; checksums are stronger.

• Parity bit:

  • One bit set so total 1s are even (even parity) or odd (odd parity).

  • Detects any odd number of flipped bits, but misses an even number (two flips cancel out).

  • Detect-only, no location or correction on its own.

• Checksum:

  • A multi-bit summary of a data block (e.g. sum of words, or a CRC).

  • Detects many multi-bit and burst errors that parity would miss.

  • Used at higher levels (network packets, files); costs more computation and space.

• Key difference:

  • Parity = 1 bit, weak but nearly free; checksum = wider field, much stronger coverage.

  • Neither corrects errors by itself (unlike ECC codes); they only detect.

RISC uses a small set of simple, fixed-length instructions that execute in a predictable number of cycles; CISC uses many complex, variable-length instructions that can do more per instruction. The industry converged on RISC-like internals because simple, uniform micro-operations are far easier to pipeline, decode in parallel, and clock fast.

• RISC philosophy:

  • Fixed-length, load/store architecture: only explicit loads/stores touch memory, arithmetic works on registers.

  • Simple decode enables deep pipelines and easy superscalar issue.

• CISC philosophy:

  • Variable-length instructions, memory operands, complex addressing: denser code, fewer instructions per task.

  • Historically minimized memory and hand-written assembly effort.

• Why RISC internals won:

  • Modern x86 chips decode CISC instructions into simple internal RISC-like micro-ops (μops) that a uniform backend executes.

  • This keeps the x86 software ecosystem while gaining RISC's pipelining, out-of-order execution, and clock scalability.

  • The CISC ISA becomes just a compressed front-end; the real engine is RISC-like.

The von Neumann bottleneck is the throughput gap between a fast CPU and the single shared bus/memory it must fetch both instructions and data through: the processor often stalls waiting on memory. Caches and prefetching hide this latency by keeping likely-needed data close and fetching it before it is requested.

• The core problem:

  • CPU speed has grown far faster than DRAM latency (the 'memory wall'), so a single memory path limits how fast work flows.

  • Instructions and data share the same channel, adding contention.

• Caches:

  • Small, fast SRAM levels (L1/L2/L3) exploit temporal and spatial locality to serve most accesses in a few cycles.

  • They turn the average memory access time down dramatically even though main memory is still slow.

• Prefetching:

  • Hardware detects access patterns (e.g. sequential strides) and pulls cache lines in ahead of demand.

  • Hides latency by overlapping fetch with computation.

• Complementary tricks: Out-of-order execution and load buffering let the CPU keep working around a pending miss; wider memory buses raise bandwidth.

Von Neumann uses one unified memory and bus for both instructions and data, while Harvard uses separate memories and buses for each. Modern high-performance CPUs adopt 'Modified Harvard': split L1 instruction and data caches (Harvard-like) backed by a single unified main memory (von Neumann-like), getting parallel fetch without giving up a flat address space.

• Von Neumann: Single memory holds code and data; simpler and flexible, but the shared bus is a bottleneck (can't fetch instruction and data at once).

• Harvard:

  • Separate instruction and data storage/buses allow simultaneous access; common in DSPs and microcontrollers.

  • Downside: rigid partitioning, harder to treat code as data.

• Modified Harvard (modern CPUs):

  • Separate L1 I-cache and D-cache let the pipeline fetch an instruction and access data in the same cycle.

  • Below L1, a unified L2/L3 and single physical memory preserve one address space, so software and self-modifying/JIT code still work.

  • Best of both: Harvard bandwidth at the top, von Neumann simplicity underneath.

The ISA is the contract visible to software (instructions, registers, addressing modes, memory model); the microarchitecture is the specific hardware implementation of that contract. Two processors sharing an ISA run the same binaries but differ in performance because their internal organization (pipeline depth, caches, execution units, clock) differs.

• ISA (the 'what'):

  • An abstract specification: the set of legal instructions, register names, data types, and memory semantics a programmer/compiler targets.

  • Stable and portable: e.g. x86-64, ARMv8, RISC-V.

• Microarchitecture (the 'how'):

  • How the ISA is realized: pipeline stages, out-of-order engines, branch predictors, cache sizes, number of ALUs, clock speed.

  • Invisible to correctly written software but decisive for speed and power.

• Why same software, different performance:

  • Intel and AMD both implement x86-64, but a chip with wider issue, bigger caches, and better prediction executes the identical binary faster.

  • The ISA guarantees compatibility; the microarchitecture determines how many instructions per cycle you actually get.

Beyond addressing more than 4 GB of memory, a 64-bit ISA typically brings wider registers, more of them, and native 64-bit operations, which reduce register spilling and let the CPU manipulate large values and pointers in a single instruction. On x86 specifically, the 64-bit mode also modernized the register file and calling conventions.

• Larger address space: 64-bit pointers address vastly more than the 4 GB limit of 32-bit, enabling large in-memory datasets and memory-mapped files.

• Lower register pressure:

  • x86-64 doubled general-purpose registers from 8 to 16, so compilers spill fewer values to the stack, cutting memory traffic.

  • Fewer spills means faster, tighter code.

• Native wide operations: 64-bit integer arithmetic in one instruction (crypto, hashing, big counters) instead of multi-instruction emulation on 32-bit.

• Improved conventions: x86-64 added register-based argument passing and RIP-relative addressing, aiding position-independent code and performance.

• Caveat: Wider pointers increase memory footprint and cache pressure, so the win is architectural capability, not free speed everywhere.

RISC (ARM, RISC-V) favors simple, fixed-length instructions and a load/store model optimized for pipelining and power efficiency; CISC (x86) favors rich, variable-length instructions that do more per opcode. Mobile shifted to RISC for its performance-per-watt, and servers increasingly follow because power and core density now dominate datacenter economics.

• RISC philosophy:

  • Fixed-length, uniform instructions with simple decode: cheap to pipeline and issue in parallel, small power/area overhead.

  • Load/store: only dedicated instructions touch memory, keeping the core regular.

• CISC philosophy:

  • Variable-length, feature-rich instructions and memory operands: dense code and a huge legacy software base.

  • Complex variable-length decode costs power and silicon.

• Why mobile went RISC: ARM's simpler decode gives better performance per watt, critical for battery life and thermals.

• Why servers are following:

  • At datacenter scale, energy and core count per rack matter more than raw single-thread legacy performance (e.g. AWS Graviton, Ampere).

  • RISC-V adds an open, license-free ISA, lowering barriers to custom silicon.

  • Note: much of the gap is manufacturing and design effort, not ISA alone, since modern x86 already decodes to RISC-like μops.

A load-store architecture only lets memory be touched by dedicated load and store instructions; all arithmetic and logic operate strictly on registers. This contrasts with register-memory (or memory-memory) designs where an arithmetic instruction can read an operand directly from memory.

• Load-store (typical RISC: ARM, RISC-V):

  • You must load data into a register, compute, then store the result back.

  • Instructions are uniform and simple: each does one memory or one compute job, easing pipelining.

• Register-memory (e.g. x86):

  • An instruction like ADD reg, [mem] fetches an operand from memory and computes in one instruction.

  • Denser code (fewer instructions) but variable execution time and harder decoding/pipelining.

• The core trade-off:

  • Load-store: more instructions but predictable, pipeline-friendly, and simpler hardware.

  • Memory-operand: fewer instructions but complex control and irregular timing.

A register-based architecture names explicit registers as operands for its instructions, while a stack-based architecture implicitly operates on the top of an operand stack (push operands, then an operation pops them and pushes the result). Modern physical CPUs are register-based because explicit operands enable faster access, parallelism, and easier optimization.

• Register-based:

  • Instructions name operands directly, e.g. ADD r3, r1, r2.

  • Values stay in fast registers and can be reused without reloading; more bits per instruction to encode operands.

• Stack-based:

  • Operands are implicit (top of stack), so instructions are tiny: PUSH a, PUSH b, ADD.

  • Compact code and simple compilers; common in virtual machines like the JVM and CPython.

• Why hardware chooses registers:

  • The strict top-of-stack ordering serializes operations and creates a bottleneck; registers expose independent operands for out-of-order and parallel execution.

  • Register access avoids the extra memory/stack traffic and enables register allocation optimizations.

  • Stack ISAs survive as portable bytecode targets, then get JIT-compiled onto register hardware.

An instruction is a fixed pattern of bits split into fields: an opcode that says what operation to do, plus operand fields that name registers, immediates, or memory addresses. Good encoding design balances decoding simplicity, code density, and enough bits to name everything the ISA needs.

• Opcode field:

  • Selects the operation; its width bounds how many distinct instructions exist.

  • May be split into a primary opcode plus a function/sub-op field (e.g. MIPS funct).

• Operand fields:

  • Register specifiers (a 5-bit field names 32 registers), immediate constants, or address/offset bits.

  • An addressing-mode field can indicate how to interpret an operand.

• Why encoding matters:

  1. Decode speed: fixed-length, few formats (RISC) let hardware decode in parallel; variable-length (x86) is denser but harder to decode.

  2. Code density: tighter encodings shrink program size and improve instruction-cache hit rates.

  3. Field placement: keeping register specifiers in the same bit positions across formats lets the CPU start reading registers before decode finishes.

  4. Extensibility: reserved opcode space leaves room for future instructions.

• Trade-off in one line: Every bit spent on the opcode is a bit unavailable for operands, so encoding is a tug-of-war between operation count and operand reach.

A call saves the return address and jumps to the callee; a return pops that address back into the PC. The hardware stack (a memory region tracked by a stack pointer) provides the LIFO storage for return addresses, saved registers, and locals, and a calling convention is the agreed contract for how caller and callee use it.

• Call/return mechanics:

  • A CALL saves the return address (on the stack or in a link register) and sets the PC to the target.

  • A RET restores that address into the PC.

  • Nesting works because the stack is LIFO: each call pushes its frame, each return pops it.

• The stack pointer and frame:

  • A stack pointer (SP) marks the top; each call allocates a stack frame holding return address, saved registers, arguments, and locals.

  • An optional frame pointer (FP/BP) gives a stable base for accessing locals as the SP moves.

• Calling convention (the contract):

  1. Argument passing: which registers vs. stack, and in what order.

  2. Return value: which register carries it.

  3. Register preservation: caller-saved (volatile) vs. callee-saved registers.

  4. Stack cleanup and alignment rules.

• Why it matters: Separately compiled code and libraries interoperate only because everyone follows the same ABI convention.

0.1 + 0.2 != 0.3 because those decimals have no exact finite representation in binary, just as 1/3 has no exact finite decimal. Each is rounded to the nearest representable IEEE-754 value, and the tiny rounding errors add up to something like 0.30000000000000004. IEEE-754 stores a number as three fields: a sign bit, a biased exponent, and a mantissa (significand).

• Why the inequality happens:

  • 0.1 and 0.2 are repeating fractions in base 2, so they're stored as the nearest 64-bit approximation.

  • Their sum rounds to a value slightly above the stored representation of 0.3.

  • Fix: compare with a tolerance (epsilon) or use decimal/fixed-point types for exact decimals (money).

• IEEE-754 layout (double = 64 bits):

  1. Sign (1 bit): 0 positive, 1 negative.

  2. Exponent (11 bits): stored with a bias of 1023, so it encodes both large and small magnitudes.

  3. Mantissa/fraction (52 bits): the significant digits, with an implicit leading 1 for normalized numbers.

• Value formula: value = (-1)^sign x 1.mantissa x 2^(exponent - bias); single precision uses 8 exponent and 23 mantissa bits.

• Key takeaway: Floating point trades exactness for range; never test equality on results of float math.

The bit pattern itself carries no sign; the instruction the CPU executes determines whether bits are interpreted as signed or unsigned. Addition and subtraction are identical for both in two's complement, but comparisons, multiplication, division, and shifts come in separate signed and unsigned forms.

• Add/subtract are shared: Two's complement makes the bit-level result identical; only which overflow flag matters differs (OF for signed, CF for unsigned).

• Comparisons differ:

  • Signed comparisons use the sign and overflow flags (jl, jg); unsigned use the carry flag (jb, ja).

  • Example: 0xFF is -1 signed but 255 unsigned, so ordering flips.

• Shifts and widening differ:

  • Arithmetic shift right (sar) sign-extends; logical shift right (shr) fills with zeros.

  • Sign-extension vs zero-extension when widening a value to a larger register.

• Mul/div differ: Separate opcodes: imul/idiv (signed) vs mul/div (unsigned).

IEEE-754 reserves the extreme exponent fields to encode special values. An all-ones exponent means infinity (zero fraction) or NaN (nonzero fraction); an all-zeros exponent means zero (zero fraction) or a subnormal (nonzero fraction), which fills the gap between zero and the smallest normal number.

• Infinity: Exponent all 1s, fraction 0; sign bit gives +∞ or -∞. Produced by overflow or 1.0/0.0.

• NaN:

  • Exponent all 1s, fraction nonzero. Result of undefined operations like 0/0 or ∞-∞.

  • Quiet NaN (top fraction bit set) propagates silently; signaling NaN raises an exception. NaN != NaN.

• Subnormals (denormals):

  • Exponent all 0s, fraction nonzero. The implicit leading bit is 0 instead of 1, giving gradual underflow toward zero.

  • They preserve precision near zero but are often slow (may trap to microcode or a slow path).

• Signed zero: Exponent and fraction both 0; +0 and -0 compare equal but differ (e.g. 1/+0 = +∞, 1/-0 = -∞).

The exponent bias is a fixed constant added to the true exponent before storing it, so the stored exponent field is always a nonnegative unsigned integer. It is used so that floating-point values can be compared and sorted using ordinary integer comparison of their bit patterns.

• How it works:

  • Stored exponent = true exponent + bias; single precision bias is 127 (8-bit field), double is 1023 (11-bit field).

  • A true exponent of 0 is stored as 127, so the field ranges over all nonnegative values.

• Why biased instead of two's complement:

  • Monotonic ordering: larger magnitude means larger bit pattern, so hardware can compare floats as integers (for same sign).

  • This also lets a single ordering handle the transition from subnormals to normals smoothly.

• Reserved extremes: Stored 0 and all-1s are reserved for zero/subnormals and infinity/NaN, so the usable true exponent range is slightly narrower.

Both store one bit, but a latch is level-sensitive (transparent while its enable is active) whereas a flip-flop is edge-triggered (samples only at a clock edge). Synchronous designs prefer flip-flops because updating state on a single clock edge makes timing predictable and analyzable.

• Latch: level-sensitive:

  • Output follows input the whole time the enable/gate is high (transparent), so input changes during that window pass straight through.

  • Cheaper (fewer gates), but the transparency window makes timing and glitch behavior hard to reason about.

• Flip-flop: edge-triggered:

  • Captures the input only at the rising (or falling) clock edge and holds it for the rest of the cycle.

  • Effectively built from two latches (master-slave) so there is no transparent window.

• Why synchronous designs favor flip-flops:

  • State changes at one well-defined instant per cycle, so setup/hold timing and max frequency are easy to compute.

  • Avoids race-through: combinational logic can settle during the cycle without feeding back through a transparent latch.

Propagation delay is the time it takes for a change at a gate's (or path's) input to produce a stable, valid output. The longest such delay through the combinational logic between registers (the critical path) sets how fast you can clock the circuit.

• What it measures: Delay from input transition to output settling, accumulated across gates in series along a path.

• Critical path determines the clock period:

  • Data launched by one flip-flop must reach and satisfy the next flip-flop's setup time before the next edge.

  • Minimum period Tclk >= Tcq + Tlogic + Tsetup (launch clock-to-Q, worst-case combinational delay, and setup at the capture register).

• Max frequency:

  • fmax = 1 / Tclk(min): a longer critical path means a lower maximum clock frequency.

  • This motivates pipelining: split long logic into shorter stages so each stage's delay (and thus the period) shrinks.

The clock is the global timing reference that tells every state element when to update: on each clock edge, flip-flops sample their inputs together, so the whole machine advances in lockstep. Clock skew is the difference in arrival time of that same clock edge at different flip-flops.

• Role of the clock:

  • Defines discrete time steps: combinational logic settles during a cycle, and results are latched at the edge.

  • Keeps all registers synchronized so data moves stage-to-stage predictably.

• Clock skew:

  • The clock edge does not reach every flip-flop simultaneously due to wire length and buffering differences.

  • Positive skew (capture clock late) can relax setup timing but worsens hold timing.

  • Large or unmanaged skew causes hold violations (data races through) or eats into the cycle budget, limiting frequency.

• Mitigation: Balanced clock distribution networks (e.g. clock trees) minimize skew across the chip.

Both control units generate the control signals that drive the datapath, but they differ in how those signals are produced: a hardwired unit uses fixed combinational/sequential logic, while a microprogrammed unit reads control signals from a small memory of microinstructions.

• Hardwired control:

  • Control signals come from logic gates and a state machine decoding the opcode directly.

  • Fast and area-efficient, but rigid: changing behavior means redesigning the logic.

  • Favored by simple/regular ISAs like RISC.

• Microprogrammed control:

  • Each machine instruction maps to a sequence of microinstructions stored in a control store (ROM); each microinstruction's bits are the control signals.

  • Flexible and easy to modify or patch, and handles complex/variable instructions cleanly.

  • Slower (extra control-store fetch per step) and uses more storage; favored by complex CISC ISAs.

• Trade-off summary: Hardwired trades flexibility for speed; microprogrammed trades speed for design flexibility.

A single-cycle datapath executes every instruction in one clock cycle, while a multi-cycle datapath breaks execution into several shorter steps that each take one cycle. The choice trades clock speed and hardware reuse against per-instruction cycle count.

• Single-cycle:

  • One instruction completes per cycle; CPI = 1.

  • Clock period must cover the slowest instruction's full path (e.g. load: fetch + read regs + ALU + memory + write-back), wasting time on fast instructions.

  • Needs duplicated resources (separate adders, no unit reused within an instruction).

• Multi-cycle:

  • Splits work into steps (fetch, decode, execute, memory, write-back); shorter cycle set by the slowest single step.

  • Instructions take varying cycle counts (CPI > 1), so simple instructions finish faster.

  • Reuses hardware across steps (e.g. one ALU for address and arithmetic) but needs internal registers to hold intermediate values.

• Trade-offs:

  • Single-cycle: simpler control, but a long, wasteful clock period.

  • Multi-cycle: higher clock frequency and less duplicated hardware, at the cost of more control complexity and multiple cycles per instruction.

  • Multi-cycle staging is also the conceptual stepping stone to pipelining.

The three pipeline hazards are structural, data, and control hazards. A data hazard occurs when an instruction needs a result that an earlier, still in-flight instruction hasn't written back yet; forwarding fixes many of these by routing the freshly computed value directly from a later stage back to the input of the ALU.

1. Structural hazard: Two instructions need the same hardware resource in the same cycle (e.g. one memory port for both fetch and load).

2. Data hazard: An instruction depends on the result of a prior one not yet written to the register file (classic RAW).

3. Control hazard: A branch changes the PC, so instructions fetched after it may be wrong.

Example of a RAW data hazard and forwarding:

• The sequence below has a dependency on x1.

• Without forwarding, the second instruction would read x1 in Decode before the first writes it in Write-back, needing several stall cycles.

• With forwarding, the ALU result of the first instruction (available at end of Execute / in the EX/MEM latch) is fed straight into the ALU input of the second, so it runs with zero stalls.

Note: a load-use hazard (lw followed by an immediate use) still costs one stall, because the loaded value isn't ready until after the Memory stage.

Pipelining overlaps the execution of multiple instructions by splitting each instruction into sequential stages, so that different instructions occupy different stages in the same cycle. This raises throughput (instructions finishing per unit time) without shortening the time any single instruction takes end to end.

• The core idea (assembly-line analogy): Each stage does one piece of work and hands off via pipeline registers; ideally a new instruction enters every cycle.

• Throughput improves: In steady state one instruction completes per cycle, so an N-stage pipeline approaches an N-fold speedup in instruction rate.

• Latency does not decrease (often slightly worsens): A single instruction still traverses all N stages; adding pipeline-register delay and clock skew can make its total latency slightly longer.

• Why the clock can go faster: The cycle time is set by the slowest single stage, not the whole instruction, so a finer split allows a higher clock.

• Limits: Hazards, stalls, and register overhead keep the real speedup below the ideal N.

Forwarding resolves a RAW hazard by taking the result the moment it is computed in a later pipeline stage and routing it directly to the input of the stage that needs it, bypassing the register file rather than waiting for the value to be written back and re-read.

• The problem: The register file is normally written in Write-back and read in Decode, so a dependent instruction would read a stale value for several cycles.

• The fix: Extra datapaths (multiplexers) feed the value from the EX/MEM or MEM/WB pipeline latch back to the ALU inputs.

• How forwarding is detected: Hardware compares the destination register of the older instruction against the source registers of the younger one; on a match it selects the forwarded value over the register-file value.

• What forwarding cannot fully hide: A load-use dependency still needs one bubble, since the data arrives only after the Memory stage.

Adding pipeline stages (deeper pipelining) generally raises throughput by allowing a higher clock frequency, but it tends to increase per-instruction latency and makes hazards more expensive. There's a sweet spot beyond which more stages hurt.

• Throughput: typically improves: Shorter, finer stages mean a shorter critical path per stage, so the clock can run faster and more instructions complete per second in steady state.

• Latency: typically worsens slightly: Each stage adds pipeline-register (latch) delay and clock skew overhead, so the total time through more stages grows even though each stage is shorter.

• Hazard penalties grow: Deeper pipelines mean longer branch mispredict penalties and more distance to cover with forwarding, raising stall costs.

• Diminishing returns: Beyond a point, latch overhead and increased stalls outweigh the clock gain (the reason very deep pipelines like early Pentium 4's 20-31 stages were abandoned).

A pipeline bubble (stall) is a no-op inserted into the pipeline to delay dependent instructions until a hazard clears, effectively wasting cycles. Compared with branch prediction, stalling is safe but slow; prediction speculatively keeps the pipeline full and only pays a penalty when it's wrong.

• What a bubble is: Control logic freezes earlier stages and feeds a NOP downstream so a hazard (load-use, unresolved branch, resource conflict) doesn't produce a wrong result.

• Cost of stalling: Every bubble is a lost slot: it directly lowers IPC, and for branches the penalty scales with how deep the branch resolves.

• Branch prediction as the alternative:

  • Guess the branch outcome and keep fetching speculatively; a correct guess costs zero bubbles.

  • A misprediction must squash the wrongly fetched instructions and refill the pipeline, so the penalty equals the pipeline depth to the resolution point.

• The trade-off: Always stalling is simple and predictable but slow; prediction wins when accuracy is high (modern predictors exceed 95%), which is why real CPUs predict rather than stall on branches.

A simple pipelined processor overlaps stages of consecutive instructions but still issues at most one instruction per cycle (peak IPC of 1). A superscalar processor has multiple parallel pipelines/functional units and issues several instructions per cycle (IPC > 1), exploiting instruction-level parallelism in width, not just depth.

• Scalar pipeline:

  • Improves throughput by overlapping fetch/decode/execute of different instructions, but one instruction enters per cycle.

  • Parallelism comes from pipeline depth (temporal overlap).

• Superscalar:

  • Duplicated resources (multiple ALUs, load/store units) let it fetch, decode, and issue N instructions per cycle.

  • Parallelism comes from pipeline width (spatial overlap), often combined with OoO scheduling.

  • Needs wider fetch, dependency-check logic across the issue group, and more register-file ports.

• Note: superscalar and OoO are orthogonal: a superscalar can be in-order, and depth (pipelining) and width (superscalar) are complementary techniques.

On a write, a write-through cache updates both the cache and the next level immediately, while a write-back cache updates only the cache line and marks it dirty, writing to memory later on eviction. Write-back reduces memory traffic and is standard for CPU caches; write-through gives simpler coherence and reliability at the cost of bandwidth.

• Write-through:

  • Every write goes to memory, so lower level always has current data (simple, consistent).

  • High write bandwidth; usually paired with a write buffer to hide latency.

  • Good when reliability/coherence simplicity matters or writes are infrequent.

• Write-back:

  • Writes accumulate in the cache; a dirty bit marks modified lines, flushed only on eviction.

  • Much less memory traffic when a line is written repeatedly (great locality of writes).

  • More complex: needs dirty tracking and careful handling in multi-core coherence.

• Choosing:

  • Modern L1/L2/L3 CPU caches use write-back for bandwidth efficiency.

  • Write-through appears where simplicity or immediate visibility outweighs bandwidth (some L1s, certain embedded/IO cases).

These describe how many cache locations a given memory block may occupy. Direct-mapped allows exactly one location (fast, cheap, but conflict-prone), fully-associative allows any location (fewest conflicts, expensive to search), and set-associative is the middle ground: a block maps to one set of N ways. The trade-off is hit time and hardware cost versus miss rate.

• Direct-mapped:

  • One possible slot per block: a single tag compare, so lowest hit time and simplest hardware.

  • Suffers conflict misses when hot blocks map to the same index.

• Fully-associative:

  • A block can go anywhere, so only capacity and compulsory misses remain (no conflict misses).

  • Requires comparing all tags in parallel (CAM): costly power/area, so only used for small structures like TLBs.

• Set-associative (N-way):

  • Block maps to a set, then any of N ways within it: N parallel tag compares.

  • Balances low miss rate with acceptable hit time; needs a replacement policy (LRU, pseudo-LRU).

• Trade-off summary: More associativity lowers miss rate but raises hit time, energy, and complexity (diminishing returns past ~8-way).

The 3 C's classify why a cache miss happens: Compulsory (first-ever access), Capacity (cache too small to hold the working set), and Conflict (too many active blocks map to the same set). Conflict misses are the ones software can attack directly, mostly by changing access patterns and data layout.

• Compulsory (cold) misses: The first reference to a block: it was never in the cache. Reduced by larger blocks or prefetching, not by more capacity.

• Capacity misses: The working set exceeds cache size, so useful blocks get evicted and re-fetched. Fixed by shrinking the working set (blocking/tiling) or a bigger cache.

• Conflict (collision) misses: Blocks that would fit in a fully associative cache collide because they map to the same set in a direct-mapped or low-associativity cache.

• How software reduces conflict misses:

  • Avoid power-of-two strides/array dimensions that make rows alias to the same set: pad arrays (e.g. size 257 instead of 256).

  • Use array-of-structs vs struct-of-arrays deliberately so co-accessed fields don't fight for one set.

  • Apply loop blocking/tiling to keep reuse within a set-friendly footprint.

  • Align hot data so multiple buffers don't repeatedly collide.

AMAT is the expected time to service a memory reference, accounting for hits and misses. The base formula is AMAT = HitTime + MissRate × MissPenalty, and for multiple levels you make the miss penalty itself the AMAT of the next level down.

• Single level: Hit time is the time when data is found in cache; miss penalty is the extra cost to fetch from the next level.

• Multi-level (recursive): The L1 miss penalty equals the L2 AMAT: AMAT = HitL1 + MissRateL1 × (HitL2 + MissRateL2 × PenaltyMem).

• Local vs global miss rate: Local: misses at that level ÷ accesses to that level. Global: misses at that level ÷ total CPU references. Use local rates in the recursive form.

• Insight: Adding levels lowers the effective miss penalty so a small fast L1 can keep a low hit time while a large L2/L3 catches most misses.

Replacement policies decide which line to evict in an associative set. LRU exploits temporal locality best in theory, but true LRU is expensive to track, so hardware uses FIFO, random, or LRU approximations that get most of the benefit at a fraction of the cost.

• LRU (Least Recently Used):

  • Evicts the block unused longest: usually the best hit rate because past reuse predicts future reuse.

  • Cost: must maintain full ordering of all ways per set, so bits/updates grow roughly with the log-factorial of associativity, expensive beyond a few ways.

• FIFO: Evicts the oldest-inserted line regardless of use: just a per-set counter, cheaper than LRU but ignores reuse and can suffer Belady's anomaly.

• Random: Picks a victim at random: almost free, no state, and surprisingly close to LRU at high associativity while avoiding pathological patterns.

• True LRU trade-offs:

  • Storage and update logic scale badly with ways; every access rewrites the order, adding latency/power.

  • Real chips use approximations: pseudo-LRU (tree bits), NRU/clock, or aging bits, which capture most of LRU's benefit cheaply.

On a write miss, the question is whether to bring the missing line into the cache before writing. Write-allocate fetches the line first and then writes it; no-write-allocate writes straight to the next level and skips the cache. The choice is usually paired with the write-hit policy.

• Write-allocate (fetch-on-write):

  • Loads the line into cache on a write miss, then applies the write, so later reads/writes to that line hit.

  • Wins when writes are followed by reuse; typically paired with write-back.

• No-write-allocate (write-around):

  • Sends the write to the next level and does not allocate a cache line, leaving the cache unchanged on the miss.

  • Wins for streaming/one-time writes that won't be re-read soon; typically paired with write-through.

• Common pairings:

  • Write-back + write-allocate: keep dirty data local and exploit write locality.

  • Write-through + no-write-allocate: avoid polluting the cache with data pushed through anyway.

A unified cache holds both instructions and data in one structure; a split cache uses separate instruction (I-cache) and data (D-cache) arrays. L1 is usually split so the pipeline can fetch an instruction and access data in the same cycle, while lower levels stay unified for flexibility.

• Split cache: Dedicated I-cache and D-cache with independent ports, tuned separately (instruction access is read-mostly/sequential).

• Unified cache: One pool serves both, so capacity is shared dynamically and there's no duplication; simpler but can't do two accesses at once cheaply.

• Why L1 is split:

  • Bandwidth: fetch and load/store happen concurrently, avoiding a structural hazard on a single-ported cache.

  • Specialization: each cache is sized/associativity-tuned to its access pattern and placed near the relevant pipeline stage.

• Why L2/L3 stay unified: Bandwidth pressure is lower and workloads vary, so a shared pool uses capacity more efficiently.

A cache splits a physical address into three fields from the low bits up: the offset selects the byte within a line, the index selects which set to search, and the tag identifies which block is actually stored there. The split is driven by line size, number of sets, and associativity.

• Offset (lowest bits): Width = log2(line size in bytes): for a 64-byte line, 6 bits pick the byte/word within the line.

• Index (middle bits): Width = log2(number of sets), where sets = cacheSize / (lineSize × associativity): selects the one set to probe.

• Tag (upper bits): The remaining high bits, stored alongside each line and compared against all ways in the indexed set to detect a hit.

• Associativity effect: More ways = fewer sets = smaller index and larger tag. Fully associative has no index (one set); direct-mapped has one way per set.

Prefetching brings data or instructions into the cache before they're demanded, so the miss latency overlaps with useful work instead of stalling the pipeline. Hardware prefetchers do this automatically by detecting access patterns; software can also issue explicit prefetch hints.

• The core idea: Latency to DRAM is hundreds of cycles; if you fetch early, the line is already present when the real access arrives, converting a miss into a hit.

• Hardware prefetchers:

  • Next-line: fetch line N+1 on access to N, exploiting sequential locality.

  • Stride/stream: detect fixed-distance patterns (e.g. array walks) and run ahead of the access stream.

• Software prefetch: Explicit hints (e.g. __builtin_prefetch / PREFETCH) for irregular patterns hardware can't predict, issued far enough ahead to hide latency.

• Risks: Cache pollution and wasted bandwidth if predictions are wrong; prefetching too late hides no latency, too early may evict the data before use.

The TLB (Translation Lookaside Buffer) is a small, fast cache of recent virtual-to-physical page translations that sits between the CPU and the page tables, letting the MMU avoid a slow page-table walk on most memory accesses.

• Role in the hierarchy:

  • Caches page translations so address translation happens in a cycle or two instead of walking the multi-level page table in DRAM.

  • Sits on the critical path of every load/store, so a hit is essential for performance.

• TLB miss:

  • The translation isn't cached, so the MMU (or OS) walks the page table to find the mapping and refills the TLB.

  • Relatively cheap: the page is still in physical memory, just not in the TLB. Costs a page-table walk (tens of cycles).

• Page fault:

  • The page-table walk finds the page is not present in physical memory (or a permission violation).

  • Very expensive: a trap to the OS, disk I/O to fetch the page (millions of cycles), then retry the instruction.

• Key distinction: a TLB miss is a hardware caching event; a page fault is a software/OS event handled by the kernel.

A page fault is an exception raised when a program accesses a virtual page that has no valid mapping to a resident physical frame, forcing the OS to intervene and either bring the page in or signal an error.

• Trigger during translation: On a TLB miss the MMU walks the page table and finds the present/valid bit clear, or a permission bit violated.

• Hardware trap: The CPU raises a fault exception, saves state (faulting address in a register like CR2 on x86), and jumps to the OS page-fault handler.

• OS handling:

  1. Classify the fault: minor (page in memory but not mapped, e.g. copy-on-write), major (must read from disk/swap), or invalid.

  2. If invalid, deliver a signal (e.g. SIGSEGV); otherwise allocate/locate a frame.

  3. For a major fault, issue disk I/O to load the page, possibly evicting another page.

  4. Update the page table entry (set present bit, physical frame number).

• Resume: Control returns and the faulting instruction is re-executed; this time the walk succeeds and refills the TLB.

• Cost: major faults are millions of cycles (disk latency), which is why working sets should fit in RAM.

The MMU splits a virtual address into a page number and an offset, uses the page number to index the page table and obtain a physical frame number, then concatenates that frame with the unchanged offset to form the physical address.

• Address decomposition: High bits = virtual page number (VPN); low bits = offset within the page (e.g. 12 bits for a 4 KB page).

• Lookup:

  • The MMU checks the TLB first; on a hit it gets the physical frame number (PFN) immediately.

  • On a miss it walks the page table (rooted at a register like CR3) using the VPN to find the page table entry (PTE).

• PTE contents:

  • Holds the PFN plus control bits: present/valid, read/write, user/supervisor, dirty, accessed.

  • The MMU checks these bits and raises a fault if the page is absent or the access is not permitted.

• Assembly: Physical address = PFN concatenated with the original offset (the offset is never translated).

The Memory Wall is the growing performance gap between fast CPUs and comparatively slow DRAM: processor speed improved far faster than memory latency, so the CPU increasingly stalls waiting for data rather than computing.

• The diverging trends:

  • CPU throughput grew rapidly for decades while DRAM latency improved only slowly (bandwidth improved more than latency).

  • Result: a main-memory access can cost hundreds of CPU cycles, during which many instructions could have run.

• Why it's a bottleneck:

  • Real programs touch memory constantly; a cache miss to DRAM stalls the pipeline and starves execution units.

  • Compute is often "free" relative to fetching operands, so memory latency, not ALU speed, limits many workloads.

• Mitigations:

  • Deep cache hierarchies (L1/L2/L3) to keep hot data close.

  • Latency hiding: out-of-order execution, prefetching, and multithreading (SMT) to overlap misses with other work.

  • More bandwidth and locality: wider memory channels, HBM, and cache-friendly data layouts.

• Takeaway: modern performance tuning is largely about locality and hiding memory latency, not reducing instruction count.

Memory alignment means storing a data object at an address that is a multiple of its size (or a natural boundary), because processors and memory systems access memory in fixed-width chunks and expect operands on those boundaries.

• What alignment means:

  • A 4-byte int aligned means its address is divisible by 4; an 8-byte double by 8, etc.

  • Compilers add padding inside structs to keep each field naturally aligned.

• Why hardware wants it:

  • Memory is fetched in aligned words/cache lines; an aligned value sits within a single chunk, so one access retrieves it.

  • Simplifies the memory interface and lets the data bus deliver the value in one transaction.

• Penalty of unaligned access:

  • The value straddles two words or two cache lines, so the CPU issues two accesses and merges the pieces: extra latency.

  • Worst case it crosses a page boundary, touching two TLB entries or triggering two faults.

  • On strict architectures (some ARM/RISC modes) an unaligned access is illegal and faults instead of being slow.

• Extra considerations:

  • Atomic operations usually require alignment to be genuinely atomic.

  • SIMD instructions often demand stronger alignment (16/32/64 bytes).

SRAM is fast but expensive and low-density, so it fits caches; DRAM is slow but cheap and dense, so it fits large main memory. The difference comes from how each cell stores a bit.

• SRAM cell: 6 transistors:

  • A cross-coupled latch (typically 6T) actively holds its value as long as power is on, no refresh needed.

  • Fast (sub-nanosecond access) but large area per bit, so low density and high cost per bit.

• DRAM cell: 1 transistor + 1 capacitor:

  • A bit is stored as charge on a tiny capacitor, gated by one transistor: extremely small, so high density and low cost.

  • Charge leaks away, so it must be periodically refreshed; access is slower and destructive (read then rewrite).

• Why the split:

  • Caches need the lowest latency and are small, so paying for SRAM is worth it.

  • Main memory needs gigabytes of capacity cheaply, so DRAM's density wins despite slower access.

Structure padding is the insertion of unused bytes between struct members (and at the end) so each member starts at an address that satisfies its alignment requirement, which lets the CPU access it in a single efficient memory operation.

• Alignment rule:

  • A type of size N typically must sit at an address that is a multiple of N (a 4-byte int at a 4-byte boundary).

  • Misaligned access is slower or faults on some architectures.

• Internal padding: The compiler inserts gap bytes before a member whose offset would otherwise be misaligned.

• Trailing padding: The struct size is rounded up to a multiple of its largest member's alignment, so arrays of the struct stay aligned.

• Practical tip: Ordering members from largest to smallest minimizes wasted padding.

DRAM stores each bit as charge on a capacitor that slowly leaks away, so every cell must be read and rewritten periodically (refresh) to preserve its value. This steals bandwidth and consumes power even when memory is idle.

• Why refresh is needed:

  • Capacitor charge leaks over time (roughly every 64 ms per row), so the controller rereads and restores each row before it decays.

  • DRAM reads are also destructive, so a normal read already rewrites the row via the sense amplifiers.

• Performance impact:

  • During a refresh cycle the affected bank is busy and cannot serve requests, adding occasional stalls.

  • Refresh overhead grows with capacity and gets worse at high temperature (leakage increases).

• Power impact:

  • Refresh burns power continuously, which is why DRAM has significant static/background power (a key reason SRAM caches, though not refreshed, differ).

  • Contrast: SRAM holds state without refresh but still leaks; flash is non-volatile and needs no refresh at all.

DMA is a hardware controller that transfers data directly between an I/O device and memory without the CPU moving each word. It is more efficient than programmed I/O because the CPU only sets up the transfer and is then free to do other work while the DMA controller handles the bulk movement.

• Programmed I/O (PIO):

  • The CPU executes a load/store for every word, so it is fully occupied for the whole transfer.

  • Fine for a few bytes, terrible for large blocks (disk/network buffers).

• How DMA works:

  • CPU programs the controller with source, destination, and count, then continues other work.

  • The DMA controller becomes bus master and moves the block; it raises an interrupt when done.

• Why it's more efficient:

  • CPU overhead is O(1) per transfer instead of O(N) per word, so the CPU overlaps computation with I/O.

  • Cost: DMA and CPU contend for the memory bus (cycle stealing), and DMA writes can leave caches stale, requiring coherence/snooping or cache flushes.

Interrupts let the device notify the CPU only when it needs service, freeing the CPU meanwhile; polling has the CPU repeatedly check a status register. Interrupts win for slow or infrequent events, but polling is more efficient when the device is very fast and almost always ready, because it avoids interrupt overhead.

• Interrupts:

  • CPU does useful work until the device signals, so no wasted cycles on idle devices.

  • Cost per event: context save/restore, handler dispatch, and pipeline/cache disruption (latency and overhead per interrupt).

• Polling: Simple, deterministic, low latency to notice readiness, but burns CPU cycles spinning when the device isn't ready.

• When polling wins:

  • High-throughput, low-latency devices where events arrive faster than interrupt overhead can be amortized: e.g. 10/40 GbE NICs (Linux NAPI, DPDK) and NVMe SSDs poll because per-packet/per-request interrupts would swamp the CPU.

  • Hybrid schemes (interrupt to wake, then poll a batch) get the best of both.

Both are ways to talk to device registers. Memory-mapped I/O (MMIO) assigns device registers addresses in the normal memory address space, so ordinary load/store instructions access them; port-mapped I/O (PMIO) uses a separate I/O address space with dedicated instructions. In MMIO the CPU distinguishes I/O from RAM purely by address: the address decoder routes certain address ranges to devices.

• Memory-mapped I/O:

  • Devices occupy real addresses; any memory instruction works, so no special opcodes and full addressing modes apply.

  • Costs address space and requires those regions be marked non-cacheable so writes/reads aren't reordered or cached.

• Port-mapped I/O:

  • Separate I/O space accessed with special instructions (x86 IN/OUT); a control line tells hardware this is an I/O cycle, not a memory cycle.

  • Keeps the memory map free but needs dedicated instructions and is x86-specific in practice.

• How MMIO is distinguished:

  • The system's address decoder watches the address bus and asserts the device's chip-select for its assigned range, forwarding those accesses to the device instead of DRAM.

  • So the CPU issues the same load/store; the routing happens in the memory/bus fabric by address.

All three transfer control to the OS via the same mechanism, but they differ in cause and timing: interrupts are asynchronous and external, while traps and exceptions are synchronous side-effects of executing an instruction.

• Interrupt (asynchronous, external):

  • Raised by hardware (timer, disk, NIC) independent of the running instruction; can occur between any two instructions.

  • Not tied to the current program; the CPU services it and resumes exactly where it left off.

• Exception / fault (synchronous, involuntary):

  • Triggered by an error condition during execution: divide-by-zero, page fault, invalid opcode, protection violation.

  • Often re-executes the offending instruction after the OS fixes the condition (e.g. loads the missing page).

• Trap (synchronous, deliberate):

  • An intentional software-generated event, typically a system call (syscall) or breakpoint.

  • Control returns to the instruction after the trap, since it completed its purpose.

• Common thread: all vector through an interrupt/trap table into a privileged handler, saving CPU state so execution can resume.

Bus arbitration is the mechanism that decides which of several competing devices (bus masters) gets to drive a shared bus at a given time, preventing two devices from transmitting simultaneously and corrupting signals.

• Why it's needed:

  • A bus is a shared electrical medium; only one master may drive the lines at once or the data collides.

  • Multiple masters (CPU, DMA controllers, other cores) may all want the bus concurrently.

• Centralized arbitration:

  • A single arbiter grants access via request/grant lines.

  • Daisy chaining (priority by position) or independent request lines with a priority scheme.

• Distributed arbitration: No central controller; devices resolve contention among themselves (e.g. self-selection by ID or collision detection).

• Goals and trade-offs: Must balance priority (fast service for critical devices) with fairness (avoid starving low-priority ones).

Interrupt vectoring is the technique where each interrupt source is associated with an identifying number (vector) that indexes a table of handler addresses, so the CPU jumps directly to the correct Interrupt Service Routine without polling.

• The vector table (IDT / IVT): A table in memory mapping vector numbers to handler entry points; the CPU knows its base address from a dedicated register.

• How the vector is obtained:

  • The interrupting device or interrupt controller supplies the vector number on the bus during acknowledgment.

  • The CPU multiplies it by the entry size and adds the table base to locate the handler address.

• On dispatch: CPU saves current state (PC, flags), loads the handler address, and switches to kernel mode.

• Contrast with non-vectored / polled interrupts: There all devices share one handler that must poll each device to find the source, which is slower.

Simultaneous Multithreading (Intel's Hyper-Threading) lets one physical core run two (or more) hardware threads at once by duplicating architectural state but sharing the execution engine, so the core fills otherwise-idle execution units. Two physical cores instead duplicate the entire core, giving truly independent execution resources.

• What SMT duplicates vs shares:

  • Duplicated per thread: register file, program counter, and other architectural state (so the OS sees two logical CPUs).

  • Shared: execution units, ALUs, caches, and the physical pipeline.

• Why it helps: When one thread stalls (cache miss, dependency), the core issues instructions from the other thread, improving execution-unit utilization.

• How two physical cores differ:

  • Each has its own full set of execution units and (typically) L1/L2 caches, so they run in parallel with no resource sharing at that level.

  • Two cores scale near 2x; SMT usually adds only ~20-30% since resources are shared.

• Implication: SMT shines on mixed/stall-heavy workloads; two threads contending for the same execution units (e.g. both compute-bound) see little gain.

Flynn's Taxonomy classifies computer architectures by how many instruction streams and data streams operate concurrently, giving four categories: SISD, SIMD, MISD, and MIMD. The two most relevant today are SIMD (one instruction applied to many data elements) and MIMD (independent instructions on independent data).

• The four classes:

  • SISD: one instruction stream, one data stream (a classic single-core scalar CPU).

  • SIMD: one instruction stream applied to multiple data streams in lockstep.

  • MISD: multiple instructions on one data stream (rare; e.g. fault-tolerant/redundant systems).

  • MIMD: multiple instruction streams on multiple data streams, each unit independent.

• SIMD vs MIMD:

  • SIMD: all lanes execute the same operation on different data; ideal for data-parallel, regular work.

  • MIMD: each core runs its own program with its own control flow; flexible for task parallelism.

• Where each is used:

  • SIMD: vector instructions (AVX, NEON), GPUs, multimedia and matrix math.

  • MIMD: multicore CPUs and clusters running distinct threads/processes.

SIMD applies a single instruction to multiple data elements simultaneously using wide vector registers, so one operation processes, say, eight floats at once. It differs from multithreading, which runs multiple independent instruction streams: SIMD is data parallelism within one instruction stream, while multithreading is task/thread parallelism across streams.

• How SIMD works:

  • Data is packed into a wide register; one vector instruction operates on all lanes in parallel in a single core.

  • Exposed via instruction sets like SSE, AVX, or ARM NEON.

• How it differs from multithreading:

  • Multithreading uses multiple cores/threads, each with its own control flow and instruction stream.

  • SIMD stays in one thread; all lanes do the identical operation, so divergent branches per element hurt it.

  • They compose: threads can each run SIMD code for combined gains.

• Best-fit workloads:

  • Regular, uniform operations over large arrays: image/audio/video processing, linear algebra, ML kernels, physics.

  • Poor fit: branchy, irregular, or pointer-chasing code with little data uniformity.

In shared-memory architectures all processors access one global address space; in distributed-memory architectures each node has private memory and processors communicate by explicitly passing messages.

• Shared memory:

  • Communication is implicit: threads read/write common variables, so programming is easier (threads, OpenMP).

  • Needs cache coherence and synchronization hardware; scaling is limited by memory bandwidth and coherence traffic.

• Distributed memory:

  • Each node's memory is private; data exchange is explicit via messages (MPI over a network).

  • Scales to thousands of nodes (clusters, supercomputers), but the programmer must manage data placement and communication.

• Trade-off:

  • Shared memory = easier programming, harder to scale; distributed memory = harder programming, scales far.

  • Large systems are hybrids: shared memory within a node, message passing between nodes.

A GPU maximizes throughput (total work per unit time) rather than single-thread latency: it runs thousands of lightweight threads over many simple SIMD cores and hides memory latency by switching between ready thread groups instead of using large caches and speculation.

• Massive thread parallelism:

  • Threads are grouped (warps/wavefronts) and executed SIMD-style: one instruction drives many data lanes.

  • Latency hiding: when one warp stalls on memory, the scheduler instantly runs another ready warp, keeping ALUs busy.

• GPU architecture: Huge fraction of die is ALUs, small caches, high-bandwidth memory, simple in-order-style control shared across lanes.

• CPU architecture: Few powerful cores optimized for latency: deep pipelines, out-of-order execution, branch prediction, large caches.

• Consequence: GPUs win on regular, data-parallel workloads; they suffer on branch-heavy code (warp divergence) and irregular control flow, where CPUs excel.

Kernel (privileged) mode lets code execute any instruction and touch any hardware, while user mode restricts it to a safe subset. The CPU tracks the current privilege level in hardware, and protection rings define these levels so attempts to do privileged things from user mode trap into the OS.

• User mode:

  • Runs application code; cannot execute privileged instructions (change page tables, disable interrupts, access I/O ports directly).

  • Violations raise a fault/trap the kernel handles.

• Kernel mode: Full access to hardware and all memory; runs the OS, drivers, interrupt handlers.

• Protection rings:

  • x86 defines rings 0 (most privileged) to 3 (least); typically only ring 0 (kernel) and ring 3 (user) are used.

  • The current level is held in the CPU (e.g. the CPL in the code segment); each memory page and instruction is checked against it.

• Crossing the boundary: A controlled transition (system call via syscall/interrupt, exception) switches to kernel mode at a fixed entry point, so user code can't jump to arbitrary kernel addresses.

A context switch must save all CPU-visible state of the outgoing thread and restore that of the incoming one, so each resumes as if never interrupted. This is primarily the register file plus the memory-management context, saved into the thread's kernel structures.

• General-purpose and special registers: All GPRs, the program counter/instruction pointer, stack pointer, and status/flags register.

• Extended register state: Floating-point and SIMD/vector registers (often saved lazily since they're large and not always used).

• Memory context: On a process switch, the page-table base register (e.g. CR3 on x86), which may flush or tag TLB entries.

• Privileged / control state: Kernel stack pointer and relevant control/segment registers.

• What is NOT explicitly saved: Caches and TLBs aren't copied; they warm up again, which is part of context-switch cost (cold-cache effect).

Amdahl's Law says the speedup of a program from parallelization is limited by its serial portion: with fraction P parallelizable on N processors, speedup = 1 / ((1 - P) + P/N). With 10% strictly serial, the maximum speedup with infinite cores is 10x.

• The formula: Speedup(N) = 1 / (S + (1 - S)/N), where S is the serial fraction.

• Applying S = 0.10: As N approaches infinity the parallel term (1 - S)/N approaches 0, leaving 1/S = 1/0.10 = 10x.

• The key insight:

  • The serial part becomes the hard ceiling: no amount of hardware overcomes it, so reducing serial work often beats adding cores.

  • Contrast with Gustafson's Law: if problem size grows with cores, achievable speedup scales better than Amdahl's fixed-size bound.

Branches are expensive because a pipelined CPU fetches new instructions every cycle, but it doesn't yet know which way a branch goes. It predicts, and if the prediction is wrong it must discard the wrongly-fetched instructions (a pipeline flush) and restart, wasting cycles.

• The problem: the outcome is known late: A branch's direction and target are resolved several stages into the pipeline, but fetch must keep going every cycle to stay full.

• Branch predictor:

  • Guesses taken/not-taken so fetch continues speculatively down the predicted path.

  • Dynamic predictors use history: e.g. a 2-bit saturating counter per branch, or correlating/global-history predictors, giving 95%+ accuracy on typical code.

• Pipeline flush (misprediction penalty):

  • On a wrong guess, all speculatively fetched instructions are squashed and the correct target is fetched.

  • Cost equals the number of pipeline stages between fetch and resolution: deep pipelines pay more (tens of cycles).

• Implication for code: Unpredictable branches hurt; compilers use predication or cmov, and programmers can make branches predictable or branchless in hot loops.

These addressing modes differ in where the operand comes from: Immediate encodes the value in the instruction, Register Indirect uses a register as a pointer to memory, and Displacement adds a constant offset to a register before dereferencing. Displacement is the workhorse for array (and struct field) access.

• Immediate: The operand is a literal constant baked into the instruction, e.g. ADD R1, #5. No memory access. Used for constants.

• Register Indirect: The register holds the memory address; operand = Mem[R1]. Good for pointer dereferencing and following linked structures.

• Displacement (base + offset):

  • Operand = Mem[R1 + offset]: a base register plus a constant.

  • Ideal for arrays: base register points at the array start and the offset (often scaled by element size) selects the element. Also perfect for struct fields and stack locals relative to a frame pointer.

The CPU Performance Equation says execution time = Instruction Count × CPI × Clock Cycle Time (or IC × CPI / frequency). Lowering CPI while raising cycle time only improves performance if the product of the two goes down, i.e. the CPI reduction outweighs the slower clock.

• The equation:

  • CPU time = IC × CPI × T, where IC is instruction count, CPI is cycles per instruction, and T is clock cycle time.

  • The three factors trade off: ISA/compiler affect IC, microarchitecture affects CPI, and circuit/process affect T.

• The trade-off condition:

  • For fixed IC, performance improves only if CPI_new × T_new < CPI_old × T_old.

  • So the fractional drop in CPI must exceed the fractional rise in cycle time.

• Worked intuition:

  • If a design cuts CPI by 30% but lengthens the cycle by only 10%, the product falls (0.70 × 1.10 = 0.77): a win.

  • If CPI drops 10% but the cycle grows 20% (0.90 × 1.20 = 1.08): a net loss.

• Why it's a real trade-off: Doing more per cycle (deeper logic, wider execution) often lengthens the critical path, so lower CPI and faster clock pull against each other.

PC-relative computes an address as the program counter plus an offset, and indexed computes it as a base register plus an index register (often scaled). PC-relative suits control flow and position-independent code; indexed suits array and table traversal.

• PC-relative addressing:

  • Effective address = PC + offset, where the offset is a signed immediate encoded in the instruction.

  • Ideal for branches and jumps: targets are usually near the current instruction, so a small offset suffices.

  • Enables position-independent code: the code runs correctly regardless of where it is loaded in memory.

• Indexed addressing:

  • Effective address = base + index (* scale), combining a base register with a variable index.

  • Ideal for arrays and tables: keep the base fixed and increment the index to walk elements.

  • Scaling (e.g. by element size) lets the index count elements rather than bytes.

• Rule of thumb: PC-relative for reaching code near yourself, indexed for stepping through data structures.

MIPS (millions of instructions per second) and FLOPS (floating-point ops per second) count raw operation throughput, but they ignore what the instructions actually accomplish, so more operations can mean less real work.

• Instructions aren't equal work:

  • A CISC instruction may do the work of several RISC instructions, so a lower MIPS chip can finish a task faster.

  • Compilers can inflate instruction counts with inefficient code, raising MIPS without helping the user.

• Numbers depend on the workload:

  • Peak FLOPS assumes perfectly scheduled math; real programs rarely sustain it due to memory stalls and dependencies.

  • Different benchmarks give different MIPS/FLOPS on the same chip.

• They ignore the memory hierarchy: Cache misses and I/O often dominate runtime, and these rates don't capture that.

• Better approach: measure wall-clock time on representative benchmarks (e.g. SPEC) for the workload you care about.

Clock speed is how many cycles per second the processor runs; IPC is how many instructions it completes per cycle. Performance is roughly the product of both, so a chip with lower frequency but higher IPC can do more real work per second.

• Clock speed (frequency):

  • Cycles per second (GHz): a higher clock shortens each cycle but says nothing about work per cycle.

  • Limited by power and heat (dynamic power scales roughly with frequency and voltage squared).

• IPC (instructions per cycle):

  • Reflects microarchitecture: superscalar width, pipelining, branch prediction, caches, out-of-order execution.

  • Higher IPC extracts more instruction-level parallelism from each cycle.

• The governing relation:

  • Performance ≈ frequency × IPC (or time = instructions × CPI ÷ frequency).

  • A 3 GHz core with IPC 4 beats a 4 GHz core with IPC 2.

• This is why the "megahertz myth" is misleading: raw clock alone doesn't determine speed.

RAID combines multiple disks for performance, redundancy, or both. RAID 0 stripes for speed with no protection, RAID 1 mirrors for redundancy, RAID 5 uses distributed parity for a balance, and RAID 10 mirrors striped sets for high performance and resilience.

• RAID 0 (striping):

  • Data split across all disks: highest read/write throughput and full capacity.

  • No redundancy: one disk failure loses everything. Needs 2+ disks.

• RAID 1 (mirroring):

  • Every disk holds an identical copy: survives a disk failure, good read performance.

  • Usable capacity is only half (50% overhead).

• RAID 5 (striping + distributed parity):

  • Parity spread across disks; tolerates one disk failure with only one disk's worth of overhead. Needs 3+ disks.

  • Write penalty (read-modify-write of parity) and slow, risky rebuilds on large drives.

• RAID 10 (mirror of stripes, 1+0):

  • Combines RAID 1 and 0: excellent performance and fast rebuilds, tolerates a disk failure per mirror. Needs 4+ disks.

  • Costly: 50% capacity overhead like mirroring.

• Trade-off summary: RAID 0 = speed only, RAID 1 = safety, RAID 5 = capacity-efficient safety, RAID 10 = speed + safety at higher cost.

Fixed-length instructions use the same number of bytes for every instruction, making decoding fast and parallel but wasting space; variable-length instructions size each instruction to its needs, giving denser code at the cost of more complex, serial decoding.

• Fixed-length (e.g. classic RISC, ARM AArch64 at 4 bytes):

  • Decode is simple: the next instruction is always a known offset away, so multiple can be decoded in parallel.

  • Alignment is trivial and fetch is predictable.

  • Downside: simple instructions still occupy a full word, so code is larger (lower code density).

• Variable-length (e.g. x86, 1 - 15 bytes):

  • Common short operations use few bytes, giving high code density and better instruction-cache use.

  • Downside: you can't know where the next instruction starts until you decode the current one, complicating parallel decode and requiring extra hardware.

• The essential trade-off:

  • Decoding simplicity/throughput (fixed) vs code density/cache efficiency (variable).

  • Compromise designs exist: ARM Thumb and RISC-V C add 16-bit forms for density while keeping decode manageable.

Microcode is a low-level layer of control instructions inside the CPU that implements complex machine instructions as sequences of simpler internal steps. Modern x86 processors translate complex instructions into micro-operations (micro-ops) so a clean, fast, RISC-like core can execute a messy, variable, CISC instruction set efficiently.

• What microcode is:

  • A stored program in the control unit that defines how each architectural instruction drives the datapath, step by step.

  • It lets one complex instruction expand into many internal control signals or micro-ops.

• Why x86 uses micro-ops:

  • The x86 ISA has complex, variable-length instructions; the core is actually a streamlined, pipelined engine that only executes simple uniform micro-ops.

  • A decoder cracks each x86 instruction into one or more micro-ops that the out-of-order backend schedules like RISC ops.

  • Simple frequent instructions decode directly (hardwired); only complex ones fall back to microcode ROM.

• Benefits:

  • Backward compatibility: keep the old ISA while modernizing the internal design.

  • Flexibility: microcode can be patched to fix bugs or errata after manufacture.

  • Performance: uniform micro-ops enable pipelining, superscalar issue, and out-of-order execution.