Computer architecture

Computer architecture explains how software becomes work performed by a processor, memory, storage, and devices. The useful engineering model is not a catalogue of current hardware; it is the path data and instructions follow and the limits each resource imposes.

For a hands-on treatment, use Module 2: How programs run.

From source code to instructions

source code
→ compiler or language runtime
→ machine instructions and data
→ operating-system process
→ CPU, memory, and devices

An instruction set architecture (ISA), such as x86-64, Arm, or RISC-V, defines the visible contract between machine code and a processor: instructions, registers, data types, addressing, and privilege behavior. A microarchitecture is one implementation of that ISA. Different processors can run the same instructions while using different pipelines, caches, and execution units.

CPU execution

At a simplified level, a processor repeatedly:

1. fetches instructions;
2. decodes them;
3. executes operations or moves data;
4. makes the architectural result visible.

Important components include:

• registers: small storage directly used by instructions;
• program counter: identifies the next architectural instruction;
• execution units: perform integer, floating-point, vector, branch, and load/store work;
• control logic: schedules and retires work while preserving ISA behavior;
• cores: independent processing units capable of running instruction streams.

Modern processors pipeline, predict branches, issue multiple instructions, and execute independent work out of order. These mechanisms improve throughput but must preserve the program's architectural semantics. A wrong branch prediction wastes work; it does not change the correct result.

Clock frequency alone does not determine performance. Work per instruction, instructions per cycle, stalls, memory behavior, core count, thermal limits, runtime overhead, and the workload all matter.

Cores, hardware threads, and software threads

A core executes instructions. Some cores expose multiple hardware threads, allowing the core to use otherwise idle resources. An operating system schedules software threads onto available hardware execution contexts.

More threads help only when work can proceed concurrently and the relevant resource is available. Dependencies, coordination, memory bandwidth, locks, and serial sections limit scaling. Measure the actual workload instead of multiplying single-thread performance by the number of cores.

Memory hierarchy

Storage closer to execution is generally smaller and faster:

Layer	Managed mainly by	Typical role
Registers	compiler and CPU	current operands and execution state
CPU caches	hardware	recently or nearby used instructions and data
Main memory	OS, runtime, application	active process code and data
Persistent storage	OS, filesystem, database	durable programs and data
Remote storage	networked systems	shared or replicated durable data

Exact sizes and latency ratios depend on the machine. The durable principle is that moving data can cost more than computing on data already nearby.

Locality

• Temporal locality: recently used data is likely to be used again.
• Spatial locality: nearby data is likely to be used soon.

Sequential traversal of compact data often uses caches better than following pointers across unrelated locations. This is why two algorithms with the same asymptotic complexity can perform differently.

Caches operate in fixed-size blocks called cache lines. A cache miss causes data to be fetched from a lower level. In multicore systems, cache-coherence protocols maintain a consistent view of shared memory, but frequent writes to shared cache lines can become expensive.

Addressing and representation

Programs operate on virtual addresses supplied by the operating system. Hardware translates those addresses through page tables before accessing physical memory. See Operating systems for the process-level model.

Representation details that commonly cross software boundaries:

• word size: influences native register and address widths;
• alignment: some values are most efficiently or legally accessed at particular address boundaries;
• endianness: defines byte order for multi-byte values, not bit order inside a byte;
• integer width: determines representable range and overflow behavior;
• floating-point format: provides finite approximations, special values, and defined rounding behavior.

Never serialize an in-memory structure by assuming another machine, process, or language has identical layout. Define byte order, widths, encoding, and version explicitly.

Devices and I/O

Applications normally do not control hardware directly. They make system calls; the kernel coordinates device drivers and controllers.

Common mechanisms include:

• interrupts: a device notifies the CPU that an event occurred;
• direct memory access (DMA): a controller transfers data without the CPU copying every byte;
• buffers: absorb differences between producer and consumer timing;
• memory-mapped I/O: hardware registers or files appear in an address range;
• persistent storage: retains data across process and power loss, subject to filesystem and device durability guarantees.

CPU use, I/O wait, memory pressure, and storage latency are different bottlenecks. A faster processor does not fix a process blocked on storage.

Performance reasoning

Use this order:

1. define the workload and user-visible target;
2. measure elapsed time, CPU time, memory, and I/O;
3. identify the saturated or waiting resource;
4. profile the implicated layer;
5. change one cause;
6. repeat under the same conditions.

Useful questions:

• Is the process executing or waiting?
• Does one core saturate while others remain idle?
• Does working-set growth increase cache misses or paging?
• Is access sequential or scattered?
• Is throughput limited by compute, memory bandwidth, storage, or synchronization?

Hardware specifications suggest hypotheses. Measurements from the real program decide which hypothesis matters.