Question bank — ARM architecture intro — used in embedded - aerospace

FALSE. ARM is load/store — the ALU only sees registers and immediates, so you must LDR both operands into registers first. The [R1] syntax is only valid on LDR/STR.

FALSE. Fixed length wastes bits on simple ops, so ARM code can be larger; that is exactly why the compact Thumb 16-bit set exists to shrink it back down.

FALSE. Each instruction still takes 5 stages (its latency is unchanged); the pipeline raises throughput to ~1 instruction per cycle by overlapping stages of different instructions.

FALSE. ARM licenses the ISA/IP (the blueprint); vendors like Apple, ST, and NXP fabricate the silicon. ARM sells the contract, not the factory.

FALSE. A predicated instruction still flows through every stage; it just doesn't write its result when the condition is false. The win is avoiding a branch and its possible flush, not saving a cycle.

FALSE. Deeper pipelines pay bigger penalties on every branch misprediction and add per-stage overhead, so embedded/aerospace cores keep pipelines short for predictable timing over peak throughput.

FALSE. In ARM32 the PC is $R_{15}$, a general-purpose register — writing to it is literally how a branch happens. That is a defining ARM quirk, not a forbidden move.

MISLEADING/FALSE. "Reduced" refers to each instruction doing one simple thing (reduced complexity per op), not to the count of opcodes. Modern ARM has plenty of instructions.

FALSE. LDR can still stall on a cache miss. Load/store makes cost more uniform and predictable, but memory latency is not literally constant.

The [R5] operand is illegal for ADD. Load first: LDR R7, [R5] then ADD R6, R4, R7. Arithmetic never dereferences memory in a load/store machine.

Branches are the opposite of free: a mispredicted branch flushes the partly-built pipeline. Prefer predication (ADDEQ) which stays straight-line and never flushes.

The last flag is V (oVerflow), not W. Overflow means a signed result exceeded the representable range; carry (C) is the unsigned counterpart — two different flags for two different number interpretations.

Only LDR/STR actually access memory in that stage; for an ADD the Memory stage is a pass-through. The stage exists for all, but is used only by load/store.

With $n=1$, $S=\frac{5}{5}=1$ — no speedup at all, because you paid the full 5-cycle fill for a single instruction. The $\to k$ limit only holds as $n\to \infty$.

Three are reserved: $R_{13}$=SP, $R_{14}$=LR, $R_{15}$=PC. Clobbering SP or LR corrupts your stack/return address, so you have ~13 truly free general registers.

Memory latency is variable (a cache miss costs many cycles). Splitting "talk to memory" (LDR/STR) from "compute" gives each instruction a more uniform, predictable cost — essential for WCET guarantees.

If every instruction is exactly 32 (or 16) bits, the CPU knows where the next one starts without decoding the current one, so fetch never waits on decode — the pipeline stays regular and predictable.

Because the ALU can't touch memory, you need lots of on-chip scratch slots; more registers mean fewer slow memory trips, which is both faster and lower power.

Flight control must guarantee a task finishes before its deadline every single time. A simple, predictable pipeline lets engineers bound worst-case time; a faster-but-erratic core cannot give that guarantee.

Even a predicted branch risks a misprediction flush and disturbs fetch; predication is plain straight-line code with a fixed cycle count, so timing is deterministic — no guessing, no flush.

These systems run on batteries, harvested energy, or radiation-hardened power budgets; work done per joule sets how long they last and how much heat they dump, which raw clock speed ignores.

$S=\frac{k\cdot 1}{k+1-1}=1$ — exactly no speedup, because you pay the full fill cost with nothing to overlap.

$S\to k$. The one-time $k$-cycle fill becomes negligible, so in steady state one instruction completes per cycle and you approach the ideal $k\times$. It never exceeds $k$.

The Z (Zero) flag becomes 1 (the subtraction gave zero). ADDEQ sees Z=1, so its condition holds and the add does execute.

Execution jumps to that address, because $R_{15}$ is the program counter; a plain data instruction becomes an effective branch. This is legal ARM behaviour, not an error.

No — the miss can blow the budget. Load/store makes cost predictable to analyse, but WCET tools must still account for miss penalties, or the memory be locked/deterministic.

The V (oVerflow) flag is set to 1, and the (wrapped, truncated) result is still written to the destination register. Overflow flags the problem; it does not suppress the write.