Justification: Why a Stack Computer Instruction Can Be “Operation Code Only” (No Address Field)

A stack computer (also called a stack machine) is a CPU model where operands for most operations are taken from, and results are pushed onto, a data stack. In such machines, the instruction stream often needs to specify only what operation to perform; the where the operands are located aspect is handled implicitly by the stack discipline (i.e., the current stack top).

Key idea: when an instruction does an arithmetic/logic operation, the machine automatically uses the top elements of the stack (e.g., $TOS$ and the next element), so an explicit address field (or register specifier) is often unnecessary.

Stack computer
Data stack
TOS
Stack pointer

1) Instruction format: why “address fields” become redundant

In many conventional (register-based or load-store) instruction formats, an instruction must indicate which registers or memory locations contain operands—so instructions often contain fields like register specifiers or memory addresses.

By contrast, in a stack machine:

• Operand sources are implicitly defined as the top elements of the stack.
• After execution, results are implicitly pushed back onto the stack.

Therefore, the instruction encoding can be simplified to mostly:

• Opcode only (e.g., ADD, SUB, MUL, DIV, AND, OR, etc.)
• Plus occasional stack-control or constant-loading operations (e.g., PUSH, POP, LOADC k) that still don’t need “address fields” for arithmetic ops, because PUSH semantics define what to put onto the stack.

This is why the statement is often phrased as: stack computer consists of an operation code only with no address field—meaning that the typical computational instruction needs only the opcode, since operand addresses are implicit in the stack.

Opcode
Instruction format
Implicit operand
LIFO

2) Concrete comparison: register-based vs stack-based operand specification

In a register-based model, instructions must name operands (registers or memory locations). In a stack-based model, operands are determined by execution state (the stack).

Register-based example (conceptual):
ADD R1, R2 must encode where R1 and R2 are.

Stack-based example:
ADD assumes that the two needed operands are already on the stack (pushed earlier), so it doesn’t encode R1 or R2.

Register-based architecture
Operand field
Execution state
Stack-based architecture

3) Why intermediate results fit naturally on a stack

Many expressions can be compiled into postfix (Reverse Polish) form, where operators appear after their operands. This maps directly to stack execution:

• Push operands as they appear.
• When an operator appears, pop the required number of operands, compute, and push the result.

That eliminates the need for addressing intermediate temporaries: they live in the stack automatically.

Postfix notation
Intermediate temporary
Compiler mapping
Expression evaluation