Call Stack & Execution Contexts

When you write result = calculateTotal(items), something remarkable happens behind the scenes. Your program must:

1. Pause what it's doing and remember where to resume
2. Transfer control to an entirely different location in code
3. Pass data (the items parameter) to that new location
4. Execute the function's code
5. Return to exactly where it left off
6. Retrieve the result and continue as if nothing complex happened

This seamless transition happens millions of times per second in running programs. The mechanism that enables it is the call stack, and understanding its precise operation transforms you from a developer who uses functions to one who truly understands them.

Before examining the solution, let's understand the problem deeply. For a function call to work, the system must solve several non-trivial challenges:

Challenge 1: Saving the Return Address

When you call a function, you leave one location in code and jump to another. But you need to come back. Where do you come back to? The instruction immediately after the call. This "return address" must be saved somewhere before the jump—and the stack is that somewhere.

Challenge 2: Passing Arguments

Functions need input. How does add(3, 5) get the values 3 and 5 to the add function? These values must be placed somewhere the function can find them. Different calling conventions solve this differently (registers, stack, or both).

Challenge 3: Providing Return Value

The function computes a result. How does it give that result back to the caller? There must be a designated location—often a specific register—where the return value is placed.

Challenge 4: Nested Calls

Functions call other functions which call other functions. Each level must independently handle all the above challenges. This is where the stack's LIFO nature becomes essential—each call adds its own context, and each return removes it.

Let's trace exactly what happens during a function call. We'll use a simplified model based on x86-64 calling conventions, though the principles apply across architectures.

The Scenario:

void caller() {
    int result = add(3, 5);
    // ... continue with result
}

int add(int a, int b) {
    int sum = a + b;
    return sum;
}

The CALL instruction is the heart of function invocation. Let's examine it in detail:

What CALL does (pseudocode):

CALL target_address:
    PUSH (address of next instruction)   ; Save return address
    JMP target_address                    ; Transfer control

In concrete terms:

If the CALL instruction is at memory address 0x1000 and is 5 bytes long, and the target function is at 0x2000:

1. The return address 0x1005 (next instruction) is pushed onto the stack
2. The instruction pointer (RIP) is set to 0x2000
3. Execution continues from 0x2000 (the function entry)

Variations in CALL:

Direct Call: The target address is encoded in the instruction itself. Example: call 0x400700

Indirect Call: The target address comes from a register or memory location. Example: call rax or call [rbx]. This enables virtual function dispatch, callbacks, and function pointers.

Relative Call: The instruction encodes an offset from the current position rather than an absolute address. This is common for position-independent code (PIC) in shared libraries.

Regardless of the variation, the stack behavior—pushing the return address—remains consistent.

The RET (return) instruction is the counterpart to CALL, completing the round trip:

What RET does (pseudocode):

RET:
    POP temp                 ; Remove return address from stack
    JMP temp                 ; Jump to that address

This simple operation undoes what CALL did—pops the saved return address and jumps to it.

Symmetry of CALL and RET:

Notice the beautiful symmetry:

This symmetry ensures that every CALL is perfectly undone by RET, maintaining stack integrity across arbitrarily deep call chains.

How arguments travel from caller to callee is defined by calling conventions—agreements about where arguments are placed. Different platforms and languages have different conventions, but they all solve the same problem.

The Three Primary Approaches:

Common Calling Conventions:

System V AMD64 ABI (Linux, macOS, BSD):

• Integer/pointer arguments: RDI, RSI, RDX, RCX, R8, R9 (first 6)
• Floating-point arguments: XMM0–XMM7 (first 8)
• Additional arguments: pushed right-to-left onto stack
• Return value: RAX (integer), XMM0 (floating-point)

Microsoft x64 (Windows):

• Integer/pointer arguments: RCX, RDX, R8, R9 (first 4)
• Floating-point arguments: XMM0–XMM3 (first 4)
• Requires 32-byte "shadow space" on stack
• Return value: RAX (integer), XMM0 (floating-point)

cdecl (32-bit x86):

• All arguments pushed onto stack, right-to-left
• Caller cleans up the stack after call
• Return value: EAX

Returning a value from a function involves placing it where the caller can find it. This is simpler than argument passing because there's only one return value (in most languages), but there are still important considerations.

Standard Return Value Locations:

The Hidden First Argument:

When a function returns a large struct (too big for registers), the compiler implements a clever workaround:

// What you write:
Struct getBigData() {
    Struct result;
    // ... fill result
    return result;
}

// What the compiler generates (conceptually):
void getBigData(Struct* __hidden_return_ptr) {
    // ... fill *__hidden_return_ptr
    return;
}

The caller allocates space for the return value and passes a pointer as a hidden first argument. The function fills that memory directly. This is called Return Value Optimization (RVO) when the compiler optimizes away intermediate copies.

The true power of the call stack emerges with nested function calls. Each call adds a layer to the stack; each return removes a layer. Let's trace through a nested scenario:

Example:

int main() {
    int x = outer(10);
    return x;
}

int outer(int n) {
    int y = inner(n + 5);
    return y * 2;
}

int inner(int m) {
    return m + 1;
}

Stack Unwinding:

The process of returning through nested calls—popping stack frames in reverse order—is called stack unwinding. This concept becomes especially important for:

1. Exception handling: When an exception is thrown, the runtime unwinds the stack, searching for a catch handler and calling destructors along the way.

2. Debugging: Stack traces show unwound call chains, revealing how execution reached the current point.

3. Profilers: Sampling profilers capture stack frames periodically, then unwind them to attribute time to calling functions.

The LIFO nature of the stack ensures unwinding happens in exactly the right order—most recent call first, then its caller, and so on.

Functions use CPU registers for computation. But when function A calls function B, B will use the same registers. If A had important values in those registers, they'd be overwritten. How is this managed?

The Solution: Dividing Registers into Two Categories

How it works in practice:

Caller-saved registers: The caller assumes these registers may be modified by any function it calls. If the caller needs a value in RAX to persist across a call, it must save that value (typically on the stack) before the call and restore it after.

Callee-saved registers: The callee promises that these registers will have the same values after it returns as they did when it was called. If the callee wants to use RBX, it must save the original RBX value (on the stack) at entry and restore it before returning.

This division minimizes total saving:

If all registers were callee-saved, every function would have to save them all. If all were caller-saved, every caller would have to save everything. The split lets functions that use few registers avoid saving, while functions that need many registers bear the cost of saving only what they modify.

Let's synthesize everything into a complete picture of what happens during a function call and return. This detailed understanding represents exactly what happens in compiled code.

We've examined the precise mechanics that enable functions to work. This knowledge connects abstract understanding to concrete implementation.

What's next:

Now that we understand function calls and returns, the next page examines what's actually inside each stack frame. We'll explore stack frames in detail—the structure that holds local variables, saved registers, and everything a function needs to execute independently. This is where the stack becomes a sophisticated memory manager for each function's execution context.