OE-9.3 ARM Architecture & Instruction Set

What this is and why it exists

This architecture is in your phone, your router, and increasingly your laptop. That gives this unit the longest professional half-life in the course.

The design philosophy section is the part worth reading slowly, because it explains a bargain rather than listing features. Simple fixed-length instructions, many registers, and a strict separation between instructions that touch memory and instructions that compute.

What that bargain buys is a pipeline that stays full without effort. A full pipeline is where the performance actually comes from.

The vocabulary

• Reduced instruction set — few, simple, fixed-length instructions.
• Load/store architecture — only load and store touch memory; arithmetic works on registers.
• Register file — the set of fast storage locations the processor computes in.
• Program status register — flags and mode bits describing the processor's current state.
• Pipeline — overlapping the stages of consecutive instructions.
• Stall — a cycle in which the pipeline cannot make progress.
• Exception — a diversion from normal flow, from hardware or from a fault.
• Mode — the privilege level the processor is running in.

The mental model

Start with the bargain. Make every instruction the same length and simple to decode, and decoding becomes trivial and predictable. Provide plenty of registers, and most work happens without touching memory. Restrict memory access to two dedicated instructions, and every other instruction has a known, short, uniform cost.

All three of those exist to serve one thing: the pipeline. Overlapping fetch, decode and execute means several instructions are in flight at once, and throughput approaches one instruction per cycle. That only works if instructions are uniform and predictable — which is precisely what the three design choices deliver. The philosophy is not an aesthetic preference; it is what makes the pipeline possible.

And it explains why pipelines stall. Anything breaking the uniform flow costs cycles. A jump whose destination is not yet known, or an instruction needing a result the previous one has not produced. That is why the compiler's instruction ordering matters on this kind of processor.

The register organisation and the status register are what you read when debugging. The status register carries the condition flags and the current mode. Reading it is often how you learn what the processor thinks is happening when the code says otherwise.

Exceptions are diversions from normal flow, and the family is broader than interrupts alone. A hardware interrupt, an invalid instruction, a failed memory access, or a deliberate call into privileged code. They are handled by the same machinery, which is a genuine economy of design and worth noticing as such.

Modes and privilege exist so that ordinary code cannot reach the hardware directly. That separation is what an operating system's protection is built on. It is also why an embedded system without one has no such protection.

The modern families then apply this in three directions. Application processors running full operating systems, real-time parts with predictable timing, and small low-power parts for microcontrollers. Same philosophy, three different points on the constraint set from the first topic.

What you should now be able to explain or do

State the three design choices and say what single goal they serve. Explain why a pipeline needs uniform instructions. Say what makes a pipeline stall and why compiler ordering matters. Read the register organisation and the status register when debugging. Say what an exception is and why one mechanism handles several kinds. Explain what modes protect and what their absence means. Place the modern families against the design metrics.

Check yourself