ARM architecture overview: Exercises — Hardware deep dive

This page assumes only what the ARM architecture overview parent note built: load-store, fixed 32-bit encoding, conditional execution, registers, Thumb, pipelines. Every symbol below is re-explained the instant it appears.

Level 1 — Recognition

L1.1 — Name the access pattern

Recall Solution

ARM is a load-store architecture: only LDR (load register) and STR (store register) touch memory; arithmetic works only on registers.

LDR r0, [r1]    ; copy the memory word at address r1 into register r0
ADD r0, r0, #5  ; add 5 — this is register-only, allowed
STR r0, [r1]    ; copy the result back to memory at address r1

The rule is the load-store principle. You cannot write ADD [r1], #5 on ARM (that IS legal on x86 — see 5.1.10-x86-architecture).

L1.2 — Read the condition suffix

Recall Solution

The suffix GT = "Greater Than". Every ARMv7 instruction carries a 4-bit condition field (bits 31–28) checked against the flags before it runs. ADDGT r1, r1, #1 means: if the last comparison set flags saying the tested value was greater than the compared value, then compute r1 = r1 + 1; otherwise the instruction becomes a NOP (no-operation, does nothing) and still costs about 1 cycle. So it only changes r1 when the GT condition is true.

L1.3 — Count the register field bits

Recall Solution

To name one of $N$ registers you need $⌈ lo g_{2} N ⌉$ bits. $lo g_{2} 16 = 4 bits$ A 32-bit data-processing instruction must pack a condition, opcode, TWO register fields (Rn, Rd), and an operand. Every extra register doubles or grows the field. Choosing $16 = 2^{4}$ makes each field exactly 4 bits — a clean fit. Twenty registers would need 5 bits per field and waste encoding space. See 5.1.07-ARM-instruction-encoding.

Level 2 — Application

L2.1 — Branch-cost formula

Recall Solution

Branch version: $0.15 \times 40 = 6 cycles wasted on average$ Plus the branch instruction itself still costs its normal cycle, but the penalty attributable to prediction is $6$ cycles. Conditional-execution version: the branch disappears; the guarded instruction is a fixed 1-cycle operation (it just turns into a NOP if the condition fails). So the average cost is $1$ cycle with zero misprediction penalty. Net saving from conditional execution here $\approx 6$ cycles per avoided branch.

L2.2 — Fetch address arithmetic

Recall Solution

Fixed-width means "next instruction" is always == $PC + 4$ == bytes (4 bytes per 32-bit instruction). Addresses are in hexadecimal, where 0x10 = 16 decimal. The current instruction is at 0x8000; the next three come from repeatedly adding 4: $next 1 0 x 8004, next 2 0 x 8008, next 3 0 x 800 C$ (0x800C because 0x8008 + 4 = 0x800C; hex digit C = 12.) The starting address 0x8000 is not one of the three, because the question asks for the ones fetched after it. This trivial "+4 forever" is exactly what variable-length x86 cannot do — it must first decode an instruction to learn its length.

L2.3 — Thumb code-size saving

Recall Solution

A $30%$ reduction means the new size is $70%$ of the original. $4000 \times (1 - 0.30) = 4000 \times 0.70 = 2800 bytes$ Saved: $4000 - 2800 = 1200 bytes$ Smaller code fits better in the instruction cache (6.3.02-cache-memory) → fewer slow fetches from DRAM → lower energy (7.1.05-power-optimization).

Level 3 — Analysis

L3.1 — Why does conditional execution beat branching here?

Worked example

Rewrite this branchy code using ARM conditional execution, then argue with numbers (use $P_{mis} = 0.15$ , $C_{flush} = 40$ ) why the conditional version is faster on average. Note carefully: in the original, MOV r2, #0 runs unconditionally (control always reaches the skip label), while ADD r1, r1, #1 runs only when the branch is not taken (i.e. when r0 > 0).

CMP r0, #0     ; set flags from (r0 - 0)
BLE skip       ; BLE = "Branch if Less than or Equal" -> jump to skip if r0 <= 0
ADD r1, r1, #1 ; only reached when r0 > 0
skip:
MOV r2, #0     ; always reached, runs in both cases

Recall Solution

First, a mnemonic definition: ==BLE== means "Branch if Less than or Equal" — ARM's branch instruction (B) with the LE condition. (ARM uses B for branches, not the x86-style J for jump.) So BLE skip jumps to skip when r0 <= 0, skipping the ADD.

Semantics we must preserve:

ADD r1, r1, #1 happens only when r0 > 0 (the branch fell through).
MOV r2, #0 happens always — it is after the label, so both paths reach it.

Conditional rewrite (same semantics):

CMP r0, #0        ; set flags from (r0 - 0)
ADDGT r1, r1, #1  ; runs only if r0 > 0, else NOP  (matches original ADD)
MOV r2, #0        ; UNCONDITIONAL — matches original always-run MOV

The MOV keeps no condition suffix, because in the original it executes on every path. Guarding it (e.g. MOVLE) would be a bug: it would skip the MOV when r0 > 0 and change the program's meaning.

No branch instruction exists anymore, so there is nothing to mispredict. Cost of branch version (expected): the BLE costs its own cycle plus an expected penalty of $P_{mis} \times C_{flush} = 0.15 \times 40 = 6 cycles .$ Cost of conditional version: each guarded (or unconditional) instruction is a fixed 1 cycle regardless of outcome — total predictable cost, penalty $= 0$ . The conditional path wins by roughly $6$ cycles per encounter and, crucially, its timing is deterministic — which is why real-time embedded ARM code loved this feature.

L3.2 — When does conditional execution lose?

Recall Solution

Every guarded instruction still occupies a pipeline slot and still takes a cycle even when it does nothing. If a whole block of $k$ guarded instructions runs but the condition is false, you paid $k$ cycles for $k$ NOPs. A branch that is predicted correctly costs almost nothing and skips those $k$ instructions entirely. So the break-even is roughly: $always-pay conditional k vs branch penalty P_{mis} \times C_{flush}$ When branch predictors got very accurate ( $P_{mis}$ small, e.g. $> 95%$ correct so $P_{mis} < 0.05$ ) the right side shrinks below the left for any block of a few instructions, and predicted branches win. Conditional execution also complicates out-of-order cores because an instruction doesn't know whether it "counts" until late. That trend (great predictors + wide out-of-order machines — see 5.2.03-pipelining) is exactly why ARMv8 removed it.

L3.3 — Banked registers, quantified

Recall Solution

Without banking: on entry you save 5 registers (5 cycles), on exit you restore 5 (5 cycles): $5 + 5 = 10 cycles per interrupt.$ With FIQ banking, the handler already has its own physical r8–r12, so it never touches the interrupted program's copies — nothing to save or restore. Banking removes all 10 cycles. Why it works: "banked" means the register name r8 maps to a different physical register depending on mode. Switching mode instantly swaps in fresh registers, so context is preserved for free by the hardware instead of by save/restore instructions — the whole point of Fast Interrupt.

Level 4 — Synthesis

L4.1 — Full instruction-field budget

Recall Solution

Register fields: $lo g_{2} 16 = 4$ bits each, so Rn = 4, Rd = 4. Fixed pieces: Cond = 4, format 00 = 2, I = 1, opcode = 4, S = 1. Sum of everything except the operand: $4 + 2 + 1 + 4 + 1 + 4 + 4 = 20 bits.$ Operand2 gets the remainder: $32 - 20 = 12 bits.$ Total check: $20 + 12 = 32$ ✓ — matches the parent note's layout (Operand2 occupies bits 11–0, which is 12 bits). Those 12 bits encode either a small immediate or a shifted register (details in 5.1.07-ARM-instruction-encoding).

The figure below is your answer drawn to scale: each coloured box is one field, and its width along the 32-bit ruler is proportional to its bit-count. Read it left-to-right from bit 31 (most-significant, Cond) down to bit 0 (Operand2). Notice how the four fixed lavender/mint/butter/coral boxes on the left consume exactly 20 bits, leaving the single wide mint Operand2 box on the right holding the remaining 12 — this is the "20 + 12 = 32" balance visualised. Any register you add would widen the two Rn/Rd boxes and steal from that right-hand operand box.

L4.2 — Register width vs encoding, the real trade-off

Recall Solution

Bits per field $= lo g_{2} N$ ; two fields cost $2 lo g_{2} N$ .

$N$ registers	bits/field	two fields
8	3	6
16	4	8
32	5	10

ARMv7 chose 16. Eight registers spill to memory too often (more slow LDR/STR). Thirty-two would eat 10 of 32 bits just on two register names, starving the operand/immediate space. Sixteen keeps each field a clean 4 bits (fits the byte-aligned layout) while giving enough registers to keep most work off memory — the balance point between (a) and (b).

Level 5 — Mastery

L5.1 — Design a pipeline-depth argument

Recall Solution

Step 1 — count mispredictions (same for both). Branch instructions: $1000 \times 0.20 = 200$ . Of those, mispredicted: $200 \times 0.10 = 20 mispredictions.$

Step 2 — Design A cycles. Base one cycle per instruction plus $C_{A} = 2$ cycles per misprediction: $cycles_{A} = 1000 + 20 \times 2 = 1000 + 40 = 1040 cycles.$ Design A time. Divide cycles by frequency $1.0 GHz = 1.0 \times 1 0^{9}$ cycles/s: $t_{A} = \frac{1040}{1.0 \times 1 0 ^{9}} s = 1.040 \times 1 0^{- 6} s = 1040 ns.$

Step 3 — Design B cycles. Base plus $C_{B} = 11$ cycles per misprediction: $cycles_{B} = 1000 + 20 \times 11 = 1000 + 220 = 1220 cycles.$ Design B time. Divide by frequency $2.5 GHz = 2.5 \times 1 0^{9}$ cycles/s: $t_{B} = \frac{1220}{2.5 \times 1 0 ^{9}} s = 4.88 \times 1 0^{- 7} s = 488 ns.$

Step 4 — compare and conclude. Even though B does more cycles ( $1220 > 1040$ ), its $2.5 \times$ higher clock makes each cycle much shorter, so: $t_{B} = 488 ns < t_{A} = 1040 ns, \frac{t _{A}}{t _{B}} = \frac{1040}{488} \approx 2.13.$ Design B is about $2.13 \times$ faster. This is exactly why high-performance ARM cores accept deep pipelines and lean on strong branch predictors (5.2.03-pipelining) — the frequency gain outweighs the flush cost as long as prediction stays good. If $P_{mis}$ rose sharply, B's larger flush penalty ( $C_{B} = 11$ vs $C_{A} = 2$ ) would erode and eventually reverse that advantage.

L5.2 — Argue the ARMv8 conditional-execution removal end-to-end

Recall Solution

Three linked points:

The 6-cycle saving assumed a bad predictor ( $P_{mis} = 0.15$ , $C_{flush} = 40$ ). Modern ARM cores predict $> 95%$ correctly, so realistic penalty is $P_{mis} \times C_{flush} = 0.05 \times C_{flush}$ — a third or less of the old figure.
Conditional execution is always-paid (L3.2): a block of $k$ guarded instructions costs $k$ cycles even when skipped, whereas a correctly predicted branch costs almost nothing. With good predictors, $P_{mis} \times C_{flush} < k$ for typical blocks, so branching wins on average.
It fights out-of-order execution (L3.2): an instruction that doesn't know if it "counts" until its condition resolves complicates the wide, deep machines (L5.1) that give ARMv8 its speed. So removal wasn't a regression — it enabled the deeper, faster, out-of-order pipelines whose frequency advantage (L5.1) dwarfs the old conditional-execution trick. The engineer's number is real but obsolete: it belongs to the slow, shallow, poorly-predicting cores of the 1990s.