The Wasm Execution Model

Analogy categoryAnalogies

WebAssembly executes as a stack machine: most instructions pop their operands off an implicit value stack and push their result back onto it, rather than operating on named registers. A local.get pushes a local variable's value, i32.add pops the top two i32 values and pushes their sum, and so on — this design keeps the instruction encoding compact and makes validation straightforward, since the type of every stack slot can be checked statically before execution begins.

🏏

Cricket analogy: Like a scoreboard operator who only ever updates the topmost running total after each ball rather than tracking every player's individual tally in separate boxes, Wasm's stack machine only ever operates on the top of its value stack.

Linear Memory

A Wasm module's linear memory is a single, contiguous, resizable array of bytes — addressed from 0 up to its current size, growable in 64 KiB pages via memory.grow — that stores everything a compiled program needs on the heap: strings, structs, arrays, and the call stack in languages compiled without native Wasm support for it. Because linear memory is just bytes, both the Wasm module and the host (via a JavaScript ArrayBuffer view) can read and write it directly, which is exactly the mechanism used to pass complex data like strings across the JS/Wasm boundary.

🏏

Cricket analogy: Like a single continuous scoreboard ledger where every run, wicket, and extra is written at a specific byte offset rather than in separate scattered notebooks, Wasm's linear memory is one contiguous, addressable byte array.

Modules, Instances, and the Store

A Wasm module is the static, compiled artifact — validated code, type signatures, and section metadata — that by itself does nothing; it must be instantiated into a module instance, which allocates its own linear memory, tables, and globals and links its imports to concrete values provided by the host. Multiple instances can be created from the same module, each with independent state, and the store is the runtime's bookkeeping structure that owns all instances, their memories, and their tables for the lifetime of the embedding (e.g., the browser tab or the standalone runtime process).

🏏

Cricket analogy: Like a fixed set of coaching drills in a manual that only produce results once a specific squad actually runs them on the training ground, a Wasm module is inert code until instantiated with real memory and state, just as drills need a real team to execute them.

Control Flow and Structured Blocks

Unlike native machine code, which uses arbitrary jump/goto instructions, Wasm restricts control flow to structured constructs — block, loop, if/else, and br/br_if for branching — that must be properly nested, which is what lets a validator prove in a single linear pass that every branch target is well-formed and every stack transition is type-safe before a single instruction runs.

🏏

Cricket analogy: Like the strict, nested structure of an over — six legal balls within an over, overs within an innings — that a scorer can validate mechanically without ambiguity, Wasm's structured blocks let a validator check control flow with no arbitrary jumps.

wat

(module
  (func $count_to_ten (result i32)
    (local $i i32)
    (local.set $i (i32.const 0))
    (block $exit
      (loop $continue
        (local.set $i (i32.add (local.get $i) (i32.const 1)))
        (br_if $exit (i32.ge_s (local.get $i) (i32.const 10)))
        (br $continue)))
    local.get $i)
  (export "count_to_ten" (func $count_to_ten)))

Wasm has no arbitrary goto: every branch (br, br_if, br_table) can only target an enclosing block or loop label, which is exactly why validators can verify a module's control flow in a single fast, linear pass.

Wasm executes as a stack machine: instructions pop operands from and push results onto an implicit value stack.
Linear memory is one contiguous, resizable byte array shared and addressable by both the module and the host.
memory.grow expands linear memory in fixed 64 KiB pages.
A module is static compiled code; a module instance is a live, running instantiation with its own memory, tables, and globals.
The store is the runtime structure that owns all instances, memories, and tables for the life of the embedding.
Wasm control flow uses only structured constructs (block, loop, if/else) with properly nested branch targets — no arbitrary goto.
This structured control flow is what enables single-pass, provably type-safe validation before execution begins.

Practice what you learned

1. How does WebAssembly's instruction set primarily operate?

2. What is Wasm linear memory?

3. What is the difference between a Wasm module and a module instance?

4. How does WebAssembly express control flow like loops and conditionals?

5. In what fixed unit does Wasm linear memory grow via memory.grow?

Was this page helpful?

Wasm vs JavaScript

WAT Text Format Basics

Related Study Notes in Web Development

Browse all study notes

Web Development

WebSockets Study Notes

Web Development · 30 topics

Web Development

gRPC Study Notes

Protocol Buffers · 30 topics

Web Development

Spring Boot Study Notes

Java · 30 topics

Web Development

Flask Study Notes

Python · 30 topics

Web Development

Django Study Notes

Python · 30 topics

Web Development

Next.js Study Notes

JavaScript · 30 topics

Topics covered

#WebAssembly#WebAssemblyStudyNotes#WebDevelopment#TheWasmExecutionModel#Wasm#Execution#Model#Linear#StudyNotes#SkillVeris

The Wasm Execution Model