Question bank — Memory addressing modes — immediate, register, direct, indirect, indexed

False — the operand is already inside the instruction word, which was pulled in during the instruction fetch; the operand costs zero additional memory accesses. Intuition: the number is printed on the card itself, so there is nowhere to travel to.

True — the operand lives in a CPU register inside the register file (a tiny bank of storage right beside the ALU), reachable in one clock without any bus trip. Intuition: it is in your pocket, not across town.

True for direct mode specifically — since $\text{EA}=A$ literally, the number of address bits caps the reachable range. Intuition: but this reach is frozen at assembly time, which is why direct mode is inflexible compared to indexed/indirect that recompute the target at runtime.

False — indexed does an addition ($\text{EA}=A+R[i]$), not a read. Intuition: adding a register value is arithmetic done inside the CPU, whereas indirect's extra step actually leaves the CPU to read a cell, which is why indirect costs 2 accesses and indexed costs 1.

False — indirect needs two ($M[A]$ to fetch the address, then $M[M[A]]$ to fetch the operand); indexed needs one. Intuition: indirect chases a pointer (two trips to memory), indexed just shifts a fixed base by a register (one trip).

False — the EA is computed on the fly by the addressing-mode logic in the datapath (the wires and adders that route operands) each time the instruction runs. Intuition: it is a result, like the sum on a calculator display, not a saved variable.

False — the register holds an address; the operand is $M[R[i]]$, the cell that address points to. Intuition: the register is a signpost reading "house 200," and the operand is whatever lives in house 200.

False — immediate supplies a source constant; it has no address, so nothing can be stored into an immediate. Intuition: you cannot mail a letter to a number printed on a card — there is no mailbox.

False — PC-relative computes $\text{EA}=\text{PC}+d$ where $d$ is a signed displacement and PC is the program counter (address of the current instruction). Intuition: because the target is measured relative to wherever the code currently sits, the whole program can be relocated and every jump still lands correctly — the opposite of an absolute address.

Error: indexed adds the register's contents $R[i]$, not a memory value — $\text{EA}=A+R[i]$. Intuition: the person dereferenced memory (that's indirect's move); indexed never opens a box to build its address, it only adds a register.

Error: naming a fixed cell is the least flexible — that instruction can only ever touch that one address. Intuition: a signpost that always points to the same house cannot follow a moving target; flexibility comes from recomputing the target at runtime (indexed for arrays, indirect for pointers).

Error: indexed mode reuses the same instruction and just bumps the index register ($R[i]\leftarrow R[i]+\text{stride}$) each pass — see Arrays and Stride. Intuition: one instruction plus a changing counter sweeps the whole street; rewriting code per element defeats the entire purpose.

Error: it is slow because of the extra memory read to fetch the pointer, not arithmetic. Intuition: a memory access crosses the bus into the far-slower memory hierarchy (hundreds of cycles on a miss), while an add finishes in one cycle.

Error: no memory cell is involved — the constant sits in the instruction's value field, already fetched. Intuition: inventing a memory round-trip would erase immediate mode's whole reason to exist, which is zero operand accesses.

Error: register mode uses the register's contents as the operand (0 accesses); register-indirect uses the register's contents as an address and reads $M[R[i]]$ (1 access). Intuition: same field, opposite meaning — "the value" versus "the value is a signpost."

Error: direct puts an absolute address $A$ in the instruction; PC-relative stores a signed offset and computes $\text{EA}=\text{PC}+d$. Intuition: one says "house 500," the other says "5 houses past where you stand" — only the relative one survives moving the whole neighbourhood.

The precise rule is: cost = (number of $M[\cdot ]$ nestings inside the EA expression) + one final $M$ to fetch the operand, unless the mode has no memory operand at all. Direct's EA is $A$ (zero nestings) + 1 operand read = 1; indirect's EA is $M[A]$ (one nesting) + 1 operand read = 2; immediate/register produce the value directly, so the "+1" is skipped and the total is 0.

Programs touch millions of cells but an opcode field has only a handful of bits — see Instruction Encoding & Opcodes. Intuition: encoding a short "recipe" and letting hardware compute the address each run is the only way to name a huge space with tiny instructions.

A node's "next" field holds the address of the following node, exactly the pattern $\text{EA}=M[A]$ — you read one stored address to reach the real target, mirroring how pointers dereference with *.

Because $\text{EA}=A+R[i]$ recomputes a fresh element address each pass while the base $A$ and the instruction bits stay fixed; bumping $R[i]$ by the element stride slides the window forward one element at a time.

A destination must have an address to write into; an immediate has no address — it is the value embedded in the instruction — so it can only ever be read.

Because the target is expressed as an offset from the current instruction's location ($\text{EA}=\text{PC}+d$), the physical base cancels out: move the whole block anywhere and every relative jump still points to the same relative spot, which is exactly what shared libraries need.

The EA resolves to $A$ itself, so the operand becomes $M[A]$ — one legitimate read; the hardware does not loop forever, because indirection is applied a fixed number of times (once), not until convergence.

$\text{EA}=A+0=A$, so it fetches $M[A]$ — indexed with a zero index degenerates into exactly direct mode's behaviour (still 1 access).

The hardware interprets the register as a signed value and effectively subtracts, so $\text{EA}=A+R[i]$ lands before the base $A$ — useful for reaching earlier array elements or a struct field at a negative offset, but a bug if you assumed the index was unsigned and expected a huge address instead.

Overflow is when a positive sum exceeds the address width and wraps to a low address; signed wraparound is when a two's-complement negative index makes the sum dip below zero and wrap to a very high address. Both yield a valid-but-wrong cell, and the CPU computes either without complaint.

No — every instruction still costs one fetch to read the instruction word itself; the "0" counts only operand accesses. All modes share the fetch cost equally.

Three — two reads to resolve the doubly-nested pointer chain plus the final operand read, following the "count the $M$ nestings + 1" rule that gives indirect its 2.

The constant may be split across bits or need a second instruction word, but the operand still costs 0 extra data-memory accesses — the extra cost is in instruction fetch, not operand fetch.

$\text{EA}=\text{PC}+0=\text{PC}$, so the instruction references its own location — a degenerate "point at myself" case, harmless but rarely useful, and the same idea that lets branch-to-self become an infinite loop.