An interpreter executes a program directly; a compiler translates it into the target machine's language first. Mixed forms exist (compile to bytecode, then interpret).

Compilation steps: a parser reads the source and builds a parse tree following a context-free grammar (written in BNF — Backus-Naur Form). The grammar also fixes precedence (so x+y*z parses correctly). Code is then generated by walking the tree and emitting a template per construct. Syntax-directed translation (result of an expression left on the stack): ⟦constant⟧ = LOAD R0 constant ; STOR R0 [--SP] ⟦variable⟧ = LOAD R0 [SP+pos(v)] ; STOR R0 [--SP] ⟦e1*e2⟧ = ⟦e1⟧ ; ⟦e2⟧(pos+1) ; BRS mul ; ADD SP 1 ⟦v := e⟧ = ⟦e⟧ ; LOAD R0 [SP++] ; STOR R0 [SP+pos(v)] ⟦if e then B1 else B2⟧ = ⟦e⟧ ; LOAD R0 [SP++] ; BEQ else ; ⟦B1⟧ ; BRA endif ; else: ⟦B2⟧ ; endif: ⟦while e do B⟧ = loop: ⟦e⟧ ; LOAD R0 [SP++] ; BEQ end ; ⟦B⟧ ; BRA loop ; end: ⟦B1;B2⟧ = ⟦B1⟧ ; ⟦B2⟧

Translation is defined recursively on the parse tree and combined — define it abstractly first, then refine. Non-optimising compilers are fast (used in development); optimising compilers are slower but emit better code (constant folding, register allocation, dead-code elimination, function inlining, instruction reordering when sequential semantics allow) — up to 10× speed-ups. Intermediate languages (LLVM IR, JVM bytecode) decouple front-ends (Java, C++, Fortran) from back-ends (ARM, x86, PowerPC).

This is the spine of gcc/LLVM/javac; understanding templates explains why certain code compiles to tight loops and why optimisation flags matter.

A computer is more than the CPU: memory, I/O controllers, and the buses that connect them. A bus has address, data and control lines.

Processor pins group into three buses: Address (M pins → 2ᴹ locations), Data (N parallel bits), Control (read/write, timing, interrupts…). A master initiates transfers; a slave responds (CPU↔memory, CPU↔I/O, DMA controller↔memory). Memory types: SRAM & ROM/flash connect simply. DRAM stores bits as capacitor charge — dense but needs periodic refresh and split row/column (RAS/CAS) addressing via a controller (DDR2/3/4 transfer 4/8/16 words per cycle).

Synchronous buses time everything to a clock (simple, but everything takes a clock multiple); asynchronous buses use handshaking (e.g. 4-phase) so transfers happen as soon as possible. Bus standards proliferate (PCI, USB, SATA…); serial buses now dominate (fewer wires, no skew). A 'chip-set' wires CPU, memory bus, PCI, USB, IDE/SATA together.

DDR generations and PCIe lanes are exactly these concepts; memory bandwidth and latency now dominate performance more than raw clock speed.

CPUs got much faster than memory, so a small fast cache keeps copies of recently used data close to the core.

Multiple cache levels (L1 fastest/smallest, L2, L3 shared). A replacement policy decides what to evict (FIFO, LRU). With several cores each having caches, the cache-coherency problem arises (cores must see a consistent value). Hyperthreading hides memory latency by running another thread while one stalls.

Modern CPUs do out-of-order execution : instructions run as soon as their data is ready, respecting only true (sequential) dependencies. This breaks naive concurrent code (e.g. Peterson's mutual-exclusion algorithm relies on ordering it doesn't enforce), so memory barriers and acquire/release semantics are needed (release: finish all earlier ops first; acquire: do this op before later ones). The consensus problem : with only read/write to shared memory, equal parties cannot always agree — so hardware adds atomic primitives: test_and_set , compare_and_swap , and ARM's LDREX/STREX (load/store exclusive). These are essential for locks and lock-free data structures.

Cache misses and false sharing dominate real-world performance; memory-ordering bugs are among the hardest concurrency defects, which is why languages define memory models.