Instruction Representation: ISA, Formats, and Addressing Modes

In the previous article, Data Representation, we saw how the computer encodes characters, integers, and floating-point numbers as bit patterns. But a program is not just data: it is a sequence of instructions that tell the processor what to do with that data. How are these instructions encoded? Where does the processor find the operands they need?

These questions are answered by the ISA (Instruction Set Architecture) and by the addressing modes it defines. The ISA is the meeting point between hardware and software: everything a program does must be expressed in terms the processor understands.

The ISA: the contract between hardware and software

#

The ISA (Instruction Set Architecture) is the interface between hardware and software. It defines the set of instructions the processor understands and the model visible to compilers, assemblers, operating systems, and programs.

The ISA specifies, among other things:

• the instruction format;
• the supported data types;
• the addressing modes;
• the registers and their roles;
• the set of operations the CPU executes natively.

It is useful to think of the ISA as a compatibility contract: programs translated for an ISA only run directly on processors that implement that ISA, except through emulation, binary translation, or virtual machines.

A useful classification of instructions

#

A didactic way to organize machine instructions is to group them by function:

This classification is useful for study, but it should not be treated as a universal taxonomy. Modern real ISAs also include, for example, vector, atomic, cryptographic, system, and synchronization instructions.

RISC architectures tend to have few instructions per category, each simple and regular. CISC architectures can have dozens of variants per category, including complex operations in a single instruction.

But regardless of the category or the complexity, the CPU needs to know how to read that order. Every instruction has to be physically packed into bits, and that is where the design of instruction formats comes in.

Instruction formats: how many operands?

#

One of the fundamental decisions in designing an ISA is how many operands each instruction carries. There is a clear trade-off: more operands allow more expressive instructions (and therefore shorter programs), but each instruction takes up more space in memory.

In the past, the concern with space was so extreme that designs such as the SEAC (1950) used up to 4 operands: three for the operation and a fourth just to indicate the address of the next instruction. With the popularization of the PC register (Program Counter), which automatically points to the next task, we save those precious bits, allowing leaner formats.

To illustrate, let us compute the expression:

in three different formats.

3-operand format

#

General form: destination ← operand1 OP operand2

MPY T1, C, D        ; T1 = C × D
ADD T2, B, T1       ; T2 = B + T1  (= B + C × D)
DIV T3, E, F        ; T3 = E / F
SUB T4, T2, T3      ; T4 = T2 − T3 (= B + C×D − E/F)
MPY X,  A, T4       ; X  = A × T4  (final result)

Total: 5 instructions. Each instruction is self-contained: it specifies input, operation, and destination. The instructions are longer (three addresses encoded in each one), but the program is compact.

2-operand format

#

General form: Op1 ← Op1 OP Op2 (the first operand is also the destination).

MOV X, C
MPY X, D            ; X = C × D
ADD X, B            ; X = B + C × D
MOV T, E
DIV T, F            ; T = E / F
SUB X, T            ; X = B + C×D − E/F
MPY X, A            ; X = A × (B + C×D − E/F)

Total: 7 instructions. We need to insert MOVs to preserve original values before overwriting them. This is the format of the classic x86 family, based on 2-operand instructions (extensions such as AVX added a 3-operand form).

1-operand format (accumulator)

#

General form: ACC ← ACC OP Operand. All operations go through a special register called the accumulator.

LDA C               ; ACC = C
MPY D               ; ACC = C × D
ADD B               ; ACC = B + C × D
STR T               ; T   = ACC           (saves temporary)
LDA E               ; ACC = E
DIV F               ; ACC = E / F
STR T2              ; T2  = ACC
LDA T               ; ACC = T  (= B + C × D)
SUB T2              ; ACC = B + C×D − E/F
MPY A               ; ACC = A × (B + C×D − E/F)
STR X               ; X   = ACC           (final result)

Total: 11 instructions. Each instruction is compact (a single address), but more of them are needed, and more memory accesses to save intermediate results. This format was common in the first microprocessors.

Comparison

#

More than the number of lines, the hardware designer looks at the balance between bits and cycles. It is worth putting numbers on this. Suppose an 8-bit opcode and 20-bit memory addresses, plausible parameters for a teaching machine. Then:

• a 3-operand instruction takes \(8 + 3 \times 20 = 68\) bits;
• a 2-operand one, \(8 + 2 \times 20 = 48\) bits;
• a 1-operand one, \(8 + 20 = 28\) bits.

The 3-operand instruction is “heavier”, but it solves the computation with fewer trips to memory. The 1-operand instruction is “light”, but it requires many more accesses to constantly load and save the accumulator. It is the eternal dilemma between spending memory on the code or spending time on execution, and the two sides of the scale are measured in different units, which makes the decision hard.

A real format: the RISC-V R-type

#

The numbers above come from a paper machine. It is worth seeing how a real ISA solves the problem, and RISC-V is the best choice for that: besides being open and documented, it has a very regular encoding, with rs1, rs2, and rd in the same position in every format. Its three-operand format, called R-type, fits in 32 bits:

Three 5-bit fields because the architecture has \(2^5 = 32\) registers. Since the three operands are registers, not memory addresses, together they take only 15 bits: the whole instruction fits in 32, 17 are left to identify the operation, and the total is far from the 68 bits of the three-memory-address format in the previous computation.

The figure below puts the four formats on the same bit ruler, the three from the paper machine and the R-type. The RISC-V three-operand format comes out shorter than the two-operand one of the hypothetical machine, and only 4 bits longer than the one-operand one.

This is the difference that the RISC × CISC discussion usually summarizes poorly: it is not “fewer instructions”, it is operands in registers and a fixed-size format, which together make decoding trivial and the pipeline predictable.

An add rd, rs1, rs2 in RISC-V has opcode = 0110011, funct3 = 000, and funct7 = 0000000; changing funct7 to 0100000 turns the same instruction into sub. The operation changes, the format does not, and that is why the decoder of a RISC processor fits in much less silicon than that of an x86, where an instruction can have from 1 to 15 bytes.

Instructions such as SQRT, NEG, or immediate shifts can appear in real or hypothetical ISAs, but their presence alone does not define an architecture as CISC or RISC.

The distinction between RISC and CISC involves a larger set of design decisions:

• regularity of the instruction formats;
• number of addressing modes;
• average complexity of the instructions;
• ease of pipelining and decoding.

Therefore, the following example is just an example of an extended hypothetical ISA, and not a proof of a “CISC philosophy”.

LDA C        ; ACC = C
MPY #4       ; ACC = 4C            (immediate addressing)
STR TEMP     ; TEMP = 4C
LDA B        ; ACC = B
MPY B        ; ACC = B²
SUB TEMP     ; ACC = B² − 4C
SQRT         ; ACC = √(B² − 4C)
STR TEMP     ; TEMP = √(B² − 4C)   (reuses the temporary)
LDA B        ; ACC = B
NEG          ; ACC = −B
ADD TEMP     ; ACC = −B + √(B² − 4C)
SHR #1       ; ACC = ACC / 2       (shift right = divide by 2)
STR X1       ; X1 = ACC

Addressing modes

#

The addressing modes define how the processor obtains the operand of an instruction.

The central point is this: the effective address (EA) is the final address of the operand in memory, when the instruction actually accesses memory. In some modes there is no memory EA, because the data is already in the instruction itself or in a register.

flowchart TD
    A([Instruction]) --> B{Addressing
Mode}
    B --> C["Immediate
operand = constant"]
    B --> D["Direct
EA = address"]
    B --> E["Indirect
EA = M[address]"]
    B --> F["Reg. Direct
operand = Rn"]
    B --> G["Reg. Indirect
EA = Rn"]
    B --> H["Indexed
EA = address + Ri"]
    B --> I["Base + Displacement
EA = RB + disp"]

After computing the EA, when there is a memory access, the operand will be:

For the processor, there are two ways to identify which of these modes to use: either the Opcode already carries that information (the code 1010 means direct LDA and 1011 means indirect LDA) or the instruction reserves a specific bit field just to signal the addressing mode to the decoder.

Immediate mode

#

The operand is the constant encoded directly in the instruction: it is not an address, it is the value itself.

• Advantage: very fast, with no additional MM access
• Disadvantage: limited by the field size; only serves for small, fixed constants
• Example: LDA #5 → ACC = 5

Direct (absolute) mode

#

The instruction field contains the memory address where the operand is.

• Advantage: simple and direct; easy to understand and debug
• Disadvantage: the address is fixed in the object code, which makes relocating the program harder
• Example: LDA 100 → ACC = M[100]

Indirect mode

#

The field contains an address that holds the address of the operand, an extra level of indirection. The field points to a pointer.

• Advantage: flexible for pointers and dynamic structures
• Disadvantage: requires 2 MM accesses, one to fetch the address and another to fetch the data
• Example: LDA @100 → ACC = M[M[100]]

Register direct mode

#

The operand is in a processor register. Here there is no effective address: there is nothing to compute or to fetch from memory, because the data is already inside the CPU. The operand field in the instruction does not hold an address, it holds the register number:

• Advantage: the fastest possible, since reading a register costs about 1 cycle, against 100 to 300 cycles for a main memory access that misses the cache. The difference is two orders of magnitude.

• Disadvantage: limited number of registers; programs need to manage which data they keep in registers

• Example: ADD R1, R2 → R1 = R1 + R2

Register indirect mode

#

The register contains the memory address where the operand is. The register works as a pointer.

• Advantage: very flexible for traversing arrays using a register as an incrementable pointer
• Example: LDA (R1) → ACC = M[R1]

Indexed mode

#

The base address is encoded in the instruction; the index register \(R_i\) is added to it to compute the effective address.

• Advantage: ideal for traversing arrays sequentially, because you just increment \(R_i\) on each iteration
• Example: LDA 100(R1) → ACC = M[100 + R1]

Imagine the task of summing 100 numbers in an array. In direct mode, you would have to write the same instruction 100 times, changing only the address. With indexed mode, you write the instruction once, pointing to the base of the array, and use an index register to “walk” through the elements. It is the difference between 300 lines of code and an efficient 5-line loop.

Base + displacement mode

#

The register contains the base; the instruction carries a fixed displacement.

• Conceptual example: accessing a structure field or a local variable on the stack
• Typical use: relocatable code, stack, function activation, access to struct fields

This mode is very common in modern architectures because it cleanly separates the dynamic base address from the fixed displacement known at compile time.

Comparison table

#

Python bonus: computing effective addresses

#

Understanding hardware by reading diagrams and mathematical formulas can seem very abstract at first. But, in the end, addressing modes are just pointer calculation logic. For a programmer, the easiest way to demystify what the silicon does is to translate that mechanics into code. See how the hardware would compute effective addresses using simple Python functions:

# Simulates the main addressing modes.
# Mind the convention: each function returns the OPERAND (the data the
# instruction wanted) and the number of MM accesses that were needed, not
# the effective address. The EA shows up along the way, commented where
# relevant.

def ea_immediate(value):
    """Immediate mode: the operand is the value itself."""
    return value, 0  # (data, MM accesses)


def ea_direct(memory: dict, address: int):
    """Direct mode: EA = address; operand = M[EA]."""
    return memory[address], 1


def ea_indirect(memory: dict, address: int):
    """Indirect mode: EA = M[address]; operand = M[EA]."""
    ptr = memory[address]            # 1st access: fetches the pointer (= EA)
    return memory[ptr], 2            # 2nd access: fetches the data


def ea_reg_indirect(memory: dict, register: int):
    """Register indirect mode: EA = Rn; operand = M[EA].

    The parameter receives the CONTENTS of the register, which is already
    the address.
    """
    return memory[register], 1


def ea_indexed(memory: dict, base: int, index: int):
    """Indexed mode: EA = base + Ri; operand = M[EA]."""
    return memory[base + index], 1


def ea_base_displacement(memory: dict, rb: int, displacement: int):
    """Base + displacement mode: EA = RB + displacement; operand = M[EA]."""
    return memory[rb + displacement], 1


# Memory table from the previous example
mem = {
    0x1AC1: 0x1AC6,
    0x1AC2: 0x1AC4,
    0x1AC3: 0x1AC1,
    0x1AC4: 0x1AC3,
    0x1AC5: 0x1AC1,
    0x1AC6: 0x1AC5,
}

data, accesses = ea_direct(mem, 0x1AC1)
print(f"Direct   (1AC1): {data:04X}  ({accesses} MM access(es))")
# Direct   (1AC1): 1AC6  (1 MM access(es))

data, accesses = ea_immediate(0x1AC5)
print(f"Immediate(1AC5): {data:04X}  ({accesses} MM access(es))")
# Immediate(1AC5): 1AC5  (0 MM access(es))

data, accesses = ea_indirect(mem, 0x1AC3)
print(f"Indirect (1AC3): {data:04X}  ({accesses} MM access(es))")
# Indirect (1AC3): 1AC6  (2 MM access(es))

# Array with indexed mode
array = {100: 10, 101: 20, 102: 30, 103: 40}
for i in range(4):
    val, _ = ea_indexed(array, 100, i)
    print(f"array[{i}] = {val}")
# array[0] = 10, array[1] = 20, array[2] = 30, array[3] = 40

Conclusion and next articles

#

The ISA defines the vocabulary the processor understands; instruction formats and addressing modes are the grammar of that vocabulary. With three operands per instruction and seven addressing modes, a processor can express anything from simple additions to dynamic access to complex data structures. The choice between more operands (CISC) and fewer operands (RISC) reflects a trade-off between expressiveness and regularity that modern hardware resolves in sophisticated ways, the topic of the article Advanced Architectures, at the end of the series.

If you want to see real instructions being generated right now, the Compiler Explorer is the right tool: you write C, C++, Rust, or a dozen other languages on one side and see, on the other, the assembly the compiler produces, and you can choose the architecture, including RISC-V, and compare the formats this article described. It is the fastest way to get out of the table and down to the bit.

In the next article, we will follow the life cycle of a program: from source code in a high-level language, through compilation, linking, and loading, until it becomes the machine instructions the processor executes. We will see how the ISA is the bridge between the code we write and the silicon that executes it, and how ISA design decisions impact the efficiency and flexibility of programs.

See you then!