Offensive Security Researcher & Quantum Cryptography Analyst

Immediate Addressing vs. Direct Addressing in Assembly Language: What’s the Difference?

Abdul Wahab Junaid
Describe the difference between immediate addressing and direct addressing

One of the first things that confused me when I moved from high-level languages into Assembly was addressing modes. In C, I never had to think about how a value gets to a variable — I just wrote x = 5; and moved on. In Assembly, the addressing mode is the whole story: it tells the CPU exactly where an operand’s value comes from, and getting it wrong (or not understanding it) leads to bugs that are hard to trace. Two of the most fundamental addressing modes — immediate and direct — look similar on the surface but behave completely differently underneath.

Table of Contents

What Is an Addressing Mode?

An addressing mode defines how the operand of an instruction is located. The operand could be a literal value baked into the instruction, a value sitting in a register, or a value sitting somewhere in memory — and there are several ways to specify “somewhere in memory.” Immediate and direct addressing are two of the most basic modes, and understanding the difference between them clears up a lot of confusion about how the CPU actually fetches data.

Immediate Addressing Explained

In immediate addressing, the operand’s value is encoded directly inside the instruction itself. There’s no memory lookup and no register dereference — the value is right there in the instruction stream, ready to be used the moment the instruction is decoded.

MOV EAX, 25      ; 25 is the literal, immediate value
ADD EBX, 10      ; 10 is immediate

Here, 25 isn’t an address — it’s the actual number. The CPU never has to go fetch anything; the value is embedded in the machine code bytes.

Direct Addressing Explained

In direct addressing, the instruction contains a memory address, and the CPU must go to that address in memory to fetch the actual value.

MOV EAX, [1000h]   ; fetch the value stored at memory address 1000h
MOV EAX, [count]   ; fetch the value stored at the label 'count'

Here, 1000h (or the label count, which the assembler resolves to an address) tells the CPU where to look, not what to use. The CPU has to perform an extra memory access to retrieve the actual data.

Side-by-Side Comparison

AspectImmediate AddressingDirect Addressing
Operand meaningThe literal value itselfThe address of the value
Memory access neededNoneOne memory read (or write)
SpeedFastest — no extra fetchSlower — extra memory cycle
Syntax (x86, Intel)MOV EAX, 5MOV EAX, [5] or MOV EAX, [label]
Syntax (ARM)MOV R0, #5LDR R0, [R1] (register holds address)
Use caseConstants, loop counters, flagsVariables, global data, arrays
Can operand change at runtimeNo — fixed in the instructionYes — memory content can change

x86/x86-64 Examples

Immediate Addressing

MOV AL, 0Fh          ; load hex value 0F directly
ADD ECX, 100         ; add literal 100
CMP EDX, 0            ; compare EDX against immediate 0

Direct Addressing

SECTION .data
value   DD 42

SECTION .text
MOV EAX, [value]     ; direct addressing: fetch what's stored at 'value'
MOV [value], EBX     ; direct addressing: store EBX's content into 'value'

In GAS/AT&T syntax, the same idea looks like this:

movl $42, %eax        # immediate
movl value(%rip), %eax   # direct (RIP-relative in modern x86-64)

ARM Examples

ARM’s load/store architecture handles this a bit differently, since ARM instructions generally can’t operate directly on memory the way x86 can — everything memory-related goes through explicit LDR/STR.

MOV R0, #10            ; immediate addressing
LDR R1, =myVar         ; load the ADDRESS of myVar into R1
LDR R2, [R1]           ; direct/indirect: dereference R1 to get the value

Note that on ARM, true “direct addressing” of a fixed memory address usually happens in two steps: load the address (often via a literal pool or LDR =), then dereference it — because ARM instructions are fixed-width and can’t always embed a full 32-bit address as an immediate.

How the CPU Processes Each Mode

flowchart TD
    A[Instruction Fetch] --> B[Instruction Decode]
    B --> C{Addressing Mode?}
    C -->|Immediate| D[Extract Literal from Instruction Encoding]
    D --> G[Use Value Directly in ALU]
    C -->|Direct| E[Extract Address from Instruction Encoding]
    E --> F[Memory Access: Read Value at Address]
    F --> G
    G --> H[Execute / Write Back]

Register and Flag Behavior

Both modes affect the CPU’s flags register (EFLAGS/RFLAGS on x86, CPSR/APSR on ARM) identically once the value is loaded — flags like Zero (ZF), Carry (CF), Sign (SF), and Overflow (OF) are set based on the result of the operation, not on how the operand was fetched. The difference is purely in how many cycles and memory accesses it takes to get the operand ready for the ALU.

Memory Diagram

AddressContentAccessed By
—25 embedded in instructionImmediate addressing (no address used)
0x100042Direct addressing via MOV EAX, [0x1000]
0x10047Direct addressing via MOV EAX, [0x1004]

Immediate values never “live” in data memory at all — they live inside the instruction encoding in the .text section. Direct-addressed values live in .data/.bss and are fetched via the address/data bus at runtime.

Performance Considerations

Practical Use Cases

Beyond the Basics: Where These Modes Fit Among Other Addressing Modes

Immediate and direct addressing are just two entries in a broader family of addressing modes every architecture supports. Seeing them next to their relatives clarifies why each exists:

Addressing ModeExample (x86)What It Means
ImmediateMOV EAX, 5Value is embedded in the instruction
DirectMOV EAX, [1000h]Value is at a fixed, known address
RegisterMOV EAX, EBXValue is in another register
Register IndirectMOV EAX, [EBX]Value is at the address held in EBX
IndexedMOV EAX, [EBX+ESI]Value is at base register + index register
Base + DisplacementMOV EAX, [EBP-4]Value is at a register plus a constant offset — common for stack locals

Direct addressing is really the simplest form of memory addressing — a fixed, compile-time-known address — while indirect and indexed modes generalize this to addresses computed at runtime. Once I saw immediate and direct as the two extremes (no memory access at all, versus the simplest possible fixed memory access), the more complex modes made a lot more sense as variations that add runtime-computed components to the address.

A Worked Example: Compiler-Generated Code

If you compile a small C snippet like this:

int global_counter = 0;
void increment() {
    global_counter = global_counter + 1;
}

and inspect the generated x86-64 Assembly (e.g., via gcc -S), you’ll typically see something close to:

increment:
    movl global_counter(%rip), %eax   # direct (RIP-relative) addressing: load global
    addl $1, %eax                      # immediate addressing: add literal 1
    movl %eax, global_counter(%rip)   # direct addressing: store back
    ret

This single function uses both modes in immediate succession — direct addressing to read and write the global variable, immediate addressing for the constant 1. Seeing real compiler output like this reinforced for me that these aren’t just academic categories; they’re the literal building blocks of every compiled program running on your machine right now.

Historical Context

On very old 8-bit and 16-bit systems, direct addressing was often the only practical way to access memory beyond a handful of registers, since register-indirect and indexed modes were more limited or slower. As architectures evolved — particularly with the rise of position-independent code for shared libraries — pure direct addressing (an absolute, fixed address baked into the instruction) became less common in user-space code, largely replaced by RIP-relative addressing on x86-64 and PC-relative addressing on ARM, both of which achieve the same “fixed offset from a known point” idea without hardcoding an absolute address that would break under address space layout randomization (ASLR).

Debugging Addressing Modes in Practice

When I’m stepping through code in GDB and something behaves unexpectedly, one of the first things I check is whether I’ve misjudged an addressing mode. GDB’s x (examine memory) command is invaluable here:

(gdb) print $eax
$1 = 25
(gdb) x/4xb &value
0x4040:  0x2a 0x00 0x00 0x00

If $eax holds the number 25 directly after a MOV EAX, 25, that confirms immediate addressing did exactly what I expected — no memory was touched. If instead I examine the memory at a label’s address and see the expected value sitting there, that confirms a MOV EAX, [label] correctly performed direct addressing. This kind of verification habit is especially useful when porting code between syntaxes, since a missed bracket ([ ]) in Intel syntax silently changes an instruction’s entire meaning without necessarily causing an assembler error.

Why This Distinction Matters for Security and Reverse Engineering

Immediate vs. direct addressing isn’t just an academic distinction — it directly affects how malware analysts and reverse engineers read disassembly. An immediate value hardcoded into an instruction (like a magic number, XOR key, or fixed buffer size) is visible right there in the instruction bytes, making it easy to spot with a simple binary search or YARA rule. A direct-addressed value, by contrast, lives in a data section and can be modified at runtime — which is exactly the technique self-modifying code and certain obfuscation methods rely on: overwrite a “constant” that was actually loaded via direct addressing, so the same instruction behaves differently across two executions. Recognizing which addressing mode a suspicious instruction uses is often the first step in understanding whether a value is truly fixed or potentially mutable.

Common Mistakes

How Compilers Choose Between the Two

It’s worth understanding that this choice isn’t always made by the programmer — compilers make it constantly during code generation. When a compiler sees a constant used in an expression, it emits an immediate operand. When it sees a reference to a global or static variable, it emits a direct (or RIP-relative) memory operand. Where compilers get genuinely clever is in constant folding and constant propagation: if a variable is provably constant throughout a function’s execution, an optimizing compiler may promote what looks like a direct-addressed variable access in your source code into an immediate value in the generated Assembly, entirely eliminating the memory access. This is one of many reasons hand-inspecting compiler-generated Assembly is such a useful exercise — it reveals exactly which addressing-mode decisions the optimizer made on your behalf, and why.

Best Practices

A Simple Mental Model to Keep Them Straight

If I ever catch myself hesitating over which mode I’m looking at, I fall back on a one-line test: does the operand describe a value or a place? MOV EAX, 25 describes a value — nothing to fetch. MOV EAX, [1000h] describes a place — go fetch what’s stored there. Every other addressing mode you’ll encounter later (indirect, indexed, base+offset) is really just a more elaborate way of describing a “place,” built on top of the same core idea direct addressing introduces: an address the CPU must dereference before it has an actual value to work with.

FAQs

Is immediate addressing always faster than direct addressing? In principle yes, since it skips a memory access. In practice, with caching, the difference for cached data can be negligible, but immediate is still cycle-for-cycle cheaper.

Can direct addressing operands change at runtime? Yes — that’s the whole point. The value stored at that memory address can be modified by other instructions, unlike an immediate value baked into the instruction itself.

Does ARM support direct addressing the same way x86 does? Not exactly. ARM’s load/store architecture requires most memory access to go through explicit LDR/STR instructions with a register holding the address, whereas x86 allows memory operands directly within many instructions.

Why do I sometimes see [label] and sometimes just label? This depends on the assembler and instruction — brackets typically mean “dereference this address,” while no brackets (in certain contexts) may mean “use this address as a value” or refer to an EQU constant.

Summary and Key Takeaways

References

Exit mobile version