The WebAssembly Execution Model

The instruction set is a stack machine's: operands are pushed, an operator pops them and pushes a result. i32.add pops two 32-bit integers and pushes their sum; there are no registers to name and no register allocation to encode. That is the same design as most bytecode formats and for the same reason — see [[stack-based-vm]] — and the reason is compactness. A stack instruction does not need operand fields, so the encoding is small, and small matters when the artifact is downloaded before anything runs.

The critical thing to keep separate is that the stack machine is the *format*, not the execution model of the code that finally runs. A runtime that compiles the module produces ordinary register machine code, and the operand stack disappears entirely into virtual registers and then physical ones. It is the same relationship as [[bytecode]] to a JIT-compiled function: the linear format is a serialisation, and treating it as a description of what the CPU does leads to wrong conclusions about performance.

Locals are typed and are *not* addressable. This matters more than it sounds: a C or C++ program that takes the address of a local cannot use a Wasm local for it, so toolchains synthesise a shadow stack inside linear memory for exactly those variables. It is why WebAssembly can validate so cheaply — a local's type is known statically and can never be aliased — and it is a real cost paid by languages whose model assumes every variable has an address.

WebAssembly has no goto. Control flow is expressed with block, loop and if constructs, and branches — br, br_if, br_table — may only target a label belonging to an enclosing construct. A br out of a block jumps to its end; a br targeting a loop jumps to its start. There is no way to write a jump into the middle of another construct, because no such target can be named.

That restriction is what makes single-pass validation possible. With arbitrary jumps, the type of the operand stack at an instruction depends on every path that could reach it, and checking becomes a dataflow problem requiring iteration to a fixed point — precisely the machinery [[data-flow-framework]] describes. With structured control flow, the stack type at every point is determined by the enclosing constructs, so the validator carries one stack type and sweeps forward. Validation cost is linear in module size and there is no worst case that blows up.

The price falls on the compiler. A backend has an arbitrary control-flow graph and must reconstruct structure from it — the relooper or stackifier problem — and irreducible control flow, which a CFG can express and structured constructs cannot, requires either code duplication or a dispatch loop with a state variable. Both cost real code size and speed. This is the clearest case in the domain of a target constraint pushing work back up the pipeline, and it is why the multi-value and later control-flow proposals exist. See [[control-flow-graph]] and [[natural-loops]] for what the compiler is working from.

A module's memory is one contiguous byte array with a declared minimum size, addressed from zero, which can be grown with memory.grow and never shrunk. Every load and store names an offset into it, and every access is bounds-checked against the current size — in practice usually by the runtime reserving a large guard region so that the hardware's own memory protection performs the check, but the semantic guarantee is the same either way.

The consequence is the safety property that matters: a module cannot address anything outside its own memory. There is no pointer to host memory, no way to construct one, and no instruction that takes an absolute machine address. A buffer overflow inside a module corrupts that module's own data — which can absolutely be a serious bug in the module's own logic — and cannot reach the host or another instance. This is memory safety at the *boundary*, not inside the module, and conflating the two is the most common overstatement made about WebAssembly.

The second half of the sandbox is the absence of ambient authority. A native process starts with the ability to make any system call the operating system permits; a Wasm instance starts with nothing. Files, clocks, randomness, network access and console output all arrive as imports the host explicitly provided, so a host that grants nothing has given a module that can compute and cannot observe or affect anything. That is capability-based security by construction — the design cannot express ambient authority, so there is nothing to configure wrongly — and it is what makes running untrusted modules a reasonable thing to do at all.

Memory only grows. An instance whose peak usage is high early on holds that memory for its lifetime, because memory.grow has no counterpart. For long-lived instances or many concurrent ones, that changes capacity planning in a way that native processes and their allocators do not.

The host boundary is a real cost. A call from host to module or module to host is not a function call in the same address space with the same conventions — arguments must be marshalled, and anything larger than a scalar must be copied into or out of linear memory, since the host cannot hand the module a pointer to its own data. A workload structured as many small crossings can spend most of its time on the boundary, and restructuring it into fewer, larger calls is usually the single largest available improvement.

And the feature set is a moving target. The 1.0 core is stable and universally implemented, but threads, SIMD, exceptions, tail calls, reference types, garbage collection and the component model have each arrived as proposals implemented at different times by different runtimes. "Does this run everywhere" is really "does every runtime I target implement every proposal my toolchain used", and the failure mode is a validation error rather than a graceful degradation.