Instructions

WebAssembly code consists of sequences of instructions. Its computational model is based on a stack machine in that instructions manipulate values on an implicit operand stack, consuming (popping) argument values and producing or returning (pushing) result values.

In addition to dynamic operands from the stack, some instructions also have static immediate arguments, typically indices or type annotations, which are part of the instruction itself.

Some instructions are structured in that they bracket nested sequences of instructions.

The following sections group instructions into a number of different categories.

Numeric Instructions

Numeric instructions provide basic operations over numeric values of specific type. These operations closely match respective operations available in hardware.

nn,mm::=32 | 64sx::=u | sinstr::=inn.const unn | fnn.const fnn|inn.iunop | fnn.funop|inn.ibinop | fnn.fbinop|inn.itestop|inn.irelop | fnn.frelop|inn.extend8_s | inn.extend16_s | i64.extend32_s|i32.wrap_i64 | i64.extend_i32_sx | inn.trunc_fmm_sx|inn.trunc_sat_fmm_sx|f32.demote_f64 | f64.promote_f32 | fnn.convert_imm_sx|inn.reinterpret_fnn | fnn.reinterpret_inn|iunop::=clz | ctz | popcntibinop::=add | sub | mul | div_sx | rem_sx|and | or | xor | shl | shr_sx | rotl | rotrfunop::=abs | neg | sqrt | ceil | floor | trunc | nearestfbinop::=add | sub | mul | div | min | max | copysignitestop::=eqzirelop::=eq | ne | lt_sx | gt_sx | le_sx | ge_sxfrelop::=eq | ne | lt | gt | le | ge

Numeric instructions are divided by number type. For each type, several subcategories can be distinguished:

  • Constants: return a static constant.

  • Unary Operations: consume one operand and produce one result of the respective type.

  • Binary Operations: consume two operands and produce one result of the respective type.

  • Tests: consume one operand of the respective type and produce a Boolean integer result.

  • Comparisons: consume two operands of the respective type and produce a Boolean integer result.

  • Conversions: consume a value of one type and produce a result of another (the source type of the conversion is the one after the “_”).

Some integer instructions come in two flavors, where a signedness annotation sx distinguishes whether the operands are to be interpreted as unsigned or signed integers. For the other integer instructions, the use of two’s complement for the signed interpretation means that they behave the same regardless of signedness.

Conventions

Occasionally, it is convenient to group operators together according to the following grammar shorthands:

unop::=iunop | funop | extendN_sbinop::=ibinop | fbinoptestop::=itestoprelop::=irelop | frelopcvtop::=wrap | extend | trunc | trunc_sat | convert | demote | promote | reinterpret

Vector Instructions

Vector instructions (also known as SIMD instructions, single instruction multiple data) provide basic operations over values of vector type.

ishape::=i8x16 | i16x8 | i32x4 | i64x2fshape::=f32x4 | f64x2shape::=ishape | fshapehalf::=low | highlaneidx::=u8
instr::=|v128.const i128|v128.vvunop|v128.vvbinop|v128.vvternop|v128.vvtestop|i8x16.shuffle laneidx16|i8x16.swizzle|shape.splat|i8x16.extract_lane_sx laneidx | i16x8.extract_lane_sx laneidx|i32x4.extract_lane laneidx | i64x2.extract_lane laneidx|fshape.extract_lane laneidx|shape.replace_lane laneidx|i8x16.virelop | i16x8.virelop | i32x4.virelop|i64x2.eq | i64x2.ne | i64x2.lt_s | i64x2.gt_s | i64x2.le_s | i64x2.ge_s|fshape.vfrelop|ishape.viunop | i8x16.popcnt|i16x8.q15mulr_sat_s|i32x4.dot_i16x8_s|fshape.vfunop|ishape.vitestop|ishape.bitmask|i8x16.narrow_i16x8_sx | i16x8.narrow_i32x4_sx|i16x8.extend_half_i8x16_sx | i32x4.extend_half_i16x8_sx|i64x2.extend_half_i32x4_sx|ishape.vishiftop|ishape.vibinop|i8x16.viminmaxop | i16x8.viminmaxop | i32x4.viminmaxop|i8x16.visatbinop | i16x8.visatbinop|i16x8.mul | i32x4.mul | i64x2.mul|i8x16.avgr_u | i16x8.avgr_u|i16x8.extmul_half_i8x16_sx | i32x4.extmul_half_i16x8_sx | i64x2.extmul_half_i32x4_sx|i16x8.extadd_pairwise_i8x16_sx | i32x4.extadd_pairwise_i16x8_sx|fshape.vfbinop|i32x4.trunc_sat_f32x4_sx | i32x4.trunc_sat_f64x2_sx_zero|f32x4.convert_i32x4_sx | f32x4.demote_f64x2_zero|f64x2.convert_low_i32x4_sx | f64x2.promote_low_f32x4|
vvunop::=notvvbinop::=and | andnot | or | xorvvternop::=bitselectvvtestop::=any_truevitestop::=all_truevirelop::=eq | ne | lt_sx | gt_sx | le_sx | ge_sxvfrelop::=eq | ne | lt | gt | le | geviunop::=abs | negvibinop::=add | subviminmaxop::=min_sx | max_sxvisatbinop::=add_sat_sx | sub_sat_sxvishiftop::=shl | shr_sxvfunop::=abs | neg | sqrt | ceil | floor | trunc | nearestvfbinop::=add | sub | mul | div | min | max | pmin | pmax

Vector instructions have a naming convention involving a prefix that determines how their operands will be interpreted. This prefix describes the shape of the operand, written txN, and consisting of a packed numeric type t and the number of lanes N of that type. Operations are performed point-wise on the values of each lane.

Note

For example, the shape i32x4 interprets the operand as four i32 values, packed into an i128. The bitwidth of the numeric type t times N always is 128.

Instructions prefixed with v128 do not involve a specific interpretation, and treat the v128 as an i128 value or a vector of 128 individual bits.

Vector instructions can be grouped into several subcategories:

  • Constants: return a static constant.

  • Unary Operations: consume one v128 operand and produce one v128 result.

  • Binary Operations: consume two v128 operands and produce one v128 result.

  • Ternary Operations: consume three v128 operands and produce one v128 result.

  • Tests: consume one v128 operand and produce a Boolean integer result.

  • Shifts: consume a v128 operand and a i32 operand, producing one v128 result.

  • Splats: consume a value of numeric type and produce a v128 result of a specified shape.

  • Extract lanes: consume a v128 operand and return the numeric value in a given lane.

  • Replace lanes: consume a v128 operand and a numeric value for a given lane, and produce a v128 result.

Some vector instructions have a signedness annotation sx which distinguishes whether the elements in the operands are to be interpreted as unsigned or signed integers. For the other vector instructions, the use of two’s complement for the signed interpretation means that they behave the same regardless of signedness.

Conventions

Occasionally, it is convenient to group operators together according to the following grammar shorthands:

vunop::=viunop | vfunop | popcntvbinop::=vibinop | vfbinop|viminmaxop | visatbinop|mul | avgr_u | q15mulr_sat_svtestop::=vitestopvrelop::=virelop | vfrelopvcvtop::=extend | trunc_sat | convert | demote | promote

Reference Instructions

Instructions in this group are concerned with accessing references.

instr::=|ref.null reftype|ref.is_null|ref.func funcidx

These instructions produce a null value, check for a null value, or produce a reference to a given function, respectively.

Parametric Instructions

Instructions in this group can operate on operands of any value type.

instr::=|drop|select (valtype)?

The drop instruction simply throws away a single operand.

The select instruction selects one of its first two operands based on whether its third operand is zero or not. It may include a value type determining the type of these operands. If missing, the operands must be of numeric type.

Note

In future versions of WebAssembly, the type annotation on select may allow for more than a single value being selected at the same time.

Variable Instructions

Variable instructions are concerned with access to local or global variables.

instr::=|local.get localidx|local.set localidx|local.tee localidx|global.get globalidx|global.set globalidx

These instructions get or set the values of variables, respectively. The local.tee instruction is like local.set but also returns its argument.

Table Instructions

Instructions in this group are concerned with tables table.

instr::=|table.get tableidx|table.set tableidx|table.size tableidx|table.grow tableidx|table.fill tableidx|table.copy tableidx tableidx|table.init tableidx elemidx|elem.drop elemidx

The table.get and table.set instructions load or store an element in a table, respectively.

The table.size instruction returns the current size of a table. The table.grow instruction grows table by a given delta and returns the previous size, or 1 if enough space cannot be allocated. It also takes an initialization value for the newly allocated entries.

The table.fill instruction sets all entries in a range to a given value.

The table.copy instruction copies elements from a source table region to a possibly overlapping destination region; the first index denotes the destination. The table.init instruction copies elements from a passive element segment into a table. The elem.drop instruction prevents further use of a passive element segment. This instruction is intended to be used as an optimization hint. After an element segment is dropped its elements can no longer be retrieved, so the memory used by this segment may be freed.

An additional instruction that accesses a table is the control instruction call_indirect.

Memory Instructions

Instructions in this group are concerned with linear memory.

memarg::={offset u32,align u32}ww::=8 | 16 | 32 | 64instr::=|inn.load memarg | fnn.load memarg | v128.load memarg|inn.store memarg | fnn.store memarg | v128.store memarg|inn.load8_sx memarg | inn.load16_sx memarg | i64.load32_sx memarg|inn.store8 memarg | inn.store16 memarg | i64.store32 memarg|v128.load8x8_sx memarg | v128.load16x4_sx memarg | v128.load32x2_sx memarg|v128.load32_zero memarg | v128.load64_zero memarg|v128.loadww_splat memarg|v128.loadww_lane memarg laneidx | v128.storeww_lane memarg laneidx|memory.size|memory.grow|memory.fill|memory.copy|memory.init dataidx|data.drop dataidx

Memory is accessed with load and store instructions for the different number types. They all take a memory immediate memarg that contains an address offset and the expected alignment (expressed as the exponent of a power of 2). Integer loads and stores can optionally specify a storage size that is smaller than the bit width of the respective value type. In the case of loads, a sign extension mode sx is then required to select appropriate behavior.

Vector loads can specify a shape that is half the bit width of v128. Each lane is half its usual size, and the sign extension mode sx then specifies how the smaller lane is extended to the larger lane. Alternatively, vector loads can perform a splat, such that only a single lane of the specified storage size is loaded, and the result is duplicated to all lanes.

The static address offset is added to the dynamic address operand, yielding a 33 bit effective address that is the zero-based index at which the memory is accessed. All values are read and written in little endian byte order. A trap results if any of the accessed memory bytes lies outside the address range implied by the memory’s current size.

Note

Future versions of WebAssembly might provide memory instructions with 64 bit address ranges.

The memory.size instruction returns the current size of a memory. The memory.grow instruction grows memory by a given delta and returns the previous size, or 1 if enough memory cannot be allocated. Both instructions operate in units of page size.

The memory.fill instruction sets all values in a region to a given byte. The memory.copy instruction copies data from a source memory region to a possibly overlapping destination region. The memory.init instruction copies data from a passive data segment into a memory. The data.drop instruction prevents further use of a passive data segment. This instruction is intended to be used as an optimization hint. After a data segment is dropped its data can no longer be retrieved, so the memory used by this segment may be freed.

Note

In the current version of WebAssembly, all memory instructions implicitly operate on memory index 0. This restriction may be lifted in future versions.

Control Instructions

Instructions in this group affect the flow of control.

blocktype::=typeidx | valtype?instr::=|nop|unreachable|block blocktype instr end|loop blocktype instr end|if blocktype instr else instr end|br labelidx|br_if labelidx|br_table vec(labelidx) labelidx|return|call funcidx|call_indirect tableidx typeidx

The nop instruction does nothing.

The unreachable instruction causes an unconditional trap.

The block, loop and if instructions are structured instructions. They bracket nested sequences of instructions, called blocks, terminated with, or separated by, end or else pseudo-instructions. As the grammar prescribes, they must be well-nested.

A structured instruction can consume input and produce output on the operand stack according to its annotated block type. It is given either as a type index that refers to a suitable function type, or as an optional value type inline, which is a shorthand for the function type [][valtype?].

Each structured control instruction introduces an implicit label. Labels are targets for branch instructions that reference them with label indices. Unlike with other index spaces, indexing of labels is relative by nesting depth, that is, label 0 refers to the innermost structured control instruction enclosing the referring branch instruction, while increasing indices refer to those farther out. Consequently, labels can only be referenced from within the associated structured control instruction. This also implies that branches can only be directed outwards, “breaking” from the block of the control construct they target. The exact effect depends on that control construct. In case of block or if it is a forward jump, resuming execution after the matching end. In case of loop it is a backward jump to the beginning of the loop.

Note

This enforces structured control flow. Intuitively, a branch targeting a block or if behaves like a break statement in most C-like languages, while a branch targeting a loop behaves like a continue statement.

Branch instructions come in several flavors: br performs an unconditional branch, br_if performs a conditional branch, and br_table performs an indirect branch through an operand indexing into the label vector that is an immediate to the instruction, or to a default target if the operand is out of bounds. The return instruction is a shortcut for an unconditional branch to the outermost block, which implicitly is the body of the current function. Taking a branch unwinds the operand stack up to the height where the targeted structured control instruction was entered. However, branches may additionally consume operands themselves, which they push back on the operand stack after unwinding. Forward branches require operands according to the output of the targeted block’s type, i.e., represent the values produced by the terminated block. Backward branches require operands according to the input of the targeted block’s type, i.e., represent the values consumed by the restarted block.

The call instruction invokes another function, consuming the necessary arguments from the stack and returning the result values of the call. The call_indirect instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must have type funcref. Since it may contain functions of heterogeneous type, the callee is dynamically checked against the function type indexed by the instruction’s second immediate, and the call is aborted with a trap if it does not match.

Expressions

Function bodies, initialization values for globals, elements and offsets of element segments, and offsets of data segments are given as expressions, which are sequences of instructions terminated by an end marker.

expr::=instr end

In some places, validation restricts expressions to be constant, which limits the set of allowable instructions.