Stack-Based Architecture of a CPU: Core Concepts, Data Paths, and Execution Flow

A stack-based CPU architecture uses a memory-backed stack (and often separate stacks) as the primary mechanism for evaluating expressions, handling operands, and supporting procedure calls/returns. Instead of explicitly naming many registers for intermediate values, most instructions implicitly take operands from the top of the stack and push results back onto it—an approach that simplifies the instruction format and can reduce the need for a large general-purpose register file.

Key terms you’ll use throughout:

• Stack pointer (SP)
• Push
• Pop
• Operand stack
• Return address

Why stacks appear in CPU designs

1. Expression evaluation: Instructions can treat the stack top(s) as operands, making bytecode/instruction encodings compact.
2. Procedure calls: The CPU can save a return address (and sometimes frame info) on the stack, enabling nested calls.
3. Calling conventions: Stack frames provide a structured place for parameters, locals, and saved registers.

Diagram: stack-based CPU micro-architecture (conceptual)

The diagram below focuses on the data movement typical of stack-based execution: the ALU consumes operands taken from the operand stack (via SP-addressed memory access) and then pushes results back.

In practice, modern implementations may use caches, internal buffers, and register renaming. But the architectural model remains: instructions implicitly interact with a stack via SP.

[CalloutBlock] type="tip" title="Pro Tip" content="When reasoning about a stack-based CPU, always track three things per instruction: (1) what values are at the top(s) of stack, (2) how many pops occur, and (3) what value is pushed back (and where—operand vs return stack)."

Comparing two “stack” roles: data vs control

Many stack-based designs conceptually separate:

• Operand/data stack for intermediate values (e.g., arithmetic).
• Control stack / call stack for procedure calls (return addresses, frames, saved state).

Even in CPUs that use a single physical stack in memory, the logical roles remain important for correctness and for understanding stack frames.

Typical instruction patterns

• Arithmetic:
  • Pop operand A
  • Pop operand B
  • Compute $B \,\text{op}\, A$
  • Push result
• Call/Return:
  • Call:
    • Push return address
    • Jump to callee
  • Return:
    • Pop return address
    • Jump back

[CalloutBlock] type="warning" title="Common pitfall" content="Don’t confuse “stack-based instruction encoding” with “a real stack machine.” The execution model might still microcode through internal registers, but the architectural behavior should match the stack semantics (push/pop order matters!)."

A concrete “stack machine” viewpoint (what changes vs register machines)

In a register-based ISA, you often specify registers explicitly for inputs/outputs (or the compiler uses fixed registers by convention). In a stack-based ISA/VM model, the instruction stream tends to look more like:

• PUSH const (push immediate onto stack)
• ADD (pop two values, push sum)
• CALL f (push return address, jump)
• RET (pop return address, jump back)

Diagram: stack evolution for a sample expression

Example expression: $(a + b) \times c$

This model emphasizes implicit operand location (stack top) rather than explicit register operands.