WebAssembly, often called Wasm, is a compact binary instruction format designed to run code safely and quickly in browsers and other environments. This cheat sheet helps students connect low-level bytecode ideas to real web applications, game engines, simulations, and compiled languages. It is useful because WebAssembly combines computer architecture concepts, programming language design, and web platform security in one practical technology.
The core ideas are a stack-based execution model, typed instructions, linear memory, and a clear boundary between a Wasm module and its host environment. A module imports functions or memory from the host, exports functions back to the host, and runs instructions that push and pop values on an operand stack. Toolchains such as Clang, Rust, Emscripten, and wasm-pack compile higher-level languages into Wasm for deployment.
Key Facts
- WebAssembly code is stored as compact bytecode in a .wasm file, while WebAssembly Text Format uses readable .wat syntax for learning and debugging.
- The stack rule is: instructions pop their operands from the operand stack and push their results back onto the operand stack.
- A typical integer addition sequence is i32.const 7, i32.const 5, i32.add, which leaves 12 on the stack.
- The four basic numeric value types are i32, i64, f32, and f64, representing 32-bit integers, 64-bit integers, 32-bit floats, and 64-bit floats.
- Linear memory is a resizable byte array addressed with integer offsets, and memory size is measured in pages where 1 page = 64 KiB.
- A Wasm module can use imports to call host-provided functions and exports to expose its own functions to JavaScript or another runtime.
- WebAssembly is sandboxed, so it cannot directly access the file system, network, DOM, or operating system unless the host gives it an interface.
- A common build path is source code to compiler to .wasm module to JavaScript or runtime loader to executed program.
Vocabulary
- WebAssembly
- WebAssembly is a portable low-level binary instruction format that runs compiled code efficiently in a safe virtual machine.
- Module
- A module is a compiled WebAssembly unit that contains functions, types, imports, exports, tables, memory, and optional globals.
- Operand Stack
- The operand stack is the temporary storage area where WebAssembly instructions place inputs and results during execution.
- Linear Memory
- Linear memory is a contiguous byte array that a WebAssembly module can read and write using numeric addresses.
- Import
- An import is a function, memory, table, or global value supplied by the host environment to a WebAssembly module.
- Export
- An export is a function, memory, table, or global value that a WebAssembly module makes available to the host environment.
Common Mistakes to Avoid
- Treating WebAssembly as a replacement for JavaScript is wrong because Wasm usually works with JavaScript or another host to access browser APIs and manage application behavior.
- Forgetting that Wasm is stack-based is wrong because many instructions do not name registers or variables, they consume values from the stack in a specific order.
- Assuming Wasm can directly change the DOM is wrong because the browser DOM is outside the Wasm sandbox and must be accessed through host functions.
- Mixing up bytes and pages in memory calculations is wrong because WebAssembly memory grows in 64 KiB pages, not in single bytes.
- Ignoring type matching is wrong because instructions such as i32.add require specific operand types, and mismatched types make the module invalid.
Practice Questions
- 1 A Wasm memory starts with 2 pages. How many KiB of linear memory does it have if 1 page = 64 KiB?
- 2 Trace the stack after these instructions: i32.const 10, i32.const 3, i32.sub. What value remains on the stack?
- 3 A module exports a function named calculate and imports a host function named log. Which direction does each function call cross the module boundary?
- 4 Explain why WebAssembly is useful for running code from languages such as C, C++, or Rust in a browser while still keeping the browser environment secure.
Understanding WebAssembly Reference
A Wasm function is checked before it runs. The runtime verifies that each instruction receives the right kind of value and that control flow reaches valid places. This validation is one reason malformed modules are rejected instead of being treated as ordinary programs.
Functions have parameter types, result types, local variables, and a declared sequence of instructions. Local variables hold temporary named slots within one function call. Globals keep values that can be shared across functions.
Students should distinguish locals from the operand stack. A local can be read many times, while a stack value is normally consumed by the next instruction that needs it.
Control flow in Wasm is structured rather than based on arbitrary jumps to any byte position. Blocks, loops, and conditional sections have clear boundaries. A branch targets an enclosing block or loop, identified by how deeply it is nested.
This design helps the validator determine whether every path has compatible values. It resembles the rules behind return types in ordinary programming, but applies inside the function too.
A loop can repeatedly calculate a memory address, load a value, change an index, then branch back. Reading short examples in text format is useful because the nested structure is visible before the compiler turns it into binary bytes.
Linear memory creates an important connection between Wasm and data representation. A program stores arrays, strings, images, or game state as bytes at chosen offsets. The module does not automatically know where an array begins or how long it is.
Code must keep track of that information, often using an address and a length. This is powerful but easy to misuse. An incorrect offset can read unrelated data or trap when it falls outside available memory.
Multi byte numbers are commonly stored with the least significant byte first. Students who understand arrays in C, buffers in JavaScript, or pixels in an image will recognize the same underlying idea.
The boundary with the host affects real program design. A compiled function can do intensive numerical work, while JavaScript handles a button click, screen drawing, or a web request. Moving data across that boundary has a cost, especially when many small calls are made.
Programs often work faster when one call processes a larger batch of values in memory. Wasm does not automatically make every task faster. Browser code, graphics APIs, and network operations still depend on host interfaces.
When debugging, inspect imports, exports, function signatures, memory contents, and compiler output. A mismatch between a host value and a Wasm value type is a common source of errors. Good tests should include boundary cases such as empty arrays, large indexes, negative integers, and floating point values that cannot be represented exactly.