WebAssembly Core Specification

1. Introduction

1.1. Introduction

WebAssembly (abbreviated Wasm [1]) is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.

WebAssembly is an open standard developed by a W3C Community Group.

This document describes version 3.0 (Draft 2024-11-07) of the core WebAssembly standard. It is intended that it will be superseded by new incremental releases with additional features in the future.

1.1.1. Design Goals

The design goals of WebAssembly are the following:

Fast, safe, and portable semantics:
- Fast: executes with near native code performance, taking advantage of capabilities common to all contemporary hardware.
- Safe: code is validated and executes in a memory-safe [2], sandboxed environment preventing data corruption or security breaches.
- Well-defined: fully and precisely defines valid programs and their behavior in a way that is easy to reason about informally and formally.
- Hardware-independent: can be compiled on all modern architectures, desktop or mobile devices and embedded systems alike.
- Language-independent: does not privilege any particular language, programming model, or object model.
- Platform-independent: can be embedded in browsers, run as a stand-alone VM, or integrated in other environments.
- Open: programs can interoperate with their environment in a simple and universal manner.
Efficient and portable representation:
- Compact: has a binary format that is fast to transmit by being smaller than typical text or native code formats.
- Modular: programs can be split up in smaller parts that can be transmitted, cached, and consumed separately.
- Efficient: can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time (JIT) or ahead-of-time (AOT) compilation.
- Streamable: allows decoding, validation, and compilation to begin as soon as possible, before all data has been seen.
- Parallelizable: allows decoding, validation, and compilation to be split into many independent parallel tasks.
- Portable: makes no architectural assumptions that are not broadly supported across modern hardware.

WebAssembly code is also intended to be easy to inspect and debug, especially in environments like web browsers, but such features are beyond the scope of this specification.

1.1.2. Scope

At its core, WebAssembly is a virtual instruction set architecture (virtual ISA). As such, it has many use cases and can be embedded in many different environments. To encompass their variety and enable maximum reuse, the WebAssembly specification is split and layered into several documents.

This document is concerned with the core ISA layer of WebAssembly. It defines the instruction set, binary encoding, validation, and execution semantics, as well as a textual representation. It does not, however, define how WebAssembly programs can interact with a specific environment they execute in, nor how they are invoked from such an environment.

Instead, this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.

1.1.3. Security Considerations

WebAssembly provides no ambient access to the computing environment in which code is executed. Any interaction with the environment, such as I/O, access to resources, or operating system calls, can only be performed by invoking functions provided by the embedder and imported into a WebAssembly module. An embedder can establish security policies suitable for a respective environment by controlling or limiting which functional capabilities it makes available for import. Such considerations are an embedder’s responsibility and the subject of API definitions for a specific environment.

Because WebAssembly is designed to be translated into machine code running directly on the host’s hardware, it is potentially vulnerable to side channel attacks on the hardware level. In environments where this is a concern, an embedder may have to put suitable mitigations into place to isolate WebAssembly computations.

1.1.4. Dependencies

WebAssembly depends on two existing standards:

[IEEE-754-2019], for the representation of floating-point data and the semantics of respective numeric operations.
[UNICODE], for the representation of import/export names and the text format.

However, to make this specification self-contained, relevant aspects of the aforementioned standards are defined and formalized as part of this specification, such as the binary representation and rounding of floating-point values, and the value range and UTF-8 encoding of Unicode characters.

Note

The aforementioned standards are the authoritative source of all respective definitions. Formalizations given in this specification are intended to match these definitions. Any discrepancy in the syntax or semantics described is to be considered an error.

1.2. Overview

1.2.1. Concepts

WebAssembly encodes a low-level, assembly-like programming language. This language is structured around the following concepts.

Values

WebAssembly provides only four basic number types. These are integers and [IEEE-754-2019] numbers, each in 32 and 64 bit width. 32 bit integers also serve as Booleans and as memory addresses. The usual operations on these types are available, including the full matrix of conversions between them. There is no distinction between signed and unsigned integer types. Instead, integers are interpreted by respective operations as either unsigned or signed in two’s complement representation.

In addition to these basic number types, there is a single 128 bit wide vector type representing different types of packed data. The supported representations are 4 32-bit, or 2 64-bit [IEEE-754-2019] numbers, or different widths of packed integer values, specifically 2 64-bit integers, 4 32-bit integers, 8 16-bit integers, or 16 8-bit integers.

Finally, values can consist of opaque references that represent pointers towards different sorts of entities. Unlike with other types, their size or representation is not observable.

Instructions: The computational model of WebAssembly is based on a stack machine. Code consists of sequences of instructions that are executed in order. Instructions manipulate values on an implicit operand stack [1] and fall into two main categories. Simple instructions perform basic operations on data. They pop arguments from the operand stack and push results back to it. Control instructions alter control flow. Control flow is structured, meaning it is expressed with well-nested constructs such as blocks, loops, and conditionals. Branches can only target such constructs.

Traps: Under some conditions, certain instructions may produce a trap, which immediately aborts execution. Traps cannot be handled by WebAssembly code, but are reported to the outside environment, where they typically can be caught.

Functions: Code is organized into separate functions. Each function takes a sequence of values as parameters and returns a sequence of values as results. Functions can call each other, including recursively, resulting in an implicit call stack that cannot be accessed directly. Functions may also declare mutable local variables that are usable as virtual registers.

Tables: A table is an array of opaque values of a particular reference type. It allows programs to select such values indirectly through a dynamic index operand. Thereby, for example, a program can call functions indirectly through a dynamic index into a table. This allows emulating function pointers by way of table indices.

Linear Memory: A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.

Modules: A WebAssembly binary takes the form of a module that contains definitions for functions, tables, and linear memories, as well as mutable or immutable global variables. Definitions can also be imported, specifying a module/name pair and a suitable type. Each definition can optionally be exported under one or more names. In addition to definitions, modules can define initialization data for their memories or tables that takes the form of segments copied to given offsets. They can also define a start function that is automatically executed.

Embedder: A WebAssembly implementation will typically be embedded into a host environment. This environment defines how loading of modules is initiated, how imports are provided (including host-side definitions), and how exports can be accessed. However, the details of any particular embedding are beyond the scope of this specification, and will instead be provided by complementary, environment-specific API definitions.

1.2.2. Semantic Phases

Conceptually, the semantics of WebAssembly is divided into three phases. For each part of the language, the specification specifies each of them.

Decoding: WebAssembly modules are distributed in a binary format. Decoding processes that format and converts it into an internal representation of a module. In this specification, this representation is modelled by abstract syntax, but a real implementation could compile directly to machine code instead.

Validation: A decoded module has to be valid. Validation checks a number of well-formedness conditions to guarantee that the module is meaningful and safe. In particular, it performs type checking of functions and the instruction sequences in their bodies, ensuring for example that the operand stack is used consistently.

Execution

Finally, a valid module can be executed. Execution can be further divided into two phases:

Instantiation. A module instance is the dynamic representation of a module, complete with its own state and execution stack. Instantiation executes the module body itself, given definitions for all its imports. It initializes globals, memories and tables and invokes the module’s start function if defined. It returns the instances of the module’s exports.

Invocation. Once instantiated, further WebAssembly computations can be initiated by invoking an exported function on a module instance. Given the required arguments, that executes the respective function and returns its results.

Instantiation and invocation are operations within the embedding environment.

2. Structure

2.1. Conventions

WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure. For conciseness, this structure is described in the form of an abstract syntax. All parts of this specification are defined in terms of this abstract syntax.

2.1.1. Grammar Notation

The following conventions are adopted in defining grammar rules for abstract syntax.

Terminal symbols (atoms) are written in sans-serif font or in symbolic form: $i32, end, \to, [,]$ .
Nonterminal symbols are written in italic font: $valtype, instr$ .
$A^{n}$ is a sequence of $n \geq 0$ iterations of $A$ .
$A^{*}$ is a possibly empty sequence of iterations of $A$ . (This is a shorthand for $A^{n}$ used where $n$ is not relevant.)
$A^{+}$ is a non-empty sequence of iterations of $A$ . (This is a shorthand for $A^{n}$ where $n \geq 1$ .)
$A^{?}$ is an optional occurrence of $A$ . (This is a shorthand for $A^{n}$ where $n \leq 1$ .)
Productions are written $sym ::= A_{1} ∣ \dots ∣ A_{n}$ .
Large productions may be split into multiple definitions, indicated by ending the first one with explicit ellipses, $sym ::= A_{1} ∣ \dots$ , and starting continuations with ellipses, $sym ::= \dots ∣ A_{2}$ .
Some productions are augmented with side conditions in parentheses, “ $(if condition)$ ”, that provide a shorthand for a combinatorial expansion of the production into many separate cases.
If the same meta variable or non-terminal symbol appears multiple times in a production, then all those occurrences must have the same instantiation. (This is a shorthand for a side condition requiring multiple different variables to be equal.)

2.1.2. Auxiliary Notation

When dealing with syntactic constructs the following notation is also used:

$ϵ$ denotes the empty sequence.
$∣s∣$ denotes the length of a sequence $s$ .
$s [i]$ denotes the $i$ -th element of a sequence $s$ , starting from $0$ .
$s [i : n]$ denotes the sub-sequence $s [i] \dots s [i + n - 1]$ of a sequence $s$ .
$s with [i] = A$ denotes the same sequence as $s$ , except that the $i$ -th element is replaced with $A$ .
$s with [i : n] = A^{n}$ denotes the same sequence as $s$ , except that the sub-sequence $s [i : n]$ is replaced with $A^{n}$ .
$concat (s^{*})$ denotes the flat sequence formed by concatenating all sequences $s_{i}$ in $s^{*}$ .

Moreover, the following conventions are employed:

The notation $x^{n}$ , where $x$ is a non-terminal symbol, is treated as a meta variable ranging over respective sequences of $x$ (similarly for $x^{*}$ , $x^{+}$ , $x^{?}$ ).
When given a sequence $x^{n}$ , then the occurrences of $x$ in a sequence written $(A_{1} x A_{2})^{n}$ are assumed to be in point-wise correspondence with $x^{n}$ (similarly for $x^{*}$ , $x^{+}$ , $x^{?}$ ). This implicitly expresses a form of mapping syntactic constructions over a sequence.

Productions of the following form are interpreted as records that map a fixed set of fields $field_{i}$ to “values” $A_{i}$ , respectively:

r ::= {field_{1} A_{1}, field_{2} A_{2}, \dots}

The following notation is adopted for manipulating such records:

$r. field$ denotes the contents of the $field$ component of $r$ .
$r with field = A$ denotes the same record as $r$ , except that the contents of the $field$ component is replaced with $A$ .
$r_{1} \oplus r_{2}$ denotes the composition of two records with the same fields of sequences by appending each sequence point-wise:

${field_{1} A_{1}^{*}, field_{2} A_{2}^{*}, \dots} \oplus {field_{1} B_{1}^{*}, field_{2} B_{2}^{*}, \dots} = {field_{1} A_{1}^{*} B_{1}^{*}, field_{2} A_{2}^{*} B_{2}^{*}, \dots}$
$⨁ r^{*}$ denotes the composition of a sequence of records, respectively; if the sequence is empty, then all fields of the resulting record are empty.

The update notation for sequences and records generalizes recursively to nested components accessed by “paths” $pth ::= ([\dots] ∣ . field)^{+}$ :

$s with [i] pth = A$ is short for $s with [i] = (s [i] with pth = A)$ ,
$r with field pth = A$ is short for $r with field = (r. field with pth = A)$ ,

where $r with . field = A$ is shortened to $r with field = A$ .

2.1.3. Vectors

Vectors are bounded sequences of the form $A^{n}$ (or $A^{*}$ ), where the $A$ can either be values or complex constructions. A vector can have at most $2^{32} - 1$ elements.

vec (A) ::= A^{n} (if n < 2^{32})

2.2. Values

WebAssembly programs operate on primitive numeric values. Moreover, in the definition of programs, immutable sequences of values occur to represent more complex data, such as text strings or other vectors.

2.2.1. Bytes

The simplest form of value are raw uninterpreted bytes. In the abstract syntax they are represented as hexadecimal literals.

byte ::= 0x 00 ∣ \dots ∣ 0x FF

2.2.1.1. Conventions

The meta variable $b$ ranges over bytes.
Bytes are sometimes interpreted as natural numbers $n < 256$ .

2.2.2. Integers

Different classes of integers with different value ranges are distinguished by their bit width $N$ and by whether they are unsigned or signed.

u N s N i N ::= ::= ::= 0 ∣ 1 ∣ \dots ∣ 2^{N} - 1 - 2^{N - 1} ∣ \dots ∣ - 1 ∣ 0 ∣ 1 ∣ \dots ∣ 2^{N - 1} - 1 u N

The class $i N$ defines uninterpreted integers, whose signedness interpretation can vary depending on context. In the abstract syntax, they are represented as unsigned values. However, some operations convert them to signed based on a two’s complement interpretation.

Note

The main integer types occurring in this specification are $u32$ , $u64$ , $s32$ , $s64$ , $i8$ , $i16$ , $i32$ , $i64$ . However, other sizes occur as auxiliary constructions, e.g., in the definition of floating-point numbers.

2.2.2.1. Conventions

The meta variables $m, n, i$ range over integers.
Numbers may be denoted by simple arithmetics, as in the grammar above. In order to distinguish arithmetics like $2^{N}$ from sequences like $(1)^{N}$ , the latter is distinguished with parentheses.

2.2.3. Floating-Point

Floating-point data represents 32 or 64 bit values that correspond to the respective binary formats of the [IEEE-754-2019] standard (Section 3.3).

Every value has a sign and a magnitude. Magnitudes can either be expressed as normal numbers of the form $m_{0} . m_{1} m_{2} \dots m_{M} \cdot 2^{e}$ , where $e$ is the exponent and $m$ is the significand whose most significant bit $m_{0}$ is $1$ , or as a subnormal number where the exponent is fixed to the smallest possible value and $m_{0}$ is $0$ ; among the subnormals are positive and negative zero values. Since the significands are binary values, normals are represented in the form $(1 + m \cdot 2^{- M}) \cdot 2^{e}$ , where $M$ is the bit width of $m$ ; similarly for subnormals.

Possible magnitudes also include the special values $\infty$ (infinity) and $nan$ (NaN, not a number). NaN values have a payload that describes the mantissa bits in the underlying binary representation. No distinction is made between signalling and quiet NaNs.

f N f Nmag ::= ::= ∣ ∣ ∣ + f Nmag ∣ - f Nmag (1 + u M \cdot 2^{- M}) \cdot 2^{e} (0 + u M \cdot 2^{- M}) \cdot 2^{e} \infty nan (n) (if - 2^{E - 1} + 2 \leq e \leq 2^{E - 1} - 1) (if e = - 2^{E - 1} + 2) (if 1 \leq n < 2^{M})

where $M = signif (N)$ and $E = expon (N)$ with

signif (32) signif (64) = = 2352 expon (32) expon (64) = = 811

A canonical NaN is a floating-point value $\pm nan (canon_{N})$ where $canon_{N}$ is a payload whose most significant bit is $1$ while all others are $0$ :

canon_{N} = 2^{signif (N) - 1}

An arithmetic NaN is a floating-point value $\pm nan (n)$ with $n \geq canon_{N}$ , such that the most significant bit is $1$ while all others are arbitrary.

Note

In the abstract syntax, subnormals are distinguished by the leading 0 of the significand. The exponent of subnormals has the same value as the smallest possible exponent of a normal number. Only in the binary representation the exponent of a subnormal is encoded differently than the exponent of any normal number.

The notion of canonical NaN defined here is unrelated to the notion of canonical NaN that the [IEEE-754-2019] standard (Section 3.5.2) defines for decimal interchange formats.

2.2.3.1. Conventions

The meta variable $z$ ranges over floating-point values where clear from context.

2.2.4. Vectors

Numeric vectors are 128-bit values that are processed by vector instructions (also known as SIMD instructions, single instruction multiple data). They are represented in the abstract syntax using $i128$ . The interpretation of lane types (integer or floating-point numbers) and lane sizes are determined by the specific instruction operating on them.

2.2.5. Names

Names are sequences of characters, which are scalar values as defined by [UNICODE] (Section 2.4).

name char ::= ::= char^{*} (if ∣ utf8 (char^{*}) ∣ < 2^{32}) U + 00 ∣ \dots ∣ U + D7FF ∣ U + E000 ∣ \dots ∣ U + 10FFFF

Due to the limitations of the binary format, the length of a name is bounded by the length of its UTF-8 encoding.

2.2.5.1. Convention

Characters (Unicode scalar values) are sometimes used interchangeably with natural numbers $n < 1114112$ .

2.3. Types

Various entities in WebAssembly are classified by types. Types are checked during validation, instantiation, and possibly execution.

2.3.1. Number Types

Number types classify numeric values.

numtype ::= i32 ∣ i64 ∣ f32 ∣ f64

The types $i32$ and $i64$ classify 32 and 64 bit integers, respectively. Integers are not inherently signed or unsigned, their interpretation is determined by individual operations.

The types $f32$ and $f64$ classify 32 and 64 bit floating-point data, respectively. They correspond to the respective binary floating-point representations, also known as single and double precision, as defined by the [IEEE-754-2019] standard (Section 3.3).

Number types are transparent, meaning that their bit patterns can be observed. Values of number type can be stored in memories.

2.3.1.1. Conventions

The notation $∣t∣$ denotes the bit width of a number type $t$ . That is, $∣ i32 ∣ = ∣ f32 ∣ = 32$ and $∣ i64 ∣ = ∣ f64 ∣ = 64$ .

2.3.2. Vector Types

Vector types classify vectors of numeric values processed by vector instructions (also known as SIMD instructions, single instruction multiple data).

vectype ::= v128

The type $v128$ corresponds to a 128 bit vector of packed integer or floating-point data. The packed data can be interpreted as signed or unsigned integers, single or double precision floating-point values, or a single 128 bit type. The interpretation is determined by individual operations.

Vector types, like number types are transparent, meaning that their bit patterns can be observed. Values of vector type can be stored in memories.

2.3.2.1. Conventions

The notation $∣t∣$ for bit width extends to vector types as well, that is, $∣ v128 ∣ = 128$ .

2.3.3. Heap Types

Heap types classify objects in the runtime store. There are three disjoint hierarchies of heap types:

function types classify functions,
aggregate types classify dynamically allocated managed data, such as structures, arrays, or unboxed scalars,
external types classify external references possibly owned by the embedder.

The values from the latter two hierarchies are interconvertible by ways of the $extern.convert_any$ and $any.convert_extern$ instructions. That is, both type hierarchies are inhabited by an isomorphic set of values, but may have different, incompatible representations in practice.

absheaptype heaptype ::= ∣ ∣ ∣ ::= func ∣ nofunc exn ∣ noexn extern ∣ noextern any ∣ eq ∣ i31 ∣ struct ∣ array ∣ none absheaptype ∣ typeidx

A heap type is either abstract or concrete.

The abstract type $func$ denotes the common supertype of all function types, regardless of their concrete definition. Dually, the type $nofunc$ denotes the common subtype of all function types, regardless of their concrete definition. This type has no values.

The abstract type $exn$ denotes the type of all exception references. Dually, the type $noexn$ denotes the common subtype of all forms of exception references. This type has no values.

The abstract type $extern$ denotes the common supertype of all external references received through the embedder. This type has no concrete subtypes. Dually, the type $noextern$ denotes the common subtype of all forms of external references. This type has no values.

The abstract type $any$ denotes the common supertype of all aggregate types, as well as possibly abstract values produced by internalizing an external reference of type $extern$ . Dually, the type $none$ denotes the common subtype of all forms of aggregate types. This type has no values.

The abstract type $eq$ is a subtype of $any$ that includes all types for which references can be compared, i.e., aggregate values and $i31$ .

The abstract types $struct$ and $array$ denote the common supertypes of all structure and array aggregates, respectively.

The abstract type $i31$ denotes unboxed scalars, that is, integers injected into references. Their observable value range is limited to 31 bits.

Note

An $i31$ is not actually allocated in the store, but represented in a way that allows them to be mixed with actual references into the store without ambiguity. Engines need to perform some form of pointer tagging to achieve this, which is why 1 bit is reserved.

Although the types $none$ , $nofunc$ , $noexn$ , and $noextern$ are not inhabited by any values, they can be used to form the types of all null references in their respective hierarchy. For example, $(ref null nofunc)$ is the generic type of a null reference compatible with all function reference types.

A concrete heap type consists of a type index and classifies an object of the respective type defined in a module.

The syntax of heap types is extended with additional forms for the purpose of specifying validation and execution.

2.3.4. Reference Types

Reference types classify values that are first-class references to objects in the runtime store.

reftype ::= ref null^{?} heaptype

A reference type is characterised by the heap type it points to.

In addition, a reference type of the form $ref null ht$ is nullable, meaning that it can either be a proper reference to $ht$ or null. Other references are non-null.

Reference types are opaque, meaning that neither their size nor their bit pattern can be observed. Values of reference type can be stored in tables.

2.3.4.1. Conventions

The reference type $anyref$ is an abbreviation for $ref null any$ .
The reference type $eqref$ is an abbreviation for $ref null eq$ .
The reference type $i31ref$ is an abbreviation for $ref null i31$ .
The reference type $structref$ is an abbreviation for $ref null struct$ .
The reference type $arrayref$ is an abbreviation for $ref null array$ .
The reference type $funcref$ is an abbreviation for $ref null func$ .
The reference type $exnref$ is an abbreviation for $ref null exn$ .
The reference type $externref$ is an abbreviation for $ref null extern$ .
The reference type $nullref$ is an abbreviation for $ref null none$ .
The reference type $nullfuncref$ is an abbreviation for $ref null nofunc$ .
The reference type $nullexnref$ is an abbreviation for $ref null noexn$ .
The reference type $nullexternref$ is an abbreviation for $ref null noextern$ .

2.3.5. Value Types

Value types classify the individual values that WebAssembly code can compute with and the values that a variable accepts. They are either number types, vector types, or reference types.

valtype ::= numtype ∣ vectype ∣ reftype

The syntax of value types is extended with additional forms for the purpose of specifying validation.

2.3.5.1. Conventions

The meta variable $t$ ranges over value types or subclasses thereof where clear from context.

2.3.6. Result Types

Result types classify the result of executing instructions or functions, which is a sequence of values, written with brackets.

resulttype ::= [vec (valtype)]

2.3.7. Function Types

Function types classify the signature of functions, mapping a vector of parameters to a vector of results. They are also used to classify the inputs and outputs of instructions.

functype ::= resulttype \to resulttype

2.3.8. Aggregate Types

Aggregate types describe compound objects consisting of multiple values. These are either structures or arrays, which both consist of a list of possibly mutable and possibly packed fields. Structures are heterogeneous, but require static indexing, while arrays need to be homogeneous, but allow dynamic indexing.

structtype arraytype fieldtype storagetype packedtype ::= ::= ::= ::= ::= fieldtype^{*} fieldtype mut storagetype valtype ∣ packedtype i8 ∣ i16

2.3.8.1. Conventions

The notation $∣t∣$ for bit width extends to packed types as well, that is, $∣ i8 ∣ = 8$ and $∣ i16 ∣ = 16$ .
The auxiliary function $unpack$ maps a storage type to the value type obtained when accessing a field:

$unpack (valtype) unpack (packedtype) = = valtype i32$

2.3.9. Composite Types

Composite types are all types composed from simpler types, including function types and aggregate types.

comptype ::= func functype ∣ struct structtype ∣ array arraytype

2.3.10. Recursive Types

Recursive types denote a group of mutually recursive composite types, each of which can optionally declare a list of type indices of supertypes that it matches. Each type can also be declared final, preventing further subtyping.

rectype subtype ::= ::= rec subtype^{*} sub final^{?} typeidx^{*} comptype

In a module, each member of a recursive type is assigned a separate type index.

The syntax of sub types is generalized for the purpose of specifying validation and execution.

2.3.11. Address Type

Address types are a subset of number types that classify the values that can be used as offsets into memories and tables.

addrtype ::= i32 ∣ i64

2.3.11.1. Conventions

The minimum of two address types is defined as the address type whose bit width is the minimum of the two.

atmin (at_{1}, at_{2}) atmin (at_{1}, at_{2}) = = at_{1} at_{2} (if ∣ at_{1} ∣ \leq ∣ at_{2} ∣) (otherwise)

2.3.12. Limits

Limits classify the size range of resizeable storage associated with memory types and table types.

limits ::= {min u64, max u64^{?}}

If no maximum is given, the respective storage can grow to any size.

2.3.13. Memory Types

Memory types classify linear memories and their size range.

memtype ::= addrtype limits

The limits constrain the minimum and optionally the maximum size of a memory. The limits are given in units of page size.

2.3.14. Table Types

Table types classify tables over elements of reference type within a size range.

tabletype ::= addrtype limits reftype

Like memories, tables are constrained by limits for their minimum and optionally maximum size. The limits are given in numbers of entries.

2.3.15. Global Types

Global types classify global variables, which hold a value and can either be mutable or immutable.

globaltype mut ::= ::= mut valtype const ∣ var

2.3.16. Tag Types

Tag types classify the signature of tags with a function type.

tagtype ::= functype

Currently tags are only used for categorizing exceptions. The parameters of $functype$ define the list of values associated with the exception thrown with this tag. Furthermore, it is an invariant of the semantics that every $functype$ in a valid tag type for an exception has an empty result type.

Note

Future versions of WebAssembly may have additional uses for tags, and may allow non-empty result types in the function types of tags.

2.3.17. External Types

External types classify imports and external values with their respective types.

externtype ::= func deftype ∣ table tabletype ∣ mem memtype ∣ global globaltype ∣ tag tagtype

2.3.17.1. Conventions

The following auxiliary notation is defined for sequences of external types. It filters out entries of a specific kind in an order-preserving fashion:

$funcs (externtype^{*}) = [deftype ∣ (func deftype) \in externtype^{*}]$
$tables (externtype^{*}) = [tabletype ∣ (table tabletype) \in externtype^{*}]$
$mems (externtype^{*}) = [memtype ∣ (mem memtype) \in externtype^{*}]$
$globals (externtype^{*}) = [globaltype ∣ (global globaltype) \in externtype^{*}]$
$tags (externtype^{*}) = [tagtype ∣ (tag tagtype) \in externtype^{*}]$

2.4. 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.

2.4.1. Numeric Instructions

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

nn, mm sx instr iunop ibinop funop fbinop itestop irelop frelop ::= ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= ::= ∣ ::= ::= ::= ::= ::= 32 ∣ 64 u ∣ s i nn . const u nn ∣ f nn . const f nn i nn . iunop ∣ f nn . funop i nn . ibinop ∣ f nn . fbinop i nn . itestop i nn . irelop ∣ f nn . frelop i nn . extend 8_s ∣ i nn . extend 16_s ∣ i64. extend 32_s i32. wrap_i64 ∣ i64. extend_i32_sx ∣ i nn . trunc_f mm_sx i nn . trunc_sat_f mm_sx f32. demote_f64 ∣ f64. promote_f32 ∣ f nn . convert_i mm_sx i nn . reinterpret_f nn ∣ f nn . reinterpret_i nn \dots clz ∣ ctz ∣ popcnt add ∣ sub ∣ mul ∣ div_sx ∣ rem_sx and ∣ or ∣ xor ∣ shl ∣ shr_sx ∣ rotl ∣ rotr abs ∣ neg ∣ sqrt ∣ ceil ∣ floor ∣ trunc ∣ nearest add ∣ sub ∣ mul ∣ div ∣ min ∣ max ∣ copysign eqz eq ∣ ne ∣ lt_sx ∣ gt_sx ∣ le_sx ∣ ge_sx 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.

2.4.1.1. Conventions

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

unop binop testop relop cvtop ::= ::= ::= ::= ::= iunop ∣ funop ∣ extend N_s ibinop ∣ fbinop itestop irelop ∣ frelop wrap ∣ extend ∣ trunc ∣ trunc_sat ∣ convert ∣ demote ∣ promote ∣ reinterpret

2.4.2. Vector Instructions

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

ishape fshape shape half laneidx ::= ::= ::= ::= ::= i8x16 ∣ i16x8 ∣ i32x4 ∣ i64x2 f32x4 ∣ f64x2 ishape ∣ fshape low ∣ high u8

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots v128. const i128 v128. vvunop v128. vvbinop v128. vvternop v128. vvtestop i8x16. shuffle laneidx^{16} 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 i8x16. relaxed_swizzle i16x8. relaxed_q15mulr_s i32x4. relaxed_trunc_f32x4_sx i16x8. relaxed_dot_i8x16_i7x16_s i32x4. relaxed_dot_i8x16_i7x16_add_s ishape . relaxed_laneselect fshape . rvfternop fshape . rvfbinop \dots

vvunop vvbinop vvternop vvtestop vitestop virelop vfrelop viunop vibinop viminmaxop visatbinop vishiftop vfunop vfbinop rvfbinop rvfternop ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= not and ∣ andnot ∣ or ∣ xor bitselect any_true all_true eq ∣ ne ∣ lt_sx ∣ gt_sx ∣ le_sx ∣ ge_sx eq ∣ ne ∣ lt ∣ gt ∣ le ∣ ge abs ∣ neg add ∣ sub min_sx ∣ max_sx add_sat_sx ∣ sub_sat_sx shl ∣ shr_sx abs ∣ neg ∣ sqrt ∣ ceil ∣ floor ∣ trunc ∣ nearest add ∣ sub ∣ mul ∣ div ∣ min ∣ max ∣ pmin ∣ pmax relaxed_min ∣ relaxed_max relaxed_madd ∣ relaxed_nmadd

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 $t x N$ , 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 bit width 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.

2.4.2.1. Conventions

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

vunop vbinop vternop vtestop vrelop vcvtop ::= ::= ∣ ∣ ∣ ∣ ::= ::= ::= ::= viunop ∣ vfunop ∣ popcnt vibinop ∣ vfbinop viminmaxop ∣ visatbinop rvfbinop mul ∣ avgr_u ∣ q15mulr_sat_s relaxed_q15mulr_s_s vvternop ∣ rvfternop vitestop virelop ∣ vfrelop extend ∣ trunc_sat ∣ convert ∣ demote ∣ promote ∣ relaxed_trunc

2.4.3. Reference Instructions

Instructions in this group are concerned with accessing references.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots ref.null heaptype ref.func funcidx ref.is_null ref.as_non_null ref.eq ref.test reftype ref.cast reftype

The $ref.null$ and $ref.func$ instructions produce a null value or a reference to a given function, respectively.

The instruction $ref.is_null$ checks for null, while $ref.as_non_null$ converts a nullable to a non-null one, and traps if it encounters null.

The $ref.eq$ compares two references.

The instructions $ref.test$ and $ref.cast$ test the dynamic type of a reference operand. The former merely returns the result of the test, while the latter performs a downcast and traps if the operand’s type does not match.

Note

The $br_on_cast$ and $br_on_cast_fail$ instructions provides versions of the latter that branch depending on the success of the downcast instead of trapping.

2.4.4. Aggregate Instructions

Instructions in this group are concerned with creating and accessing references to aggregate types.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots struct.new typeidx struct.new_default typeidx struct.get typeidx fieldidx struct.get_sx typeidx fieldidx struct.set typeidx fieldidx array.new typeidx array.new_fixed typeidx u32 array.new_default typeidx array.new_data typeidx dataidx array.new_elem typeidx elemidx array.get typeidx array.get_sx typeidx array.set typeidx array.len array.fill typeidx array.copy typeidx typeidx array.init_data typeidx dataidx array.init_elem typeidx elemidx ref.i31 i31.get_sx any.convert_extern extern.convert_any

The instructions $struct.new$ and $struct.new_default$ allocate a new structure, initializing them either with operands or with default values. The remaining instructions on structs access individual fields, allowing for different sign extension modes in the case of packed storage types.

Similarly, arrays can be allocated either with an explicit initialization operand or a default value. Furthermore, $array.new_fixed$ allocates an array with statically fixed size, and $array.new_data$ and $array.new_elem$ allocate an array and initialize it from a data or element segment, respectively. $array.get$ , $array.get_s$ , $array.get_u$ , and $array.set$ access individual slots, again allowing for different sign extension modes in the case of a packed storage type. $array.len$ produces the length of an array. $array.fill$ fills a specified slice of an array with a given value and $array.copy$ , $array.init_data$ , and $array.init_elem$ copy elements to a specified slice of an array from a given array, data segment, or element segment, respectively.

The instructions $ref.i31$ and $i31.get_sx$ convert between type $i31$ and an unboxed scalar.

The instructions $any.convert_extern$ and $extern.convert_any$ allow lossless conversion between references represented as type $(ref null extern)$ .

2.4.5. Parametric Instructions

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

instr ::= ∣ ∣ \dots 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.

2.4.6. Variable Instructions

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

instr ::= ∣ ∣ ∣ ∣ ∣ \dots 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.

2.4.7. Table Instructions

Instructions in this group are concerned with tables table.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 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$ .

2.4.8. Memory Instructions

Instructions in this group are concerned with linear memory.

memarg ww instr ::= ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ {offset u64, align u32} 8 ∣ 16 ∣ 32 ∣ 64 \dots i nn . load memidx memarg ∣ f nn . load memidx memarg v128. load memidx memarg i nn . store memidx memarg ∣ f nn . store memidx memarg v128. store memidx memarg i nn . load 8_sx memidx memarg ∣ i nn . load 16_sx memidx memarg ∣ i64. load 32_sx memidx memarg v128. load 8x8_sx memidx memarg ∣ v128. load 16x4_sx memidx memarg ∣ v128. load 32x2_sx memidx memarg v128. load 32_zero memidx memarg ∣ v128. load 64_zero memidx memarg v128. load ww_splat memidx memarg v128. load ww_lane memidx memarg laneidx ∣ i nn . store 8 memidx memarg ∣ i nn . store 16 memidx memarg ∣ i64. store 32 memidx memarg v128. store ww_lane memidx memarg laneidx memory.size memidx memory.grow memidx memory.fill memidx memory.copy memidx memidx memory.init memidx dataidx data.drop dataidx

Memory is accessed with $load$ and $store$ instructions for the different number types and vector types. They all take a memory index and 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 or 65-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.

The $memory.size$ instruction returns the current size of a memory. The $memory.grow$ instruction grows a 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 of a memory to a given byte. The $memory.copy$ instruction copies data from a source memory region to a possibly overlapping destination region in another or the same memory; the first index denotes the destination. 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.

2.4.9. Control Instructions

Instructions in this group affect the flow of control.

blocktype instr catch ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= ∣ ∣ ∣ typeidx ∣ valtype^{?} \dots 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 br_on_null labelidx br_on_non_null labelidx br_on_cast labelidx reftype reftype br_on_cast_fail labelidx reftype reftype return call funcidx call_ref typeidx call_indirect tableidx typeidx return_call funcidx return_call_ref typeidx return_call_indirect tableidx typeidx throw tagidx throw_ref try_table blocktype catch^{*} instr^{*} end catch tagidx labelidx catch_ref tagidx labelidx catch_all labelidx catch_all_ref labelidx

The $nop$ instruction does nothing.

The $unreachable$ instruction causes an unconditional trap.

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

The instructions $throw$ , $throw_ref$ , and $try_table$ are concerned with exceptions. The $try_table$ instruction installs an exception handler that handles exceptions as specified by its catch clauses.. The $throw$ and $throw_ref$ instructions raise and reraise an exception, respectively, and transfers control to the innermost enclosing exception handler that has a matching catch clause.

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 reinterpreted as an instruction type, or as an optional value type inline, which is a shorthand for the instruction type $[] \to [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 $br_on_null$ and $br_on_non_null$ instructions check whether a reference operand is null and branch if that is the case or not the case, respectively. Similarly, $br_on_cast$ and $br_on_cast_fail$ attempt a downcast on a reference operand and branch if that succeeds, or fails, respectively.

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_ref$ instruction invokes a function indirectly through a function reference operand. The $call_indirect$ instruction calls a function indirectly through an operand indexing into a table that is denoted by a table index and must contain function references. 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.

The $return_call$ , $return_call_ref$ , and $return_call_indirect$ instructions are tail-call variants of the previous ones. That is, they first return from the current function before actually performing the respective call. It is guaranteed that no sequence of nested calls using only these instructions can cause resource exhaustion due to hitting an implementation’s limit on the number of active calls.

2.4.10. 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.

2.5. Modules

WebAssembly programs are organized into modules, which are the unit of deployment, loading, and compilation. A module collects definitions for types, functions, tables, memories, tags, and globals. In addition, it can declare imports and exports and provide initialization in the form of data and element segments, or a start function.

module ::= {types vec (rectype), funcs vec (func), tables vec (table), mems vec (mem), globals vec (global), tags vec (tag), elems vec (elem), datas vec (data), start start^{?}, imports vec (import), exports vec (export)}

Each of the vectors – and thus the entire module – may be empty.

2.5.1. Indices

Definitions are referenced with zero-based indices. Each class of definition has its own index space, as distinguished by the following classes.

typeidx funcidx tableidx memidx globalidx tagidx elemidx dataidx localidx labelidx fieldidx ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= u32 u32 u32 u32 u32 u32 u32 u32 u32 u32 u32

The index space for functions, tables, memories, globals, and tags includes respective imports declared in the same module. The indices of these imports precede the indices of other definitions in the same index space.

Element indices reference element segments and data indices reference data segments.

The index space for locals is only accessible inside a function and includes the parameters of that function, which precede the local variables.

Label indices reference structured control instructions inside an instruction sequence.

Each aggregate type provides an index space for its fields.

2.5.1.1. Conventions

The meta variable $l$ ranges over label indices.
The meta variables $x, y$ range over indices in any of the other index spaces.
The notation $idx (A)$ denotes the set of indices from index space $idx$ occurring free in $A$ . Sometimes this set is reinterpreted as the vector of its elements.

Note

For example, if $instr^{*}$ is $(data.drop x) (memory.init y)$ , then $dataidx (instr^{*}) = {x, y}$ , or equivalently, the vector $x y$ .

2.5.2. Types

The $types$ component of a module defines a vector of recursive types, each of consisting of a list of sub types referenced by individual type indices. All function or aggregate types used in a module must be defined in this component.

2.5.3. Functions

The $funcs$ component of a module defines a vector of functions with the following structure:

func local ::= ::= {type typeidx, locals vec (local), body expr} {type valtype}

The $type$ of a function declares its signature by reference to a type defined in the module. The parameters of the function are referenced through 0-based local indices in the function’s body; they are mutable.

The $locals$ declare a vector of mutable local variables and their types. These variables are referenced through local indices in the function’s body. The index of the first local is the smallest index not referencing a parameter.

The $body$ is an instruction sequence that upon termination must produce a stack matching the function type’s result type.

Functions are referenced through function indices, starting with the smallest index not referencing a function import.

2.5.4. Tables

The $tables$ component of a module defines a vector of tables described by their table type:

table ::= {type tabletype, init expr}

A table is an array of opaque values of a particular reference type. Moreover, each table slot is initialized with the $init$ value given by a constant initializer expression. Tables can further be initialized through element segments.

The $min$ size in the limits of the table type specifies the initial size of that table, while its $max$ , if present, restricts the size to which it can grow later.

Tables are referenced through table indices, starting with the smallest index not referencing a table import. Most constructs implicitly reference table index $0$ .

2.5.5. Memories

The $mems$ component of a module defines a vector of linear memories (or memories for short) as described by their memory type:

mem ::= {type memtype}

A memory is a vector of raw uninterpreted bytes. The $min$ size in the limits of the memory type specifies the initial size of that memory, while its $max$ , if present, restricts the size to which it can grow later. Both are in units of page size.

Memories can be initialized through data segments.

Memories are referenced through memory indices, starting with the smallest index not referencing a memory import. Most constructs implicitly reference memory index $0$ .

2.5.6. Globals

The $globals$ component of a module defines a vector of global variables (or globals for short):

global ::= {type globaltype, init expr}

Each global stores a single value of the given global type. Its $type$ also specifies whether a global is immutable or mutable. Moreover, each global is initialized with an $init$ value given by a constant initializer expression.

Globals are referenced through global indices, starting with the smallest index not referencing a global import.

2.5.7. Tags

The $tags$ component of a module defines a vector of tags with the following structure.

tag ::= {type typeidx}

The result type of the function signature with type index $typeidx$ must be empty.

Tags are referenced through tag indices, starting with the smallest index not referencing a tag import.

2.5.8. Element Segments

The initial contents of a table is uninitialized. Element segments can be used to initialize a subrange of a table from a static vector of elements.

The $elems$ component of a module defines a vector of element segments. Each element segment defines a reference type and a corresponding list of constant element expressions.

Element segments have a mode that identifies them as either passive, active, or declarative. A passive element segment’s elements can be copied to a table using the $table.init$ instruction. An active element segment copies its elements into a table during instantiation, as specified by a table index and a constant expression defining an offset into that table. A declarative element segment is not available at runtime but merely serves to forward-declare references that are formed in code with instructions like $ref.func$ .

elem elemmode ::= ::= ∣ ∣ {type reftype, init vec (expr), mode elemmode} passive active {table tableidx, offset expr} declarative

The $offset$ is given by a constant expression.

Element segments are referenced through element indices.

2.5.9. Data Segments

The initial contents of a memory are zero bytes. Data segments can be used to initialize a range of memory from a static vector of bytes.

The $datas$ component of a module defines a vector of data segments.

Like element segments, data segments have a mode that identifies them as either passive or active. A passive data segment’s contents can be copied into a memory using the $memory.init$ instruction. An active data segment copies its contents into a memory during instantiation, as specified by a memory index and a constant expression defining an offset into that memory.

data datamode ::= ::= ∣ {init vec (byte), mode datamode} passive active {memory memidx, offset expr}

Data segments are referenced through data indices.

Note

In the current version of WebAssembly, at most one memory is allowed in a module. Consequently, the only valid $memidx$ is $0$ .

2.5.10. Start Function

The $start$ component of a module declares the function index of a start function that is automatically invoked when the module is instantiated, after tables and memories have been initialized.

start ::= {func funcidx}

Note

The start function is intended for initializing the state of a module. The module and its exports are not accessible externally before this initialization has completed.

2.5.11. Exports

The $exports$ component of a module defines a set of exports that become accessible to the host environment once the module has been instantiated.

export exportdesc ::= ::= ∣ ∣ ∣ ∣ {name name, desc exportdesc} func funcidx table tableidx mem memidx global globalidx tag tagidx

Each export is labeled by a unique name. Exportable definitions are functions, tables, memories, globals, and tags, which are referenced through a respective descriptor.

2.5.11.1. Conventions

The following auxiliary notation is defined for sequences of exports, filtering out indices of a specific kind in an order-preserving fashion:

$funcs (export^{*}) = [funcidx ∣ func funcidx \in (export . desc)^{*}]$
$tables (export^{*}) = [tableidx ∣ table tableidx \in (export . desc)^{*}]$
$mems (export^{*}) = [memidx ∣ mem memidx \in (export . desc)^{*}]$
$globals (export^{*}) = [globalidx ∣ global globalidx \in (export . desc)^{*}]$
$tags (export^{*}) = [tagidx ∣ tag tagidx \in (export . desc)^{*}]$

2.5.12. Imports

The $imports$ component of a module defines a set of imports that are required for instantiation.

import importdesc ::= ::= ∣ ∣ ∣ ∣ {module name, name name, desc importdesc} func typeidx table tabletype mem memtype global globaltype tag typeidx

Each import is labeled by a two-level name space, consisting of a $module$ name and a $name$ for an entity within that module. Importable definitions are functions, tables, memories, globals, and tags. Each import is specified by a descriptor with a respective type that a definition provided during instantiation is required to match.

Every import defines an index in the respective index space. In each index space, the indices of imports go before the first index of any definition contained in the module itself.

Note

Unlike export names, import names are not necessarily unique. It is possible to import the same $module$ / $name$ pair multiple times; such imports may even have different type descriptions, including different kinds of entities. A module with such imports can still be instantiated depending on the specifics of how an embedder allows resolving and supplying imports. However, embedders are not required to support such overloading, and a WebAssembly module itself cannot implement an overloaded name.

3. Validation

3.1. Conventions

Validation checks that a WebAssembly module is well-formed. Only valid modules can be instantiated.

Validity is defined by a type system over the abstract syntax of a module and its contents. For each piece of abstract syntax, there is a typing rule that specifies the constraints that apply to it. All rules are given in two equivalent forms:

In prose, describing the meaning in intuitive form.
In formal notation, describing the rule in mathematical form. [1]

Note

The prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.

In both cases, the rules are formulated in a declarative manner. That is, they only formulate the constraints, they do not define an algorithm. The skeleton of a sound and complete algorithm for type-checking instruction sequences according to this specification is provided in the appendix.

3.1.1. Types

To define the semantics, the definition of some sorts of types is extended to include additional forms. By virtue of not being representable in either the binary format or the text format, these forms cannot be used in a program; they only occur during validation or execution.

valtype absheaptype heaptype subtype ::= ::= ::= ::= \dots ∣ bot \dots ∣ bot \dots ∣ deftype ∣ rec i sub final^{?} heaptype^{*} comptype

The unique value type $bot$ is a bottom type that matches all value types. Similarly, $bot$ is also used as a bottom type of all heap types.

Note

No validation rule uses bottom types explicitly, but various rules can pick any value or heap type, including bottom. This ensures the existence of principal types, and thus a validation algorithm without back tracking.

A concrete heap type can consist of a defined type directly. this occurs as the result of substituting a type index with its definition.

A concrete heap type may also be a recursive type index. Such an index refers to the $i$ -th component of a surrounding recursive type. It occurs as the result of rolling up the definition of a recursive type.

Finally, the representation of supertypes in a sub type is generalized from mere type indices to heap types. They occur as defined types or recursive type indices after substituting type indices or rolling up recursive types.

Note

It is an invariant of the semantics that sub types occur only in one of two forms: either as “syntactic” types as in a source module, where all supertypes are type indices, or as “semantic” types, where all supertypes are resolved to either defined types or recursive type indices.

A type of any form is closed when it does not contain a heap type that is a type index or a recursive type index without a surrounding recursive type, i.e., all type indices have been substituted with their defined type and all free recursive type indices have been unrolled.

Note

Recursive type indices are internal to a recursive type. They are distinguished from regular type indices and represented such that two closed types are syntactically equal if and only if they have the same recursive structure.

3.1.1.1. Convention

The difference $rt_{1} ∖ rt_{2}$ between two reference types is defined as follows:

$(ref null_{1}^{?} ht_{1}) ∖ (ref null ht_{2}) (ref null_{1}^{?} ht_{1}) ∖ (ref ht_{2}) = = (ref ht_{1}) (ref null_{1}^{?} ht_{1})$

Note

This definition computes an approximation of the reference type that is inhabited by all values from $rt_{1}$ except those from $rt_{2}$ . Since the type system does not have general union types, the defnition only affects the presence of null and cannot express the absence of other values.

3.1.2. Defined Types

Defined types denote the individual types defined in a module. Each such type is represented as a projection from the recursive type group it originates from, indexed by its position in that group.

deftype ::= rectype . i

Defined types do not occur in the binary or text format, but are formed by rolling up the recursive types defined in a module.

It is hence an invariant of the semantics that all recursive types occurring in defined types are rolled up.

3.1.2.1. Conventions

$t [x^{*} := dt^{*}]$ denotes the parallel substitution of type indices $x^{*}$ with defined types $dt^{*}$ in type $t$ , provided $∣ x^{*} ∣ = ∣ dt^{*} ∣$ .
$t [(rec i)^{*} := dt^{*}]$ denotes the parallel substitution of recursive type indices $(rec i)^{*}$ with defined types $dt^{*}$ in type $t$ , provided $∣ (rec i)^{*} ∣ = ∣ dt^{*} ∣$ .
$t [:= dt^{*}]$ is shorthand for the substitution $t [x^{*} := dt^{*}]$ , where $x^{*} = 0 \dots (∣ dt^{*} ∣ - 1)$ .

3.1.3. Rolling and Unrolling

In order to allow comparing recursive types for equivalence, their representation is changed such that all type indices internal to the same recursive type are replaced by recursive type indices.

Note

This representation is independent of the type index space, so that it is meaningful across module boundaries. Moreover, this representation ensures that types with equivalent recursive structure are also syntactically equal, hence allowing a simple equality check on (closed) types. It gives rise to an iso-recursive interpretation of types.

The representation change is performed by two auxiliary operations on the syntax of recursive types:

Rolling up a recursive type substitutes its internal type indices with corresponding recursive type indices.
Unrolling a recursive type substitutes its recursive type indices with the corresponding defined types.

These operations are extended to defined types and defined as follows:

roll_{x} (rec subtype^{*}) unroll (rec subtype^{*}) unroll (rectype . i) = = = rec (subtype [(x + i)^{*} := (rec i)^{*}])^{*} rec (subtype [(rec i)^{*} := ((rec subtype^{*}) . i)^{*}])^{*} subtype^{*} [i] (if (if \land (if i^{*} = 0 \dots (∣ subtype^{*} ∣ - 1)) i^{*} = 0 \dots (∣ subtype^{*} ∣ - 1)) 2 e x] roll^{*}_{x} (rectype) roll_{x} (rectype) = rec subtype^{*}) unroll (rectype) = rec subtype^{*}) = ((rec subtype^{*}) . i)^{*} (if i^{*} = 0 \dots (∣ subtype^{*} ∣ - 1)

In addition, the following auxiliary function denotes the expansion of a defined type:

expand (deftype) = comptype (if unroll (deftype) = sub final^{?} ht^{*} comptype)

3.1.4. Instruction Types

Instruction types classify the behaviour of instructions or instruction sequences, by describing how they manipulate the operand stack and the initialization status of locals:

instrtype ::= resulttype \to_{localidx^{*}} resulttype

An instruction type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ describes the required input stack with argument values of types $t_{1}^{*}$ that an instruction pops off and the provided output stack with result values of types $t_{2}^{*}$ that it pushes back. Moreover, it enumerates the indices $x^{*}$ of locals that have been set by the instruction or sequence.

Note

Instruction types are only used for validation, they do not occur in programs.

3.1.5. Local Types

Local types classify locals, by describing their value type as well as their initialization status:

init localtype ::= ::= set ∣ unset init valtype

Note

Local types are only used for validation, they do not occur in programs.

3.1.6. Contexts

Validity of an individual definition is specified relative to a context, which collects relevant information about the surrounding module and the definitions in scope:

Types: the list of types defined in the current module.
Functions: the list of functions declared in the current module, represented by a defined type that expands to their function type.
Tables: the list of tables declared in the current module, represented by their table type.
Memories: the list of memories declared in the current module, represented by their memory type.
Globals: the list of globals declared in the current module, represented by their global type.
Tags: the list of tags declared in the current module, represented by their tag type.
Element Segments: the list of element segments declared in the current module, represented by the elements’ reference type.
Data Segments: the list of data segments declared in the current module, each represented by an $ok$ entry.
Locals: the list of locals declared in the current function (including parameters), represented by their local type.
Labels: the stack of labels accessible from the current position, represented by their result type.
Return: the return type of the current function, represented as an optional result type that is absent when no return is allowed, as in free-standing expressions.
References: the list of function indices that occur in the module outside functions and can hence be used to form references inside them.

In other words, a context contains a sequence of suitable types for each index space, describing each defined entry in that space. Locals, labels and return type are only used for validating instructions in function bodies, and are left empty elsewhere. The label stack is the only part of the context that changes as validation of an instruction sequence proceeds.

More concretely, contexts are defined as records $C$ with abstract syntax:

C ::= {types funcs tables mems globals tags elems datas locals labels return refs deftype^{*}, deftype^{*}, tabletype^{*}, memtype^{*}, globaltype^{*}, tagtype^{*}, reftype^{*}, ok^{*}, localtype^{*}, resulttype^{*}, resulttype^{?}, funcidx^{*}}

In addition to field access written $C. field$ the following notation is adopted for manipulating contexts:

When spelling out a context, empty fields are omitted.
$C, field A^{*}$ denotes the same context as $C$ but with the elements $A^{*}$ prepended to its $field$ component sequence.

Note

Indexing notation like $C. labels [i]$ is used to look up indices in their respective index space in the context. Context extension notation $C, field A$ is primarily used to locally extend relative index spaces, such as label indices. Accordingly, the notation is defined to append at the front of the respective sequence, introducing a new relative index $0$ and shifting the existing ones.

3.1.6.1. Convention

Any form of type can be closed to bring it into closed form relative to a context it is valid in by substituting each type index $x$ occurring in it with the corresponding defined type $C. types [x]$ , after first closing the types in $C. types$ themselves.

clos_{C} (t) clos^{*} (dt^{*} dt_{N}) = = t [:= clos^{*} (C . types)] 2 e x] clos^{*} (ϵ) dt^{'}^{*} dt_{N} [:= dt^{'}^{*}] = (if dt^{'}^{*} = clos^{*} (dt^{*})) ϵ

3.1.7. Prose Notation

Validation is specified by stylised rules for each relevant part of the abstract syntax. The rules not only state constraints defining when a phrase is valid, they also classify it with a type. The following conventions are adopted in stating these rules.

A phrase $A$ is said to be “valid with type $T$ ” if and only if all constraints expressed by the respective rules are met. The form of $T$ depends on what $A$ is.

Note

For example, if $A$ is a function, then $T$ is a function type; for an $A$ that is a global, $T$ is a global type; and so on.
The rules implicitly assume a given context $C$ .
In some places, this context is locally extended to a context $C^{'}$ with additional entries. The formulation “Under context $C^{'}$ , … statement …” is adopted to express that the following statement must apply under the assumptions embodied in the extended context.

3.1.8. Formal Notation

Note

This section gives a brief explanation of the notation for specifying typing rules formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]

The proposition that a phrase $A$ has a respective type $T$ is written $A : T$ . In general, however, typing is dependent on a context $C$ . To express this explicitly, the complete form is a judgement $C ⊢ A : T$ , which says that $A : T$ holds under the assumptions encoded in $C$ .

The formal typing rules use a standard approach for specifying type systems, rendering them into deduction rules. Every rule has the following general form:

\frac{premise _{1} premise _{2} \dots premise _{n}}{conclusion}

Such a rule is read as a big implication: if all premises hold, then the conclusion holds. Some rules have no premises; they are axioms whose conclusion holds unconditionally. The conclusion always is a judgment $C ⊢ A : T$ , and there is one respective rule for each relevant construct $A$ of the abstract syntax.

Note

For example, the typing rule for the $i32 . add$ instruction can be given as an axiom:

C ⊢ i32 . add : [ i32 i32 ] \to [ i32 ]

The instruction is always valid with type $[i32 i32] \to [i32]$ (saying that it consumes two $i32$ values and produces one), independent of any side conditions.

An instruction like $local.get$ can be typed as follows:

\frac{C. globals [ x ] = mut t}{C ⊢ global.get x : [ ] \to [ t ]}

Here, the premise enforces that the immediate global index $x$ exists in the context. The instruction produces a value of its respective type $t$ (and does not consume any values). If $C. globals [x]$ does not exist then the premise does not hold, and the instruction is ill-typed.

Finally, a structured instruction requires a recursive rule, where the premise is itself a typing judgement:

\frac{C ⊢ blocktype : [ t _{1}^{*} ] \to [ t _{2}^{*} ] C , label [ t _{2}^{*} ] ⊢ instr ^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ block blocktype instr ^{*} end : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

A $block$ instruction is only valid when the instruction sequence in its body is. Moreover, the result type must match the block’s annotation $blocktype$ . If so, then the $block$ instruction has the same type as the body. Inside the body an additional label of the corresponding result type is available, which is expressed by extending the context $C$ with the additional label information for the premise.

3.2. Types

Simple types, such as number types are universally valid. However, restrictions apply to most other types, such as reference types, function types, as well as the limits of table types and memory types, which must be checked during validation.

Moreover, block types are converted to plain function types for ease of processing.

3.2.1. Number Types

Number types are always valid.

C ⊢ numtype ok

3.2.2. Vector Types

Vector types are always valid.

C ⊢ vectype ok

3.2.3. Heap Types

Concrete heap types are only valid when the type index is, while abstract ones are vacuously valid.

3.2.3.1. $absheaptype$

The heap type is valid.

C ⊢ absheaptype ok

3.2.3.2. $typeidx$

The type $C. types [typeidx]$ must be defined in the context.
Then the heap type is valid.

\frac{C. types [ typeidx ] = deftype}{C ⊢ typeidx ok}

3.2.4. Reference Types

Reference types are valid when the referenced heap type is.

3.2.4.1. $ref null^{?} heaptype$

The heap type $heaptype$ must be valid.
Then the reference type is valid.

\frac{C ⊢ heaptype ok}{C ⊢ ref null ^{?} heaptype ok}

3.2.5. Value Types

Valid value types are either valid number types, valid vector types, or valid reference types.

3.2.6. Block Types

Block types may be expressed in one of two forms, both of which are converted to instruction types by the following rules.

3.2.6.1. $typeidx$

The type $C. types [typeidx]$ must be defined in the context.
The expansion of $C. funcs [typeidx]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the block type is valid as instruction type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{expand ( C. types [ typeidx ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ typeidx : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

3.2.6.2. $[valtype^{?}]$

The value type $valtype$ must either be absent, or valid.
Then the block type is valid as instruction type $[] \to [valtype^{?}]$ .

\frac{( C ⊢ valtype ok ) ^{?}}{C ⊢ [ valtype ^{?} ] : [ ] \to [ valtype ^{?} ]}

3.2.7. Result Types

3.2.7.1. $[t^{*}]$

Each value type $t_{i}$ in the type sequence $t^{*}$ must be valid.
Then the result type is valid.

\frac{( C ⊢ t ok ) ^{*}}{C ⊢ [ t ^{*} ] ok}

3.2.8. Instruction Types

3.2.8.1. $[t_{1}^{}] \to_{x^{}} [t_{2}^{*}]$

The result type $[t_{1}^{*}]$ must be valid.
The result type $[t_{2}^{*}]$ must be valid.
Each local index $x_{i}$ in $x^{*}$ must be defined in the context.
Then the instruction type is valid.

\frac{C ⊢ [ t _{1}^{*} ] ok C ⊢ [ t _{2}^{*} ] ok ( C. locals [ x ] = localtype ) ^{*}}{C ⊢ [ t _{1}^{*} ] \to _{x^{*}} [ t _{2}^{*} ] ok}

3.2.9. Function Types

3.2.9.1. $[t_{1}^{}] \to [t_{2}^{}]$

The result type $[t_{1}^{*}]$ must be valid.
The result type $[t_{2}^{*}]$ must be valid.
Then the function type is valid.

\frac{C ⊢ [ t _{1}^{*} ] ok C ⊢ [ t _{2}^{*} ] ok}{C ⊢ [ t _{1}^{*} ] \to [ t _{2}^{*} ] ok}

3.2.10. Composite Types

3.2.10.1. $func functype$

The function type $functype$ must be valid.
Then the composite type is valid.

\frac{C ⊢ functype ok}{C ⊢ func functype ok}

3.2.10.2. $struct fieldtype^{*}$

For each field type $fieldtype_{i}$ in $fieldtype^{*}$ :
- The field type $fieldtype_{i}$ must be valid.
Then the composite type is valid.

\frac{( C ⊢ ft ok ) ^{*}}{C ⊢ struct ft ^{*} ok}

3.2.10.3. $array fieldtype$

The field type $fieldtype$ must be valid.
Then the composite type is valid.

\frac{C ⊢ ft ok}{C ⊢ array ft ok}

3.2.11. Field Types

3.2.11.1. $mut storagetype$

The storage type $storagetype$ must be valid.
Then the field type is valid.

\frac{C ⊢ st ok}{C ⊢ mut st ok}

3.2.11.2. $packedtype$

The packed type is valid.

C ⊢ packedtype ok

3.2.12. Recursive Types

Recursive types are validated for a specific type index that denotes the index of the type defined by the recursive group.

3.2.12.1. $rec subtype^{*}$

Either the sequence $subtype^{*}$ is empty.
Or:
- The first sub type of the sequence $subtype^{*}$ must be valid for the type index $x$ .
- The remaining sequence $subtype^{*}$ must be valid for the type index $x + 1$ .
Then the recursive type is valid for the type index $x$ .

C ⊢ rec ϵ ok ( x ) \frac{C ⊢ subtype ok ( x ) C ⊢ rec subtype ^{'} ^{*} ok ( x + 1 )}{C ⊢ rec subtype subtype ^{'} ^{*} ok ( x )}

3.2.12.2. $sub final^{?} y^{*} comptype$

The composite type $comptype$ must be valid.
The sequence $y^{*}$ may be no longer than $1$ .
For every type index $y_{i}$ in $y^{*}$ :
- The type index $y_{i}$ must be smaller than $x$ .
- The type index $y_{i}$ must exist in the context $C$ .
- Let $subtype_{i}$ be the unrolling of the defined type $C. types [y_{i}]$ .
- The sub type $subtype_{i}$ must not contain $final$ .
- Let $comptype_{i}^{'}$ be the composite type in $subtype_{i}$ .
- The composite type $comptype$ must match $comptype_{i}^{'}$ .
Then the sub type is valid for the type index $x$ .

\frac{∣ y ^{*} ∣ \leq 1 ( y < x ) ^{*} ( unroll ( C . types [ y ]) = sub y ^{'} ^{*} comptype ^{'} ) ^{*} C ⊢ comptype ok ( C ⊢ comptype \leq comptype ^{'} ) ^{*}}{C ⊢ sub final ^{?} y ^{*} comptype ok ( x )}

Note

The side condition on the index ensures that a declared supertype is a previously defined types, preventing cyclic subtype hierarchies.

Future versions of WebAssembly may allow more than one supertype.

3.2.13. Defined Types

3.2.13.1. $rectype .i$

The recursive type $rectype$ must be valid for some type index $x$ .
Let $rec subtype^{*}$ be the defined type $rectype$ .
The number $i$ must be smaller than the length of the sequence $subtype^{*}$ of sub types.
Then the defined type is valid.

\frac{C ⊢ rectype ok ( x ) rectype = rec subtype ^{n} i < n}{C ⊢ rectype .i ok}

3.2.14. Limits

Limits must have meaningful bounds that are within a given range.

3.2.14.1. ${min n, max m^{?}}$

The value of $n$ must not be larger than $k$ .
If the maximum $m^{?}$ is not empty, then:
- Its value must not be larger than $k$ .
- Its value must not be smaller than $n$ .
Then the limit is valid within range $k$ .

\frac{n \leq k ( m \leq k ) ^{?} ( n \leq m ) ^{?}}{C ⊢ { min n , max m ^{?} } : k}

3.2.15. Table Types

3.2.15.1. $addrtype limits reftype$

The limits $limits$ must be valid within range $2^{∣ addrtype ∣} - 1$ .
The reference type $reftype$ must be valid.
Then the table type is valid.

\frac{C ⊢ limits : 2 ^{∣ addrtype ∣} - 1 C ⊢ reftype ok}{C ⊢ addrtype limits reftype ok}

3.2.16. Memory Types

3.2.16.1. $addrtype limits$

The limits $limits$ must be valid within range $2^{∣ addrtype ∣ - 16}$ .
Then the memory type is valid.

\frac{C ⊢ limits : 2 ^{∣ addrtype ∣ - 16}}{C ⊢ limits ok}

3.2.17. Tag Types

3.2.17.1. $[t_{1}^{n}] \to [t_{2}^{m}]$

The function type $[t_{1}^{n}] \to [t_{2}^{m}]$ must be valid.
The type sequence $t_{2}^{m}$ must be empty.
Then the tag type is valid.

⊢ [ t ^{*} ] \to [ ] ok

3.2.18. Global Types

3.2.18.1. $mut valtype$

The value type $valtype$ must be valid.
Then the global type is valid.

\frac{C ⊢ valtype ok}{C ⊢ mut valtype ok}

3.2.19. External Types

3.2.19.1. $func deftype$

The defined type $deftype$ must be valid.
The defined type $deftype$ must be a function type.
Then the external type is valid.

\frac{C ⊢ deftype ok expand ( deftype ) = func functype}{C ⊢ func deftype}

3.2.19.2. $table tabletype$

The table type $tabletype$ must be valid.
Then the external type is valid.

\frac{C ⊢ tabletype ok}{C ⊢ table tabletype ok}

3.2.19.3. $mem memtype$

The memory type $memtype$ must be valid.
Then the external type is valid.

\frac{C ⊢ memtype ok}{C ⊢ mem memtype ok}

3.2.19.4. $tag tagtype$

The tag type $tagtype$ must be valid.
Then the external type is valid.

\frac{⊢ tagtype ok}{⊢ tag tagtype ok}

3.2.19.5. $global globaltype$

The global type $globaltype$ must be valid.
Then the external type is valid.

\frac{C ⊢ globaltype ok}{C ⊢ global globaltype ok}

3.2.20. Defaultable Types

A type is defaultable if it has a default value for initialization.

3.2.20.1. Value Types

A defaultable value type $t$ must be:
- either a number type,
- or a vector type,
- or a nullable reference type.

C ⊢ numtype defaultable

C ⊢ vectype defaultable

C ⊢ ( ref null heaptype ) defaultable

3.3. Matching

On most types, a notion of subtyping is defined that is applicable in validation rules, during module instantiation when checking the types of imports, or during execution, when performing casts.

3.3.1. Number Types

A number type $numtype_{1}$ matches a number type $numtype_{2}$ if and only if:

Both $numtype_{1}$ and $numtype_{2}$ are the same.

C ⊢ numtype \leq numtype

3.3.2. Vector Types

A vector type $vectype_{1}$ matches a vector type $vectype_{2}$ if and only if:

Both $vectype_{1}$ and $vectype_{2}$ are the same.

C ⊢ vectype \leq vectype

3.3.3. Heap Types

A heap type $heaptype_{1}$ matches a heap type $heaptype_{2}$ if and only if:

Either both $heaptype_{1}$ and $heaptype_{2}$ are the same.
Or there exists a valid heap type $heaptype^{'}$ , such that $heaptype_{1}$ matches $heaptype^{'}$ and $heaptype^{'}$ matches $heaptype_{2}$ .
Or $heaptyp e_{1}$ is $eq$ and $heaptype_{2}$ is $any$ .
Or $heaptype_{1}$ is one of $i31$ , $struct$ , or $array$ and $heaptyp e_{2}$ is $eq$ .
Or $heaptype_{1}$ is a defined type which expands to a structure type and $heaptype_{2}$ is $struct$ .
Or $heaptype_{1}$ is a defined type which expands to an array type and $heaptype_{2}$ is $array$ .
Or $heaptype_{1}$ is a defined type which expands to a function type and $heaptype_{2}$ is $func$ .
Or $heaptype_{1}$ is a defined type $deftype_{1}$ and $heaptype_{2}$ is a defined type $deftype_{2}$ , and $deftype_{1}$ matches $deftype_{2}$ .
Or $heaptype_{1}$ is a type index $x_{1}$ , and the defined type $C. types [x_{1}]$ matches $heaptype_{2}$ .
Or $heaptype_{2}$ is a type index $x_{2}$ , and $heaptype_{1}$ matches the defined type $C. types [x_{2}]$ .
Or $heaptype_{1}$ is $none$ and $heaptype_{2}$ matches $any$ .
Or $heaptype_{1}$ is $nofunc$ and $heaptype_{2}$ matches $func$ .
Or $heaptype_{1}$ is $noextern$ and $heaptype_{2}$ matches $extern$ .
Or $heaptype_{1}$ is $bot$ .

C ⊢ heaptype \leq heaptype \frac{C ⊢ heaptype ^{'} ok C ⊢ heaptype _{1} \leq heaptype ^{'} C ⊢ heaptype ^{'} \leq heaptype _{2}}{C ⊢ heaptype _{1} \leq heaptype _{2}}

C ⊢ eq \leq any C ⊢ i31 \leq eq C ⊢ struct \leq eq C ⊢ array \leq eq

\frac{expand ( deftype ) = struct st}{C ⊢ deftype \leq struct} \frac{expand ( deftype ) = array at}{C ⊢ deftype \leq array} \frac{expand ( deftype ) = func ft}{C ⊢ deftype \leq func}

\frac{C ⊢ C . types [ typeidx _{1} ] \leq heaptype _{2}}{C ⊢ typeidx _{1} \leq heaptype _{2}} \frac{C ⊢ heaptype _{1} \leq C . types [ typeidx _{2} ]}{C ⊢ heaptype _{1} \leq typeidx _{2}}

\frac{C ⊢ ht \leq any}{C ⊢ none \leq ht} \frac{C ⊢ ht \leq func}{C ⊢ nofunc \leq ht} \frac{C ⊢ ht \leq extern}{C ⊢ noextern \leq ht}

C ⊢ bot \leq heaptype

3.3.4. Reference Types

A reference type $ref null_{1}^{?} heaptyp e_{1}$ matches a reference type $ref null_{2}^{?} heaptyp e_{2}$ if and only if:

The heap type $heaptype_{1}$ matches $heaptype_{2}$ .
$null_{1}$ is absent or $null_{2}$ is present.

\frac{C ⊢ heaptype _{1} \leq heaptype _{2}}{C ⊢ ref heaptype _{1} \leq ref heaptype _{2}} \frac{C ⊢ heaptype _{1} \leq heaptype _{2}}{C ⊢ ref null ^{?} heaptype _{1} \leq ref null heaptype _{2}}

3.3.5. Value Types

A value type $valtype_{1}$ matches a value type $valtype_{2}$ if and only if:

Either both $valtype_{1}$ and $valtype_{2}$ are number types and $valtype_{1}$ matches $valtype_{2}$ .
Or both $valtype_{1}$ and $valtype_{2}$ are reference types and $valtype_{1}$ matches $valtype_{2}$ .
Or $valtype_{1}$ is $bot$ .

C ⊢ bot \leq valtype

3.3.6. Result Types

Subtyping is lifted to result types in a pointwise manner. That is, a result type $[t_{1}^{*}]$ matches a result type $[t_{2}^{*}]$ if and only if:

Every value type $t_{1}$ in $[t_{1}^{*}]$ matches the corresponding value type $t_{2}$ in $[t_{2}^{*}]$ .

\frac{( C ⊢ t _{1} \leq t _{2} ) ^{*}}{C ⊢ [ t _{1}^{*} ] \leq [ t _{2}^{*} ]}

3.3.7. Instruction Types

Subtyping is further lifted to instruction types. An instruction type $[t_{11}^{*}] \to_{x_{1}^{*}} [t_{12}^{*}]$ matches a type $[t_{21}^{a} st] \to_{x_{2}^{*}} [t_{22}^{*}]$ if and only if:

There is a common sequence of value types $t^{*}$ such that $t_{21}^{*}$ equals $t^{*} t ’_{21}^{*}$ and $t_{22}^{*}$ equals $t^{*} t ’_{22}^{*}$ .
The result type $[t ’_{21}^{*}]$ matches $[t_{11}^{*}]$ .
The result type $[t_{12}^{*}]$ matches $[t ’_{22}^{*}]$ .
For every local index $x$ that is in $x_{2}^{*}$ but not in $x_{1}^{*}$ , the local type $C. locals [x]$ is $set t_{x}$ for some value type $t_{x}$ .

\frac{C ⊢ [ t _{21}^{*} ] \leq [ t _{11}^{*} ] C ⊢ [ t _{12}^{*} ] \leq [ t _{22}^{*} ] { x ^{*} } = { x _{2}^{*} } ∖ { x _{1}^{*} } ( C . locals [ x ] = set t _{x} ) ^{*}}{C ⊢ [ t _{11}^{*} ] \to _{x_{1}^{*}} [ t _{12}^{*} ] \leq [ t ^{*} t _{21}^{*} ] \to _{x_{2}^{*}} [ t ^{*} t _{22}^{*} ]}

Note

Instruction types are contravariant in their input and covariant in their output. Subtyping also incorporates a sort of “frame” condition, which allows adding arbitrary invariant stack elements on both sides in the super type.

Finally, the supertype may ignore variables from the init set $x_{1}^{*}$ . It may also add variables to the init set, provided these are already set in the context, i.e., are vacuously initialized.

3.3.8. Function Types

A function type $[t_{11}^{*}] \to [t_{12}^{*}]$ matches a type $[t_{21}^{a} st] \to [t_{22}^{*}]$ if and only if:

The result type $[t_{21}^{*}]$ matches $[t_{11}^{*}]$ .
The result type $[t_{12}^{*}]$ matches $[t_{22}^{*}]$ .

\frac{C ⊢ [ t _{21}^{*} ] \leq [ t _{11}^{*} ] C ⊢ [ t _{12}^{*} ] \leq [ t _{22}^{*} ]}{C ⊢ [ t _{11}^{*} ] \to [ t _{12}^{*} ] \leq [ t _{21}^{*} ] \to [ t _{22}^{*} ]}

3.3.9. Composite Types

A composite type $comptype_{1}$ matches a type $comptype_{2}$ if and only if:

Either the composite type $comptype_{1}$ is $func functype_{1}$ and $comptype_{2}$ is $func functype_{2}$ and:
- The function type $functype_{1}$ matches $functype_{2}$ .
Or the composite type $comptype_{1}$ is $struct fieldtype_{1}^{n_{1}}$ and $comptype_{2}$ is $struct fieldtype_{2}$ and:
- The arity $n_{1}$ is greater than or equal to $n_{2}$ .
- For every field type $fieldtype_{2i}$ in $fieldtype_{2}^{n_{2}}$ and corresponding $fieldtype_{1i}$ in $fieldtype_{1}^{n_{1}}$
  - The field type $fieldtype_{1i}$ matches $fieldtype_{2i}$ .
Or the composite type $comptype_{1}$ is $array fieldtype_{1}$ and $comptype_{2}$ is $array fieldtype_{2}$ and:
- The field type $fieldtype_{1}$ matches $fieldtype_{2}$ .

\frac{C ⊢ functype _{1} \leq functype _{2}}{C ⊢ func functype _{1} \leq func functype _{2}}

\frac{( C ⊢ fieldtype _{1} \leq fieldtype _{2} ) ^{*}}{C ⊢ struct fieldtype _{1}^{*} fieldtype ^{'} _{1}^{*} \leq struct fieldtype _{2}^{*}}

\frac{C ⊢ fieldtype _{1} \leq fieldtype _{2}}{C ⊢ array fieldtype _{1} \leq array fieldtype _{2}}

3.3.10. Field Types

A field type $mut_{1} storagetype_{1}$ matches a type $mut_{2} storagetype_{2}$ if and only if:

Storage type $storagetype_{1}$ matches $storagetype_{2}$ .
Either both $mut_{1}$ and $mut_{2}$ are $const$ .
Or both $mut_{1}$ and $mut_{2}$ are $var$ and $storagetype_{2}$ matches $storagetype_{1}$ as well.

\frac{C ⊢ storagetype _{1} \leq storagetype _{2}}{C ⊢ const storagetype _{1} \leq const storagetype _{2}} \frac{C ⊢ storagetype _{1} \leq storagetype _{2} C ⊢ storagetype _{2} \leq storagetype _{1}}{C ⊢ var storagetype _{1} \leq var storagetype _{2}}

A storage type $storagetype_{1}$ matches a type $storagetype_{2}$ if and only if:

Either $storagetype_{1}$ is a value type $valtype_{1}$ and $storagetype_{2}$ is a value type $valtype_{2}$ and $valtype_{1}$ matches $valtype_{2}$ .
Or $storagetype_{1}$ is a packed type $packedtype_{1}$ and $storagetype_{2}$ is a packed type $packedtype_{2}$ and $packedtype_{1}$ matches $packedtype_{2}$ .

A packed type $packedtype_{1}$ matches a type $packedtype_{2}$ if and only if:

The packed type $packedtype_{1}$ is the same as $packedtype_{2}$ .

C ⊢ packedtype \leq packedtype

3.3.11. Defined Types

A defined type $deftype_{1}$ matches a type $deftype_{2}$ if and only if:

Either $deftype_{1}$ and $deftype_{2}$ are equal when closed under context $C$ .
Or:
- Let the sub type $sub final^{?} heaptype^{*} comptype$ be the result of unrolling $deftype_{1}$ .
- Then there must exist a heap type $heaptype_{i}$ in $heaptype^{*}$ that matches $deftype_{2}$ .

\frac{clos _{C} ( deftype _{1} ) = clos _{C} ( deftype _{2} )}{C ⊢ deftype _{1} \leq deftype _{2}}

\frac{unroll ( deftype _{1} ) = sub final ^{?} heaptype ^{*} comptype C ⊢ heaptype ^{*} [ i ] \leq deftype _{2}}{C ⊢ deftype _{1} \leq deftype _{2}}

Note

Note that there is no explicit definition of type _equivalence_, since it coincides with syntactic equality, as used in the premise of the former rule above.

3.3.12. Limits

Limits ${min n_{1}, max m_{1}^{?}}$ match limits ${min n_{2}, max m_{2}^{?}}$ if and only if:

$n_{1}$ is larger than or equal to $n_{2}$ .
Either:
- $m_{2}^{?}$ is empty.
Or:
- Both $m_{1}^{?}$ and $m_{2}^{?}$ are non-empty.
- $m_{1}$ is smaller than or equal to $m_{2}$ .

\frac{n _{1} \geq n _{2}}{C ⊢ { min n _{1} , max m _{1}^{?} } \leq { min n _{2} , max ϵ }} \frac{n _{1} \geq n _{2} m _{1} \leq m _{2}}{C ⊢ { min n _{1} , max m _{1} } \leq { min n _{2} , max m _{2} }}

3.3.13. Table Types

A table type $(addrtype_{1} limits_{1} reftype_{1})$ matches $(addrtype_{2} limits_{2} reftype_{2})$ if and only if:

Address types $addrtype_{1}$ and $addrtype_{2}$ are the same.
Limits $limits_{1}$ match $limits_{2}$ .
The reference type $reftype_{1}$ matches $reftype_{2}$ , and vice versa.

\frac{C ⊢ limits _{1} \leq limits _{2} C ⊢ reftype _{1} \leq reftype _{2} C ⊢ reftype _{2} \leq reftype _{1}}{C ⊢ addrtype limits _{1} reftype _{1} \leq addrtype limits _{2} reftype _{2}}

3.3.14. Memory Types

A memory type $(addrtype_{1} limits_{1})$ matches $(addrtype_{2} limits_{2})$ if and only if:

Address types $addrtype_{1}$ and $addrtype_{2}$ are the same.
Limits $limits_{1}$ match $limits_{2}$ .

\frac{C ⊢ limits _{1} \leq limits _{2}}{C ⊢ addrtype limits _{1} \leq addrtype limits _{2}}

3.3.15. Global Types

A global type $(mut_{1} t_{1})$ matches $(mut_{2} t_{2})$ if and only if:

Either both $mut_{1}$ and $mut_{2}$ are $var$ and $t_{1}$ matches $t_{2}$ and vice versa.
Or both $mut_{1}$ and $mut_{2}$ are $const$ and $t_{1}$ matches $t_{2}$ .

\frac{C ⊢ t _{1} \leq t _{2} C ⊢ t _{2} \leq t _{1}}{C ⊢ var t _{1} \leq var t _{2}} \frac{C ⊢ t _{1} \leq t _{2}}{C ⊢ const t _{1} \leq const t _{2}}

3.3.16. Tag Types

A tag type $tagtype_{1}$ matches $tagtype_{2}$ if and only if they are the same.

C ⊢ tagtype \leq tagtype

3.3.17. External Types

3.3.17.1. Functions

An external type $func deftype_{1}$ matches $func deftype_{2}$ if and only if:

The defined type $deftype_{1}$ matches $deftype_{2}$ .

\frac{C ⊢ deftype _{1} \leq deftype _{2}}{C ⊢ func deftype _{1} \leq func deftype _{2}}

3.3.17.2. Tables

An external type $table tabletype_{1}$ matches $table tabletype_{2}$ if and only if:

Table type $tabletype_{1}$ matches $tabletype_{2}$ .

\frac{C ⊢ tabletype _{1} \leq tabletype _{2}}{C ⊢ table tabletype _{1} \leq table tabletype _{2}}

3.3.17.3. Memories

An external type $mem memtype_{1}$ matches $mem memtype_{2}$ if and only if:

Memory type $memtype_{1}$ matches $memtype_{2}$ .

\frac{C ⊢ memtype _{1} \leq memtype _{2}}{C ⊢ mem memtype _{1} \leq mem memtype _{2}}

3.3.17.4. Globals

An external type $global globaltype_{1}$ matches $global globaltype_{2}$ if and only if:

Global type $globaltype_{1}$ matches $globaltype_{2}$ .

\frac{C ⊢ globaltype _{1} \leq globaltype _{2}}{C ⊢ global globaltype _{1} \leq global globaltype _{2}}

3.3.17.5. Tags

An external type $tag tagtype_{1}$ matches $tag tagtype_{2}$ if and only if:

Tag type $tagtype_{1}$ matches $tagtype_{2}$ .

\frac{C ⊢ tagtype _{1} \leq tagtype _{2}}{C ⊢ tag tagtype _{1} \leq tag tagtype _{2}}

3.4. Instructions

Instructions are classified by instruction types that describe how they manipulate the operand stack and initialize locals: A type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ describes the required input stack with argument values of types $t_{1}^{*}$ that an instruction pops off and the provided output stack with result values of types $t_{2}^{*}$ that it pushes back. Moreover, it enumerates the indices $x^{*}$ of locals that have been set by the instruction. In most cases, this is empty.

Note

For example, the instruction $i32 . add$ has type $[i32 i32] \to [i32]$ , consuming two $i32$ values and producing one. The instruction $local.set x$ has type $[t] \to_{x} []$ , provided $t$ is the type declared for the local $x$ .

Typing extends to instruction sequences $instr^{*}$ . Such a sequence has an instruction type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ if the accumulative effect of executing the instructions is consuming values of types $t_{1}^{*}$ off the operand stack, pushing new values of types $t_{2}^{*}$ , and setting all locals $x^{*}$ .

For some instructions, the typing rules do not fully constrain the type, and therefore allow for multiple types. Such instructions are called polymorphic. Two degrees of polymorphism can be distinguished:

value-polymorphic: the value type $t$ of one or several individual operands is unconstrained. That is the case for all parametric instructions like $drop$ and $select$ .
stack-polymorphic: the entire (or most of the) instruction type $[t_{1}^{*}] \to [t_{2}^{*}]$ of the instruction is unconstrained. That is the case for all control instructions that perform an unconditional control transfer, such as $unreachable$ , $br$ , $br_table$ , and $return$ .

In both cases, the unconstrained types or type sequences can be chosen arbitrarily, as long as they meet the constraints imposed for the surrounding parts of the program.

Note

For example, the $select$ instruction is valid with type $[t t i32] \to [t]$ , for any possible number type $t$ . Consequently, both instruction sequences

(i32 . const 1) (i32 . const 2) (i32 . const 3) select

and

(f64 . const 1.0) (f64 . const 2.0) (i32 . const 3) select

are valid, with $t$ in the typing of $select$ being instantiated to $i32$ or $f64$ , respectively.

The $unreachable$ instruction is stack-polymorphic, and hence valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ for any possible sequences of value types $t_{1}^{*}$ and $t_{2}^{*}$ . Consequently,

unreachable i32 . add

is valid by assuming type $[] \to [i32]$ for the $unreachable$ instruction. In contrast,

unreachable (i64 . const 0) i32 . add

is invalid, because there is no possible type to pick for the $unreachable$ instruction that would make the sequence well-typed.

The Appendix describes a type checking algorithm that efficiently implements validation of instruction sequences as prescribed by the rules given here.

3.4.1. Numeric Instructions

3.4.1.1. $t . const c$

The instruction is valid with type $[] \to [t]$ .

C ⊢ t . const c : [ ] \to [ t ]

3.4.1.2. $t . unop$

The instruction is valid with type $[t] \to [t]$ .

C ⊢ t . unop : [ t ] \to [ t ]

3.4.1.3. $t . binop$

The instruction is valid with type $[t t] \to [t]$ .

C ⊢ t . binop : [ t t ] \to [ t ]

3.4.1.4. $t . testop$

The instruction is valid with type $[t] \to [i32]$ .

C ⊢ t . testop : [ t ] \to [ i32 ]

3.4.1.5. $t . relop$

The instruction is valid with type $[t t] \to [i32]$ .

C ⊢ t . relop : [ t t ] \to [ i32 ]

3.4.1.6. $t_{2} . cvtop_t_{1}_sx^{?}$

The instruction is valid with type $[t_{1}] \to [t_{2}]$ .

C ⊢ t _{2} . cvtop _ t _{1} _ sx ^{?} : [ t _{1} ] \to [ t _{2} ]

3.4.2. Reference Instructions

3.4.2.1. $ref.null ht$

The heap type $ht$ must be valid.
Then the instruction is valid with type $[] \to [(ref null ht)]$ .

\frac{C ⊢ ht ok}{C ⊢ ref.null ht : [ ] \to [( ref null ht )]}

3.4.2.2. $ref.func x$

The function $C. funcs [x]$ must be defined in the context.
Let $dt$ be the defined type $C. funcs [x]$ .
The function index $x$ must be contained in $C. refs$ .
The instruction is valid with type $[] \to [(ref dt)]$ .

\frac{C. funcs [ x ] = dt x \in C. refs}{C ⊢ ref.func x : [ ] \to [( ref dt )]}

3.4.2.3. $ref.is_null$

The instruction is valid with type $[(ref null ht)] \to [i32]$ , for any valid heap type $ht$ .

\frac{C ⊢ ht ok}{C ⊢ ref.is_null : [( ref null ht )] \to [ i32 ]}

3.4.2.4. $ref.as_non_null$

The instruction is valid with type $[(ref null ht)] \to [(ref ht)]$ , for any valid heap type $ht$ .

\frac{C ⊢ ht ok}{C ⊢ ref.as_non_null : [( ref null ht )] \to [( ref ht )]}

3.4.2.5. $ref.eq$

The instruction is valid with type $[(ref null eq) (ref null eq)] \to [i32]$ .

C ⊢ ref.eq : [( ref null eq ) ( ref null eq )] \to [ i32 ]

3.4.2.6. $ref.test rt$

The reference type $rt$ must be valid.
Then the instruction is valid with type $[rt^{'}] \to [i32]$ for any valid reference type $rt^{'}$ for which $rt$ matches $rt^{'}$ .

\frac{C ⊢ rt ok C ⊢ r t ^{'} ok C ⊢ rt \leq rt ^{'}}{C ⊢ ref.test rt : [ rt ^{'} ] \to [ i32 ]}

Note

The liberty to pick a supertype $rt^{'}$ allows typing the instruction with the least precise super type of $rt$ as input, that is, the top type in the corresponding heap subtyping hierarchy.

3.4.2.7. $ref.cast rt$

The reference type $rt$ must be valid.
Then the instruction is valid with type $[rt^{'}] \to [rt]$ for any valid reference type $rt^{'}$ for which $rt$ matches $rt^{'}$ .

\frac{C ⊢ rt ok C ⊢ r t ^{'} ok C ⊢ rt \leq rt ^{'}}{C ⊢ ref.cast rt : [ rt ^{'} ] \to [ rt ]}

Note

The liberty to pick a supertype $rt^{'}$ allows typing the instruction with the least precise super type of $rt$ as input, that is, the top type in the corresponding heap subtyping hierarchy.

3.4.3. Aggregate Reference Instructions

3.4.3.1. $struct.new x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be a structure type $struct fieldtype^{*}$ .
For each field type $fieldtype_{i}$ in $fieldtype^{*}$ :
- Let $fieldtype_{i}$ be $mut storagetype_{i}$ .
- Let $t_{i}$ be the value type $unpack (storagetype_{i})$ .
Let $t^{*}$ be the concatenation of all $t_{i}$ .
Then the instruction is valid with type $[t^{*}] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = struct ( mut st ) ^{*}}{C ⊢ struct.new x : [( unpack ( st ) ) ^{*} ] \to [( ref x )]}

3.4.3.2. $struct.new_default x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be a structure type $struct fieldtype^{*}$ .
For each field type $fieldtype_{i}$ in $fieldtype^{*}$ :
- Let $fieldtype_{i}$ be $mut storagetype_{i}$ .
- Let $t_{i}$ be the value type $unpack (storagetype_{i})$ .
- The type $t_{i}$ must be defaultable.
Let $t^{*}$ be the concatenation of all $t_{i}$ .
Then the instruction is valid with type $[] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = struct ( mut st ) ^{*} ( C ⊢ unpack ( st ) defaultable ) ^{*}}{C ⊢ struct.new_default x : [ ] \to [( ref x )]}

3.4.3.3. $struct.get_sx^{?} x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be a structure type $struct fieldtype^{*}$ .
Let the field type $mut storagetype$ be $fieldtype^{*} [y]$ .
Let $t$ be the value type $unpack (storagetype)$ .
The extension $sx$ must be present if and only if $storagetype$ is a packed type.
Then the instruction is valid with type $[(ref null x)] \to [t]$ .

\frac{expand ( C. types [ x ]) = struct ft ^{*} ft ^{*} [ y ] = mut st sx ^{?} = ϵ \Leftrightarrow st = unpack ( st )}{C ⊢ struct.get _ sx ^{?} x y : [( ref null x )] \to [ unpack ( st )]}

3.4.3.4. $struct.set x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be a structure type $struct fieldtype^{*}$ .
Let the field type $mut storagetype$ be $fieldtype^{*} [y]$ .
The prefix $mut$ must be $var$ .
Let $t$ be the value type $unpack (storagetype)$ .
Then the instruction is valid with type $[(ref null x) t] \to []$ .

\frac{expand ( C. types [ x ]) = struct ft ^{*} ft ^{*} [ y ] = var st}{C ⊢ struct.set x y : [( ref null x ) unpack ( st )] \to [ ]}

3.4.3.5. $array.new x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
Let $t$ be the value type $unpack (storagetype)$ .
Then the instruction is valid with type $[t i32] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = array ( mut st )}{C ⊢ array.new x : [ unpack ( st ) i32 ] \to [( ref x )]}

3.4.3.6. $array.new_default x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
Let $t$ be the value type $unpack (storagetype)$ .
The type $t$ must be defaultable.
Then the instruction is valid with type $[i32] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = array ( mut st ) C ⊢ unpack ( st ) defaultable}{C ⊢ array.new x : [ i32 ] \to [( ref x )]}

3.4.3.7. $array.new_fixed x n$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
Let $t$ be the value type $unpack (storagetype)$ .
Then the instruction is valid with type $[t^{n}] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = array ( mut st )}{C ⊢ array.new_fixed x n : [ unpack ( st ) ^{n} ] \to [( ref x )]}

3.4.3.8. $array.new_elem x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
The storage type $storagetype$ must be a reference type $rt$ .
The element segment $C. elems [y]$ must exist.
Let $rt^{'}$ be the reference type $C. elems [y]$ .
The reference type $rt^{'}$ must match $rt$ .
Then the instruction is valid with type $[i32 i32] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = array ( mut rt ) C ⊢ C. elems [ y ] \leq rt}{C ⊢ array.new_elem x y : [ i32 i32 ] \to [( ref x )]}

3.4.3.9. $array.new_data x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
Let $t$ be the value type $unpack (storagetype)$ .
The type $t$ must be a numeric type or a vector type.
The data segment $C. datas [y]$ must exist.
Then the instruction is valid with type $[i32 i32] \to [(ref x)]$ .

\frac{expand ( C. types [ x ]) = array ( mut st ) unpack ( st ) = numtype \lor unpack ( st ) = vectype C. datas [ y ] = ok}{C ⊢ array.new_data x y : [ i32 i32 ] \to [( ref x )]}

3.4.3.10. $array.get_sx^{?} x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let the field type $mut storagetype$ be $fieldtype$ .
Let $t$ be the value type $unpack (storagetype)$ .
The extension $sx$ must be present if and only if $storagetype$ is a packed type.
Then the instruction is valid with type $[(ref null x) i32] \to [t]$ .

\frac{expand ( C. types [ x ]) = array ( mut st ) sx ^{?} = ϵ \Leftrightarrow st = unpack ( st )}{C ⊢ array.get _ sx ^{?} x : [( ref null x ) i32 ] \to [ unpack ( st )]}

3.4.3.11. $array.set x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let the field type $mut storagetype$ be $fieldtype$ .
The prefix $mut$ must be $var$ .
Let $t$ be the value type $unpack (storagetype)$ .
Then the instruction is valid with type $[(ref null x) i32 t] \to []$ .

\frac{expand ( C. types [ x ]) = array ( var st )}{C ⊢ array.set x : [( ref null x ) i32 unpack ( st )] \to [ ]}

3.4.3.12. $array.len$

The the instruction is valid with type $[(ref null array)] \to [i32]$ .

C ⊢ array.len : [( ref null array )] \to [ i32 ]

3.4.3.13. $array.fill x$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let the field type $mut storagetype$ be $fieldtype$ .
The prefix $mut$ must be $var$ .
Let $t$ be the value type $unpack (storagetype)$ .
Then the instruction is valid with type $[(ref null x) i32 t i32] \to []$ .

\frac{expand ( C. types [ x ]) = array ( var st )}{C ⊢ array.fill x : [( ref null x ) i32 unpack ( st ) i32 ] \to [ ]}

3.4.3.14. $array.copy x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype_{1}$ .
Let the field type $mut_{1} storagetype_{1}$ be $fieldtype_{1}$ .
The prefix $mut_{1}$ must be $var$ .
The defined type $C. types [y]$ must exist.
The expansion of $C. types [y]$ must be an array type $array fieldtype_{2}$ .
Let the field type $mut_{2} storagetype_{2}$ be $fieldtype_{2}$ .
The storage type $storagetype_{2}$ must match $storagetype_{1}$ .
Then the instruction is valid with type $[(ref null x) i32 (ref null y) i32 i32] \to []$ .

\frac{expand ( C. types [ x ]) = array ( var s t _{1} ) expand ( C. types [ y ]) = array ( mut s t _{2} ) C ⊢ s t _{2} \leq s t _{1}}{C ⊢ array.copy x y : [( ref null x ) i32 ( ref null y ) i32 i32 ] \to [ ]}

3.4.3.15. $array.init_data x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let the field type $mut storagetype$ be $fieldtype$ .
The prefix $mut$ must be $var$ .
Let $t$ be the value type $unpack (storagetype)$ .
The value type $t$ must be a numeric type or a vector type.
The data segment $C. datas [y]$ must exist.
Then the instruction is valid with type $[(ref null x) i32 i32 i32] \to []$ .

\frac{expand ( C. types [ x ]) = array ( var st ) unpack ( st ) = numtype \lor unpack ( st ) = vectype C. datas [ y ] = ok}{C ⊢ array.init_data x y : [( ref null x ) i32 i32 i32 ] \to [ ]}

3.4.3.16. $array.init_elem x y$

The defined type $C. types [x]$ must exist.
The expansion of $C. types [x]$ must be an array type $array fieldtype$ .
Let the field type $mut storagetype$ be $fieldtype$ .
The prefix $mut$ must be $var$ .
The storage type $storagetype$ must be a reference type $rt$ .
The element segment $C. elems [y]$ must exist.
Let $rt^{'}$ be the reference type $C. elems [y]$ .
The reference type $rt^{'}$ must match $rt$ .
Then the instruction is valid with type $[(ref null x) i32 i32 i32] \to []$ .

\frac{expand ( C. types [ x ]) = array ( var rt ) C ⊢ C. elems [ y ] \leq rt}{C ⊢ array.init_elem x y : [( ref null x ) i32 i32 i32 ] \to [ ]}

3.4.4. Scalar Reference Instructions

3.4.4.1. $ref.i31$

The instruction is valid with type $[i32] \to [(ref i31)]$ .

C ⊢ ref.i31 : [ i32 ] \to [( ref i31 )]

3.4.4.2. $i31.get_sx$

The instruction is valid with type $[(ref null i31)] \to [i32]$ .

C ⊢ i31.get _ sx : [( ref null i31 )] \to [ i32 ]

3.4.5. External Reference Instructions

3.4.5.1. $any.convert_extern$

The instruction is valid with type $[(ref null_{1}^{?} extern)] \to [(ref null_{2}^{?} any)]$ for any $null_{1}^{?}$ that equals $null_{2}^{?}$ .

\frac{null _{1}^{?} = null _{2}^{?}}{C ⊢ any.convert_extern : [( ref null _{1}^{?} extern )] \to [( ref null _{2}^{?} any )]}

3.4.5.2. $extern.convert_any$

The instruction is valid with type $[(ref null_{1}^{?} any)] \to [(ref null_{2}^{?} extern)]$ for any $null_{1}^{?}$ that equals $null_{2}^{?}$ .

\frac{null _{1}^{?} = null _{2}^{?}}{C ⊢ extern.convert_any : [( ref null _{1}^{?} any )] \to [( ref null _{2}^{?} extern )]}

3.4.6. Vector Instructions

Vector instructions can have a prefix to describe the shape of the operand. Packed numeric types, $i8$ and $i16$ , are not value types. An auxiliary function maps such packed type shapes to value types:

unpack (t x N) = unpack (t)

The following auxiliary function denotes the number of lanes in a vector shape, i.e., its dimension:

dim (t x N) = N

3.4.6.1. $v128 . const c$

The instruction is valid with type $[] \to [v128]$ .

C ⊢ v128 . const c : [ ] \to [ v128 ]

3.4.6.2. $v128 . vvunop$

The instruction is valid with type $[v128] \to [v128]$ .

C ⊢ v128 . vvunop : [ v128 ] \to [ v128 ]

3.4.6.3. $v128 . vvbinop$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ v128 . vvbinop : [ v128 v128 ] \to [ v128 ]

3.4.6.4. $v128 . vvternop$

The instruction is valid with type $[v128 v128 v128] \to [v128]$ .

C ⊢ v128 . vvternop : [ v128 v128 v128 ] \to [ v128 ]

3.4.6.5. $v128 . vvtestop$

The instruction is valid with type $[v128] \to [i32]$ .

C ⊢ v128 . vvtestop : [ v128 ] \to [ i32 ]

3.4.6.6. $i8x16. swizzle$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ i8x16. swizzle : [ v128 v128 ] \to [ v128 ]

3.4.6.7. $i8x16. relaxed_swizzle$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ i8x16. relaxed_swizzle : [ v128 v128 ] \to [ v128 ]

3.4.6.8. $i8x16. shuffle laneidx^{16}$

For all $laneidx_{i}$ , in $laneidx^{16}$ , $laneidx_{i}$ must be smaller than $32$ .
The instruction is valid with type $[v128 v128] \to [v128]$ .

\frac{( laneidx < 32 ) ^{16}}{C ⊢ i8x16. shuffle laneidx ^{16} : [ v128 v128 ] \to [ v128 ]}

3.4.6.9. $shape . splat$

Let $t$ be $unpack (shape)$ .
The instruction is valid with type $[t] \to [v128]$ .

C ⊢ shape . splat : [ unpack ( shape )] \to [ v128 ]

3.4.6.10. $shape . extract_lane_sx^{?} laneidx$

The lane index $laneidx$ must be smaller than $dim (shape)$ .
The instruction is valid with type $[v128] \to [unpack (shape)]$ .

\frac{laneidx < dim ( shape )}{C ⊢ shape . extract_lane _ sx ^{?} laneidx : [ v128 ] \to [ unpack ( shape )]}

3.4.6.11. $shape . replace_lane laneidx$

The lane index $laneidx$ must be smaller than $dim (shape)$ .
Let $t$ be $unpack (shape)$ .
The instruction is valid with type $[v128 t] \to [v128]$ .

\frac{laneidx < dim ( shape )}{C ⊢ shape . replace_lane laneidx : [ v128 unpack ( shape )] \to [ v128 ]}

3.4.6.12. $shape . vunop$

The instruction is valid with type $[v128] \to [v128]$ .

C ⊢ shape . vunop : [ v128 ] \to [ v128 ]

3.4.6.13. $shape . vbinop$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ shape . vbinop : [ v128 v128 ] \to [ v128 ]

3.4.6.14. $shape . vternop$

The instruction is valid with type $[v128 v128 v128] \to [v128]$ .

C ⊢ shape . vternop : [ v128 v128 v128 ] \to [ v128 ]

3.4.6.15. $shape . relaxed_laneselect$

The instruction is valid with type $[v128 v128 v128] \to [v128]$ .

C ⊢ shape . relaxed_laneselect : [ v128 v128 v128 ] \to [ v128 ]

3.4.6.16. $shape . vrelop$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ shape . vrelop : [ v128 v128 ] \to [ v128 ]

3.4.6.17. $ishape . vishiftop$

The instruction is valid with type $[v128 i32] \to [v128]$ .

C ⊢ ishape . vishiftop : [ v128 i32 ] \to [ v128 ]

3.4.6.18. $shape . vtestop$

The instruction is valid with type $[v128] \to [i32]$ .

C ⊢ shape . vtestop : [ v128 ] \to [ i32 ]

3.4.6.19. $shape . vcvtop_half^{?}_shape_sx^{?}_zero^{?}$

The instruction is valid with type $[v128] \to [v128]$ .

C ⊢ shape . vcvtop _ half ^{?} _ shape _ sx ^{?} _zero ^{?} : [ v128 ] \to [ v128 ]

3.4.6.20. $ishape_{1} . narrow_ishape_{2}_sx$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ ishape _{1} . narrow _ ishape _{2} _ sx : [ v128 v128 ] \to [ v128 ]

3.4.6.21. $ishape . bitmask$

The instruction is valid with type $[v128] \to [i32]$ .

C ⊢ ishape . bitmask : [ v128 ] \to [ i32 ]

3.4.6.22. $ishape_{1} . dot_ishape_{2}_s$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ ishape _{1} . dot _ ishape _{2} _s : [ v128 v128 ] \to [ v128 ]

3.4.6.23. $ishape_{1} . dot_ishape_{2}_i7x16_s$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ ishape _{1} . dot _ ishape _{2} _ i7x16_s : [ v128 v128 ] \to [ v128 ]

3.4.6.24. $ishape_{1} . dot_ishape_{2}_i7x16_add__s$

The instruction is valid with type $[v128 v128 v128] \to [v128]$ .

C ⊢ ishape _{1} . dot _ ishape _{2} _ i7x16_add__s : [ v128 v128 v128 ] \to [ v128 ]

3.4.6.25. $ishape_{1} . extmul_half_ishape_{2}_sx$

The instruction is valid with type $[v128 v128] \to [v128]$ .

C ⊢ ishape _{1} . extmul _ half _ ishape _{2} _ sx : [ v128 v128 ] \to [ v128 ]

3.4.6.26. $ishape_{1} . extadd_pairwise_ishape_{2}_sx$

The instruction is valid with type $[v128] \to [v128]$ .

C ⊢ ishape _{1} . extadd_pairwise _ ishape _{2} _ sx : [ v128 ] \to [ v128 ]

3.4.7. Parametric Instructions

3.4.7.1. $drop$

The instruction is valid with type $[t] \to []$ , for any valid value type $t$ .

\frac{C ⊢ t ok}{C ⊢ drop : [ t ] \to [ ]}

Note

Both $drop$ and $select$ without annotation are value-polymorphic instructions.

3.4.7.2. $select (t^{*})^{?}$

If $t^{*}$ is present, then:
- The result type $[t^{*}]$ must be valid.
- The length of $t^{*}$ must be $1$ .
- Then the instruction is valid with type $[t^{*} t^{*} i32] \to [t^{*}]$ .
Else:
- The instruction is valid with type $[t t i32] \to [t]$ , for any valid value type $t$ that matches some number type or vector type.

\frac{C ⊢ [ t ] ok}{C ⊢ select t : [ t t i32 ] \to [ t ]} \frac{C ⊢ [ t ] ok C ⊢ [ t ] \leq [ numtype ]}{C ⊢ select : [ t t i32 ] \to [ t ]} \frac{C ⊢ [ t ] ok C ⊢ t \leq vectype}{C ⊢ select : [ t t i32 ] \to [ t ]}

Note

In future versions of WebAssembly, $select$ may allow more than one value per choice.

3.4.8. Variable Instructions

3.4.8.1. $local.get x$

The local $C. locals [x]$ must be defined in the context.
Let $init t$ be the local type $C. locals [x]$ .
The initialization status $init$ must be $set$ .
Then the instruction is valid with type $[] \to [t]$ .

\frac{C. locals [ x ] = set t}{C ⊢ local.get x : [ ] \to [ t ]}

3.4.8.2. $local.set x$

The local $C. locals [x]$ must be defined in the context.
Let $init t$ be the local type $C. locals [x]$ .
Then the instruction is valid with type $[t] \to_{x} []$ .

\frac{C. locals [ x ] = init t}{C ⊢ local.set x : [ t ] \to _{x} [ ]}

3.4.8.3. $local.tee x$

The local $C. locals [x]$ must be defined in the context.
Let $init t$ be the local type $C. locals [x]$ .
Then the instruction is valid with type $[t] \to_{x} [t]$ .

\frac{C. locals [ x ] = init t}{C ⊢ local.tee x : [ t ] \to _{x} [ t ]}

3.4.8.4. $global.get x$

The global $C. globals [x]$ must be defined in the context.
Let $mut t$ be the global type $C. globals [x]$ .
Then the instruction is valid with type $[] \to [t]$ .

\frac{C. globals [ x ] = mut t}{C ⊢ global.get x : [ ] \to [ t ]}

3.4.8.5. $global.set x$

The global $C. globals [x]$ must be defined in the context.
Let $mut t$ be the global type $C. globals [x]$ .
The mutability $mut$ must be $var$ .
Then the instruction is valid with type $[t] \to []$ .

\frac{C. globals [ x ] = var t}{C ⊢ global.set x : [ t ] \to [ ]}

3.4.9. Table Instructions

3.4.9.1. $table.get x$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
Then the instruction is valid with type $[at] \to [t]$ .

\frac{C. tables [ x ] = at limits t}{C ⊢ table.get x : [ at ] \to [ t ]}

3.4.9.2. $table.set x$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
Then the instruction is valid with type $[at t] \to []$ .

\frac{C. tables [ x ] = at limits t}{C ⊢ table.set x : [ at t ] \to [ ]}

3.4.9.3. $table.size x$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
Then the instruction is valid with type $[] \to [at]$ .

\frac{C. tables [ x ] = at limits t}{C ⊢ table.size x : [ ] \to [ at ]}

3.4.9.4. $table.grow x$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
Then the instruction is valid with type $[t at] \to [at]$ .

\frac{C. tables [ x ] = at limits t}{C ⊢ table.grow x : [ t at ] \to [ at ]}

3.4.9.5. $table.fill x$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
Then the instruction is valid with type $[at t at] \to []$ .

\frac{C. tables [ x ] = at limits t}{C ⊢ table.fill x : [ at t at ] \to [ ]}

3.4.9.6. $table.copy x y$

The table $C. tables [x]$ must be defined in the context.
Let $at_{1} limits_{1} t_{1}$ be the table type $C. tables [x]$ .
The table $C. tables [y]$ must be defined in the context.
Let $at_{2} limits_{2} t_{2}$ be the table type $C. tables [y]$ .
The reference type $t_{2}$ must match $t_{1}$ .
Let $at$ be the minimum of $at_{1}$ and $at_{2}$
Then the instruction is valid with type $[at_{1} at_{2} at] \to []$ .

\frac{C. tables [ x ] = at limits _{1} t _{1} C. tables [ y ] = at limits _{2} t _{2} C ⊢ t _{2} \leq t _{1}}{C ⊢ table.copy x y : [ at _{1} at _{2} atmin ( at _{1} , at _{2} )] \to [ ]}

3.4.9.7. $table.init x y$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t_{1}$ be the table type $C. tables [x]$ .
The element segment $C. elems [y]$ must be defined in the context.
Let $t_{2}$ be the reference type $C. elems [y]$ .
The reference type $t_{2}$ must match $t_{1}$ .
Then the instruction is valid with type $[at i32 i32] \to []$ .

\frac{C. tables [ x ] = at limits t _{1} C. elems [ y ] = t _{2} C ⊢ t _{2} \leq t _{1}}{C ⊢ table.init x y : [ at i32 i32 ] \to [ ]}

3.4.9.8. $elem.drop x$

The element segment $C. elems [x]$ must be defined in the context.
Then the instruction is valid with type $[] \to []$ .

\frac{C. elems [ x ] = t}{C ⊢ elem.drop x : [ ] \to [ ]}

3.4.10. Memory Instructions

3.4.10.1. $t . load x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than the bit width of $t$ divided by $8$ .
Then the instruction is valid with type $[at] \to [t]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq ∣t∣/8}{C ⊢ t .load x memarg : [ at ] \to [ t ]}

3.4.10.2. $t . load N_sx x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
Then the instruction is valid with type $[at] \to [t]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8}{C ⊢ t .load N _ sx x memarg : [ at ] \to [ t ]}

3.4.10.3. $t . store x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than the bit width of $t$ divided by $8$ .
Then the instruction is valid with type $[at t] \to []$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq ∣t∣/8}{C ⊢ t .store x memarg : [ at t ] \to [ ]}

3.4.10.4. $t . store N x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
Then the instruction is valid with type $[at t] \to []$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8}{C ⊢ t .store N x memarg : [ at t ] \to [ ]}

3.4.10.5. $v128. load N x M_sx x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8 \cdot M$ .
Then the instruction is valid with type $[at] \to [v128]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8 \cdot M}{C ⊢ v128. load N x M_ sx x memarg : [ at ] \to [ v128 ]}

3.4.10.6. $v128. load N_splat x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
Then the instruction is valid with type $[at] \to [v128]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8}{C ⊢ v128. load N _splat x memarg : [ at ] \to [ v128 ]}

3.4.10.7. $v128. load N_zero x memarg$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
Then the instruction is valid with type $[at] \to [v128]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8}{C ⊢ v128. load N _zero x memarg : [ at ] \to [ v128 ]}

3.4.10.8. $v128. load N_lane x memarg laneidx$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
The lane index $laneidx$ must be smaller than $128/N$ .
Then the instruction is valid with type $[at v128] \to [v128]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8 laneidx < 128/N}{C ⊢ v128. load N _lane x memarg laneidx : [ at v128 ] \to [ v128 ]}

3.4.10.9. $v128. store N_lane x memarg laneidx$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The offset $memarg . offset$ must be less than $2^{∣ at ∣}$ .
The alignment $2^{memarg . align}$ must not be larger than $N/8$ .
The lane index $laneidx$ must be smaller than $128/N$ .
Then the instruction is valid with type $[at v128] \to [v128]$ .

\frac{C. mems [ x ] = at limits memarg . offset < 2 ^{∣ at ∣} 2 ^{memarg . align} \leq N/8 laneidx < 128/N}{C ⊢ v128. store N _lane x memarg laneidx : [ at v128 ] \to [ ]}

3.4.10.10. $memory.size x$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
Then the instruction is valid with type $[] \to [at]$ .

\frac{C. mems [ x ] = at limits}{C ⊢ memory.size x : [ ] \to [ at ]}

3.4.10.11. $memory.grow x$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
Then the instruction is valid with type $[at] \to [at]$ .

\frac{C. mems [ x ] = at limits}{C ⊢ memory.grow x : [ at ] \to [ at ]}

3.4.10.12. $memory.fill x$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
Then the instruction is valid with type $[at i32 at] \to []$ .

\frac{C. mems [ x ] = at limits}{C ⊢ memory.fill x : [ at i32 at ] \to [ ]}

3.4.10.13. $memory.copy x y$

The memory $C. mems [x]$ must be defined in the context.
The memory $C. mems [y]$ must be defined in the context.
Let $at_{x} limits_{x}$ be the memory type $C. mems [x]$ .
Let $at_{y} limits_{y}$ be the memory type $C. mems [y]$ .
Let $at$ be the minimum of $at_{x}$ and $at_{y}$
Then the instruction is valid with type $[at_{x} at_{y} at] \to []$ .

\frac{C. mems [ x ] = at _{x} limits _{y} C. mems [ y ] = at _{y} limits _{y}}{C ⊢ memory.copy x y : [ at _{x} at _{y} atmin ( at _{x} , at _{y} )] \to [ ]}

3.4.10.14. $memory.init x y$

The memory $C. mems [x]$ must be defined in the context.
Let $at limits$ be the memory type $C. mems [x]$ .
The data segment $C. datas [y]$ must be defined in the context.
Then the instruction is valid with type $[at i32 i32] \to []$ .

\frac{C. mems [ x ] = at limits C. datas [ y ] = ok}{C ⊢ memory.init x y : [ at i32 i32 ] \to [ ]}

3.4.10.15. $data.drop x$

The data segment $C. datas [x]$ must be defined in the context.
Then the instruction is valid with type $[] \to []$ .

\frac{C. datas [ x ] = ok}{C ⊢ data.drop x : [ ] \to [ ]}

3.4.11. Control Instructions

3.4.11.1. $nop$

The instruction is valid with type $[] \to []$ .

C ⊢ nop : [ ] \to [ ]

3.4.11.2. $unreachable$

The instruction is valid with any valid type of the form $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{C ⊢ [ t _{1}^{*} ] \to [ t _{2}^{*} ] ok}{C ⊢ unreachable : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

Note

The $unreachable$ instruction is stack-polymorphic.

3.4.11.3. $block blocktype instr^{*} end$

The block type must be valid as some instruction type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Let $C^{'}$ be the same context as $C$ , but with the result type $[t_{2}^{*}]$ prepended to the $labels$ vector.
Under context $C^{'}$ , the instruction sequence $instr^{*}$ must be valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{C ⊢ blocktype : [ t _{1}^{*} ] \to [ t _{2}^{*} ] C , labels [ t _{2}^{*} ] ⊢ instr ^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ block blocktype instr ^{*} end : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

Note

The notation $C, labels [t^{*}]$ inserts the new label type at index $0$ , shifting all others.

3.4.11.4. $loop blocktype instr^{*} end$

The block type must be valid as some instruction type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ .
Let $C^{'}$ be the same context as $C$ , but with the result type $[t_{1}^{*}]$ prepended to the $labels$ vector.
Under context $C^{'}$ , the instruction sequence $instr^{*}$ must be valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{C ⊢ blocktype : [ t _{1}^{*} ] \to [ t _{2}^{*} ] C , labels [ t _{1}^{*} ] ⊢ instr ^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ loop blocktype instr ^{*} end : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

Note

The notation $C, labels [t^{*}]$ inserts the new label type at index $0$ , shifting all others.

3.4.11.5. $if blocktype instr_{1}^{} else instr_{2}^{} end$

The block type must be valid as some instruction type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Let $C^{'}$ be the same context as $C$ , but with the result type $[t_{2}^{*}]$ prepended to the $labels$ vector.
Under context $C^{'}$ , the instruction sequence $instr_{1}^{*}$ must be valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Under context $C^{'}$ , the instruction sequence $instr_{2}^{*}$ must be valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[t_{1}^{*} i32] \to [t_{2}^{*}]$ .

\frac{C ⊢ blocktype : [ t _{1}^{*} ] \to [ t _{2}^{*} ] C , labels [ t _{2}^{*} ] ⊢ instr _{1}^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ] C , labels [ t _{2}^{*} ] ⊢ instr _{2}^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ if blocktype instr _{1}^{*} else instr _{2}^{*} end : [ t _{1}^{*} i32 ] \to [ t _{2}^{*} ]}

Note

The notation $C, labels [t^{*}]$ inserts the new label type at index $0$ , shifting all others.

3.4.11.6. $try_table blocktype catch^{} instr^{} end$

The block type must be valid as some function type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
For every catch clause $catch_{i}$ in $catch^{*}$ , $catch_{i}$ must be valid.
Let $C^{'}$ be the same context as $C$ , but with the result type $[t_{2}^{*}]$ prepended to the $labels$ vector.
Under context $C^{'}$ , the instruction sequence $instr^{*}$ must be valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{C ⊢ blocktype : [ t _{1}^{*} ] \to [ t _{2}^{*} ] ( C ⊢ catch ok ) ^{*} C , labels [ t _{2}^{*} ] ⊢ instr ^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ try_table blocktype catch ^{*} instr ^{*} end : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

Note

The notation $C, labels [t^{*}]$ inserts the new label type at index $0$ , shifting all others.

3.4.11.7. $catch x l$

The tag $C. tags [x]$ must be defined in the context.
Let $[t^{*}] \to [t^{'}^{*}]$ be the expansion of the tag type $C. tags [x]$ .
The result type $[t^{'}^{*}]$ must be empty.
The label $C. labels [l]$ must be defined in the context.
The result type $[t^{*}]$ must be the same as $C. labels [l]$ .
Then the catch clause is valid.

\frac{expand ( C. tags [ x ]) = [ t ^{*} ] \to [ ] C. labels [ l ] = [ t ^{*} ]}{C ⊢ catch x l ok}

3.4.11.8. $catch_ref x l$

The tag $C. tags [x]$ must be defined in the context.
Let $[t^{*}] \to [t^{'}^{*}]$ be the expansion of the tag type $C. tags [x]$ .
The result type $[t^{'}^{*}]$ must be empty.
The label $C. labels [l]$ must be defined in the context.
The result type $[t^{*} (ref exn)]$ must match $C. labels [l]$ .
Then the catch clause is valid.

\frac{expand ( C. tags [ x ]) = [ t ^{*} ] \to [ ] C ⊢ [ t ^{*} ( ref exn )] \leq C. labels [ l ]}{C ⊢ catch_ref x l ok}

3.4.11.9. $catch_all l$

The label $C. labels [l]$ must be defined in the context.
The result type $C. labels [l]$ must be empty.
Then the catch clause is valid.

\frac{C. labels [ l ] = [ ]}{C ⊢ catch_all l ok}

3.4.11.10. $catch_all_ref l$

The label $C. labels [l]$ must be defined in the context.
The result type $[(ref exn)]$ must match $C. labels [l]$ .
Then the catch clause is valid.

\frac{C ⊢ [( ref exn )] \leq C. labels [ l ]}{C ⊢ catch_all_ref l ok}

3.4.11.11. $br l$

The label $C. labels [l]$ must be defined in the context.
Let $[t^{*}]$ be the result type $C. labels [l]$ .
Then the instruction is valid with any valid type of the form $[t_{1}^{*} t^{*}] \to [t_{2}^{*}]$ .

\frac{C. labels [ l ] = [ t ^{*} ] C ⊢ [ t _{1}^{*} t ^{*} ] \to [ t _{2}^{*} ] ok}{C ⊢ br l : [ t _{1}^{*} t ^{*} ] \to [ t _{2}^{*} ]}

Note

The label index space in the context $C$ contains the most recent label type first, so that $C. labels [l]$ performs a relative lookup as expected.

The $br$ instruction is stack-polymorphic.

3.4.11.12. $br_if l$

The label $C. labels [l]$ must be defined in the context.
Let $[t^{*}]$ be the result type $C. labels [l]$ .
Then the instruction is valid with type $[t^{*} i32] \to [t^{*}]$ .

\frac{C. labels [ l ] = [ t ^{*} ]}{C ⊢ br_if l : [ t ^{*} i32 ] \to [ t ^{*} ]}

Note

The label index space in the context $C$ contains the most recent label type first, so that $C. labels [l]$ performs a relative lookup as expected.

3.4.11.13. $br_table l^{*} l_{N}$

The label $C. labels [l_{N}]$ must be defined in the context.
For each label $l_{i}$ in $l^{*}$ , the label $C. labels [l_{i}]$ must be defined in the context.
There must be a sequence $t^{*}$ of value types, such that:
- The result type $[t^{*}]$ matches $C. labels [l_{N}]$ .
- For all $l_{i}$ in $l^{*}$ , the result type $[t^{*}]$ matches $C. labels [l_{i}]$ .
Then the instruction is valid with any valid type of the form $[t_{1}^{*} t^{*} i32] \to [t_{2}^{*}]$ .

\frac{( C ⊢ [ t ^{*} ] \leq C. labels [ l ] ) ^{*} C ⊢ [ t ^{*} ] \leq C. labels [ l _{N} ] C ⊢ [ t _{1}^{*} t ^{*} i32 ] \to [ t _{2}^{*} ] ok}{C ⊢ br_table l ^{*} l _{N} : [ t _{1}^{*} t ^{*} i32 ] \to [ t _{2}^{*} ]}

Note

The label index space in the context $C$ contains the most recent label first, so that $C. labels [l_{i}]$ performs a relative lookup as expected.

The $br_table$ instruction is stack-polymorphic.

Furthermore, the result type $[t^{*}]$ is also chosen non-deterministically in this rule. Although it may seem necessary to compute $[t^{*}]$ as the greatest lower bound of all label types in practice, a simple linear algorithm does not require this.

3.4.11.14. $br_on_null l$

The label $C. labels [l]$ must be defined in the context.
Let $[t^{*}]$ be the result type $C. labels [l]$ .
Then the instruction is valid with type $[t^{*} (ref null ht)] \to [t^{*} (ref ht)]$ for any valid heap type $ht$ .

\frac{C. labels [ l ] = [ t ^{*} ] C ⊢ ht ok}{C ⊢ br_on_null l : [ t ^{*} ( ref null ht )] \to [ t ^{*} ( ref ht )]}

3.4.11.15. $br_on_non_null l$

The label $C. labels [l]$ must be defined in the context.
Let $[t^{'}^{*}]$ be the result type $C. labels [l]$ .
The result type $[t^{'}^{*}]$ must contain at least one type.
Let the value type $t_{l}$ be the last element in the sequence $t^{'}^{*}$ , and $[t^{*}]$ the remainder of the sequence preceding it.
The value type $t_{l}$ must be a reference type of the form $ref null^{?} ht$ .
Then the instruction is valid with type $[t^{*} (ref null ht)] \to [t^{*}]$ .

\frac{C. labels [ l ] = [ t ^{*} ( ref ht )]}{C ⊢ br_on_non_null l : [ t ^{*} ( ref null ht )] \to [ t ^{*} ]}

3.4.11.16. $br_on_cast l rt_{1} rt_{2}$

The label $C. labels [l]$ must be defined in the context.
Let $[t_{l}^{*}]$ be the result type $C. labels [l]$ .
The type sequence $t_{l}^{*}$ must be of the form $t^{*} rt^{'}$ .
The reference type $rt_{1}$ must be valid.
The reference type $rt_{2}$ must be valid.
The reference type $rt_{2}$ must match $rt_{1}$ .
The reference type $rt_{2}$ must match $rt^{'}$ .
Let $rt_{1}^{'}$ be the type difference between $rt_{1}$ and $rt_{2}$ .
Then the instruction is valid with type $[t^{*} rt_{1}] \to [t^{*} rt_{1}^{'}]$ .

\frac{C. labels [ l ] = [ t ^{*} rt ] C ⊢ rt _{1} ok C ⊢ rt _{2} ok C ⊢ rt _{2} \leq rt _{1} C ⊢ rt _{2} \leq rt}{C ⊢ br_on_cast l rt _{1} rt _{2} : [ t ^{*} rt _{1} ] \to [ t ^{*} rt _{1} ∖ rt _{2} ]}

3.4.11.17. $br_on_cast_fail l rt_{1} rt_{2}$

The label $C. labels [l]$ must be defined in the context.
Let $[t_{l}^{*}]$ be the result type $C. labels [l]$ .
The type sequence $t_{l}^{*}$ must be of the form $t^{*} rt^{'}$ .
The reference type $rt_{1}$ must be valid.
The reference type $rt_{2}$ must be valid.
The reference type $rt_{2}$ must match $rt_{1}$ .
Let $rt_{1}^{'}$ be the type difference between $rt_{1}$ and $rt_{2}$ .
The reference type $rt_{1}^{'}$ must match $rt^{'}$ .
Then the instruction is valid with type $[t^{*} rt_{1}] \to [t^{*} rt_{2}]$ .

\frac{C. labels [ l ] = [ t ^{*} rt ] C ⊢ rt _{1} ok C ⊢ rt _{2} ok C ⊢ rt _{2} \leq rt _{1} C ⊢ rt _{1} ∖ rt _{2} \leq rt}{C ⊢ br_on_cast_fail l rt _{1} rt _{2} : [ t ^{*} rt _{1} ] \to [ t ^{*} rt _{2} ]}

3.4.11.18. $return$

The return type $C. return$ must not be absent in the context.
Let $[t^{*}]$ be the result type of $C. return$ .
Then the instruction is valid with any valid type of the form $[t_{1}^{*} t^{*}] \to [t_{2}^{*}]$ .

\frac{C. return = [ t ^{*} ] C ⊢ [ t _{1}^{*} t ^{*} ] \to [ t _{2}^{*} ] ok}{C ⊢ return : [ t _{1}^{*} t ^{*} ] \to [ t _{2}^{*} ]}

Note

The $return$ instruction is stack-polymorphic.

$C. return$ is absent (set to $ϵ$ ) when validating an expression that is not a function body. This differs from it being set to the empty result type ( $[ϵ]$ ), which is the case for functions not returning anything.

3.4.11.19. $call x$

The function $C. funcs [x]$ must be defined in the context.
The expansion of $C. funcs [x]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{expand ( C. funcs [ x ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ call x : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

3.4.11.20. $call_ref x$

The type $C. types [x]$ must be defined in the context.
The expansion of $C. funcs [x]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the instruction is valid with type $[t_{1}^{*} (ref null x)] \to [t_{2}^{*}]$ .

\frac{expand ( C. types [ x ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ call_ref x : [ t _{1}^{*} ( ref null x )] \to [ t _{2}^{*} ]}

3.4.11.21. $call_indirect x y$

The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
The reference type $t$ must match type $ref null func$ .
The type $C. types [y]$ must be defined in the context.
The expansion of $C. types [y]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the instruction is valid with type $[t_{1}^{*} at] \to [t_{2}^{*}]$ .

\frac{C. tables [ x ] = at limits t C ⊢ t \leq ref null func expand ( C. types [ y ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{C ⊢ call_indirect x y : [ t _{1}^{*} at ] \to [ t _{2}^{*} ]}

3.4.11.22. $return_call x$

The return type $C. return$ must not be absent in the context.
The function $C. funcs [x]$ must be defined in the context.
The expansion of $C. funcs [x]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
The result type $[t_{2}^{*}]$ must match $C. return$ .
Then the instruction is valid with any valid type $[t_{3}^{*} t_{1}^{*}] \to [t_{4}^{*}]$ .

\frac{expand ( C. funcs [ x ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ] C ⊢ [ t _{2}^{*} ] \leq C. return C ⊢ [ t _{3}^{*} t _{1}^{*} ] \to [ t _{4}^{*} ] ok}{C ⊢ return_call x : [ t _{3}^{*} t _{1}^{*} ] \to [ t _{4}^{*} ]}

Note

The $return_call$ instruction is stack-polymorphic.

3.4.11.23. $return_call_ref x$

The type $C. types [x]$ must be defined in the context.
The expansion of $C. types [x]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
The result type $[t_{2}^{*}]$ must match $C. return$ .
Then the instruction is valid with any valid type $[t_{3}^{*} t_{1}^{*} (ref null x)] \to [t_{4}^{*}]$ .

\frac{expand ( C. types [ x ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ] C ⊢ [ t _{2}^{*} ] \leq C. return C ⊢ [ t _{3}^{*} t _{1}^{*} ( ref null x )] \to [ t _{4}^{*} ] ok}{C ⊢ call_ref x : [ t _{3}^{*} t _{1}^{*} ( ref null x )] \to [ t _{4}^{*} ]}

Note

The $return_call_ref$ instruction is stack-polymorphic.

3.4.11.24. $return_call_indirect x y$

The return type $C. return$ must not be empty in the context.
The table $C. tables [x]$ must be defined in the context.
Let $at limits t$ be the table type $C. tables [x]$ .
The reference type $t$ must match type $ref null func$ .
The type $C. types [y]$ must be defined in the context.
The expansion of $C. types [y]$ must be a function type $func [t_{1}^{*}] \to [t_{2}^{*}]$ .
The result type $[t_{2}^{*}]$ must match $C. return$ .
Then the instruction is valid with type $[t_{3}^{*} t_{1}^{*} at] \to [t_{4}^{*}]$ , for any sequences of value types $t_{3}^{*}$ and $t_{4}^{*}$ .

\frac{C. tables [ x ] = at limits t C ⊢ t \leq ref null func expand ( C. types [ y ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ] C ⊢ [ t _{2}^{*} ] \leq C. return C ⊢ [ t _{3}^{*} t _{1}^{*} i32 ] \to [ t _{4}^{*} ] ok}{C ⊢ return_call_indirect x y : [ t _{3}^{*} t _{1}^{*} at ] \to [ t _{4}^{*} ]}

Note

The $return_call_indirect$ instruction is stack-polymorphic.

3.4.11.25. $throw x$

The tag $C. tags [x]$ must be defined in the context.
Let $[t^{*}] \to [t^{'}^{*}]$ be the tag type $C. tags [x]$ .
The result type $[t^{'}^{*}]$ must be empty.
Then the instruction is valid with type $[t_{1}^{*} t^{*}] \to [t_{2}^{*}]$ , for any sequences of value types $t_{1}^{*}$ and $t_{2}^{*}$ .

\frac{C. tags [ x ] = [ t ^{*} ] \to [ ]}{C ⊢ throw x : [ t _{1}^{*} t ^{*} ] \to [ t _{2}^{*} ]}

Note

The $throw$ instruction is stack-polymorphic.

3.4.11.26. $throw_ref$

The instruction is valid with type $[t_{1}^{*} exnref] \to [t_{2}^{*}]$ , for any sequences of value types $t_{1}^{*}$ and $t_{2}^{*}$ .

C ⊢ throw_ref : [ t _{1}^{*} exnref ] \to [ t _{2}^{*} ]

Note

The $throw_ref$ instruction is stack-polymorphic.

3.4.12. Instruction Sequences

Typing of instruction sequences is defined recursively.

3.4.12.1. Empty Instruction Sequence: $ϵ$

The empty instruction sequence is valid with type $[] \to []$ .

C ⊢ ϵ : [ ] \to [ ]

3.4.12.2. Non-empty Instruction Sequence: $instr instr^{'}^{*}$

The instruction $instr$ must be valid with some type $[t_{1}^{*}] \to_{x_{1}^{*}} [t_{2}^{*}]$ .
Let $C^{'}$ be the same context as $C$ , but with:
- $locals$ the same as in C, except that for every local index $x$ in $x_{1}^{*}$ , the local type $locals [x]$ has been updated to initialization status $set$ .
Under the context $C^{'}$ , the instruction sequence $instr^{'}^{*}$ must be valid with some type $[t_{2}^{*}] \to_{x_{2}^{*}} [t_{3}^{*}]$ .
Then the combined instruction sequence is valid with type $[t_{1}^{*}] \to_{x_{1}^{*} x_{2}^{*}} [t_{3}^{*}]$ .

\frac{C ⊢ instr : [ t _{1}^{*} ] \to _{x_{1}^{*}} [ t _{2}^{*} ] C ^{'} ⊢ instr ^{'} ^{*} : [ t _{2}^{*} ] \to _{x_{2}^{*}} [ t _{3}^{*} ] ( C . locals [ x _{1} ] = init t ) ^{*} C ^{'} = C ( with C . locals [ x _{1} ] = set t ) ^{*}}{C ⊢ instr instr ^{'} ^{*} : [ t _{1}^{*} ] \to _{x_{1}^{*} x_{2}^{*}} [ t _{2}^{*} t _{3}^{*} ]}

3.4.12.3. Subsumption for $instr^{*}$

The instruction sequence $instr^{*}$ must be valid with some type $instrtype$ .
The instruction type $instrtype^{'}$ : must be a valid
The instruction type $instrtype$ must match the type $instrtype^{'}$ .
Then the instruction sequence $instr^{*}$ is also valid with type $instrtype^{'}$ .

\frac{C ⊢ instr : instrtype C ⊢ instrtype ^{'} ok C ⊢ instrtype \leq instrtype ^{'}}{C ⊢ instr ^{*} : instrtype ^{'}}

Note

In combination with the previous rule, subsumption allows to compose instructions whose types would not directly fit otherwise. For example, consider the instruction sequence

(i32 . const 1) (i32 . const 1) i32 . add

To type this sequence, its subsequence $(i32 . const 1) i32 . add$ needs to be valid with an intermediate type. But the direct type of $(i32 . const 1)$ is $[] \to [i32]$ , not matching the two inputs expected by $i32 . add$ . The subsumption rule allows to weaken the type of $(i32 . const 1)$ to the supertype $[i32] \to [i32 i32]$ , such that it can be composed with $i32 . add$ and yields the intermediate type $[i32] \to [i32]$ for the subsequence. That can in turn be composed with the first constant.

Furthermore, subsumption allows to drop init variables $x^{*}$ from the instruction type in a context where they are not needed, for example, at the end of the body of a block.

3.4.13. Expressions

Expressions $expr$ are classified by result types of the form $[t^{*}]$ .

3.4.13.1. $instr^{*} end$

The instruction sequence $instr^{*}$ must be valid with type $[] \to [t^{*}]$ .
Then the expression is valid with result type $[t^{*}]$ .

\frac{C ⊢ instr ^{*} : [ ] \to [ t ^{*} ]}{C ⊢ instr ^{*} end : [ t ^{*} ]}

3.4.13.2. Constant Expressions

In a constant expression $instr^{*} end$ all instructions in $instr^{*}$ must be constant.
A constant instruction $instr$ must be:
- either of the form $t. const c$ ,
- or of the form $i nn . ibinop$ , where $ibinop$ is limited to $add$ , $sub$ , or $mul$ .
- or of the form $ref.null$ ,
- or of the form $ref.i31$ ,
- or of the form $ref.func x$ ,
- or of the form $struct.new x$ ,
- or of the form $struct.new_default x$ ,
- or of the form $array.new x$ ,
- or of the form $array.new_default x$ ,
- or of the form $array.new_fixed x$ ,
- or of the form $any.convert_extern$ ,
- or of the form $extern.convert_any$ ,
- or of the form $global.get x$ , in which case $C. globals [x]$ must be a global type of the form $const t$ .

\frac{( C ⊢ instr const ) ^{*}}{C ⊢ instr ^{*} end const}

C ⊢ t. const c const \frac{ibinop \in { add , sub , mul }}{C ⊢ i nn . ibinop const}

C ⊢ ref.null t const C ⊢ ref.i31 const C ⊢ ref.func x const

C ⊢ struct.new x const C ⊢ struct.new_default x const

C ⊢ array.new x const C ⊢ array.new_default x const C ⊢ array.new_fixed x const

C ⊢ any.convert_extern const C ⊢ extern.convert_any const

\frac{C. globals [ x ] = const t}{C ⊢ global.get x const}

Note

Currently, constant expressions occurring in globals are further constrained in that contained $global.get$ instructions are only allowed to refer to imported or previously defined globals. Constant expressions occurring in tables may only have $global.get$ instructions that refer to imported globals. This is enforced in the validation rule for modules by constraining the context $C$ accordingly.

The definition of constant expression may be extended in future versions of WebAssembly.

3.5. Modules

Modules are valid when all the components they contain are valid. Furthermore, most definitions are themselves classified with a suitable type.

3.5.1. Types

The sequence of types defined in a module is validated incrementally, yielding a suitable context.

3.5.1.1. $type^{*}$

If the sequence is empty, then:
- The context $C$ must be empty.
- Then the type sequence is valid.
Otherwise:
- Let the recursive type $rectype$ be the last element in the sequence.
- The sequence without $rectype$ must be valid for some context $C^{'}$ .
- Let the type index $x$ be the length of $C^{'} . types$ , i.e., the first type index free in $C^{'}$ .
- Let the sequence of defined types $deftype^{*}$ be the result $roll^{*}_{x} (rectype)$ of rolling up into its sequence of defined types.
- The recursive type $rectype$ must be valid under the context $C$ for type index $x$ .
- The current context $C$ be the same as $C^{'}$ , but with $deftype^{*}$ appended to $types$ .
- Then the type sequence is valid.

{ } ⊢ ϵ ok

\frac{C ^{'} ⊢ type ^{*} ok C = C ^{'} with types = C ^{'} . types roll ^{*} _{∣ C^{'} . types ∣} ( rectype ) C ⊢ rectype ok ( ∣ C ^{'} . types ∣ )}{C ⊢ type ^{*} rectype ok}

Note

Despite the appearance, the context $C$ is effectively an _output_ of this judgement.

3.5.2. Functions

Functions $func$ are classified by defined types that expand to function types of the form $func [t_{1}^{*}] \to [t_{2}^{*}]$ .

3.5.2.1. ${type x, locals t^{*}, body expr}$

The defined type $C. types [x]$ must be a function type.
Let $func [t_{1}^{*}] \to [t_{2}^{*}]$ be the expansion of the defined type $C. types [x]$ .
For each local declared by a value type $t$ in $t^{*}$ :
- The local for type $t$ must be valid with local type $localtype_{i}$ .
Let $localtype^{*}$ be the concatenation of all $localtype_{i}$ .
Let $C^{'}$ be the same context as $C$ , but with:
- $locals$ set to the sequence of value types $(set t_{1})^{*} localtype^{*}$ , concatenating parameters and locals,
- $labels$ set to the singular sequence containing only result type $[t_{2}^{*}]$ .
- $return$ set to the result type $[t_{2}^{*}]$ .
Under the context $C^{'}$ , the expression $expr$ must be valid with type $[t_{2}^{*}]$ .
Then the function definition is valid with type $C. types [x]$ .

\frac{expand ( C. types [ x ]) = func [ t _{1}^{*} ] \to [ t _{2}^{*} ] ( C ⊢ { type t } : init t ) ^{*} C , locals ( set t _{1} ) ^{*} ( init t ) ^{*} , labels [ t _{2}^{*} ] , return [ t _{2}^{*} ] ⊢ expr : [ t _{2}^{*} ]}{C ⊢ { type x , locals { type t } ^{*} , body expr } : C. types [ x ]}

3.5.3. Locals

Locals are classified with local types.

3.5.3.1. ${type valtype}$

The value type $valtype$ must be valid.
If $valtype$ is defaultable, then:
- The local is valid with local type $set valtype$ .
Else:
- The local is valid with local type $unset valtype$ .

\frac{C ⊢ t ok C ⊢ t defaultable}{C ⊢ { type t } : set t}

\frac{C ⊢ t ok}{C ⊢ { type t } : unset t}

Note

For cases where both rules are applicable, the former yields the more permissable type.

3.5.4. Tables

Tables $table$ are classified by table types.

3.5.4.1. ${type tabletype, init expr}$

The table type $tabletype$ must be valid.
Let $t$ be the element reference type of $tabletype$ .
The expression $expr$ must be valid with result type $[t]$ .
The expression $expr$ must be constant.
Then the table definition is valid with type $tabletype$ .

\frac{C ⊢ tabletype ok tabletype = limits t C ⊢ expr : [ t ] C ⊢ expr const}{C ⊢ { type tabletype , init expr } : tabletype}

3.5.5. Memories

Memories $mem$ are classified by memory types.

3.5.5.1. ${type memtype}$

The memory type $memtype$ must be valid.
Then the memory definition is valid with type $memtype$ .

\frac{C ⊢ memtype ok}{C ⊢ { type memtype } : memtype}

3.5.6. Globals

Globals $global$ are classified by global types of the form $mut t$ .

Sequences of globals are handled incrementally, such that each definition has access to previous definitions.

3.5.6.1. ${type mut t, init expr}$

The global type $mut t$ must be valid.
The expression $expr$ must be valid with result type $[t]$ .
The expression $expr$ must be constant.
Then the global definition is valid with type $mut t$ .

\frac{C ⊢ mut t ok C ⊢ expr : [ t ] C ⊢ expr const}{C ⊢ { type mut t , init expr } : mut t}

3.5.6.2. $global^{*}$

If the sequence is empty, then it is valid with the empty sequence of global types.
Else:
- The first global definition must be valid with some type global type $gt_{1}$ .
- Let $C^{'}$ be the same context as $C$ , but with the global type $gt_{1}$ apppended to the $globals$ vector.
- Under context $C^{'}$ , the remainder of the sequence must be valid with some sequence $gt^{*}$ of global types.
- Then the sequence is valid with the sequence of global types consisting of $gt_{1}$ prepended to $gt^{*}$ .

C ⊢ ϵ : ϵ \frac{C ⊢ global _{1} : gt _{1} C \oplus { globals gt _{1} } ⊢ global ^{*} : gt ^{*}}{C ⊢ global _{1} global ^{*} : gt _{1} gt ^{*}}

3.5.7. Tags

Tags $tag$ are classified by their tag type, each containing an index to a function type with empty result.

3.5.7.1. ${type x}$

The type $C. types [x]$ must be defined in the context.
Let $[t^{*}] \to [t^{'}^{*}]$ be the function type $C. types [x]$ .
The sequence $t^{'}^{*}$ must be empty.
Then the tag definition is valid with tag type $[t^{*}] \to []$ .

\frac{C. types [ x ] = [ t ^{*} ] \to [ ]}{C ⊢ { type x } : [ t ^{*} ] \to [ ]}

Note

Future versions of WebAssembly might allow non-empty return types for tags.

3.5.8. Element Segments

Element segments $elem$ are classified by the reference type of their elements.

3.5.8.1. ${type t, init e^{*}, mode elemmode}$

The reference type $t$ must be valid.
For each $e_{i}$ in $e^{*}$ :
- The expression $e_{i}$ must be valid with some result type $[t]$ .
- The expression $e_{i}$ must be constant.
The element mode $elemmode$ must be valid with some reference type $t^{'}$ .
The reference type $t$ must match the reference type $t^{'}$ .
Then the element segment is valid with reference type $t$ .

\frac{C ⊢ t ok ( C ⊢ e : [ t ] ) ^{*} ( C ⊢ e const ) ^{*} C ⊢ elemmode : t ^{'} C ⊢ t \leq t ^{'}}{C ⊢ { type t , init e ^{*} , mode elemmode } : t}

3.5.8.2. $passive$

The element mode is valid with any valid reference type.

\frac{C ⊢ reftype ok}{C ⊢ passive : reftype}

3.5.8.3. $active {table x, offset expr}$

The table $C. tables [x]$ must be defined in the context.
Let $limits t$ be the table type $C. tables [x]$ .
The expression $expr$ must be valid with result type $[i32]$ .
The expression $expr$ must be constant.
Then the element mode is valid with reference type $t$ .

\frac{C . tables [ x ] = limits t C ⊢ expr : [ i32 ] C ⊢ expr const}{C ⊢ active { table x , offset expr } : t}

3.5.8.4. $declarative$

The element mode is valid with any valid reference type.

\frac{C ⊢ reftype ok}{C ⊢ declarative : reftype}

3.5.9. Data Segments

Data segments $data$ are not classified by any type but merely checked for well-formedness.

3.5.9.1. ${init b^{*}, mode datamode}$

The data mode $datamode$ must be valid.
Then the data segment is valid.

\frac{C ⊢ datamode ok}{C ⊢ { init b ^{*} , mode datamode } ok}

3.5.9.2. $passive$

The data mode is valid.

C ⊢ passive ok

3.5.9.3. $active {memory x, offset expr}$

The memory $C. mems [x]$ must be defined in the context.
The expression $expr$ must be valid with result type $[i32]$ .
The expression $expr$ must be constant.
Then the data mode is valid.

\frac{C. mems [ x ] = limits C ⊢ expr : [ i32 ] C ⊢ expr const}{C ⊢ active { memory x , offset expr } ok}

3.5.10. Start Function

Start function declarations $start$ are not classified by any type.

3.5.10.1. ${func x}$

The function $C. funcs [x]$ must be defined in the context.
The expansion of $C. funcs [x]$ must be a function type $func [] \to []$ .
Then the start function is valid.

\frac{expand ( C. funcs [ x ]) = func [ ] \to [ ]}{C ⊢ { func x } ok}

3.5.11. Exports

Exports $export$ and export descriptions $exportdesc$ are classified by their external type.

3.5.11.1. ${name name, desc exportdesc}$

The export description $exportdesc$ must be valid with external type $externtype$ .
Then the export is valid with external type $externtype$ .

\frac{C ⊢ exportdesc : externtype}{C ⊢ { name name , desc exportdesc } : externtype}

3.5.11.2. $func x$

The function $C. funcs [x]$ must be defined in the context.
Let $dt$ be the defined type $C. funcs [x]$ .
Then the export description is valid with external type $func dt$ .

\frac{C. funcs [ x ] = dt}{C ⊢ func x : func dt}

3.5.11.3. $table x$

The table $C. tables [x]$ must be defined in the context.
Then the export description is valid with external type $table C. tables [x]$ .

\frac{C. tables [ x ] = tabletype}{C ⊢ table x : table tabletype}

3.5.11.4. $mem x$

The memory $C. mems [x]$ must be defined in the context.
Then the export description is valid with external type $mem C. mems [x]$ .

\frac{C. mems [ x ] = memtype}{C ⊢ mem x : mem memtype}

3.5.11.5. $global x$

The global $C. globals [x]$ must be defined in the context.
Then the export description is valid with external type $global C. globals [x]$ .

\frac{C. globals [ x ] = globaltype}{C ⊢ global x : global globaltype}

3.5.11.6. $tag x$

The tag $C. tags [x]$ must be defined in the context.
Then the export description is valid with external type $tag C. tags [x]$ .

\frac{C. tags [ x ] = tagtype}{C ⊢ tag x : tag tagtype}

3.5.12. Imports

Imports $import$ and import descriptions $importdesc$ are classified by external types.

3.5.12.1. ${module name_{1}, name name_{2}, desc importdesc}$

The import description $importdesc$ must be valid with type $externtype$ .
Then the import is valid with type $externtype$ .

\frac{C ⊢ importdesc : externtype}{C ⊢ { module name _{1} , name name _{2} , desc importdesc } : externtype}

3.5.12.2. $func x$

The defined type $C. types [x]$ must be a function type.
Then the import description is valid with type $func C. types [x]$ .

\frac{expand ( C. types [ x ]) = func functype}{C ⊢ func x : func C. types [ x ]}

3.5.12.3. $table tabletype$

The table type $tabletype$ must be valid.
Then the import description is valid with type $table tabletype$ .

\frac{C ⊢ tabletype ok}{C ⊢ table tabletype : table tabletype}

3.5.12.4. $mem memtype$

The memory type $memtype$ must be valid.
Then the import description is valid with type $mem memtype$ .

\frac{C ⊢ memtype ok}{C ⊢ mem memtype : mem memtype}

3.5.12.5. $global globaltype$

The global type $globaltype$ must be valid.
Then the import description is valid with type $global globaltype$ .

\frac{C ⊢ globaltype ok}{C ⊢ global globaltype : global globaltype}

3.5.12.6. $tag tag$

Let ${type x}$ be the tag $tag$ .
The type $C. types [x]$ must be defined in the context.
The tag type $C. types [x]$ must be a valid tag type.
Then the import description is valid with type $tag C. types [x]$ .

\frac{⊢ C. types [ x ] ok}{C ⊢ tag { type x } : tag C. types [ x ]}

3.5.13. Modules

Modules are classified by their mapping from the external types of their imports to those of their exports.

A module is entirely closed, that is, its components can only refer to definitions that appear in the module itself. Consequently, no initial context is required. Instead, the context $C$ for validation of the module’s content is constructed from the definitions in the module.

The external types classifying a module may contain free type indices that refer to types defined within the module.

Let $module$ be the module to validate.
The types $module . types$ must be valid yielding a context $C_{0}$ .
Let $C$ be a context where:
- $C. types$ is $C_{0} . types$ ,
- $C. funcs$ is $funcs (it^{*})$ concatenated with $dt^{*}$ , with the import’s external types $it^{*}$ and the internal defined types $dt^{*}$ as determined below,
- $C. tables$ is $tables (it^{*})$ concatenated with $tt^{*}$ , with the import’s external types $it^{*}$ and the internal table types $tt^{*}$ as determined below,
- $C. mems$ is $mems (it^{*})$ concatenated with $mt^{*}$ , with the import’s external types $it^{*}$ and the internal memory types $mt^{*}$ as determined below,
- $C. globals$ is $globals (it^{*})$ concatenated with $gt^{*}$ , with the import’s external types $it^{*}$ and the internal global types $gt^{*}$ as determined below,
- $C. tags$ is $tags (it^{*})$ concatenated with $ht^{*}$ , with the import’s external types $it^{*}$ and the internal tag types $ht^{*}$ as determined below,
- $C. elems$ is $rt^{*}$ as determined below,
- $C. datas$ is $ok^{n}$ , where $n$ is the length of the vector $module . datas$ ,
- $C. locals$ is empty,
- $C. labels$ is empty,
- $C. return$ is empty.
- $C. refs$ is the set $funcidx (module with funcs = ϵ with start = ϵ)$ , i.e., the set of function indices occurring in the module, except in its functions or start function.
Let $C^{'}$ be the context where:
- $C^{'} . globals$ is the sequence $globals (it^{*})$ ,
- $C^{'} . types$ is the same as $C. types$ ,
- $C^{'} . funcs$ is the same as $C. funcs$ ,
- $C^{'} . tables$ is the same as $C. tables$ ,
- $C^{'} . mems$ is the same as $C. mems$ ,
- $C^{'} . refs$ is the same as $C. refs$ ,
- all other fields are empty.
Under the context $C^{'}$ :
- The sequence $module . globals$ of globals must be valid with a sequence $gt^{*}$ of global types.
- For each $table_{i}$ in $module . tables$ , the definition $table_{i}$ must be valid with a table type $tt_{i}$ .
- For each $mem_{i}$ in $module . mems$ , the definition $mem_{i}$ must be valid with a memory type $mt_{i}$ .
Under the context $C$ :
- For each $func_{i}$ in $module . funcs$ , the definition $func_{i}$ must be valid with a defined type $dt_{i}$ .
- For each $tag_{i}$ in $module . tags$ , the definition $tag_{i}$ must be valid with a tag type $ht_{i}$ .
- For each $elem_{i}$ in $module . elems$ , the segment $elem_{i}$ must be valid with reference type $rt_{i}$ .
- For each $data_{i}$ in $module . datas$ , the segment $data_{i}$ must be valid.
- If $module . start$ is non-empty, then $module . start$ must be valid.
- For each $import_{i}$ in $module . imports$ , the segment $import_{i}$ must be valid with an external type $it_{i}$ .
- For each $export_{i}$ in $module . exports$ , the segment $export_{i}$ must be valid with external type $et_{i}$ .
Let $dt^{*}$ be the concatenation of the internal function types $dt_{i}$ , in index order.
Let $tt^{*}$ be the concatenation of the internal table types $tt_{i}$ , in index order.
Let $mt^{*}$ be the concatenation of the internal memory types $mt_{i}$ , in index order.
Let $gt^{*}$ be the concatenation of the internal global types $gt_{i}$ , in index order.
Let $ht^{*}$ be the concatenation of the internal tag types $ht_{i}$ , in index order.
Let $rt^{*}$ be the concatenation of the reference types $rt_{i}$ , in index order.
Let $it^{*}$ be the concatenation of external types $it_{i}$ of the imports, in index order.
Let $et^{*}$ be the concatenation of external types $et_{i}$ of the exports, in index order.
The length of $C. mems$ must not be larger than $1$ .
All export names $export_{i} . name$ must be different.
Then the module is valid with external types $it^{*} \to et^{*}$ .

\frac{C _{0} ⊢ type ^{*} ok C ^{'} ⊢ global ^{*} : gt ^{*} ( C ^{'} ⊢ table : tt ) ^{*} ( C ^{'} ⊢ mem : mt ) ^{*} ( C ⊢ func : dt ) ^{*} ( C ⊢ tag : ht ) ^{*} ( C ⊢ elem : rt ) ^{*} ( C ⊢ data ok ) ^{n} ( C ⊢ start ok ) ^{?} ( C ⊢ import : it ) ^{*} idt ^{*} = funcs ( it ^{*} ) itt ^{*} = tables ( it ^{*} ) imt ^{*} = mems ( it ^{*} ) igt ^{*} = globals ( it ^{*} ) iht ^{*} = tags ( it ^{*} ) x ^{*} = funcidx ( module with funcs = ϵ with start = ϵ ) C = { types C _{0} . types , funcs idt ^{*} dt ^{*} , tables itt ^{*} tt ^{*} , mems imt ^{*} mt ^{*} , globals igt ^{*} gt ^{*} , tags iht ^{*} ht ^{*} , elems rt ^{*} , datas ok ^{n} , refs x ^{*} } C ^{'} = { types C _{0} . types , globals igt ^{*} , funcs ( C . funcs ) , tables ( C . tables ) , mems ( C . mems ) , refs ( C . refs )} ( export . name ) ^{*} disjoint module = { types type ^{*} , funcs func ^{*} , tables table ^{*} , mems mem ^{*} , globals global ^{*} , tags tag ^{*} , elems elem ^{*} , datas data ^{n} , start start ^{?} , imports import ^{*} , exports export ^{*} }}{⊢ module : it ^{*} \to et ^{*}}

Note

All functions in a module are mutually recursive. Consequently, the definition of the context $C$ in this rule is recursive: it depends on the outcome of validation of the function, table, memory, and global definitions contained in the module, which itself depends on $C$ . However, this recursion is just a specification device. All types needed to construct $C$ can easily be determined from a simple pre-pass over the module that does not perform any actual validation.

Globals, however, are not recursive but evaluated sequentially, such that each constant expressions only has access to imported or previously defined globals.

4. Execution

4.1. Conventions

WebAssembly code is executed when instantiating a module or invoking an exported function on the resulting module instance.

Execution behavior is defined in terms of an abstract machine that models the program state. It includes a stack, which records operand values and control constructs, and an abstract store containing global state.

For each instruction, there is a rule that specifies the effect of its execution on the program state. Furthermore, there are rules describing the instantiation of a module. As with validation, all rules are given in two equivalent forms:

In prose, describing the execution in intuitive form.
In formal notation, describing the rule in mathematical form. [1]

Note

As with validation, the prose and formal rules are equivalent, so that understanding of the formal notation is not required to read this specification. The formalism offers a more concise description in notation that is used widely in programming languages semantics and is readily amenable to mathematical proof.

4.1.1. Prose Notation

Execution is specified by stylised, step-wise rules for each instruction of the abstract syntax. The following conventions are adopted in stating these rules.

The execution rules implicitly assume a given store $S$ .
The execution rules also assume the presence of an implicit stack that is modified by pushing or popping values, labels, and frames.
Certain rules require the stack to contain at least one frame. The most recent frame is referred to as the current frame.
Both the store and the current frame are mutated by replacing some of their components. Such replacement is assumed to apply globally.
The execution of an instruction may trap, in which case the entire computation is aborted and no further modifications to the store are performed by it. (Other computations can still be initiated afterwards.)
The execution of an instruction may also end in a jump to a designated target, which defines the next instruction to execute.
Execution can enter and exit instruction sequences that form blocks.
Instruction sequences are implicitly executed in order, unless a trap or jump occurs, or an exception is thrown.
In various places the rules contain assertions expressing crucial invariants about the program state.

4.1.2. Formal Notation

Note

This section gives a brief explanation of the notation for specifying execution formally. For the interested reader, a more thorough introduction can be found in respective text books. [2]

The formal execution rules use a standard approach for specifying operational semantics, rendering them into reduction rules. Every rule has the following general form:

configuration ↪ configuration

A configuration is a syntactic description of a program state. Each rule specifies one step of execution. As long as there is at most one reduction rule applicable to a given configuration, reduction – and thereby execution – is deterministic. WebAssembly has only very few exceptions to this, which are noted explicitly in this specification.

For WebAssembly, a configuration typically is a tuple $(S; F; instr^{*})$ consisting of the current store $S$ , the call frame $F$ of the current function, and the sequence of instructions that is to be executed. (A more precise definition is given later.)

To avoid unnecessary clutter, the store $S$ and the frame $F$ are omitted from reduction rules that do not touch them.

There is no separate representation of the stack. Instead, it is conveniently represented as part of the configuration’s instruction sequence. In particular, values are defined to coincide with $const$ instructions, and a sequence of $const$ instructions can be interpreted as an operand “stack” that grows to the right.

Note

For example, the reduction rule for the $i32 . add$ instruction can be given as follows:

(i32 . const n_{1}) (i32 . const n_{2}) i32 . add ↪ (i32 . const (n_{1} + n_{2}) mod 2^{32})

Per this rule, two $const$ instructions and the $add$ instruction itself are removed from the instruction stream and replaced with one new $const$ instruction. This can be interpreted as popping two values off the stack and pushing the result.

When no result is produced, an instruction reduces to the empty sequence:

nop ↪ ϵ

Labels and frames are similarly defined to be part of an instruction sequence.

The order of reduction is determined by the definition of an appropriate evaluation context.

Reduction terminates when no more reduction rules are applicable. Soundness of the WebAssembly type system guarantees that this is only the case when the original instruction sequence has either been reduced to a sequence of $const$ instructions, which can be interpreted as the values of the resulting operand stack, or if a trap or an uncaught exception occurred.

Note

For example, the following instruction sequence,

(f64 . const x_{1}) (f64 . const x_{2}) f64 . neg (f64 . const x_{3}) f64 . add f64 . mul

terminates after three steps:

↪ ↪ ↪ (f64 . const x_{1}) (f64 . const x_{2}) f64 . neg (f64 . const x_{3}) f64 . add f64 . mul (f64 . const x_{1}) (f64 . const x_{4}) (f64 . const x_{3}) f64 . add f64 . mul (f64 . const x_{1}) (f64 . const x_{5}) f64 . mul (f64 . const x_{6})

where $x_{4} = - x_{2}$ and $x_{5} = - x_{2} + x_{3}$ and $x_{6} = x_{1} \cdot (- x_{2} + x_{3})$ .

4.2. Runtime Structure

Store, stack, and other runtime structure forming the WebAssembly abstract machine, such as values or module instances, are made precise in terms of additional auxiliary syntax.

4.2.1. Values

WebAssembly computations manipulate values of either the four basic number types, i.e., integers and floating-point data of 32 or 64 bit width each, or vectors of 128 bit width, or of reference type.

In most places of the semantics, values of different types can occur. In order to avoid ambiguities, values are therefore represented with an abstract syntax that makes their type explicit. It is convenient to reuse the same notation as for the $const$ instructions and $ref.null$ producing them.

References other than null are represented with additional administrative instructions. They either are scalar references, containing a 31-bit integer, structure references, pointing to a specific structure address, array references, pointing to a specific array address, function references, pointing to a specific function address, exception references, pointing to a specific exception address, or host references pointing to an uninterpreted form of host address defined by the embedder. Any of the aformentioned references can furthermore be wrapped up as an external reference.

num vec ref val ::= ∣ ∣ ∣ ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= i32 . const i32 i64 . const i64 f32 . const f32 f64 . const f64 v128 . const i128 ref.null (absheaptype ∣ deftype) ref . i31 u31 ref . struct structaddr ref . array arrayaddr ref . func funcaddr ref . exn exnaddr ref . host hostaddr ref . extern ref num ∣ vec ∣ ref

Note

Future versions of WebAssembly may add additional forms of reference.

Value types can have an associated default value; it is the respective value $0$ for number types, $0$ for vector types, and null for nullable reference types. For other references, no default value is defined, $default_{t}$ hence is an optional value $val^{?}$ .

default_{t} default_{t} default_{t} default_{t} = = = = t . const 0 t . const 0 ref.null t ϵ (if t = numtype) (if t = vectype) (if t = (ref null heaptype)) (if t = (ref heaptype))

4.2.1.1. Convention

The meta variable $r$ ranges over reference values where clear from context.

4.2.2. Results

A result is the outcome of a computation. It is either a sequence of values, an uncaught exception, or a trap.

result ::= ∣ ∣ val^{*} T [(ref . exn exnaddr) throw_ref] trap

4.2.3. Store

The store represents all global state that can be manipulated by WebAssembly programs. It consists of the runtime representation of all instances of functions, tables, memories, globals, tags, element segments, data segments, and structures, arrays or exceptions that have been allocated during the life time of the abstract machine. [1]

It is an invariant of the semantics that no element or data instance is addressed from anywhere else but the owning module instances.

Syntactically, the store is defined as a record listing the existing instances of each category:

store ::= {funcs tables mems globals tags elems datas structs arrays exns funcinst^{*}, tableinst^{*}, meminst^{*}, globalinst^{*}, taginst^{*}, eleminst^{*}, datainst^{*}, structinst^{*}, arrayinst^{*}, exninst^{*}}

4.2.3.1. Convention

The meta variable $S$ ranges over stores where clear from context.

4.2.4. Addresses

Function instances, table instances, memory instances, global instances, tag instances, element instances, data instances and structure, array instances or exception instances in the store are referenced with abstract addresses. These are simply indices into the respective store component. In addition, an embedder may supply an uninterpreted set of host addresses.

addr funcaddr tableaddr memaddr globaladdr tagaddr elemaddr dataaddr structaddr arrayaddr exnaddr hostaddr ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= 0 ∣ 1 ∣ 2 ∣ \dots addr addr addr addr addr addr addr addr addr addr addr

An embedder may assign identity to exported store objects corresponding to their addresses, even where this identity is not observable from within WebAssembly code itself (such as for function instances or immutable globals).

Note

Addresses are dynamic, globally unique references to runtime objects, in contrast to indices, which are static, module-local references to their original definitions. A memory address $memaddr$ denotes the abstract address of a memory instance in the store, not an offset inside a memory instance.

There is no specific limit on the number of allocations of store objects, hence logical addresses can be arbitrarily large natural numbers.

4.2.4.1. Conventions

The notation $addr (A)$ denotes the set of addresses from address space $addr$ occurring free in $A$ . We sometimes reinterpret this set as the vector of its elements.

4.2.5. Module Instances

A module instance is the runtime representation of a module. It is created by instantiating a module, and collects runtime representations of all entities that are imported, defined, or exported by the module.

moduleinst ::= {types funcaddrs tableaddrs memaddrs globaladdrs tagaddrs elemaddrs dataaddrs exports deftype^{*}, funcaddr^{*}, tableaddr^{*}, memaddr^{*}, globaladdr^{*}, tagaddr^{*}, elemaddr^{*}, dataaddr^{*}, exportinst^{*}}

Each component references runtime instances corresponding to respective declarations from the original module – whether imported or defined – in the order of their static indices. Function instances, table instances, memory instances, global instances, and tag instances are referenced with an indirection through their respective addresses in the store.

It is an invariant of the semantics that all export instances in a given module instance have different names.

4.2.6. Function Instances

A function instance is the runtime representation of a function. It effectively is a closure of the original function over the runtime module instance of its originating module. The module instance is used to resolve references to other definitions during execution of the function.

funcinst hostfunc ::= ∣ ::= {type deftype, module moduleinst, code func} {type deftype, hostcode hostfunc} \dots

A host function is a function expressed outside WebAssembly but passed to a module as an import. The definition and behavior of host functions are outside the scope of this specification. For the purpose of this specification, it is assumed that when invoked, a host function behaves non-deterministically, but within certain constraints that ensure the integrity of the runtime.

Note

Function instances are immutable, and their identity is not observable by WebAssembly code. However, the embedder might provide implicit or explicit means for distinguishing their addresses.

4.2.7. Table Instances

A table instance is the runtime representation of a table. It records its type and holds a sequence of reference values.

tableinst ::= {type tabletype, elem ref^{*}}

Table elements can be mutated through table instructions, the execution of an active element segment, or by external means provided by the embedder.

It is an invariant of the semantics that all table elements have a type matching the element type of $tabletype$ . It also is an invariant that the length of the element sequence never exceeds the maximum size of $tabletype$ , if present.

4.2.8. Memory Instances

A memory instance is the runtime representation of a linear memory. It records its type and holds a sequence of bytes.

meminst ::= {type memtype, data byte^{*}}

The length of the sequence always is a multiple of the WebAssembly page size, which is defined to be the constant $65536$ – abbreviated $64 Ki$ .

The bytes can be mutated through memory instructions, the execution of an active data segment, or by external means provided by the embedder.

It is an invariant of the semantics that the length of the byte vector, divided by page size, never exceeds the maximum size of $memtype$ , if present.

4.2.9. Global Instances

A global instance is the runtime representation of a global variable. It records its type and holds an individual value.

globalinst ::= {type globaltype, value val}

The value of mutable globals can be mutated through variable instructions or by external means provided by the embedder.

It is an invariant of the semantics that the value has a type matching the value type of $globaltype$ .

4.2.10. Tag Instances

A tag instance is the runtime representation of a tag definition. It records the type of the tag.

taginst ::= {type tagtype}

4.2.11. Element Instances

An element instance is the runtime representation of an element segment. It holds a vector of references and their common type.

eleminst ::= {type reftype, elem vec (ref)}

4.2.12. Data Instances

An data instance is the runtime representation of a data segment. It holds a vector of bytes.

datainst ::= {data vec (byte)}

4.2.13. Export Instances

An export instance is the runtime representation of an export. It defines the export’s name and the associated external value.

exportinst ::= {name name, value externval}

4.2.14. External Values

An external value is the runtime representation of an entity that can be imported or exported. It is an address denoting either a function instance, table instance, memory instance, tag instances, or global instances in the shared store.

externval ::= ∣ ∣ ∣ ∣ func funcaddr table tableaddr mem memaddr global globaladdr tag tagaddr

4.2.14.1. Conventions

The following auxiliary notation is defined for sequences of external values. It filters out entries of a specific kind in an order-preserving fashion:

$funcs (externval^{*}) = [funcaddr ∣ (func funcaddr) \in externval^{*}]$
$tables (externval^{*}) = [tableaddr ∣ (table tableaddr) \in externval^{*}]$
$mems (externval^{*}) = [memaddr ∣ (mem memaddr) \in externval^{*}]$
$globals (externval^{*}) = [globaladdr ∣ (global globaladdr) \in externval^{*}]$
$tags (externval^{*}) = [tagaddr ∣ (tag tagaddr) \in externval^{*}]$

4.2.15. Aggregate Instances

A structure instance is the runtime representation of a heap object allocated from a structure type. Likewise, an array instance is the runtime representation of a heap object allocated from an array type. Both record their respective defined type and hold a vector of the values of their fields.

structinst arrayinst fieldval packedval ::= ::= ::= ::= {type deftype, fields vec (fieldval)} {type deftype, fields vec (fieldval)} val ∣ packedval i8.pack u8 ∣ i16.pack u16

4.2.15.1. Conventions

Conversion of a regular value to a field value is defined as follows:

$pack_{valtype} (val) pack_{packedtype} (i32 . const i) = = val packedtype . pack (wrap_{32, ∣ packedtype ∣} (i))$
The inverse conversion of a field value to a regular value is defined as follows:

$unpack_{valtype} (val) unpack_{packedtype}^{sx} (packedtype . pack i) = = val i32 . const (extend_{∣ packedtype ∣, 32}^{sx} (i))$

4.2.16. Exception Instances

An exception instance is the runtime representation of an _exception_ produced by a $throw$ instruction. It holds the address of the respective tag and the argument values.

exninst ::= {tag tagaddr, fields vec (val)}

4.2.17. Stack

Besides the store, most instructions interact with an implicit stack. The stack contains the following kinds of entries:

Values: the operands of instructions.
Labels: active structured control instructions that can be targeted by branches.
Activations: the call frames of active function calls.
Handlers: active exception handlers.

These entries can occur on the stack in any order during the execution of a program. Stack entries are described by abstract syntax as follows.

Note

It is possible to model the WebAssembly semantics using separate stacks for operands, control constructs, and calls. However, because the stacks are interdependent, additional book keeping about associated stack heights would be required. For the purpose of this specification, an interleaved representation is simpler.

4.2.17.1. Values

Values are represented by themselves.

4.2.17.2. Labels

Labels carry an argument arity $n$ and their associated branch target, which is expressed syntactically as an instruction sequence:

label ::= label_{n} {instr^{*}}

Intuitively, $instr^{*}$ is the continuation to execute when the branch is taken, in place of the original control construct.

Note

For example, a loop label has the form

label_{n} {loop \dots end}

When performing a branch to this label, this executes the loop, effectively restarting it from the beginning. Conversely, a simple block label has the form

label_{n} {ϵ}

When branching, the empty continuation ends the targeted block, such that execution can proceed with consecutive instructions.

4.2.17.3. Activation Frames

Activation frames carry the return arity $n$ of the respective function, hold the values of its locals (including arguments) in the order corresponding to their static local indices, and a reference to the function’s own module instance:

frame framestate ::= ::= frame_{n} {framestate} {locals (val^{?})^{*}, module moduleinst}

Locals may be uninitialized, in which case they are empty. Locals are mutated by respective variable instructions.

4.2.17.4. Exception Handlers

Exception handlers are installed by $try_table$ instructions and record the corresponding list of catch clauses:

handler ::= handler_{n} {catch^{*}}

The handlers on the stack are searched when an exception is thrown.

4.2.17.5. Conventions

The meta variable $L$ ranges over labels where clear from context.
The meta variable $F$ ranges over frame states where clear from context.
The meta variable $H$ ranges over exception handlers where clear from context.
The following auxiliary definition takes a block type and looks up the instruction type that it denotes in the current frame:

instrtype_{S; F} (typeidx) instrtype_{S; F} ([valtype^{?}]) = = functype [] \to [valtype^{?}] (if expand (F . module . types [typeidx]) = func functype)

4.2.18. Administrative Instructions

Note

This section is only relevant for the formal notation.

In order to express the reduction of traps, calls, exception handling, and control instructions, the syntax of instructions is extended to include the following administrative instructions:

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots trap ref . i31 u31 ref . struct structaddr ref . array arrayaddr ref . func funcaddr ref . exn exnaddr ref . host hostaddr ref . extern ref invoke funcaddr return_invoke funcaddr label_{n} {instr^{*}} instr^{*} end handler_{n} {catch^{*}} instr^{*} end frame_{n} {framestate} instr^{*} end

The $trap$ instruction represents the occurrence of a trap. Traps are bubbled up through nested instruction sequences, ultimately reducing the entire program to a single $trap$ instruction, signalling abrupt termination.

The $ref . i31$ instruction represents unboxed scalar reference values, $ref . struct$ and $ref . array$ represent structure and array references, respectively, $ref . func$ represents function references, and $ref . exn$ represents exception references. Similarly, $ref . host$ represents host references and $ref . extern$ represents any externalized reference.

The $invoke$ instruction represents the imminent invocation of a function instance, identified by its address. It unifies the handling of different forms of calls. Analogously, $return_invoke$ represents the imminent tail invocation of a function instance.

The $label$ , $frame$ , and $handler$ instructions model labels, frames, and active exception handlers, respectively, “on the stack”. Moreover, the administrative syntax maintains the nesting structure of the original structured control instruction or function body and their instruction sequences with an $end$ marker. That way, the end of the inner instruction sequence is known when part of an outer sequence.

Note

For example, the reduction rule for $block$ is:

block [t^{n}] instr^{*} end ↪ label_{n} {ϵ} instr^{*} end

This replaces the block with a label instruction, which can be interpreted as “pushing” the label on the stack. When $end$ is reached, i.e., the inner instruction sequence has been reduced to the empty sequence – or rather, a sequence of $n$ $const$ instructions representing the resulting values – then the $label$ instruction is eliminated courtesy of its own reduction rule:

label_{m} {instr^{*}} val^{n} end ↪ val^{n}

This can be interpreted as removing the label from the stack and only leaving the locally accumulated operand values.

4.2.18.1. Block Contexts

In order to specify the reduction of branches, the following syntax of block contexts is defined, indexed by the count $k$ of labels surrounding a hole $[_]$ that marks the place where the next step of computation is taking place:

B^{k} C^{0} C^{k + 1} ::= ::= ::= val B^{k} ∣ B^{k} instr ∣ handler_{n} {catch^{*}} B^{k} end ∣ C^{k} [_] label_{n} {instr^{*}} B^{k} end

This definition allows to index active labels surrounding a branch or return instruction.

Note

For example, the reduction of a simple branch can be defined as follows:

label_{0} {instr^{*}} B^{l} [br l] end ↪ instr^{*}

Here, the hole $[_]$ of the context is instantiated with a branch instruction. When a branch occurs, this rule replaces the target label and associated instruction sequence with the label’s continuation. The selected label is identified through the label index $l$ , which corresponds to the number of surrounding $label$ instructions that must be hopped over – which is exactly the count encoded in the index of a block context.

4.2.18.2. Throw Contexts

In order to specify the reduction of $try_table$ blocks, the following syntax of throw contexts is defined, as well as associated structural rules:

T ::= ∣ ∣ ∣ [_] val^{*} T instr^{*} label_{n} {instr^{*}} T end frame_{n} {F} T end

Throw contexts allow matching the program context around a throw instruction up to the innermost enclosing exception handler, if one exists.

Note

Contrary to block contexts, throw contexts do not skip over handlers.

4.2.18.3. Configurations

A configuration consists of the current store and an executing thread.

A thread is a computation over instructions that operates relative to the state of a current frame referring to the module instance in which the computation runs, i.e., where the current function originates from.

config thread ::= ::= store; thread framestate; instr^{*}

Note

The current version of WebAssembly is single-threaded, but configurations with multiple threads may be supported in the future.

4.2.18.4. Evaluation Contexts

Finally, the following definition of evaluation context and associated structural rules enable reduction inside instruction sequences and administrative forms as well as the propagation of traps:

E ::= [_] ∣ val^{*} E instr^{*} ∣ label_{n} {instr^{*}} E end ∣ handler_{n} {catch^{*}} E end

S; F; E [instr^{*}] S; F; frame_{n} {F^{'}} instr^{*} end S; F; frame_{n} {F^{'}} trap end ↪ ↪ ↪ S^{'}; F^{'}; E [instr^{'}^{*}] (if S; F; instr^{*} ↪ S^{'}; F^{'}; instr^{'}^{*}) S^{'}; F; frame_{n} {F^{''}} instr^{' *} end (if S; F^{'}; instr^{*} ↪ S^{'}; F^{''}; instr^{'}^{*}) 1 e x] S; F; E [trap] S; F; trap ↪ S; F; trap (if E \neq = [_])

Reduction terminates when a thread’s instruction sequence has been reduced to a result, that is, either a sequence of values, to an uncaught exception, or to a $trap$ .

Note

The restriction on evaluation contexts rules out contexts like $[_]$ and $ϵ [_] ϵ$ for which $E [trap] = trap$ .

For an example of reduction under evaluation contexts, consider the following instruction sequence.

(f64 . const x_{1}) (f64 . const x_{2}) f64 . neg (f64 . const x_{3}) f64 . add f64 . mul

This can be decomposed into $E [(f64 . const x_{2}) f64 . neg]$ where

[E = (f64 . const x_{1}) [_] (f64 . const x_{3}) f64 . add f64 . mul

Moreover, this is the only possible choice of evaluation context where the contents of the hole matches the left-hand side of a reduction rule.

4.3. Numerics

Numeric primitives are defined in a generic manner, by operators indexed over a bit width $N$ .

Some operators are non-deterministic, because they can return one of several possible results (such as different NaN values). Technically, each operator thus returns a set of allowed values. For convenience, deterministic results are expressed as plain values, which are assumed to be identified with a respective singleton set.

Some operators are partial, because they are not defined on certain inputs. Technically, an empty set of results is returned for these inputs.

In formal notation, each operator is defined by equational clauses that apply in decreasing order of precedence. That is, the first clause that is applicable to the given arguments defines the result. In some cases, similar clauses are combined into one by using the notation $\pm$ or $\mp$ . When several of these placeholders occur in a single clause, then they must be resolved consistently: either the upper sign is chosen for all of them or the lower sign.

Note

For example, the $fcopysign$ operator is defined as follows:

fcopysign_{N} (\pm p_{1}, \pm p_{2}) fcopysign_{N} (\pm p_{1}, \mp p_{2}) = = \pm p_{1} \mp p_{1}

This definition is to be read as a shorthand for the following expansion of each clause into two separate ones:

fcopysign_{N} (+ p_{1}, + p_{2}) fcopysign_{N} (- p_{1}, - p_{2}) fcopysign_{N} (+ p_{1}, - p_{2}) fcopysign_{N} (- p_{1}, + p_{2}) = = = = + p_{1} - p_{1} - p_{1} + p_{1}

Numeric operators are lifted to input sequences by applying the operator element-wise, returning a sequence of results. When there are multiple inputs, they must be of equal length.

o p (c_{1}^{n}, \dots, c_{k}^{n}) = o p (c_{1}^{n} [0], \dots, c_{k}^{n} [0]) \dots o p (c_{1}^{n} [n - 1], \dots, c_{k}^{n} [n - 1])

Note

For example, the unary operator $fabs$ , when given a sequence of floating-point values, return a sequence of floating-point results:

fabs_{N} (z^{n}) = fabs_{N} (z [0]) \dots fabs_{N} (z [n])

The binary operator $iadd$ , when given two sequences of integers of the same length, $n$ , return a sequence of integer results:

iadd_{N} (i_{1}^{n}, i_{2}^{n}) = iadd_{N} (i_{1} [0], i_{2} [0]) \dots iadd_{N} (i_{1} [n], i_{2} [n])

Conventions:

The meta variable $d$ is used to range over single bits.
The meta variable $p$ is used to range over (signless) magnitudes of floating-point values, including $nan$ and $\infty$ .
The meta variable $q$ is used to range over (signless) rational magnitudes, excluding $nan$ or $\infty$ .
The notation $f^{- 1}$ denotes the inverse of a bijective function $f$ .
Truncation of rational values is written $trunc (\pm q)$ , with the usual mathematical definition:

$trunc (\pm q) = \pm i (if i \in N \land + q - 1 < i \leq + q)$

Saturation of integers is written $sat_u_{N} (i)$ and $sat_s_{N} (i)$ . The arguments to these two functions range over arbitrary signed integers.
- Unsigned saturation, $sat_u_{N} (i)$ clamps $i$ to between $0$ and $2^{N} - 1$ :
  
  $sat_u_{N} (i) sat_u_{N} (i) sat_u_{N} (i) = = = 0 2^{N} - 1 i (if i < 0) (if i > 2^{N} - 1) (otherwise)$
- Signed saturation, $sat_s_{N} (i)$ clamps $i$ to between $- 2^{N - 1}$ and $2^{N - 1} - 1$ :
$sat_s_{N} (i) sat_s_{N} (i) sat_s_{N} (i) = = = - 2^{N - 1} 2^{N - 1} - 1 i (if i < - 2^{N - 1}) (if i > 2^{N - 1} - 1) (otherwise)$

4.3.1. Representations

Numbers and numeric vectors have an underlying binary representation as a sequence of bits:

bits_{i N} (i) bits_{f N} (z) bits_{v N} (i) = = = ibits_{N} (i) fbits_{N} (z) ibits_{N} (i)

The first case of these applies to representations of both integer value types and packed types.

Each of these functions is a bijection, hence they are invertible.

4.3.1.1. Integers

Integers are represented as base two unsigned numbers:

ibits_{N} (i) = d_{N - 1} \dots d_{0} (i = 2^{N - 1} \cdot d_{N - 1} + \dots + 2^{0} \cdot d_{0})

Boolean operators like $\land$ , $\lor$ , or $⊻$ are lifted to bit sequences of equal length by applying them pointwise.

4.3.1.2. Floating-Point

Floating-point values are represented in the respective binary format defined by [IEEE-754-2019] (Section 3.4):

fbits_{N} (\pm (1 + m \cdot 2^{- M}) \cdot 2^{e}) fbits_{N} (\pm (0 + m \cdot 2^{- M}) \cdot 2^{e}) fbits_{N} (\pm \infty) fbits_{N} (\pm nan (n)) fsign (+) fsign (-) = = = = = = fsign (\pm) ibits_{E} (e + fbias_{N}) ibits_{M} (m) fsign (\pm) (0)^{E} ibits_{M} (m) fsign (\pm) (1)^{E} (0)^{M} fsign (\pm) (1)^{E} ibits_{M} (n) 1 e x] fbias_{N} 01 = 2^{E - 1} - 1

where $M = signif (N)$ and $E = expon (N)$ .

4.3.1.3. Vectors

Numeric vectors of type $v N$ have the same underlying representation as an $i N$ . They can also be interpreted as a sequence of numeric values packed into a $v N$ with a particular $shape$ $t x M$ , provided that $N = ∣t∣ \cdot M$ .

lanes_{t x M} (c) = c_{0} \dots c_{M - 1} (where \land \land w b^{*} c_{i} = = = ∣ t ∣/8 bytes_{i N} (c) bytes_{t}^{- 1} (b^{*} [i \cdot w : w]))

This function is a bijection on $i N$ , hence it is invertible.

4.3.1.4. Storage

When a number is stored into memory, it is converted into a sequence of bytes in little endian byte order:

bytes_{t} (i) littleendian (d^{8} d^{'}^{*}) = = littleendian (bits_{t} (i)) 1 e x] littleendian (ϵ) littleendian (d^{'}^{*}) ibits_{8}^{- 1} (d^{8}) = ϵ

Again these functions are invertible bijections.

4.3.2. Integer Operations

4.3.2.1. Sign Interpretation

Integer operators are defined on $i N$ values. Operators that use a signed interpretation convert the value using the following definition, which takes the two’s complement when the value lies in the upper half of the value range (i.e., its most significant bit is $1$ ):

signed_{N} (i) signed_{N} (i) = = i i - 2^{N} (0 \leq i < 2^{N - 1}) (2^{N - 1} \leq i < 2^{N})

This function is bijective, and hence invertible.

4.3.2.2. Boolean Interpretation

The integer result of predicates – i.e., tests and relational operators – is defined with the help of the following auxiliary function producing the value $1$ or $0$ depending on a condition.

bool (C) bool (C) = = 10 (if C) (otherwise)

4.3.2.3. $iadd_{N} (i_{1}, i_{2})$

Return the result of adding $i_{1}$ and $i_{2}$ modulo $2^{N}$ .

iadd_{N} (i_{1}, i_{2}) = (i_{1} + i_{2}) mod 2^{N}

4.3.2.4. $isub_{N} (i_{1}, i_{2})$

Return the result of subtracting $i_{2}$ from $i_{1}$ modulo $2^{N}$ .

isub_{N} (i_{1}, i_{2}) = (i_{1} - i_{2} + 2^{N}) mod 2^{N}

4.3.2.5. $imul_{N} (i_{1}, i_{2})$

Return the result of multiplying $i_{1}$ and $i_{2}$ modulo $2^{N}$ .

imul_{N} (i_{1}, i_{2}) = (i_{1} \cdot i_{2}) mod 2^{N}

4.3.2.6. $idiv_u_{N} (i_{1}, i_{2})$

If $i_{2}$ is $0$ , then the result is undefined.
Else, return the result of dividing $i_{1}$ by $i_{2}$ , truncated toward zero.

idiv_u_{N} (i_{1}, 0) idiv_u_{N} (i_{1}, i_{2}) = = {} trunc (i_{1} / i_{2})

Note

This operator is partial.

4.3.2.7. $idiv_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
If $j_{2}$ is $0$ , then the result is undefined.
Else if $j_{1}$ divided by $j_{2}$ is $2^{N - 1}$ , then the result is undefined.
Else, return the result of dividing $j_{1}$ by $j_{2}$ , truncated toward zero.

idiv_s_{N} (i_{1}, 0) idiv_s_{N} (i_{1}, i_{2}) idiv_s_{N} (i_{1}, i_{2}) = = = {} {} (if signed_{N} (i_{1}) / signed_{N} (i_{2}) = 2^{N - 1}) signed_{N}^{- 1} (trunc (signed_{N} (i_{1}) / signed_{N} (i_{2})))

Note

This operator is partial. Besides division by $0$ , the result of $(- 2^{N - 1}) / (- 1) = + 2^{N - 1}$ is not representable as an $N$ -bit signed integer.

4.3.2.8. $irem_u_{N} (i_{1}, i_{2})$

If $i_{2}$ is $0$ , then the result is undefined.
Else, return the remainder of dividing $i_{1}$ by $i_{2}$ .

irem_u_{N} (i_{1}, 0) irem_u_{N} (i_{1}, i_{2}) = = {} i_{1} - i_{2} \cdot trunc (i_{1} / i_{2})

Note

This operator is partial.

As long as both operators are defined, it holds that $i_{1} = i_{2} \cdot idiv_u (i_{1}, i_{2}) + irem_u (i_{1}, i_{2})$ .

4.3.2.9. $irem_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
If $i_{2}$ is $0$ , then the result is undefined.
Else, return the remainder of dividing $j_{1}$ by $j_{2}$ , with the sign of the dividend $j_{1}$ .

irem_s_{N} (i_{1}, 0) irem_s_{N} (i_{1}, i_{2}) = = {} signed_{N}^{- 1} (j_{1} - j_{2} \cdot trunc (j_{1} / j_{2})) (where j_{1} = signed_{N} (i_{1}) \land j_{2} = signed_{N} (i_{2}))

Note

This operator is partial.

As long as both operators are defined, it holds that $i_{1} = i_{2} \cdot idiv_s (i_{1}, i_{2}) + irem_s (i_{1}, i_{2})$ .

4.3.2.10. $inot_{N} (i)$

Return the bitwise negation of $i$ .

inot_{N} (i) = ibits_{N}^{- 1} (ibits_{N} (i) ⊻ ibits_{N} (2^{N} - 1))

4.3.2.11. $iand_{N} (i_{1}, i_{2})$

Return the bitwise conjunction of $i_{1}$ and $i_{2}$ .

iand_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (ibits_{N} (i_{1}) \land ibits_{N} (i_{2}))

4.3.2.12. $iandnot_{N} (i_{1}, i_{2})$

Return the bitwise conjunction of $i_{1}$ and the bitwise negation of $i_{2}$ .

iandnot_{N} (i_{1}, i_{2}) = iand_{N} (i_{1}, inot_{N} (i_{2}))

4.3.2.13. $ior_{N} (i_{1}, i_{2})$

Return the bitwise disjunction of $i_{1}$ and $i_{2}$ .

ior_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (ibits_{N} (i_{1}) \lor ibits_{N} (i_{2}))

4.3.2.14. $ixor_{N} (i_{1}, i_{2})$

Return the bitwise exclusive disjunction of $i_{1}$ and $i_{2}$ .

ixor_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (ibits_{N} (i_{1}) ⊻ ibits_{N} (i_{2}))

4.3.2.15. $ishl_{N} (i_{1}, i_{2})$

Let $k$ be $i_{2}$ modulo $N$ .
Return the result of shifting $i_{1}$ left by $k$ bits, modulo $2^{N}$ .

ishl_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (d_{2}^{N - k} 0^{k}) (if ibits_{N} (i_{1}) = d_{1}^{k} d_{2}^{N - k} \land k = i_{2} mod N)

4.3.2.16. $ishr_u_{N} (i_{1}, i_{2})$

Let $k$ be $i_{2}$ modulo $N$ .
Return the result of shifting $i_{1}$ right by $k$ bits, extended with $0$ bits.

ishr_u_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (0^{k} d_{1}^{N - k}) (if ibits_{N} (i_{1}) = d_{1}^{N - k} d_{2}^{k} \land k = i_{2} mod N)

4.3.2.17. $ishr_s_{N} (i_{1}, i_{2})$

Let $k$ be $i_{2}$ modulo $N$ .
Return the result of shifting $i_{1}$ right by $k$ bits, extended with the most significant bit of the original value.

ishr_s_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (d_{0}^{k + 1} d_{1}^{N - k - 1}) (if ibits_{N} (i_{1}) = d_{0} d_{1}^{N - k - 1} d_{2}^{k} \land k = i_{2} mod N)

4.3.2.18. $irotl_{N} (i_{1}, i_{2})$

Let $k$ be $i_{2}$ modulo $N$ .
Return the result of rotating $i_{1}$ left by $k$ bits.

irotl_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (d_{2}^{N - k} d_{1}^{k}) (if ibits_{N} (i_{1}) = d_{1}^{k} d_{2}^{N - k} \land k = i_{2} mod N)

4.3.2.19. $irotr_{N} (i_{1}, i_{2})$

Let $k$ be $i_{2}$ modulo $N$ .
Return the result of rotating $i_{1}$ right by $k$ bits.

irotr_{N} (i_{1}, i_{2}) = ibits_{N}^{- 1} (d_{2}^{k} d_{1}^{N - k}) (if ibits_{N} (i_{1}) = d_{1}^{N - k} d_{2}^{k} \land k = i_{2} mod N)

4.3.2.20. $iclz_{N} (i)$

Return the count of leading zero bits in $i$ ; all bits are considered leading zeros if $i$ is $0$ .

iclz_{N} (i) = k (if ibits_{N} (i) = 0^{k} (1 d^{*})^{?})

4.3.2.21. $ictz_{N} (i)$

Return the count of trailing zero bits in $i$ ; all bits are considered trailing zeros if $i$ is $0$ .

ictz_{N} (i) = k (if ibits_{N} (i) = (d^{*} 1)^{?} 0^{k})

4.3.2.22. $ipopcnt_{N} (i)$

Return the count of non-zero bits in $i$ .

ipopcnt_{N} (i) = k (if ibits_{N} (i) = (0^{*} 1)^{k} 0^{*})

4.3.2.23. $ieqz_{N} (i)$

Return $1$ if $i$ is zero, $0$ otherwise.

ieqz_{N} (i) = bool (i = 0)

4.3.2.24. $ieq_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ equals $i_{2}$ , $0$ otherwise.

ieq_{N} (i_{1}, i_{2}) = bool (i_{1} = i_{2})

4.3.2.25. $ine_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ does not equal $i_{2}$ , $0$ otherwise.

ine_{N} (i_{1}, i_{2}) = bool (i_{1} \neq = i_{2})

4.3.2.26. $ilt_u_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ is less than $i_{2}$ , $0$ otherwise.

ilt_u_{N} (i_{1}, i_{2}) = bool (i_{1} < i_{2})

4.3.2.27. $ilt_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
Return $1$ if $j_{1}$ is less than $j_{2}$ , $0$ otherwise.

ilt_s_{N} (i_{1}, i_{2}) = bool (signed_{N} (i_{1}) < signed_{N} (i_{2}))

4.3.2.28. $igt_u_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ is greater than $i_{2}$ , $0$ otherwise.

igt_u_{N} (i_{1}, i_{2}) = bool (i_{1} > i_{2})

4.3.2.29. $igt_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
Return $1$ if $j_{1}$ is greater than $j_{2}$ , $0$ otherwise.

igt_s_{N} (i_{1}, i_{2}) = bool (signed_{N} (i_{1}) > signed_{N} (i_{2}))

4.3.2.30. $ile_u_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ is less than or equal to $i_{2}$ , $0$ otherwise.

ile_u_{N} (i_{1}, i_{2}) = bool (i_{1} \leq i_{2})

4.3.2.31. $ile_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
Return $1$ if $j_{1}$ is less than or equal to $j_{2}$ , $0$ otherwise.

ile_s_{N} (i_{1}, i_{2}) = bool (signed_{N} (i_{1}) \leq signed_{N} (i_{2}))

4.3.2.32. $ige_u_{N} (i_{1}, i_{2})$

Return $1$ if $i_{1}$ is greater than or equal to $i_{2}$ , $0$ otherwise.

ige_u_{N} (i_{1}, i_{2}) = bool (i_{1} \geq i_{2})

4.3.2.33. $ige_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$ .
Let $j_{2}$ be the signed interpretation of $i_{2}$ .
Return $1$ if $j_{1}$ is greater than or equal to $j_{2}$ , $0$ otherwise.

ige_s_{N} (i_{1}, i_{2}) = bool (signed_{N} (i_{1}) \geq signed_{N} (i_{2}))

4.3.2.34. $iextend M_s_{N} (i)$

Let $j$ be the result of computing $wrap_{N, M} (i)$ .
Return $extend^{s}_{M, N} (j)$ .

iextend M_s_{N} (i) = extend^{s}_{M, N} (wrap_{N, M} (i))

4.3.2.35. $ibitselect_{N} (i_{1}, i_{2}, i_{3})$

Let $j_{1}$ be the bitwise conjunction of $i_{1}$ and $i_{3}$ .
Let $j_{3}^{'}$ be the bitwise negation of $i_{3}$ .
Let $j_{2}$ be the bitwise conjunction of $i_{2}$ and $j_{3}^{'}$ .
Return the bitwise disjunction of $j_{1}$ and $j_{2}$ .

ibitselect_{N} (i_{1}, i_{2}, i_{3}) = ior_{N} (iand_{N} (i_{1}, i_{3}), iand_{N} (i_{2}, inot_{N} (i_{3})))

4.3.2.36. $iabs_{N} (i)$

Let $j$ be the signed interpretation of $i$ .
If $j$ is greater than or equal to $0$ , then return $i$ .
Else return the negation of j, modulo $2^{N}$ .

iabs_{N} (i) iabs_{N} (i) = = i - signed_{N} (i) mod 2^{N} (if signed_{N} (i) \geq 0) (otherwise)

4.3.2.37. $ineg_{N} (i)$

Return the result of negating $i$ , modulo $2^{N}$ .

ineg_{N} (i) = (2^{N} - i) mod 2^{N}

4.3.2.38. $imin_u_{N} (i_{1}, i_{2})$

Return $i_{1}$ if $ilt_u_{N} (i_{1}, i_{2})$ is $1$ , return $i_{2}$ otherwise.

imin_u_{N} (i_{1}, i_{2}) imin_u_{N} (i_{1}, i_{2}) = = i_{1} i_{2} (if ilt_u_{N} (i_{1}, i_{2}) = 1) (otherwise)

4.3.2.39. $imin_s_{N} (i_{1}, i_{2})$

Return $i_{1}$ if $ilt_s_{N} (i_{1}, i_{2})$ is $1$ , return $i_{2}$ otherwise.

imin_s_{N} (i_{1}, i_{2}) imin_s_{N} (i_{1}, i_{2}) = = i_{1} i_{2} (if ilt_s_{N} (i_{1}, i_{2}) = 1) (otherwise)

4.3.2.40. $imax_u_{N} (i_{1}, i_{2})$

Return $i_{1}$ if $igt_u_{N} (i_{1}, i_{2})$ is $1$ , return $i_{2}$ otherwise.

imax_u_{N} (i_{1}, i_{2}) imax_u_{N} (i_{1}, i_{2}) = = i_{1} i_{2} (if igt_u_{N} (i_{1}, i_{2}) = 1) (otherwise)

4.3.2.41. $imax_s_{N} (i_{1}, i_{2})$

Return $i_{1}$ if $igt_s_{N} (i_{1}, i_{2})$ is $1$ , return $i_{2}$ otherwise.

imax_s_{N} (i_{1}, i_{2}) imax_s_{N} (i_{1}, i_{2}) = = i_{1} i_{2} (if igt_s_{N} (i_{1}, i_{2}) = 1) (otherwise)

4.3.2.42. $iadd_sat_u_{N} (i_{1}, i_{2})$

Let $i$ be the result of adding $i_{1}$ and $i_{2}$ .
Return $sat_u_{N} (i)$ .

iadd_sat_u_{N} (i_{1}, i_{2}) = sat_u_{N} (i_{1} + i_{2})

4.3.2.43. $iadd_sat_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$
Let $j_{2}$ be the signed interpretation of $i_{2}$
Let $j$ be the result of adding $j_{1}$ and $j_{2}$ .
Return the value whose signed interpretation is $sat_s_{N} (j)$ .

iadd_sat_s_{N} (i_{1}, i_{2}) = signed_{N}^{- 1} (sat_s_{N} (signed_{N} (i_{1}) + signed_{N} (i_{2})))

4.3.2.44. $isub_sat_u_{N} (i_{1}, i_{2})$

Let $i$ be the result of subtracting $i_{2}$ from $i_{1}$ .
Return $sat_u_{N} (i)$ .

isub_sat_u_{N} (i_{1}, i_{2}) = sat_u_{N} (i_{1} - i_{2})

4.3.2.45. $isub_sat_s_{N} (i_{1}, i_{2})$

Let $j_{1}$ be the signed interpretation of $i_{1}$
Let $j_{2}$ be the signed interpretation of $i_{2}$
Let $j$ be the result of subtracting $j_{2}$ from $j_{1}$ .
Return the value whose signed interpretation is $sat_s_{N} (j)$ .

isub_sat_s_{N} (i_{1}, i_{2}) = signed_{N}^{- 1} (sat_s_{N} (signed_{N} (i_{1}) - signed_{N} (i_{2})))

4.3.2.46. $iavgr_u_{N} (i_{1}, i_{2})$

Let $j$ be the result of adding $i_{1}$ , $i_{2}$ , and $1$ .
Return the result of dividing $j$ by $2$ , truncated toward zero.

iavgr_u_{N} (i_{1}, i_{2}) = trunc ((i_{1} + i_{2} + 1) /2)

4.3.2.47. $iq15mulrsat_s_{N} (i_{1}, i_{2})$

Return the whose signed interpretation is the result of $sat_s_{N} (ishr_s_{N} (i_{1} \cdot i_{2} + 2^{14}, 15))$ .

iq15mulrsat_s_{N} (i_{1}, i_{2}) = signed_{N}^{- 1} (sat_s_{N} (ishr_s_{N} (i_{1} \cdot i_{2} + 2^{14}, 15)))

4.3.3. Floating-Point Operations

Floating-point arithmetic follows the [IEEE-754-2019] standard, with the following qualifications:

All operators use round-to-nearest ties-to-even, except where otherwise specified. Non-default directed rounding attributes are not supported.
Following the recommendation that operators propagate NaN payloads from their operands is permitted but not required.
All operators use “non-stop” mode, and floating-point exceptions are not otherwise observable. In particular, neither alternate floating-point exception handling attributes nor operators on status flags are supported. There is no observable difference between quiet and signalling NaNs.

Note

Some of these limitations may be lifted in future versions of WebAssembly.

4.3.3.1. Rounding

Rounding always is round-to-nearest ties-to-even, in correspondence with [IEEE-754-2019] (Section 4.3.1).

An exact floating-point number is a rational number that is exactly representable as a floating-point number of given bit width $N$ .

A limit number for a given floating-point bit width $N$ is a positive or negative number whose magnitude is the smallest power of $2$ that is not exactly representable as a floating-point number of width $N$ (that magnitude is $2^{128}$ for $N = 32$ and $2^{1024}$ for $N = 64$ ).

A candidate number is either an exact floating-point number or a positive or negative limit number for the given bit width $N$ .

A candidate pair is a pair $z_{1}, z_{2}$ of candidate numbers, such that no candidate number exists that lies between the two.

A real number $r$ is converted to a floating-point value of bit width $N$ as follows:

If $r$ is $0$ , then return $+ 0$ .
Else if $r$ is an exact floating-point number, then return $r$ .
Else if $r$ greater than or equal to the positive limit, then return $+ \infty$ .
Else if $r$ is less than or equal to the negative limit, then return $- \infty$ .
Else if $z_{1}$ and $z_{2}$ are a candidate pair such that $z_{1} < r < z_{2}$ , then:
- If $∣r - z_{1} ∣ < ∣r - z_{2} ∣$ , then let $z$ be $z_{1}$ .
- Else if $∣r - z_{1} ∣ > ∣r - z_{2} ∣$ , then let $z$ be $z_{2}$ .
- Else if $∣r - z_{1} ∣ = ∣r - z_{2} ∣$ and the significand of $z_{1}$ is even, then let $z$ be $z_{1}$ .
- Else, let $z$ be $z_{2}$ .
If $z$ is $0$ , then:
- If $r < 0$ , then return $- 0$ .
- Else, return $+ 0$ .
Else if $z$ is a limit number, then:
- If $r < 0$ , then return $- \infty$ .
- Else, return $+ \infty$ .
Else, return $z$ .

float_{N} (0) float_{N} (r) float_{N} (r) float_{N} (r) float_{N} (r) closest_{N} (r, z_{1}, z_{2}) closest_{N} (r, z_{1}, z_{2}) closest_{N} (r, z_{1}, z_{2}) rectify_{N} (r, 0) rectify_{N} (r, 0) rectify_{N} (r, z) = = = = = = = = = = = + 0 r + \infty - \infty closest_{N} (r, z_{1}, z_{2}) rectify_{N} (r, z_{2}) rectify_{N} (r, z_{1}) rectify_{N} (r, z_{2}) + 0 (r \geq 0) - 0 (r < 0) z (if r \in exact_{N}) (if r \geq + limit_{N}) (if r \leq - limit_{N}) (if z_{1} < r < z_{2} \land (z_{1}, z_{2}) \in candidatepair_{N}) 1 e x] closest_{N} (r, z_{1}, z_{2}) (if ∣ r - z_{1} ∣ > ∣ r - z_{2} ∣) (if ∣ r - z_{1} ∣ = ∣ r - z_{2} ∣ \land even_{N} (z_{1})) (if ∣ r - z_{1} ∣ = ∣ r - z_{2} ∣ \land even_{N} (z_{2})) 1 e x] rectify_{N} (r, \pm limit_{N}) = = rectify_{N} (r, z_{1}) \pm \infty (if ∣ r - z_{1} ∣ < ∣ r - z_{2} ∣)

where:

exact_{N} limit_{N} candidate_{N} candidatepair_{N} even_{N} (\pm limit_{N}) = = = = \Leftrightarrow f N \cap Q 2^{2^{expon (N) - 1}} exact_{N} \cup {+ limit_{N}, - limit_{N}} {(z_{1}, z_{2}) \in candidate_{N}^{2} ∣ z_{1} < z_{2} \land \forall z \in candidate_{N}, z \leq z_{1} \lor z \geq z_{2}} 1 e x] even_{N} ((d + m \cdot 2^{- M}) \cdot 2^{e}) true \Leftrightarrow m mod 2 = 0

4.3.3.2. NaN Propagation

When the result of a floating-point operator other than $fneg$ , $fabs$ , or $fcopysign$ is a NaN, then its sign is non-deterministic and the payload is computed as follows:

If the payload of all NaN inputs to the operator is canonical (including the case that there are no NaN inputs), then the payload of the output is canonical as well.
Otherwise the payload is picked non-deterministically among all arithmetic NaNs; that is, its most significant bit is $1$ and all others are unspecified.
In the deterministic profile, however, a positive canonical NaNs is reliably produced in the latter case.

The non-deterministic result is expressed by the following auxiliary function producing a set of allowed outputs from a set of inputs:

^{[! DET]}^{[! DET]} nans_{N} {z^{*}} nans_{N} {z^{*}} nans_{N} {z^{*}} = = = {+ nan (canon_{N})} {+ nan (n), - nan (n) ∣ n = canon_{N}} {+ nan (n), - nan (n) ∣ n \geq canon_{N}} (if {z^{*}} \subseteq {+ nan (canon_{N}), - nan (canon_{N})} (if {z^{*}} \neq \subseteq {+ nan (canon_{N}), - nan (canon_{N})}

4.3.3.3. $fadd_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities of opposite signs, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities of equal sign, then return that infinity.
Else if either $z_{1}$ or $z_{2}$ is an infinity, then return that infinity.
Else if both $z_{1}$ and $z_{2}$ are zeroes of opposite sign, then return positive zero.
Else if both $z_{1}$ and $z_{2}$ are zeroes of equal sign, then return that zero.
Else if either $z_{1}$ or $z_{2}$ is a zero, then return the other operand.
Else if both $z_{1}$ and $z_{2}$ are values with the same magnitude but opposite signs, then return positive zero.
Else return the result of adding $z_{1}$ and $z_{2}$ , rounded to the nearest representable value.

fadd_{N} (\pm nan (n), z_{2}) fadd_{N} (z_{1}, \pm nan (n)) fadd_{N} (\pm \infty, \mp \infty) fadd_{N} (\pm \infty, \pm \infty) fadd_{N} (z_{1}, \pm \infty) fadd_{N} (\pm \infty, z_{2}) fadd_{N} (\pm 0, \mp 0) fadd_{N} (\pm 0, \pm 0) fadd_{N} (z_{1}, \pm 0) fadd_{N} (\pm 0, z_{2}) fadd_{N} (\pm q, \mp q) fadd_{N} (z_{1}, z_{2}) = = = = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} nans_{N} {} \pm \infty \pm \infty \pm \infty + 0 \pm 0 z_{1} z_{2} + 0 float_{N} (z_{1} + z_{2})

4.3.3.4. $fsub_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities of equal signs, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities of opposite sign, then return $z_{1}$ .
Else if $z_{1}$ is an infinity, then return that infinity.
Else if $z_{2}$ is an infinity, then return that infinity negated.
Else if both $z_{1}$ and $z_{2}$ are zeroes of equal sign, then return positive zero.
Else if both $z_{1}$ and $z_{2}$ are zeroes of opposite sign, then return $z_{1}$ .
Else if $z_{2}$ is a zero, then return $z_{1}$ .
Else if $z_{1}$ is a zero, then return $z_{2}$ negated.
Else if both $z_{1}$ and $z_{2}$ are the same value, then return positive zero.
Else return the result of subtracting $z_{2}$ from $z_{1}$ , rounded to the nearest representable value.

fsub_{N} (\pm nan (n), z_{2}) fsub_{N} (z_{1}, \pm nan (n)) fsub_{N} (\pm \infty, \pm \infty) fsub_{N} (\pm \infty, \mp \infty) fsub_{N} (z_{1}, \pm \infty) fsub_{N} (\pm \infty, z_{2}) fsub_{N} (\pm 0, \pm 0) fsub_{N} (\pm 0, \mp 0) fsub_{N} (z_{1}, \pm 0) fsub_{N} (\pm 0, \pm q_{2}) fsub_{N} (\pm q, \pm q) fsub_{N} (z_{1}, z_{2}) = = = = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} nans_{N} {} \pm \infty \mp \infty \pm \infty + 0 \pm 0 z_{1} \mp q_{2} + 0 float_{N} (z_{1} - z_{2})

Note

Up to the non-determinism regarding NaNs, it always holds that $fsub_{N} (z_{1}, z_{2}) = fadd_{N} (z_{1}, fneg_{N} (z_{2}))$ .

4.3.3.5. $fmul_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if one of $z_{1}$ and $z_{2}$ is a zero and the other an infinity, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities of equal sign, then return positive infinity.
Else if both $z_{1}$ and $z_{2}$ are infinities of opposite sign, then return negative infinity.
Else if either $z_{1}$ or $z_{2}$ is an infinity and the other a value with equal sign, then return positive infinity.
Else if either $z_{1}$ or $z_{2}$ is an infinity and the other a value with opposite sign, then return negative infinity.
Else if both $z_{1}$ and $z_{2}$ are zeroes of equal sign, then return positive zero.
Else if both $z_{1}$ and $z_{2}$ are zeroes of opposite sign, then return negative zero.
Else return the result of multiplying $z_{1}$ and $z_{2}$ , rounded to the nearest representable value.

fmul_{N} (\pm nan (n), z_{2}) fmul_{N} (z_{1}, \pm nan (n)) fmul_{N} (\pm \infty, \pm 0) fmul_{N} (\pm \infty, \mp 0) fmul_{N} (\pm 0, \pm \infty) fmul_{N} (\pm 0, \mp \infty) fmul_{N} (\pm \infty, \pm \infty) fmul_{N} (\pm \infty, \mp \infty) fmul_{N} (\pm q_{1}, \pm \infty) fmul_{N} (\pm q_{1}, \mp \infty) fmul_{N} (\pm \infty, \pm q_{2}) fmul_{N} (\pm \infty, \mp q_{2}) fmul_{N} (\pm 0, \pm 0) fmul_{N} (\pm 0, \mp 0) fmul_{N} (z_{1}, z_{2}) = = = = = = = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} + \infty - \infty + \infty - \infty + \infty - \infty + 0 - 0 float_{N} (z_{1} \cdot z_{2})

4.3.3.6. $fdiv_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if both $z_{1}$ and $z_{2}$ are infinities, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if $z_{1}$ is an infinity and $z_{2}$ a value with equal sign, then return positive infinity.
Else if $z_{1}$ is an infinity and $z_{2}$ a value with opposite sign, then return negative infinity.
Else if $z_{2}$ is an infinity and $z_{1}$ a value with equal sign, then return positive zero.
Else if $z_{2}$ is an infinity and $z_{1}$ a value with opposite sign, then return negative zero.
Else if $z_{1}$ is a zero and $z_{2}$ a value with equal sign, then return positive zero.
Else if $z_{1}$ is a zero and $z_{2}$ a value with opposite sign, then return negative zero.
Else if $z_{2}$ is a zero and $z_{1}$ a value with equal sign, then return positive infinity.
Else if $z_{2}$ is a zero and $z_{1}$ a value with opposite sign, then return negative infinity.
Else return the result of dividing $z_{1}$ by $z_{2}$ , rounded to the nearest representable value.

fdiv_{N} (\pm nan (n), z_{2}) fdiv_{N} (z_{1}, \pm nan (n)) fdiv_{N} (\pm \infty, \pm \infty) fdiv_{N} (\pm \infty, \mp \infty) fdiv_{N} (\pm 0, \pm 0) fdiv_{N} (\pm 0, \mp 0) fdiv_{N} (\pm \infty, \pm q_{2}) fdiv_{N} (\pm \infty, \mp q_{2}) fdiv_{N} (\pm q_{1}, \pm \infty) fdiv_{N} (\pm q_{1}, \mp \infty) fdiv_{N} (\pm 0, \pm q_{2}) fdiv_{N} (\pm 0, \mp q_{2}) fdiv_{N} (\pm q_{1}, \pm 0) fdiv_{N} (\pm q_{1}, \mp 0) fdiv_{N} (z_{1}, z_{2}) = = = = = = = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} + \infty - \infty + 0 - 0 + 0 - 0 + \infty - \infty float_{N} (z_{1} / z_{2})

4.3.3.7. $fma_{N} (z_{1}, z_{2}, z_{3})$

The function $fma$ is the same as fusedMultiplyAdd defined by [IEEE-754-2019] (Section 5.4.1). It computes $(z_{1} \cdot z_{2}) + z_{3}$ as if with unbounded range and precision, rounding only once for the final result.

If either $z_{1}$ or $z_{2}$ or $z_{3}$ is a NaN, return an element of $nans_{N} z_{1}, z_{2}, z_{3}$ .
Else if either $z_{1}$ or $z_{2}$ is a zero and the other is an infinity, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ or $z_{2}$ are infinities of equal sign, and $z_{3}$ is a negative infinity, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ or $z_{2}$ are infinities of opposite sign, and $z_{3}$ is a positive infinity, then return an element of $nans_{N} {}$ .
Else if either $z_{1}$ or $z_{2}$ is an infinity and the other is a value of the same sign, and $z_{3}$ is a negative infinity, then return an element of $nans_{N} {}$ .
Else if either $z_{1}$ or $z_{2}$ is an infinity and the other is a value of the opposite sign, and $z_{3}$ is a positive infinity, then return an element of $nans_{N} {}$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes of the same sign and $z_{3}$ is a zero, then return positive zero.
Else if both $z_{1}$ and $z_{2}$ are zeroes of the opposite sign and $z_{3}$ is a positive zero, then return positive zero.
Else if both $z_{1}$ and $z_{2}$ are zeroes of the opposite sign and $z_{3}$ is a negative zero, then return negative zero.
Else return the result of multiplying $z_{1}$ and $z_{2}$ , adding $z_{3}$ to the intermediate, and the final result ref:rounded <aux-ieee> to the nearest representable value.

fma_{N} (\pm nan (n), z_{2}, z_{3}) fma_{N} (z_{1}, \pm nan (n), z_{3}) fma_{N} (z_{1}, z_{2}, \pm nan (n)) fma_{N} (\pm \infty, \pm 0, z_{3}) fma_{N} (\pm \infty, \mp 0, z_{3}) fma_{N} (\pm \infty, \pm \infty, - \infty) fma_{N} (\pm \infty, \mp \infty, + \infty) fma_{N} (\pm q_{1}, \pm \infty, - \infty) fma_{N} (\pm q_{1}, \mp \infty, + \infty) fma_{N} (\pm \infty, \pm q_{1}, - \infty) fma_{N} (\mp \infty, \pm q_{1}, + \infty) fma_{N} (\pm 0, \pm 0, \mp 0) fma_{N} (\pm 0, \pm 0, \pm 0) fma_{N} (\pm 0, \mp 0, + 0) fma_{N} (\pm 0, \mp 0, - 0) fma_{N} (z_{1}, z_{2}, z_{3}) = = = = = = = = = = = = = = = = nans_{N} {\pm nan (n), z_{2}, z_{3}} nans_{N} {\pm nan (n), z_{1}, z_{3}} nans_{N} {\pm nan (n), z_{1}, z_{2}} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} nans_{N} {} + 0 + 0 + 0 - 0 float_{N} (z_{1} \cdot z_{2} + z_{3})

4.3.3.8. $fmin_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if either $z_{1}$ or $z_{2}$ is a negative infinity, then return negative infinity.
Else if either $z_{1}$ or $z_{2}$ is a positive infinity, then return the other value.
Else if both $z_{1}$ and $z_{2}$ are zeroes of opposite signs, then return negative zero.
Else return the smaller value of $z_{1}$ and $z_{2}$ .

fmin_{N} (\pm nan (n), z_{2}) fmin_{N} (z_{1}, \pm nan (n)) fmin_{N} (+ \infty, z_{2}) fmin_{N} (- \infty, z_{2}) fmin_{N} (z_{1}, + \infty) fmin_{N} (z_{1}, - \infty) fmin_{N} (\pm 0, \mp 0) fmin_{N} (z_{1}, z_{2}) fmin_{N} (z_{1}, z_{2}) = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} z_{2} - \infty z_{1} - \infty - 0 z_{1} z_{2} (if z_{1} \leq z_{2}) (if z_{2} \leq z_{1})

4.3.3.9. $fmax_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return an element of $nans_{N} {z_{1}, z_{2}}$ .
Else if either $z_{1}$ or $z_{2}$ is a positive infinity, then return positive infinity.
Else if either $z_{1}$ or $z_{2}$ is a negative infinity, then return the other value.
Else if both $z_{1}$ and $z_{2}$ are zeroes of opposite signs, then return positive zero.
Else return the larger value of $z_{1}$ and $z_{2}$ .

fmax_{N} (\pm nan (n), z_{2}) fmax_{N} (z_{1}, \pm nan (n)) fmax_{N} (+ \infty, z_{2}) fmax_{N} (- \infty, z_{2}) fmax_{N} (z_{1}, + \infty) fmax_{N} (z_{1}, - \infty) fmax_{N} (\pm 0, \mp 0) fmax_{N} (z_{1}, z_{2}) fmax_{N} (z_{1}, z_{2}) = = = = = = = = = nans_{N} {\pm nan (n), z_{2}} nans_{N} {\pm nan (n), z_{1}} + \infty z_{2} + \infty z_{1} + 0 z_{1} z_{2} (if z_{1} \geq z_{2}) (if z_{2} \geq z_{1})

4.3.3.10. $fcopysign_{N} (z_{1}, z_{2})$

If $z_{1}$ and $z_{2}$ have the same sign, then return $z_{1}$ .
Else return $z_{1}$ with negated sign.

fcopysign_{N} (\pm p_{1}, \pm p_{2}) fcopysign_{N} (\pm p_{1}, \mp p_{2}) = = \pm p_{1} \mp p_{1}

4.3.3.11. $fabs_{N} (z)$

If $z$ is a NaN, then return $z$ with positive sign.
Else if $z$ is an infinity, then return positive infinity.
Else if $z$ is a zero, then return positive zero.
Else if $z$ is a positive value, then $z$ .
Else return $z$ negated.

fabs_{N} (\pm nan (n)) fabs_{N} (\pm \infty) fabs_{N} (\pm 0) fabs_{N} (\pm q) = = = = + nan (n) + \infty + 0 + q

4.3.3.12. $fneg_{N} (z)$

If $z$ is a NaN, then return $z$ with negated sign.
Else if $z$ is an infinity, then return that infinity negated.
Else if $z$ is a zero, then return that zero negated.
Else return $z$ negated.

fneg_{N} (\pm nan (n)) fneg_{N} (\pm \infty) fneg_{N} (\pm 0) fneg_{N} (\pm q) = = = = \mp nan (n) \mp \infty \mp 0 \mp q

4.3.3.13. $fsqrt_{N} (z)$

If $z$ is a NaN, then return an element of $nans_{N} {z}$ .
Else if $z$ is negative infinity, then return an element of $nans_{N} {}$ .
Else if $z$ is positive infinity, then return positive infinity.
Else if $z$ is a zero, then return that zero.
Else if $z$ has a negative sign, then return an element of $nans_{N} {}$ .
Else return the square root of $z$ .

fsqrt_{N} (\pm nan (n)) fsqrt_{N} (- \infty) fsqrt_{N} (+ \infty) fsqrt_{N} (\pm 0) fsqrt_{N} (- q) fsqrt_{N} (+ q) = = = = = = nans_{N} {\pm nan (n)} nans_{N} {} + \infty \pm 0 nans_{N} {} float_{N} (q)

4.3.3.14. $fceil_{N} (z)$

If $z$ is a NaN, then return an element of $nans_{N} {z}$ .
Else if $z$ is an infinity, then return $z$ .
Else if $z$ is a zero, then return $z$ .
Else if $z$ is smaller than $0$ but greater than $- 1$ , then return negative zero.
Else return the smallest integral value that is not smaller than $z$ .

fceil_{N} (\pm nan (n)) fceil_{N} (\pm \infty) fceil_{N} (\pm 0) fceil_{N} (- q) fceil_{N} (\pm q) = = = = = nans_{N} {\pm nan (n)} \pm \infty \pm 0 - 0 float_{N} (i) (if - 1 < - q < 0) (if \pm q \leq i < \pm q + 1)

4.3.3.15. $ffloor_{N} (z)$

If $z$ is a NaN, then return an element of $nans_{N} {z}$ .
Else if $z$ is an infinity, then return $z$ .
Else if $z$ is a zero, then return $z$ .
Else if $z$ is greater than $0$ but smaller than $1$ , then return positive zero.
Else return the largest integral value that is not larger than $z$ .

ffloor_{N} (\pm nan (n)) ffloor_{N} (\pm \infty) ffloor_{N} (\pm 0) ffloor_{N} (+ q) ffloor_{N} (\pm q) = = = = = nans_{N} {\pm nan (n)} \pm \infty \pm 0 + 0 float_{N} (i) (if 0 < + q < 1) (if \pm q - 1 < i \leq \pm q)

4.3.3.16. $ftrunc_{N} (z)$

If $z$ is a NaN, then return an element of $nans_{N} {z}$ .
Else if $z$ is an infinity, then return $z$ .
Else if $z$ is a zero, then return $z$ .
Else if $z$ is greater than $0$ but smaller than $1$ , then return positive zero.
Else if $z$ is smaller than $0$ but greater than $- 1$ , then return negative zero.
Else return the integral value with the same sign as $z$ and the largest magnitude that is not larger than the magnitude of $z$ .

ftrunc_{N} (\pm nan (n)) ftrunc_{N} (\pm \infty) ftrunc_{N} (\pm 0) ftrunc_{N} (+ q) ftrunc_{N} (- q) ftrunc_{N} (\pm q) = = = = = = nans_{N} {\pm nan (n)} \pm \infty \pm 0 + 0 - 0 float_{N} (\pm i) (if 0 < + q < 1) (if - 1 < - q < 0) (if + q - 1 < i \leq + q)

4.3.3.17. $fnearest_{N} (z)$

If $z$ is a NaN, then return an element of $nans_{N} {z}$ .
Else if $z$ is an infinity, then return $z$ .
Else if $z$ is a zero, then return $z$ .
Else if $z$ is greater than $0$ but smaller than or equal to $0.5$ , then return positive zero.
Else if $z$ is smaller than $0$ but greater than or equal to $- 0.5$ , then return negative zero.
Else return the integral value that is nearest to $z$ ; if two values are equally near, return the even one.

fnearest_{N} (\pm nan (n)) fnearest_{N} (\pm \infty) fnearest_{N} (\pm 0) fnearest_{N} (+ q) fnearest_{N} (- q) fnearest_{N} (\pm q) fnearest_{N} (\pm q) = = = = = = = nans_{N} {\pm nan (n)} \pm \infty \pm 0 + 0 - 0 float_{N} (\pm i) float_{N} (\pm i) (if 0 < + q \leq 0.5) (if - 0.5 \leq - q < 0) (if ∣ i - q ∣ < 0.5) (if ∣ i - q ∣ = 0.5 \land i even)

4.3.3.18. $feq_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $0$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $1$ .
Else if both $z_{1}$ and $z_{2}$ are the same value, then return $1$ .
Else return $0$ .

feq_{N} (\pm nan (n), z_{2}) feq_{N} (z_{1}, \pm nan (n)) feq_{N} (\pm 0, \mp 0) feq_{N} (z_{1}, z_{2}) = = = = 001 bool (z_{1} = z_{2})

4.3.3.19. $fne_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $1$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $0$ .
Else if both $z_{1}$ and $z_{2}$ are the same value, then return $0$ .
Else return $1$ .

fne_{N} (\pm nan (n), z_{2}) fne_{N} (z_{1}, \pm nan (n)) fne_{N} (\pm 0, \mp 0) fne_{N} (z_{1}, z_{2}) = = = = 110 bool (z_{1} \neq = z_{2})

4.3.3.20. $flt_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $0$ .
Else if $z_{1}$ and $z_{2}$ are the same value, then return $0$ .
Else if $z_{1}$ is positive infinity, then return $0$ .
Else if $z_{1}$ is negative infinity, then return $1$ .
Else if $z_{2}$ is positive infinity, then return $1$ .
Else if $z_{2}$ is negative infinity, then return $0$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $0$ .
Else if $z_{1}$ is smaller than $z_{2}$ , then return $1$ .
Else return $0$ .

flt_{N} (\pm nan (n), z_{2}) flt_{N} (z_{1}, \pm nan (n)) flt_{N} (z, z) flt_{N} (+ \infty, z_{2}) flt_{N} (- \infty, z_{2}) flt_{N} (z_{1}, + \infty) flt_{N} (z_{1}, - \infty) flt_{N} (\pm 0, \mp 0) flt_{N} (z_{1}, z_{2}) = = = = = = = = = 00001100 bool (z_{1} < z_{2})

4.3.3.21. $fgt_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $0$ .
Else if $z_{1}$ and $z_{2}$ are the same value, then return $0$ .
Else if $z_{1}$ is positive infinity, then return $1$ .
Else if $z_{1}$ is negative infinity, then return $0$ .
Else if $z_{2}$ is positive infinity, then return $0$ .
Else if $z_{2}$ is negative infinity, then return $1$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $0$ .
Else if $z_{1}$ is larger than $z_{2}$ , then return $1$ .
Else return $0$ .

fgt_{N} (\pm nan (n), z_{2}) fgt_{N} (z_{1}, \pm nan (n)) fgt_{N} (z, z) fgt_{N} (+ \infty, z_{2}) fgt_{N} (- \infty, z_{2}) fgt_{N} (z_{1}, + \infty) fgt_{N} (z_{1}, - \infty) fgt_{N} (\pm 0, \mp 0) fgt_{N} (z_{1}, z_{2}) = = = = = = = = = 00010010 bool (z_{1} > z_{2})

4.3.3.22. $fle_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $0$ .
Else if $z_{1}$ and $z_{2}$ are the same value, then return $1$ .
Else if $z_{1}$ is positive infinity, then return $0$ .
Else if $z_{1}$ is negative infinity, then return $1$ .
Else if $z_{2}$ is positive infinity, then return $1$ .
Else if $z_{2}$ is negative infinity, then return $0$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $1$ .
Else if $z_{1}$ is smaller than or equal to $z_{2}$ , then return $1$ .
Else return $0$ .

fle_{N} (\pm nan (n), z_{2}) fle_{N} (z_{1}, \pm nan (n)) fle_{N} (z, z) fle_{N} (+ \infty, z_{2}) fle_{N} (- \infty, z_{2}) fle_{N} (z_{1}, + \infty) fle_{N} (z_{1}, - \infty) fle_{N} (\pm 0, \mp 0) fle_{N} (z_{1}, z_{2}) = = = = = = = = = 00101101 bool (z_{1} \leq z_{2})

4.3.3.23. $fge_{N} (z_{1}, z_{2})$

If either $z_{1}$ or $z_{2}$ is a NaN, then return $0$ .
Else if $z_{1}$ and $z_{2}$ are the same value, then return $1$ .
Else if $z_{1}$ is positive infinity, then return $1$ .
Else if $z_{1}$ is negative infinity, then return $0$ .
Else if $z_{2}$ is positive infinity, then return $0$ .
Else if $z_{2}$ is negative infinity, then return $1$ .
Else if both $z_{1}$ and $z_{2}$ are zeroes, then return $1$ .
Else if $z_{1}$ is smaller than or equal to $z_{2}$ , then return $1$ .
Else return $0$ .

fge_{N} (\pm nan (n), z_{2}) fge_{N} (z_{1}, \pm nan (n)) fge_{N} (z, z) fge_{N} (+ \infty, z_{2}) fge_{N} (- \infty, z_{2}) fge_{N} (z_{1}, + \infty) fge_{N} (z_{1}, - \infty) fge_{N} (\pm 0, \mp 0) fge_{N} (z_{1}, z_{2}) = = = = = = = = = 00110011 bool (z_{1} \geq z_{2})

4.3.3.24. $fpmin_{N} (z_{1}, z_{2})$

If $z_{2}$ is less than $z_{1}$ then return $z_{2}$ .
Else return $z_{1}$ .

fpmin_{N} (z_{1}, z_{2}) fpmin_{N} (z_{1}, z_{2}) = = z_{2} z_{1} (if flt_{N} (z_{2}, z_{1}) = 1) (otherwise)

4.3.3.25. $fpmax_{N} (z_{1}, z_{2})$

If $z_{1}$ is less than $z_{2}$ then return $z_{2}$ .
Else return $z_{1}$ .

fpmax_{N} (z_{1}, z_{2}) fpmax_{N} (z_{1}, z_{2}) = = z_{2} z_{1} (if flt_{N} (z_{1}, z_{2}) = 1) (otherwise)

4.3.4. Conversions

4.3.4.1. $extend^{u}_{M, N} (i)$

Return $i$ .

extend^{u}_{M, N} (i) = i

Note

In the abstract syntax, unsigned extension just reinterprets the same value.

4.3.4.2. $extend^{s}_{M, N} (i)$

Let $j$ be the signed interpretation of $i$ of size $M$ .
Return the two’s complement of $j$ relative to size $N$ .

extend^{s}_{M, N} (i) = signed_{N}^{- 1} (signed_{M} (i))

4.3.4.3. $wrap_{M, N} (i)$

Return $i$ modulo $2^{N}$ .

wrap_{M, N} (i) = i mod 2^{N}

4.3.4.4. $trunc^{u}_{M, N} (z)$

If $z$ is a NaN, then the result is undefined.
Else if $z$ is an infinity, then the result is undefined.
Else if $z$ is a number and $trunc (z)$ is a value within range of the target type, then return that value.
Else the result is undefined.

trunc^{u}_{M, N} (\pm nan (n)) trunc^{u}_{M, N} (\pm \infty) trunc^{u}_{M, N} (\pm q) trunc^{u}_{M, N} (\pm q) = = = = {} {} trunc (\pm q) {} (if - 1 < trunc (\pm q) < 2^{N}) (otherwise)

Note

This operator is partial. It is not defined for NaNs, infinities, or values for which the result is out of range.

4.3.4.5. $trunc^{s}_{M, N} (z)$

If $z$ is a NaN, then the result is undefined.
Else if $z$ is an infinity, then the result is undefined.
If $z$ is a number and $trunc (z)$ is a value within range of the target type, then return that value.
Else the result is undefined.

trunc^{s}_{M, N} (\pm nan (n)) trunc^{s}_{M, N} (\pm \infty) trunc^{s}_{M, N} (\pm q) trunc^{s}_{M, N} (\pm q) = = = = {} {} trunc (\pm q) {} (if - 2^{N - 1} - 1 < trunc (\pm q) < 2^{N - 1}) (otherwise)

Note

This operator is partial. It is not defined for NaNs, infinities, or values for which the result is out of range.

4.3.4.6. $trunc_sat_u_{M, N} (z)$

If $z$ is a NaN, then return $0$ .
Else if $z$ is negative infinity, then return $0$ .
Else if $z$ is positive infinity, then return $2^{N} - 1$ .
Else, return $sat_u_{N} (trunc (z))$ .

trunc_sat_u_{M, N} (\pm nan (n)) trunc_sat_u_{M, N} (- \infty) trunc_sat_u_{M, N} (+ \infty) trunc_sat_u_{M, N} (z) = = = = 00 2^{N} - 1 sat_u_{N} (trunc (z))

4.3.4.7. $trunc_sat_s_{M, N} (z)$

If $z$ is a NaN, then return $0$ .
Else if $z$ is negative infinity, then return $- 2^{N - 1}$ .
Else if $z$ is positive infinity, then return $2^{N - 1} - 1$ .
Else, return the value whose signed interpretation is $sat_s_{N} (trunc (z))$ .

trunc_sat_s_{M, N} (\pm nan (n)) trunc_sat_s_{M, N} (- \infty) trunc_sat_s_{M, N} (+ \infty) trunc_sat_s_{M, N} (z) = = = = 0 - 2^{N - 1} 2^{N - 1} - 1 signed_{N}^{- 1} (sat_s_{N} (trunc (z)))

4.3.4.8. $promote_{M, N} (z)$

If $z$ is a canonical NaN, then return an element of $nans_{N} {}$ (i.e., a canonical NaN of size $N$ ).
Else if $z$ is a NaN, then return an element of $nans_{N} {\pm nan (1)}$ (i.e., any arithmetic NaN of size $N$ ).
Else, return $z$ .

promote_{M, N} (\pm nan (n)) promote_{M, N} (\pm nan (n)) promote_{M, N} (z) = = = nans_{N} {} nans_{N} {+ nan (1)} z (if n = canon_{N}) (otherwise)

4.3.4.9. $demote_{M, N} (z)$

If $z$ is a canonical NaN, then return an element of $nans_{N} {}$ (i.e., a canonical NaN of size $N$ ).
Else if $z$ is a NaN, then return an element of $nans_{N} {\pm nan (1)}$ (i.e., any NaN of size $N$ ).
Else if $z$ is an infinity, then return that infinity.
Else if $z$ is a zero, then return that zero.
Else, return $float_{N} (z)$ .

demote_{M, N} (\pm nan (n)) demote_{M, N} (\pm nan (n)) demote_{M, N} (\pm \infty) demote_{M, N} (\pm 0) demote_{M, N} (\pm q) = = = = = nans_{N} {} nans_{N} {+ nan (1)} \pm \infty \pm 0 float_{N} (\pm q) (if n = canon_{N}) (otherwise)

4.3.4.10. $convert^{u}_{M, N} (i)$

Return $float_{N} (i)$ .

convert^{u}_{M, N} (i) = float_{N} (i)

4.3.4.11. $convert^{s}_{M, N} (i)$

Let $j$ be the signed interpretation of $i$ .
Return $float_{N} (j)$ .

convert^{s}_{M, N} (i) = float_{N} (signed_{M} (i))

4.3.4.12. $reinterpret_{t_{1}, t_{2}} (c)$

Let $d^{*}$ be the bit sequence $bits_{t_{1}} (c)$ .
Return the constant $c^{'}$ for which $bits_{t_{2}} (c^{'}) = d^{*}$ .

reinterpret_{t_{1}, t_{2}} (c) = bits_{t_{2}}^{- 1} (bits_{t_{1}} (c))

4.3.4.13. $narrow^{s}_{M, N} (i)$

Let $j$ be the signed interpretation of $i$ of size $M$ .
Return the value whose signed interpretation is $sat_s_{N} (j)$ .

narrow^{s}_{M, N} (i) = signed_{N}^{- 1} (sat_s_{N} (signed_{M} (i)))

4.3.4.14. $narrow^{u}_{M, N} (i)$

Let $j$ be the signed interpretation of $i$ of size $M$ .
Return $sat_u_{N} (j)$ .

narrow^{u}_{M, N} (i) = sat_u_{N} (signed_{M} (i))

4.3.5. Relaxed Operations

The result of relaxed operators are implementation-dependent, because the set of possible results may depend on properties of the host environment, such as its hardware. Technically, their behaviour is controlled by a set of global parameters to the semantics that an implementation can instantiate in different ways. These choices are fixed, that is, parameters are constant during the execution of any given program.

Every such parameter is an index into a sequence of possible sets of results and must be instantiated to a defined index. In the deterministic profile, every parameter is prescribed to be 0. This behaviour is expressed by the following auxiliary function, where $R$ is a global parameter selecting one of the allowed outcomes:

^{[! DET]} relaxed (R) [A_{0}, \dots, A_{n}] = A_{R} relaxed (R) [A_{0}, \dots, A_{n}] = A_{0}

Note

Each parameter can be thought of as inducing a family of operations that is fixed to one particular choice by an implementation. The fixed operation itself can still be non-deterministic or partial.

Implementations are expexted to either choose the behaviour that is the most efficient on the underlying hardware, or the behaviour of the deterministic profile.

4.3.5.1. $frelaxed_madd_{N} (z_{1}, z_{2}, z_{3})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{fmadd} \in {0, 1}$ .

Return $relaxed (R_{fmadd}) [fadd_{N} (fmul_{N} (z_{1}, z_{2}), z_{3})$ or $fma_{N} (z_{1}, z_{2}, z_{3})]$ .

frelaxed_madd_{N} (z_{1}, z_{2}, z_{3}) = relaxed (R_{fmadd}) [fadd_{N} (fmul_{N} (z_{1}, z_{2}), z_{3}), fma_{N} (z_{1}, z_{2}, z_{3})]

Note

Relaxed multiply-add allows for fused or unfused results, which leads to implementation-dependent rounding behaviour. In the deterministic profile, the unfused behaviour is used.

4.3.5.2. $frelaxed_nmadd_{N} (z_{1}, z_{2}, z_{3})$

Return $frelaxed_madd (- z_{1}, z_{2}, z_{3})$ .

frelaxed_nmadd_{N} (z_{1}, z_{2}, z_{3}) = frelaxed_madd_{N} (- z_{1}, z_{2}, z_{3})

Note

This operation is implementation-dependent because $frelaxed_madd$ is implementation-dependent.

4.3.5.3. $frelaxed_min_{N} (z_{1}, z_{2})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{fmin} \in {0, 1, 2, 3}$ .

If $z_{1}$ is a NaN, then return $relaxed (R_{fmin}) [fmin_{N} (z_{1}, z_{2})$ , NAN(n), z_2, z_2 ]`.
If $z_{2}$ is a NaN, then return $relaxed (R_{fmin}) [fmin_{N} (z_{1}, z_{2})$ , z_1, NAN(n), z_1 ]`.
If both $z_{1}$ and $z_{2}$ are zeroes of opposite sign, then return $relaxed (R_{fmin}) [fmin_{N} (z_{1}, z_{2})$ , pm 0, mp 0, -0 ]`.
Return $fmin_{N} (z_{1}, z_{2})$ .

frelaxed_min_{N} (\pm nan (n), z_{2}) frelaxed_min_{N} (z_{1}, \pm nan (n)) frelaxed_min_{N} (\pm 0, \mp 0) frelaxed_min_{N} (z_{1}, z_{2}) = = = = relaxed (R_{fmin}) [fmin_{N} (\pm nan (n), z_{2}), nan (n), z_{2}, z_{2}] relaxed (R_{fmin}) [fmin_{N} (z_{1}, \pm nan (n)), z_{1}, nan (n), z_{1}] relaxed (R_{fmin}) [fmin_{N} (\pm 0, \mp 0), \pm 0, \mp 0, - 0] fmin_{N} (z_{1}, z_{2}) (otherwise)

Note

Relaxed minimum is implementation-dependent for NaNs and for zeroes with different signs. In the deterministic profile, it behaves like regular $fmin$ .

4.3.5.4. $frelaxed_max_{N} (z_{1}, z_{2})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{fmax} \in {0, 1, 2, 3}$ .

If $z_{1}$ is a NaN, then return $relaxed (R_{fmax}) [fmax_{N} (z_{1}, z_{2})$ , NAN(n), z_2, z_2 ]`.
If $z_{2}$ is a NaN, then return $relaxed (R_{fmax}) [fmax_{N} (z_{1}, z_{2})$ , z_1, NAN(n), z_1 ]`.
If both $z_{1}$ and $z_{2}$ are zeroes of opposite sign, then return $relaxed (R_{fmax}) [fmax_{N} (z_{1}, z_{2})$ , pm 0, mp 0, +0 ]`.
Return $fmax_{N} (z_{1}, z_{2})$ .

frelaxed_max_{N} (\pm nan (n), z_{2}) frelaxed_max_{N} (z_{1}, \pm nan (n)) frelaxed_max_{N} (\pm 0, \mp 0) frelaxed_max_{N} (z_{1}, z_{2}) = = = = relaxed (R_{fmax}) [fmax_{N} (\pm nan (n), z_{2}), nan (n), z_{2}, z_{2}] relaxed (R_{fmax}) [fmax_{N} (z_{1}, \pm nan (n)), z_{1}, nan (n), z_{1}] relaxed (R_{fmax}) [fmax_{N} (\pm 0, \mp 0), \pm 0, \mp 0, + 0] fmax_{N} (z_{1}, z_{2}) (otherwise)

Note

Relaxed maximum is implementation-dependent for NaNs and for zeroes with different signs. In the deterministic profile, it behaves like regular $fmax$ .

4.3.5.5. $irelaxed_dot_mul_{M, N} (i_{1}, i_{2})$

This is an auxiliary operator for the specification of $relaxed_dot$ .

The implementation-specific behaviour of this operation is determined by the global parameter $R_{idot} \in {0, 1}$ .

Return $relaxed (R_{idot}) [imul_{N} (extend^{s}_{M, N} (i_{1}), extend^{s}_{M, N} (i_{2})), imul_{N} (extend^{s}_{M, N} (i_{1}), extend^{u}_{M, N} (i_{2}))]$ .

irelaxed_dot_mul_{M, N} (i_{1}, i_{2}) = relaxed (R_{idot}) [imul_{N} (extend^{s}_{M, N} (i_{1}), extend^{s}_{M, N} (i_{2})), imul_{N} (extend^{s}_{M, N} (i_{1}), extend^{u}_{M, N} (i_{2}))]

Note

Relaxed dot product is implementation-dependent when the second operand is negative in a signed intepretation. In the deterministic profile, it behaves like signed dot product.

4.3.5.6. $irelaxed_q15mulr_s_{N} (i_{1}, i_{2})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{iq15mulr} \in {0, 1}$ .

If both $i_{1}$ and $i_{2}$ equal $(signed_{N}^{- 1} (- 2^{N - 1})$ , then return $relaxed (R_{iq15mulr}) [2^{N - 1} - 1, signed_{N}^{- 1} (- 2^{N - 1})]$ .
Return $iq15mulrsat_s (i_{1}, i_{2})$

irelaxed_q15mulr_s_{N} (signed_{N}^{- 1} (- 2^{N - 1}), signed_{N}^{- 1} (- 2^{N - 1})) irelaxed_q15mulr_s_{N} (i_{1}, i_{2}) = = relaxed (R_{iq15mulr}) [2^{N - 1} - 1, signed_{N}^{- 1} (- 2^{N - 1})] iq15mulrsat_s (i_{1}, i_{2})

Note

Relaxed Q15 multiplication is implementation-dependent when the result overflows. In the deterministic profile, it behaves like regular $iq15mulrsat_s$ .

4.3.5.7. $relaxed_trunc_{M, N}^{u} (z)$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{trunc_u} \in {0, 1, 2, 3}$ .

If $z$ is normal or subnormal and $trunc (z)$ is non-negative and less than $2^{N}$ , then return $trunc^{u}_{M, N} (z)$ .
Else, return $relaxed (R_{trunc_u}) [trunc_sat_u_{M, N} (z), 2^{N} - 1, 2^{N} - 2, 2^{(} N - 1)]$ .

relaxed_trunc_{M, N}^{u} (\pm q) relaxed_trunc_{M, N}^{u} (z) = = trunc^{u}_{M, N} (\pm q) relaxed (R_{trunc_u}) [trunc_sat_u_{M, N} (z), 2^{N} - 1, 2^{N} - 2, 2^{N - 1}] (if 0 \leq trunc (\pm q) < 2^{N}) (otherwise)

Note

Relaxed unsigned truncation is implementation-dependent for NaNs and out-of-range values. In the deterministic profile, it behaves like regular $trunc_sat_u$ .

4.3.5.8. $relaxed_trunc_{M, N}^{s} (z)$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{trunc_s} \in {0, 1}$ .

If $z$ is normal or subnormal and $trunc (z)$ is greater than or equal to $- 2^{N - 1}$ and less than $2^{N - 1}$ , then return $trunc^{s}_{M, N} (z)$ .
Else, return $relaxed (R_{trunc_s}) [trunc_sat_s_{M, N} (z), 2^{N} - 1, 2^{N} - 2, 2^{(} N - 1)]$ .

relaxed_trunc_{M, N}^{s} (\pm q) relaxed_trunc_{M, N}^{s} (z) = = trunc^{s}_{M, N} (\pm q) relaxed (R_{trunc_s}) [trunc_sat_s_{M, N} (z), signed_{N}^{- 1} (- 2^{N - 1})] (if - 2^{N - 1} \leq trunc (\pm q) < 2^{N - 1}) (otherwise)

Note

Relaxed signed truncation is implementation-dependent for NaNs and out-of-range values. In the deterministic profile, it behaves like regular $trunc_sat_s$ .

4.3.5.9. $frelaxed_swizzle (i^{n}, j^{n})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{swizzle} \in {0, 1}$ .

For each $j_{k}$ in $j^{n}$ , let $r_{k}$ be the value $frelaxed_swizzle_lane (i^{n}, j_{k})$ .
Let $r^{n}$ be the concatenation of all $r_{k}$ .
Return $r^{n}$ .

frelaxed_swizzle (i^{n}, j^{n}) = frelaxed_swizzle_lane (i^{n}, j)^{n}

where:

frelaxed_swizzle_lane (i^{n}, j) frelaxed_swizzle_lane (i^{n}, j) frelaxed_swizzle_lane (i^{n}, j) = = = i [j] 0 relaxed (R_{swizzle}) [0, i^{n} [j mod n]] (if j < 16) (if signed_{8} (j) < 0) (otherwise)

Note

Relaxed swizzle is implementation-dependent if the signed interpretation of any of the 8-bit indices in $j^{n}$ is larger than or equal to 16. In the deterministic profile, it behaves like regular $swizzle$ .

4.3.5.10. $irelaxed_laneselect_{N} (i_{1}, i_{2}, i_{3})$

The implementation-specific behaviour of this operation is determined by the global parameter $R_{laneselect} \in {0, 1}$ .

If $i_{3}$ is smaller than $2^{N - 1}$ , then let $i ’_{3}$ be the value $0$ , otherwise $2^{N} - 1$ .
Let $i_{3}^{''}$ be $relaxed (R_{laneselect}) [i_{3}, i ’_{3}]$ .
Return $ibitselect_{N} (i_{1}, i_{2}, i_{3}^{''})$ .

irelaxed_laneselect_{N} (i_{1}, i_{2}, i_{3}) = ibitselect_{N} (i_{1}, i_{2}, relaxed (R_{laneselect}) [i_{3}, extend^{s}_{1, N} (ishr_u_{N} (i_{3}, N - 1))])

Note

Relaxed lane selection is non-deterministic when the mask mixes set and cleared bits, since the value of the high bit may or may not be expanded to all bits. In the deterministic profile, it behaves like $ibitselect$ .

4.4. Types

Execution has to check and compare types in a few places, such as executing $call_indirect$ or instantiating modules.

It is an invariant of the semantics that all types occurring during execution are closed.

Note

Runtime type checks generally involve types from multiple modules or types not defined by a module at all, such that module-local type indices are not meaningful.

4.4.1. Instantiation

Any form of type can be instantiated into a closed type inside a module instance by substituting each type index $x$ occurring in it with the corresponding defined type $moduleinst . types [x]$ .

clos_{moduleinst} (t) = t [:= moduleinst . types]

Note

This is the runtime equivalent to type closure.

4.5. Values

4.5.1. Value Typing

For the purpose of checking argument values against the parameter types of exported functions, values are classified by value types. The following auxiliary typing rules specify this typing relation relative to a store $S$ in which possibly referenced addresses live.

4.5.1.1. Numeric Values $t. const c$

The value is valid with number type $t$ .

S ⊢ t. const c : t

4.5.1.2. Vector Values $t. const c$

The value is valid with vector type $t$ .

S ⊢ t. const c : t

4.5.1.3. Null References $ref.null t$

The heap type must be valid under the empty context.
Then the value is valid with reference type $(ref null t^{'})$ , where the heap type $t^{'}$ is the least type that matches $t$ .

\frac{⊢ t ok t ^{'} \in { none , nofunc , noextern } ⊢ t ^{'} \leq t}{S ⊢ ref.null t : ( ref null t ^{'} )}

Note

A null reference is typed with the least type in its respective hierarchy. That ensures that it is compatible with any nullable type in that hierarchy.

4.5.1.4. Scalar References $ref . i31 i$

The value is valid with reference type $(ref i31)$ .

S ⊢ ref . i31 i : ref i31

4.5.1.5. Structure References $ref . struct a$

The structure address $a$ must exist in the store.
Let $structinst$ be the structure instance $S. structs [a]$ .
Let $deftype$ be the defined type $structinst . type$ .
The expansion of $deftype$ must be a struct type.
Then the value is valid with reference type $(ref deftype)$ .

\frac{deftype = S. structs [ a ] . type expand ( deftype ) = struct structtype}{S ⊢ ref . struct a : ref deftype}

4.5.1.6. Array References $ref . array a$

The array address $a$ must exist in the store.
Let $arrayinst$ be the array instance $S. arrays [a]$ .
Let $deftype$ be the defined type $arrayinst . type$ .
The expansion of $deftype$ must be an array type.
Then the value is valid with reference type $(ref arraytype)$ .

\frac{deftype = S. arrays [ a ] . type expand ( deftype ) = array arraytype}{S ⊢ ref . array a : ref deftype}

4.5.1.7. Exception References $ref . exn a$

The store entry $S. exns [a]$ must exist.
Then the value is valid with reference type $exnref$ .

\frac{S. exns [ a ] = exninst}{S ⊢ ref . exn : exnref}

4.5.1.8. Function References $ref . func a$

The function address $a$ must exist in the store.
Let $funcinst$ be the function instance $S. funcs [a]$ .
Let $deftype$ be the defined type $funcinst . type$ .
The expansion of $deftype$ must be a function type.
Then the value is valid with reference type $(ref functype)$ .

\frac{deftype = S. funcs [ a ] . type expand ( deftype ) = func functype}{S ⊢ ref . func a : ref deftype}

4.5.1.9. Host References $ref . host a$

The value is valid with reference type $(ref any)$ .

S ⊢ ref . host a : ref any

Note

A host reference is considered internalized by this rule.

4.5.1.10. External References $ref . extern ref$

The reference value $ref$ must be valid with some reference type $(ref null^{?} t)$ .
The heap type $t$ must match the heap type $any$ .
Then the value is valid with reference type $(ref null^{?} extern)$ .

\frac{S ⊢ ref : ref null ^{?} t ⊢ t \leq any}{S ⊢ ref . extern ref : ref null ^{?} extern}

4.5.1.11. Subsumption

The value must be valid with some value type $t$ .
The value type $t$ matches another valid type $t^{'}$ .
Then the value is valid with type $t^{'}$ .

\frac{S ⊢ val : t ⊢ t ^{'} ok ⊢ t \leq t ^{'}}{S ⊢ val : t ^{'}}

4.5.2. External Typing

For the purpose of checking external values against imports, such values are classified by external types. The following auxiliary typing rules specify this typing relation relative to a store $S$ in which the referenced instances live.

4.5.2.1. $func a$

The store entry $S. funcs [a]$ must exist.
Then $func a$ is valid with external type $func S. funcs [a] . type$ .

S ⊢ func a : func S. funcs [ a ] . type

4.5.2.2. $table a$

The store entry $S. tables [a]$ must exist.
Then $table a$ is valid with external type $table S. tables [a] . type$ .

S ⊢ table a : table S. tables [ a ] . type

4.5.2.3. $mem a$

The store entry $S. mems [a]$ must exist.
Then $mem a$ is valid with external type $mem S. mems [a] . type$ .

S ⊢ mem a : mem S. mems [ a ] . type

4.5.2.4. $global a$

The store entry $S. globals [a]$ must exist.
Then $global a$ is valid with external type $global S. globals [a] . type$ .

S ⊢ global a : global S. globals [ a ] . type

4.5.2.5. $tag a$

The store entry $S. tags [a]$ must exist.
Let $tagtype$ be the function type $S. tags [a] . type$ .
Then $tag a$ is valid with external type $tag tagtype$ .

S ⊢ tag a : tag S. tags [ a ] . type

4.5.2.6. Subsumption

The external value must be valid with some external type $et$ .
The external type $et$ matches another valid type $e t^{'}$ .
Then the external value is valid with type $e t^{'}$ .

\frac{S ⊢ externval : et ⊢ e t ^{'} ok ⊢ et \leq e t ^{'}}{S ⊢ externval : e t ^{'}}

4.6. Instructions

WebAssembly computation is performed by executing individual instructions.

4.6.1. Numeric Instructions

Numeric instructions are defined in terms of the generic numeric operators. The mapping of numeric instructions to their underlying operators is expressed by the following definition:

op_{i N} (i_{1}, \dots, i_{k}) op_{f N} (z_{1}, \dots, z_{k}) = = i op_{N} (i_{1}, \dots, i_{k}) f op_{N} (z_{1}, \dots, z_{k})

And for conversion operators:

cvtop_{t_{1}, t_{2}}^{sx^{?}} (c) = cvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx^{?}} (c)

Where the underlying operators are partial, the corresponding instruction will trap when the result is not defined. Where the underlying operators are non-deterministic, because they may return one of multiple possible NaN values, so are the corresponding instructions.

Note

For example, the result of instruction $i32 . add$ applied to operands $i_{1}, i_{2}$ invokes $add_{i32} (i_{1}, i_{2})$ , which maps to the generic $iadd_{32} (i_{1}, i_{2})$ via the above definition. Similarly, $i64 . trunc_f32_s$ applied to $z$ invokes $trunc_{f32, i64}^{s} (z)$ , which maps to the generic $trunc^{s}_{32, 64} (z)$ .

4.6.1.1. $t . const c$

Push the value $t. const c$ to the stack.

Note

No formal reduction rule is required for this instruction, since $const$ instructions already are values.

4.6.1.2. $t . unop$

Assert: due to validation, a value of value type $t$ is on the top of the stack.
Pop the value $t. const c_{1}$ from the stack.
If $unop_{t} (c_{1})$ is defined, then:
1. Let $c$ be a possible result of computing $unop_{t} (c_{1})$ .
2. Push the value $t. const c$ to the stack.
Else:
1. Trap.

(t . const c_{1}) t . unop (t . const c_{1}) t . unop ↪ ↪ (t . const c) trap (if c \in unop_{t} (c_{1})) (if unop_{t} (c_{1}) = {})

4.6.1.3. $t . binop$

Assert: due to validation, two values of value type $t$ are on the top of the stack.
Pop the value $t. const c_{2}$ from the stack.
Pop the value $t. const c_{1}$ from the stack.
If $binop_{t} (c_{1}, c_{2})$ is defined, then:
1. Let $c$ be a possible result of computing $binop_{t} (c_{1}, c_{2})$ .
2. Push the value $t. const c$ to the stack.
Else:
1. Trap.

(t . const c_{1}) (t . const c_{2}) t . binop (t . const c_{1}) (t . const c_{2}) t . binop ↪ ↪ (t . const c) trap (if c \in binop_{t} (c_{1}, c_{2})) (if binop_{t} (c_{1}, c_{2}) = {})

4.6.1.4. $t . testop$

Assert: due to validation, a value of value type $t$ is on the top of the stack.
Pop the value $t. const c_{1}$ from the stack.
Let $c$ be the result of computing $testop_{t} (c_{1})$ .
Push the value $i32 . const c$ to the stack.

(t . const c_{1}) t . testop ↪ (i32 . const c) (if c = testop_{t} (c_{1}))

4.6.1.5. $t . relop$

Assert: due to validation, two values of value type $t$ are on the top of the stack.
Pop the value $t. const c_{2}$ from the stack.
Pop the value $t. const c_{1}$ from the stack.
Let $c$ be the result of computing $relop_{t} (c_{1}, c_{2})$ .
Push the value $i32 . const c$ to the stack.

(t . const c_{1}) (t . const c_{2}) t . relop ↪ (i32 . const c) (if c = relop_{t} (c_{1}, c_{2}))

4.6.1.6. $t_{2} . cvtop_t_{1}_sx^{?}$

Assert: due to validation, a value of value type $t_{1}$ is on the top of the stack.
Pop the value $t_{1} . const c_{1}$ from the stack.
If $cvtop_{t_{1}, t_{2}}^{sx^{?}} (c_{1})$ is defined:
1. Let $c_{2}$ be a possible result of computing $cvtop_{t_{1}, t_{2}}^{sx^{?}} (c_{1})$ .
2. Push the value $t_{2} . const c_{2}$ to the stack.
Else:
1. Trap.

(t_{1} . const c_{1}) t_{2} . cvtop_t_{1}_sx^{?} (t_{1} . const c_{1}) t_{2} . cvtop_t_{1}_sx^{?} ↪ ↪ (t_{2} . const c_{2}) trap (if c_{2} \in cvtop_{t_{1}, t_{2}}^{sx^{?}} (c_{1})) (if cvtop_{t_{1}, t_{2}}^{sx^{?}} (c_{1}) = {})

4.6.2. Reference Instructions

4.6.2.1. $ref.null x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Push the value $ref.null deftype$ to the stack.

F; (ref.null x) ↪ F; (ref.null deftype) (if deftype = F . module . types [x])

Note

No formal reduction rule is required for the case $ref.null$ $absheaptype$ , since the instruction form is already a value.

4.6.2.2. $ref.func x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . funcaddrs [x]$ exists.
Let $a$ be the function address $F. module . funcaddrs [x]$ .
Push the value $ref . func a$ to the stack.

F; (ref.func x) ↪ F; (ref . func a) (if a = F . module . funcaddrs [x])

4.6.2.3. $ref.is_null$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Push the value $i32 . const 1$ to the stack.
Else:
1. Push the value $i32 . const 0$ to the stack.

ref ref.is_null ref ref.is_null ↪ ↪ (i32 . const 1) (i32 . const 0) (if ref = ref.null ht) (otherwise)

4.6.2.4. $ref.as_non_null$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Trap.
Push the value $ref$ back to the stack.

ref ref.as_non_null ref ref.as_non_null ↪ ↪ trap ref (if ref = ref.null ht) (otherwise)

4.6.2.5. $ref.eq$

Assert: due to validation, two reference values are on the top of the stack.
Pop the value $ref_{2}$ from the stack.
Pop the value $ref_{1}$ from the stack.
If $ref_{1}$ is the same as $ref_{2}$ , then:
1. Push the value $i32 . const 1$ to the stack.
Else:
1. Push the value $i32 . const 0$ to the stack.

ref_{1} ref_{2} ref.eq ref_{1} ref_{2} ref.eq ref_{1} ref_{2} ref.eq ↪ ↪ ↪ (i32 . const 1) (i32 . const 1) (i32 . const 0) (if ref_{1} = (ref.null ht_{1}) \land ref_{2} = (ref.null ht_{2})) (if ref_{1} = ref_{2}) (otherwise)

4.6.2.6. $ref.test rt$

Let $F$ be the current frame.
Let $rt_{1}$ be the reference type $clos_{F. module} (rt)$ .
Assert: due to validation, $rt_{1}$ is closed.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
Assert: due to validation, the reference value is valid with some reference type.
Let $rt_{2}$ be the reference type of $ref$ .
If the reference type $rt_{2}$ matches $rt_{1}$ , then:
1. Push the value $i32 . const 1$ to the stack.
Else:
1. Push the value $i32 . const 0$ to the stack.

S; F; ref (ref.test rt) S; F; ref (ref.test rt) ↪ ↪ (i32 . const 1) (i32 . const 0) (if S ⊢ ref : rt^{'} \land ⊢ rt^{'} \leq clos_{F . module} (rt)) (otherwise)

4.6.2.7. $ref.cast rt$

Let $F$ be the current frame.
Let $rt_{1}$ be the reference type $clos_{F. module} (rt)$ .
Assert: due to validation, $rt_{1}$ is closed.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
Assert: due to validation, the reference value is valid with some reference type.
Let $rt_{2}$ be the reference type of $ref$ .
If the reference type $rt_{2}$ matches $rt_{1}$ , then:
1. Push the value $ref$ back to the stack.
Else:
1. Trap.

S; F; ref (ref.cast rt) S; F; ref (ref.cast rt) ↪ ↪ ref trap (if S ⊢ ref : rt^{'} \land ⊢ rt^{'} \leq clos_{F . module} (rt)) (otherwise)

4.6.2.8. $ref.i31$

Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
Let $j$ be the result of computing $wrap_{32, 31} (i)$ .
Push the reference value $(ref . i31 j)$ to the stack.

(i32 . const i) ref.i31 ↪ (ref . i31 wrap_{32, 31} (i))

4.6.2.9. $i31.get_sx$

Assert: due to validation, a value of type $(ref null i31)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:
1. Trap.
Assert: due to validation, a $ref$ is a scalar reference.
Let $ref . i31 i$ be the reference value $ref$ .
Let $j$ be the result of computing $extend_{31, 32}^{sx} (i)$ .
Push the value $i32 . const j$ to the stack.

(ref . i31 i) i31.get_sx (ref.null t) i31.get_sx ↪ ↪ (i32 . const extend_{31, 32}^{sx} (i)) trap

4.6.2.10. $struct.new x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is a structure type.
Let $struct ft^{*}$ be the expanded structure type of $deftype$ .
Let $n$ be the length of the field type sequence $ft^{*}$ .
Assert: due to validation, $n$ values are on the top of the stack.
Pop the $n$ values $val^{*}$ from the stack.
For every value $val_{i}$ in $val^{*}$ and corresponding field type $ft_{i}$ in $ft^{*}$ :
1. Let $fieldval_{i}$ be the result of computing $pack_{ft_{i}} (val_{i}))$ .
Let $fieldval^{*}$ the concatenation of all field values $fieldval_{i}$ .
Let $si$ be the structure instance ${type deftype, fields fieldval^{*}}$ .
Let $a$ be the length of $S. structs$ .
Append $si$ to $S. structs$ .
Push the structure reference $ref . struct a$ to the stack.

S; F; val^{n} (struct.new x) ↪ S^{'}; F; (ref . struct ∣ S . structs ∣) (if \land \land expand (F . module . types [x]) = struct ft^{n} si = {type F . module . types [x], fields (pack_{ft} (val))^{n}} S^{'} = S with structs = S . structs si)

4.6.2.11. $struct.new_default x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is a structure type.
Let $struct ft^{*}$ be the expanded structure type of $deftype$ .
Let $n$ be the length of the field type sequence $ft^{*}$ .
For every field type $ft_{i}$ in $ft^{*}$ :
1. Let $t_{i}$ be the value type $unpack (ft_{i})$ .
2. Assert: due to validation, $default_{t_{i}}$ is defined.
3. Push the value $default_{t_{i}}$ to the stack.
Execute the instruction $(struct.new x)$ .

F; (struct.new_default x) ↪ (default_{unpack (ft)}))^{n} (struct.new x) (if expand (F . module . types [x]) = struct ft^{n})

4.6.2.12. $struct.get_sx^{?} x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is a structure type with at least $y + 1$ fields.
Let $struct ft^{*}$ be the expanded structure type of $deftype$ .
Let $ft_{y}$ be the $y$ -th field type of $ft^{*}$ .
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:
1. Trap.
Assert: due to validation, a $ref$ is a structure reference.
Let $ref . struct a$ be the reference value $ref$ .
Assert: due to validation, the structure instance $S. structs [a]$ exists and has at least $y + 1$ fields.
Let $fieldval$ be the field value $S. structs [a] . fields [y]$ .
Let $val$ be the result of computing $unpack_{ft_{y}}^{sx^{?}} (fieldval))$ .
Push the value $val$ to the stack.

S; F; (ref . struct a) (struct.get_sx^{?} x y) S; F; (ref.null t) (struct.get_sx^{?} x y) ↪ ↪ val trap (if \land expand (F . module . types [x]) = struct ft^{n} val = unpack_{ft^{n} [y]}^{sx^{?}} (S . structs [a] . fields [y]))

4.6.2.13. $struct.set x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is a structure type with at least $y + 1$ fields.
Let $struct ft^{*}$ be the expanded structure type of $deftype$ .
Let $ft_{y}$ be the $y$ -th field type of $ft^{*}$ .
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:

Trap.

Assert: due to validation, a $ref$ is a structure reference.
Let $ref . struct a$ be the reference value $ref$ .
Assert: due to validation, the structure instance $S. structs [a]$ exists and has at least $y + 1$ fields.
Let $fieldval$ be the result of computing $pack_{ft_{y}} (val))$ .
Replace the field value $S. structs [a] . fields [y]$ with $fieldval$ .

S; F; (ref . struct a) val (struct.set x y) S; F; (ref.null t) val (struct.set x y) ↪ ↪ S^{'}; ϵ trap (if \land expand (F . module . types [x]) = struct ft^{n} S^{'} = S with structs [a] . fields [y] = pack_{ft^{n} [y]} (val))

4.6.2.14. $array.new x$

Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $(i32 . const n)$ from the stack.
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Push the value $val$ to the stack $n$ times.
Execute the instruction $(array.new_fixed x n)$ .

val (i32 . const n) (array.new x) ↪ val^{n} (array.new_fixed x n)

4.6.2.15. $array.new_default x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type of $deftype$ .
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Let $t$ be the value type $unpack (ft)$ .
Assert: due to validation, $default_{t}$ is defined.
Push the value $default_{t}$ to the stack $n$ times.
Execute the instruction $(array.new_fixed x n)$ .

F; (i32 . const n) (array.new_default x) ↪ (default_{unpack (ft}))^{n} (array.new_fixed x n) (if expand (F . module . types [x]) = array ft)

4.6.2.16. $array.new_fixed x n$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is a array type.
Let $array ft$ be the expanded array type of $deftype$ .
Assert: due to validation, $n$ values are on the top of the stack.
Pop the $n$ values $val^{*}$ from the stack.
For every value $val_{i}$ in $val^{*}$ :
1. Let $fieldval_{i}$ be the result of computing $pack_{ft} (val_{i}))$ .
Let $fieldval^{*}$ be the concatenation of all field values $fieldval_{i}$ .
Let $ai$ be the array instance ${type deftype, fields fieldval^{*}}$ .
Let $a$ be the length of $S. arrays$ .
Append $ai$ to $S. arrays$ .
Push the array reference $ref . array a$ to the stack.

S; F; val^{n} (array.new_fixed x n) ↪ S^{'}; F; (ref . array ∣ S . arrays ∣) (if \land \land expand (F . module . types [x]) = array ft ai = {type F . module . types [x], fields (pack_{ft} (val))^{n}} S^{'} = S with arrays = S . arrays ai)

4.6.2.17. $array.new_data x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type of $deftype$ .
Assert: due to validation, the data address $F. module . dataaddrs [y]$ exists.
Let $da$ be the data address $F. module . dataaddrs [y]$ .
Assert: due to validation, the data instance $S. datas [da]$ exists.
Let $datainst$ be the data instance $S. datas [da]$ .
Assert: due to validation, two values of type $i32$ are on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Pop the value $i32 . const s$ from the stack.
Assert: due to validation, the field type $ft$ has a defined bit width.
Let $z$ be the bit width of field type $ft$ divided by eight.
If the sum of $s$ and $n$ times $z$ is larger than the length of $datainst . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $datainst . data [s : n \cdot z]$ .
Let $t$ be the value type $unpack (ft)$ .
For each of the $n$ consecutive subsequences $b^{'}^{z}$ of $b^{*}$ :
1. Assert: due to validation, $bytes_{ft}$ is defined.
2. Let $c_{i}$ be the constant for which $bytes_{ft} (c_{i})$ is $b^{'}^{z}$ .
3. Push the value $t. const c_{i}$ to the stack.
Execute the instruction $(array.new_fixed x n)$ .

S; F; (i32 . const s) (i32 . const n) (array.new_data x y) 1 e x] S; F; (i32 . const s) (i32 . const n) (array.new_data x y) ↪ ↪ trap (if \land expand (F . module . types [x]) = array ft s + n \cdot ∣ ft ∣/8 > ∣ S . datas [F . module . dataaddrs [y]] . data ∣) (t . const c)^{n} (array.new_fixed x n) (if \land \land expand (F . module . types [x]) = array ft t = unpack (ft) concat ((bytes_{ft} (c))^{n}) = S . datas [F . module . dataaddrs [y]] . data [s : n \cdot ∣ ft ∣/8]

4.6.2.18. $array.new_elem x y$

Let $F$ be the current frame.
Assert: due to validation, the element address $F. module . elemaddrs [y]$ exists.
Let $ea$ be the element address $F. module . elemaddrs [y]$ .
Assert: due to validation, the element instance $S. elems [ea]$ exists.
Let $eleminst$ be the element instance $S. elems [ea]$ .
Assert: due to validation, two values of type $i32$ are on the top of the stack.
Pop the value $(i32 . const n)$ from the stack.
Pop the value $(i32 . const s)$ from the stack.
If the sum of $s$ and $n$ is larger than the length of $eleminst . elem$ , then:
1. Trap.
Let $ref^{*}$ be the reference sequence $eleminst . elem [s : n]$ .
Push the references $ref^{*}$ to the stack.
Execute the instruction $(array.new_fixed x n)$ .

S; F; (i32 . const s) (i32 . const n) (array.new_elem x y) ↪ trap (if s + n > ∣ S . elems [F . module . elemaddrs [y]] . elem ∣) 1 e x] S; F; (i32 . const s) (i32 . const n) (array.new_elem x y) (if ref^{n} = S . elems [F . module . elemaddrs [y]] . elem [s : n]) ↪ ref^{n} (array.new_fixed x n)

4.6.2.19. $array.get_sx^{?} x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type of $deftype$ .
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
If $n$ is larger than or equal to the length of $S. arrays [a] . fields$ , then:
1. Trap.
Let $fieldval$ be the field value $S. arrays [a] . fields [i]$ .
Let $val$ be the result of computing $unpack_{ft}^{sx^{?}} (fieldval))$ .
Push the value $val$ to the stack.

S; F; (ref . array a) (i32 . const i) (array.get_sx^{?} x) ↪ trap (if i \geq ∣ arrays [a] . fields ∣) 1 e x] S; F; (ref . array a) (i32 . const i) (array.get_sx^{?} x) ↪ val (if \land expand (F . module . types [x]) = array ft val = unpack_{ft}^{sx^{?}} (S . arrays [a] . fields [i])) 1 e x] S; F; (ref.null t) (i32 . const i) (array.get_sx^{?} x) ↪ trap

4.6.2.20. $array.set x$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type of $deftype$ .
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
If $n$ is larger than or equal to the length of $S. arrays [a] . fields$ , then:
1. Trap.
Let $fieldval$ be the result of computing $pack_{ft} (val))$ .
Replace the field value $S. arrays [a] . fields [i]$ with $fieldval$ .

S; F; (ref . array a) (i32 . const i) val (array.set x) ↪ trap (if i \geq ∣ arrays [a] . fields ∣) 1 e x] S; F; (ref . array a) (i32 . const i) val (array.set x) ↪ S^{'}; ϵ (if \land expand (F . module . types [x]) = array ft S^{'} = S with arrays [a] . fields [i] = pack_{ft} (val)) 1 e x] S; F; (ref.null t) (i32 . const i) val (array.set x) ↪ trap

4.6.2.21. $array.len$

Assert: due to validation, a value of type $(ref null array)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:
1. Trap.
Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
Let $n$ be the length of $S. arrays [a] . fields$ .
Push the value $(i32 . const n)$ to the stack.

S; (ref . array a) array.len S; (ref.null t) array.len ↪ ↪ (i32 . const ∣ S . arrays [a] . fields ∣) trap

4.6.2.22. $array.fill x$

Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $n$ from the stack.
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $d$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:
1. Trap.
Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
If $d + n$ is larger than the length of $S. arrays [a] . fields$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Push the value $ref . array a$ to the stack.
Push the value $i32 . const d$ to the stack.
Push the value $val$ to the stack.
Execute the instruction $array.set x$ .
Push the value $ref . array a$ to the stack.
Assert: due to the earlier check against the array size, $d + 1 < 2^{32}$ .
Push the value $i32 . const (d + 1)$ to the stack.
Push the value $val$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $array.fill x$ .

S; (ref . array a) (i32 . const d) val (i32 . const n) (array.fill x) ↪ trap (if d + n > ∣ S . arrays [a] . fields ∣) 1 e x] S; (ref . array a) (i32 . const d) val (i32 . const 0) (array.fill x) ↪ ϵ (otherwise) 1 e x] S; (ref . array a) (i32 . const d) val (i32 . const n + 1) (array.fill x) ↪ (ref . array a) (i32 . const d) val (array.set x) (ref . array a) (i32 . const d + 1) val (i32 . const n) (array.fill x) (otherwise) 1 e x] S; (ref.null t) (i32 . const d) val (i32 . const n) (array.fill x) ↪ trap

4.6.2.23. $array.copy x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [y]$ exists.
Let $deftype$ be the defined type $F. module . types [y]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array mut st$ be the expanded array type $deftype$ .
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const s$ from the stack.
Assert: due to validation, a value of type $(ref null y)$ is on the top of the stack.
Pop the value $ref_{2}$ from the stack.
Assert: due to validation, a value of type $i32$ is on the top of the stack.
Pop the value $i32 . const d$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref_{1}$ from the stack.
If $ref_{1}$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref_{1}$ is an array reference.
Let $ref . array a_{1}$ be the reference value $ref_{1}$ .
If $ref_{2}$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref_{2}$ is an array reference.
Let $ref . array a_{2}$ be the reference value $ref_{2}$ .
Assert: due to validation, the array instance $S. arrays [a_{1}]$ exists.
Assert: due to validation, the array instance $S. arrays [a_{2}]$ exists.
If $d + n$ is larger than the length of $S. arrays [a_{1}] . fields$ , then:
1. Trap.
If $s + n$ is larger than the length of $S. arrays [a_{2}] . fields$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
If $d \leq s$ , then:
1. Push the value $ref . array a_{1}$ to the stack.
2. Push the value $i32 . const d$ to the stack.
3. Push the value $ref . array a_{2}$ to the stack.
4. Push the value $i32 . const s$ to the stack.
5. Execute $getfield (st)$ .
6. Execute the instruction $array.set x$ .
7. Push the value $ref . array a_{1}$ to the stack.
8. Assert: due to the earlier check against the array size, $d + 1 < 2^{32}$ .
9. Push the value $i32 . const (d + 1)$ to the stack.
10. Push the value $ref . array a_{2}$ to the stack.
11. Assert: due to the earlier check against the array size, $s + 1 < 2^{32}$ .
12. Push the value $i32 . const (s + 1)$ to the stack.
Else:
1. Push the value $ref . array a_{1}$ to the stack.
2. Assert: due to the earlier check against the array size, $d + n - 1 < 2^{32}$ .
3. Push the value $i32 . const (d + n - 1)$ to the stack.
4. Push the value $ref . array a_{2}$ to the stack.
5. Assert: due to the earlier check against the array size, $s + n - 1 < 2^{32}$ .
6. Push the value $i32 . const (s + n - 1)$ to the stack.
7. Execute $getfield (st)$ .
8. Execute the instruction $array.set x$ .
9. Push the value $ref . array a_{1}$ to the stack.
10. Push the value $i32 . const d$ to the stack.
11. Push the value $ref . array a_{2}$ to the stack.
12. Push the value $i32 . const s$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $array.copy x y$ .

S; F; (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) (i32 . const n) (array.copy x y) ↪ trap (if d + n > ∣ S . arrays [a_{1}] . fields ∣ \lor s + n > ∣ S . arrays [a_{2}] . fields ∣) 1 e x] S; F; (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) (i32 . const 0) (array.copy x y) ↪ ϵ (otherwise) 1 e x] S; F; (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) (i32 . const n + 1) (array.copy x y) ↪ (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) getfield (st) (array.set x) (ref . array a_{1}) (i32 . const d + 1) (ref . array a_{2}) (i32 . const s + 1) (i32 . const n) (array.copy x y) (otherwise, if d \leq s \land F . module . types [y] = array mut st) 1 e x] S; F; (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) (i32 . const n + 1) (array.copy x y) ↪ (ref . array a_{1}) (i32 . const d + n) (ref . array a_{2}) (i32 . const s + n) getfield (st) (array.set x) (ref . array a_{1}) (i32 . const d) (ref . array a_{2}) (i32 . const s) (i32 . const n) (array.copy x y) (otherwise, if d > s \land F . module . types [y] = array mut st) 1 e x] S; F; (ref.null t) (i32 . const d) val (i32 . const s) (i32 . const n) (array.copy x y) ↪ trap 1 e x] S; F; val (i32 . const d) (ref.null t) (i32 . const s) (i32 . const n) (array.copy x y) ↪ trap

Where:

getfield (valtype) getfield (packedtype) = = array.get y array.get_u y

4.6.2.24. $array.init_data x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type $deftype$ .
Assert: due to validation, the data address $F. module . dataaddrs [y]$ exists.
Let $da$ be the data address $F. module . dataaddrs [y]$ .
Assert: due to validation, the data instance $S. datas [da]$ exists.
Let $datainst$ be the data instance $S. datas [da]$ .
Assert: due to validation, three values of type $i32$ are on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Pop the value $i32 . const s$ from the stack.
Pop the value $i32 . const d$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
Assert: due to validation, the field type $ft$ has a defined bit width.
Let $z$ be the bit width of field type $ft$ divided by eight.
If $d + n$ is larger than the length of $S. arrays [a] . fields$ , or the sum of $s$ and $n$ times $z$ is larger than the length of $datainst . data$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Let $b^{*}$ be the byte sequence $datainst . data [s : z]$ .
Let $t$ be the value type $unpack (ft)$ .
Assert: due to validation, $bytes_{ft}$ is defined.
Let $c$ be the constant for which $bytes_{ft} (c)$ is $b^{*}$ .
Push the value $ref . array a$ to the stack.
Push the value $i32 . const d$ to the stack.
Push the value $t. const c$ to the stack.
Execute the instruction $array.set x$ .
Push the value $ref . array a$ to the stack.
Push the value $i32 . const (d + 1)$ to the stack.
Push the value $i32 . const (s + z)$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $array.init_data x y$ .

S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const n) (array.init_data x y) ↪ trap (if \lor d + n > ∣ S . arrays [a] . fields ∣ (F . module . types [x] = array ft \land s + n \cdot ∣ ft ∣/8 > ∣ S . datas [F . module . dataaddrs [y]] . data ∣)) 1 e x] S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const 0) (array.init_data x y) ↪ ϵ (otherwise) 1 e x] S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const n + 1) (array.init_data x y) ↪ (ref . array a) (i32 . const d) (t . const c) (array.set x) (ref . array a) (i32 . const d + 1) (i32 . const s + ∣ ft ∣/8) (i32 . const n) (array.init_data x y) (otherwise, if \land \land F . module . types [x] = array ft t = unpack (ft) bytes_{ft} (c) = S . datas [F . module . dataaddrs [y]] . data [s : ∣ ft ∣/8] 1 e x] S; F; (ref.null t) (i32 . const d) (i32 . const s) (i32 . const n) (array.init_data x y) ↪ trap

4.6.2.25. $array.init_elem x y$

Let $F$ be the current frame.
Assert: due to validation, the defined type $F. module . types [x]$ exists.
Let $deftype$ be the defined type $F. module . types [x]$ .
Assert: due to validation, the expansion of $deftype$ is an array type.
Let $array ft$ be the expanded array type $deftype$ .
Assert: due to validation, the element address $F. module . elemaddrs [y]$ exists.
Let $ea$ be the element address $F. module . elemaddrs [y]$ .
Assert: due to validation, the element instance $S. elems [ea]$ exists.
Let $eleminst$ be the element instance $S. elems [ea]$ .
Assert: due to validation, three values of type $i32$ are on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Pop the value $i32 . const s$ from the stack.
Pop the value $i32 . const d$ from the stack.
Assert: due to validation, a value of type $(ref null x)$ is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null t$ , then:

Trap.

Assert: due to validation, $ref$ is an array reference.
Let $ref . array a$ be the reference value $ref$ .
Assert: due to validation, the array instance $S. arrays [a]$ exists.
If $d + n$ is larger than the length of $S. arrays [a] . fields$ , or $s + n$ is larger than the length of $eleminst . elem$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Let $ref^{'}$ be the reference value $eleminst . elem [s]$ .
Push the value $ref . array a$ to the stack.
Push the value $i32 . const d$ to the stack.
Push the value $ref^{'}$ to the stack.
Execute the instruction $array.set x$ .
Push the value $ref . array a$ to the stack.
Push the value $i32 . const (d + 1)$ to the stack.
Push the value $i32 . const (s + 1)$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $array.init_elem x y$ .

S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const n) (array.init_elem x y) ↪ trap (if \lor d + n > ∣ S . arrays [a] . fields ∣ s + n > ∣ S . elems [F . module . elemaddrs [y]] . elem ∣) 1 e x] S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const 0) (array.init_elem x y) ↪ ϵ (otherwise) 1 e x] S; F; (ref . array a) (i32 . const d) (i32 . const s) (i32 . const n + 1) (array.init_elem x y) ↪ (ref . array a) (i32 . const d) ref (array.set x) (ref . array a) (i32 . const d + 1) (i32 . const s + 1) (i32 . const n) (array.init_elem x y) (otherwise, if ref = S . elems [F . module . elemaddrs [y]] . elem [s]) 1 e x] S; F; (ref.null t) (i32 . const d) (i32 . const s) (i32 . const n) (array.init_elem x y) ↪ trap

4.6.2.26. $any.convert_extern$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Push the reference value $(ref.null any)$ to the stack.
Else:
1. Assert: due to validation, a $ref$ is an external reference.
2. Let $ref . extern ref^{'}$ be the reference value $ref$ .
3. Push the reference value $ref^{'}$ to the stack.

(ref.null ht) any.convert_extern (ref . extern ref) any.convert_extern ↪ ↪ (ref.null any) ref

4.6.2.27. $extern.convert_any$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Push the reference value $(ref.null extern)$ to the stack.
Else:
1. Let $ref^{'}$ be the reference value $(ref . extern ref)$ .
2. Push the reference value $ref^{'}$ to the stack.

(ref.null ht) extern.convert_any ref extern.convert_any ↪ ↪ (ref.null extern) (ref . extern ref) (if ref \neq = (ref.null ht))

4.6.3. Vector Instructions

Vector instructions that operate bitwise are handled as integer operations of respective width.

op_{v N} (i_{1}, \dots, i_{k}) = i op_{N} (i_{1}, \dots, i_{k})

Most other vector instructions are defined in terms of numeric operators that are applied lane-wise according to the given shape.

op_{t x N} (n_{1}, \dots, n_{k}) = lanes_{t x N}^{- 1} (op_{t} (i_{1}, \dots, i_{k})^{*}) (if i_{1}^{*} = lanes_{t x N} (n_{1}) \land \dots \land i_{k}^{*} = lanes_{t x N} (n_{k})

Note

For example, the result of instruction $i32x4 . add$ applied to operands $v_{1}, v_{2}$ invokes $add_{i32x4} (v_{1}, v_{2})$ , which maps to $lanes_{i32x4}^{- 1} (add_{i32} (i_{1}, i_{2})^{*})$ , where $i_{1}^{*}$ and $i_{2}^{*}$ are sequences resulting from invoking $lanes_{i32x4} (v_{1})$ and $lanes_{i32x4} (v_{2})$ respectively.

For non-deterministic operators this definition is generalized to sets:

op_{t x N} (n_{1}, \dots, n_{k}) = {lanes_{t x N}^{- 1} (i^{*}) ∣ i^{*} \in \times op_{t} (i_{1}, \dots, i_{k})^{*} \land i_{1}^{*} = lanes_{t x N} (n_{1}) \land \dots \land i_{k}^{*} = lanes_{t x N} (n_{k})}

where $\times {x^{*}}^{N}$ transforms a sequence of $N$ sets of values into a set of sequences of $N$ values by computing the set product:

\times (S_{1} \dots S_{N}) = {x_{1} \dots x_{N} ∣ x_{1} \in S_{1} \land \dots \land x_{N} \in S_{N}}

4.6.3.1. $v128 . const c$

Push the value $v128 . const c$ to the stack.

Note

No formal reduction rule is required for this instruction, since $const$ instructions coincide with values.

4.6.3.2. $v128 . vvunop$

Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c$ be the result of computing $vvunop_{v128} (c_{1})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) v128 . vvunop ↪ (v128 . const c) (if c = vvunop_{v128} (c_{1}))

4.6.3.3. $v128 . vvbinop$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c$ be the result of computing $vvbinop_{v128} (c_{1}, c_{2})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (v128 . const c_{2}) v128 . vvbinop ↪ (v128 . const c) (if c = vvbinop_{v128} (c_{1}, c_{2}))

4.6.3.4. $v128 . vvternop$

Assert: due to validation, three values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{3}$ from the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c$ be the result of computing $vvternop_{v128} (c_{1}, c_{2}, c_{3})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (v128 . const c_{2}) (v128 . const c_{3}) v128 . vvternop ↪ (v128 . const c) (if c = vvternop_{v128} (c_{1}, c_{2}, c_{3}))

4.6.3.5. $v128 . any_true$

Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i$ be the result of computing $ine_{128} (c_{1}, 0)$ .
Push the value $i32 . const i$ onto the stack.

(v128 . const c_{1}) v128 . any_true ↪ (i32 . const i) (if i = ine_{128} (c_{1}, 0))

4.6.3.6. $i8x16. swizzle$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{i8x16} (c_{2})$ .
Pop the value $v128 . const c_{1}$ from the stack.
Let $j^{*}$ be the result of computing $lanes_{i8x16} (c_{1})$ .
Let $c^{*}$ be the concatenation of the two sequences $j^{*}$ and $0^{240}$ .
Let $c^{'}$ be the result of computing $lanes_{i8x16}^{- 1} (c^{*} [i^{*} [0]] \dots c^{*} [i^{*} [15]])$ .
Push the value $v128 . const c^{'}$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) i8x16 . swizzle ↪ (v128 . const c^{'}) (if \land \land i^{*} = lanes_{i8x16} (c_{2}) c^{*} = lanes_{i8x16} (c_{1}) 0^{240} c^{'} = lanes_{i8x16}^{- 1} (c^{*} [i^{*} [0]] \dots c^{*} [i^{*} [15]]))

4.6.3.7. $i8x16. relaxed_swizzle$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c^{'}$ be the result of computing $lanes_{i8x16}^{- 1} (frelaxed_swizzle (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2})))$ .
Push the value $v128 . const c^{'}$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) i8x16 . frelaxed_swizzle ↪ (v128 . const c^{'}) (if c^{'} = lanes_{i8x16}^{- 1} (frelaxed_swizzle (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2})))

4.6.3.8. $i8x16. shuffle x^{*}$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Assert: due to validation, for all $x_{i}$ in $x^{*}$ it holds that $x_{i} < 32$ .
Pop the value $v128 . const c_{2}$ from the stack.
Let $i_{2}^{*}$ be the result of computing $lanes_{i8x16} (c_{2})$ .
Pop the value $v128 . const c_{1}$ from the stack.
Let $i_{1}^{*}$ be the result of computing $lanes_{i8x16} (c_{1})$ .
Let $i^{*}$ be the concatenation of the two sequences $i_{1}^{*}$ and $i_{2}^{*}$ .
Let $c$ be the result of computing $lanes_{i8x16}^{- 1} (i^{*} [x^{*} [0]] \dots i^{*} [x^{*} [15]])$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) (i8x16 . shuffle x^{*}) ↪ (v128 . const c) (if \land i^{*} = lanes_{i8x16} (c_{1}) lanes_{i8x16} (c_{2}) c = lanes_{i8x16}^{- 1} (i^{*} [x^{*} [0]] \dots i^{*} [x^{*} [15]]))

4.6.3.9. $shape . splat$

Let $t$ be the type $unpack (shape)$ .
Assert: due to validation, a value of value type $t$ is on the top of the stack.
Pop the value $t. const c_{1}$ from the stack.
Let $N$ be the integer $dim (shape)$ .
Let $c$ be the result of computing $lanes_{shape}^{- 1} (c_{1}^{N})$ .
Push the value $v128 . const c$ to the stack.

(t . const c_{1}) shape . splat ↪ (v128 . const c) (if t = unpack (shape) \land c = lanes_{shape}^{- 1} (c_{1}^{dim (shape)}))

4.6.3.10. $t_{1} x N . extract_lane_sx^{?} x$

Assert: due to validation, $x < N$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t_{1} x N} (c_{1})$ .
Let $t_{2}$ be the type $unpack (t_{1} x N)$ .
Let $c_{2}$ be the result of computing $extend_{t_{1}, t_{2}}^{s x^{?}} (i^{*} [x])$ .
Push the value $t_{2} . const c_{2}$ to the stack.

(v128 . const c_{1}) (t_{1} x N . extract_lane x) ↪ (t_{2} . const c_{2}) (if \land t_{2} = unpack (t_{1} x N) c_{2} = extend_{t_{1}, t_{2}}^{s x^{?}} (lanes_{t_{1} x N} (c_{1}) [x]))

4.6.3.11. $shape . replace_lane x$

Assert: due to validation, $x < dim (shape)$ .
Let $t_{2}$ be the type $unpack (shape)$ .
Assert: due to validation, a value of value type $t_{1}$ is on the top of the stack.
Pop the value $t_{2} . const c_{2}$ from the stack.
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{shape} (c_{1})$ .
Let $c$ be the result of computing $lanes_{shape}^{- 1} (i^{*} with [x] = c_{2})$ .
Push $v128 . const c$ on the stack.

(v128 . const c_{1}) (t_{2} . const c_{2}) (shape . replace_lane x) ↪ (v128 . const c) (if \land i^{*} = lanes_{shape} (c_{1}) c = lanes_{shape}^{- 1} (i^{*} with [x] = c_{2}))

4.6.3.12. $shape . vunop$

Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c$ be the result of computing $vunop_{shape} (c_{1})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) shape . vunop ↪ (v128 . const c) (if c = vunop_{shape} (c_{1}))

4.6.3.13. $shape . vbinop$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
If $vbinop_{shape} (c_{1}, c_{2})$ is defined:
1. Let $c$ be a possible result of computing $vbinop_{shape} (c_{1}, c_{2})$ .
2. Push the value $v128 . const c$ to the stack.
Else:
1. Trap.

(v128 . const c_{1}) (v128 . const c_{2}) shape . vbinop (v128 . const c_{1}) (v128 . const c_{2}) shape . vbinop ↪ ↪ (v128 . const c) trap (if c \in vbinop_{shape} (c_{1}, c_{2})) (if vbinop_{shape} (c_{1}, c_{2}) = {})

4.6.3.14. $shape . vternop$

Assert: due to validation, three values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{3}$ from the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $c$ be the result of computing $vternop_{shape} (c_{1}, c_{2}, c_{3})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (v128 . const c_{2}) (v128 . const c_{3}) v128 . vternop ↪ (v128 . const c) (if c = vternop_{shape} (c_{1}, c_{2}, c_{3}))

4.6.3.15. $t x N . relaxed_laneselect$

Assert: due to validation, three values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{3}$ from the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $N$ be the bit width $∣t∣$ of value type $t$ .
Let $c$ be the result of computing $irelaxed_laneselect_{t x N} (c_{1}, c_{2}, c_{3})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (v128 . const c_{2}) (v128 . const c_{3}) v128 . relaxed_laneselect ↪ (v128 . const c) (if c = irelaxed_laneselect_{t x N} (c_{1}, c_{2}, c_{3})^{*}

4.6.3.16. $t x N . vrelop$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i_{1}^{*}$ be the result of computing $lanes_{t x N} (c_{1})$ .
Let $i_{2}^{*}$ be the result of computing $lanes_{t x N} (c_{2})$ .
Let $i^{*}$ be the result of computing $vrelop_{t} (i_{1}^{*}, i_{2}^{*})$ .
Let $j^{*}$ be the result of computing $extend^{s}_{1, ∣t∣} (i^{*})$ .
Let $c$ be the result of computing $lanes_{t x N}^{- 1} (j^{*})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (v128 . const c_{2}) t x N . vrelop ↪ (v128 . const c) (if c = lanes_{t x N}^{- 1} (extend^{s}_{1, ∣ t ∣} (vrelop_{t} (lanes_{t x N} (c_{1}), lanes_{t x N} (c_{2})))))

4.6.3.17. $t x N . vishiftop$

Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const s$ from the stack.
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t x N} (c_{1})$ .
Let $j^{*}$ be the result of computing $vishiftop_{t} (i^{*}, s^{N})$ .
Let $c$ be the result of computing $lanes_{t x N}^{- 1} (j^{*})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) (i32 . const s) t x N . vishiftop ↪ (v128 . const c) (if \land i^{*} = lanes_{t x N} (c_{1}) c = lanes_{t x N}^{- 1} (vishiftop_{t} (i^{*}, s^{N})))

4.6.3.18. $shape . all_true$

Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c$ from the stack.
Let $i_{1}^{*}$ be the result of computing $lanes_{shape} (c)$ .
Let $i$ be the result of computing $bool (⋀ (i_{1} \neq = 0)^{*})$ .
Push the value $i32 . const i$ onto the stack.

(v128 . const c) shape . all_true ↪ (i32 . const i) (if \land i_{1}^{*} = lanes_{shape} (c) i = bool (⋀ (i_{1} \neq = 0)^{*}))

4.6.3.19. $t x N . bitmask$

Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c$ from the stack.
Let $i_{1}^{N}$ be the result of computing $lanes_{t x N} (c)$ .
Let $B$ be the bit width $∣t∣$ of value type $t$ .
Let $i_{2}^{N}$ be the result of computing $ilt_s_{B} (i_{1}^{N}, 0^{N})$ .
Let $j^{*}$ be the concatenation of the two sequences $i_{2}^{N}$ and $0^{32 - N}$ .
Let $i$ be the result of computing $ibits_{32}^{- 1} (j^{*})$ .
Push the value $i32 . const i$ onto the stack.

(v128 . const c) t x N . bitmask ↪ (i32 . const i) (if i = ibits_{32}^{- 1} (ilt_s_{∣ t ∣} (lanes_{t x N} (c), (0)^{N}) (0)^{32 - N}))

4.6.3.20. $t_{2} x N . narrow_t_{1} x M_sx$

Assert: due to syntax, $N = 2 \cdot M$ .
Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Let $i_{2}^{M}$ be the result of computing $lanes_{t_{1} x M} (c_{2})$ .
Let $d_{2}^{M}$ be the result of computing $narrow_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (i_{2}^{M})$ .
Pop the value $v128 . const c_{1}$ from the stack.
Let $i_{1}^{M}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
Let $d_{1}^{M}$ be the result of computing $narrow_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (i_{1}^{M})$ .
Let $j^{N}$ be the concatenation of the two sequences $d_{1}^{M}$ and $d_{2}^{M}$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (j^{N})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) t_{2} x N . narrow_t_{1} x M_sx ↪ (v128 . const c) (if \land \land d_{1}^{M} = narrow_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (lanes_{t_{1} x M} (c_{1})) d_{2}^{M} = narrow_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (lanes_{t_{1} x M} (c_{2})) c = lanes_{t_{2} x N}^{- 1} (d_{1}^{M} d_{2}^{M}))

4.6.3.21. $t_{2} x N . vcvtop_t_{1} x M_sx$

Assert: due to syntax, $N = M$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
Let $j^{*}$ be the result of computing $vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (i^{*})$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (j^{*})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) t_{2} x N . vcvtop_t_{1} x M_sx ↪ (v128 . const c) (if c = lanes_{t_{2} x N}^{- 1} (vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (lanes_{t_{1} x M} (c_{1}))))

4.6.3.22. $t_{2} x N . vcvtop_half_t_{1} x M_sx^{?}$

Assert: due to syntax, $N = M/2$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
If $half$ is $low$ , then:
1. Let $j^{*}$ be the sequence $i^{*} [0 : N]$ .
Else:
1. Let $j^{*}$ be the sequence $i^{*} [N : N]$ .
Let $k^{*}$ be the result of computing $vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx^{?}} (j^{*})$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (k^{*})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) t_{2} x N . vcvtop_half_t_{1} x M_sx^{?} ↪ (v128 . const c) (if c = lanes_{t_{2} x N}^{- 1} (vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx^{?}} (lanes_{t_{1} x M} (c_{1}) [half (0, N) : N])))

where:

low (x, y) high (x, y) = = x y

4.6.3.23. $t_{2} x N . vcvtop_t_{1} x M_sx^{?}_zero$

Assert: due to syntax, $N = 2 \cdot M$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
Let $j^{*}$ be the result of computing $vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx^{?}} (i^{*})$ .
Let $k^{*}$ be the concatenation of the two sequences $j^{*}$ and $0^{M}$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (k^{*})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) t_{2} x N . vcvtop_t_{1} x M_sx^{?}_zero ↪ (v128 . const c) (if c = lanes_{t_{2} x N}^{- 1} (vcvtop_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx^{?}} (lanes_{t_{1} x M} (c_{1})) 0^{M}))

4.6.3.24. $i32x4. dot_i16x8_s$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i_{1}^{*}$ be the result of computing $lanes_{i16x8} (c_{1})$ .
Let $j_{1}^{*}$ be the result of computing $extend^{s}_{16, 32} (i_{1}^{*})$ .
Let $i_{2}^{*}$ be the result of computing $lanes_{i16x8} (c_{2})$ .
Let $j_{2}^{*}$ be the result of computing $extend^{s}_{16, 32} (i_{2}^{*})$ .
Let $(k_{1} k_{2})^{*}$ be the result of computing $imul_{32} (j_{1}^{*}, j_{2}^{*})$ .
Let $k^{*}$ be the result of computing $iadd_{32} (k_{1}, k_{2})^{*}$ .
Let $c$ be the result of computing $lanes_{i32x4}^{- 1} (k^{*})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) i32x4. dot_i16x8_s ↪ (v128 . const c) (if \land \land (i_{1} i_{2})^{*} = imul_{32} (extend^{s}_{16, 32} (lanes_{i16x8} (c_{1})), extend^{s}_{16, 32} (lanes_{i16x8} (c_{2}))) j^{*} = iadd_{32} (i_{1}, i_{2})^{*} c = lanes_{i32x4}^{- 1} (j^{*}))

4.6.3.25. $i16x8. relaxed_dot_i8x16_i7x16_s$

Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $(i_{1} i_{2})^{8}$ be the result of computing $irelaxed_dot_mul_{8, 16} (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2}))$
Let $j^{8}$ be the result of computing $iadd_sat_s_{16} (i_{1}, i_{2})^{8}$ .
Let $c$ be the result of computing $lanes_{i16x8}^{- 1} (j^{8})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) i16x8. relaxed_dot_i8x16_i7x16_s ↪ (v128 . const c) (if \land \land (i_{1} i_{2})^{8} = irelaxed_dot_mul_{8, 16} (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2})) j^{8} = iadd_sat_s_{16} (i_{1}, i_{2})^{8} c = lanes_{i16x8}^{- 1} (j^{8}))

4.6.3.26. $i32x4. relaxed_dot_i8x16_i7x16_add_s$

Assert: due to validation, three values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{3}$ from the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $(i_{1} i_{2})^{8}$ be the result of computing $irelaxed_dot_mul_{8, 16} (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2}))$
Let $(j_{1} j_{2})^{4}$ be the result of computing $iadd_sat_s_{16} (i_{1}, i_{2})^{8}$ .
Let $j^{4}$ be the result of computing $iadd_{32} (extend^{s}_{16, 32} (j_{1}), extend^{s}_{16, 32} (j_{2}))^{4}$ .
Let $k^{4}$ be the result of computing $lanes_{i32x4} (c_{3})$ .
Let $l^{4}$ be the result of computing $iadd_{32} (j, k)^{4}$ .
Let $c$ be the result of computing $lanes_{i32x4}^{- 1} (l^{4})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) (v128 . const c_{3}) i32x4. relaxed_dot_i8x16_i7x16_add_s ↪ (v128 . const c) (if \land \land \land \land \land (i_{1} i_{2})^{8} = irelaxed_dot_mul_{8, 16} (lanes_{i8x16} (c_{1}), lanes_{i8x16} (c_{2})) (j_{1} j_{2})^{4} = iadd_sat_s_{16} (i_{1}, i_{2})^{8} j^{4} = iadd_{32} (extend^{s}_{16, 32} (j_{1}), extend^{s}_{16, 32} (j_{2}))^{4} k^{4} = lanes_{i32x4} (c_{3}) l^{4} = iadd_{32} (j, k)^{4} c = lanes_{i32x4}^{- 1} (l^{4}))

4.6.3.27. $t_{2} x N . extmul_half_t_{1} x M_sx$

Assert: due to syntax, $N = M/2$ .
Assert: due to validation, two values of value type $v128$ are on the top of the stack.
Pop the value $v128 . const c_{2}$ from the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i_{1}^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
Let $i_{2}^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{2})$ .
If $half$ is $low$ , then:
1. Let $j_{1}^{*}$ be the sequence $i_{1}^{*} [0 : N]$ .
2. Let $j_{2}^{*}$ be the sequence $i_{2}^{*} [0 : N]$ .
Else:
1. Let $j_{1}^{*}$ be the sequence $i_{1}^{*} [N : N]$ .
2. Let $j_{2}^{*}$ be the sequence $i_{2}^{*} [N : N]$ .
Let $k_{1}^{*}$ be the result of computing $extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (j_{1}^{*})$ .
Let $k_{2}^{*}$ be the result of computing $extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (j_{2}^{*})$ .
Let $k^{*}$ be the result of computing $imul_{∣ t_{2} ∣} (k_{1}^{*}, k_{2}^{*})$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (k^{*})$ .
Push the value $v128 . const c$ onto the stack.

(v128 . const c_{1}) (v128 . const c_{2}) t_{2} x N . extmul_half_t_{1} x M_sx ↪ (v128 . const c) (if \land \land i^{*} = lanes_{t_{1} x M} (c_{1}) [half (0, N) : N] j^{*} = lanes_{t_{1} x M} (c_{2}) [half (0, N) : N] c = lanes_{t_{2} x N}^{- 1} (imul_{∣ t_{2} ∣} (extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (i^{*}), extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (j^{*}))))

where:

low (x, y) high (x, y) = = x y

4.6.3.28. $t_{2} x N . extadd_pairwise_t_{1} x M_sx$

Assert: due to syntax, $N = M/2$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c_{1}$ from the stack.
Let $i^{*}$ be the result of computing $lanes_{t_{1} x M} (c_{1})$ .
Let $(j_{1} j_{2})^{*}$ be the result of computing $extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (i^{*})$ .
Let $k^{*}$ be the result of computing $iadd_{∣ t_{2} ∣} (j_{1}, j_{2})^{*}$ .
Let $c$ be the result of computing $lanes_{t_{2} x N}^{- 1} (k^{*})$ .
Push the value $v128 . const c$ to the stack.

(v128 . const c_{1}) t_{2} x N . extadd_pairwise_t_{1} x M_sx ↪ (v128 . const c) (if \land \land (i_{1} i_{2})^{*} = extend_{∣ t_{1} ∣, ∣ t_{2} ∣}^{sx} (lanes_{t_{1} x M} (c_{1})) j^{*} = iadd_{∣ t_{2} ∣} (i_{1}, i_{2})^{*} c = lanes_{t_{2} x N}^{- 1} (j^{*}))

4.6.4. Parametric Instructions

4.6.4.1. $drop$

Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.

val drop ↪ ϵ

4.6.4.2. $select (t^{*})^{?}$

Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const c$ from the stack.
Assert: due to validation, two more values (of the same value type) are on the top of the stack.
Pop the value $val_{2}$ from the stack.
Pop the value $val_{1}$ from the stack.
If $c$ is not $0$ , then:
1. Push the value $val_{1}$ back to the stack.
Else:
1. Push the value $val_{2}$ back to the stack.

val_{1} val_{2} (i32 . const c) (select t^{?}) val_{1} val_{2} (i32 . const c) (select t^{?}) ↪ ↪ val_{1} val_{2} (if c \neq = 0) (if c = 0)

Note

In future versions of WebAssembly, $select$ may allow more than one value per choice.

4.6.5. Variable Instructions

4.6.5.1. $local.get x$

Let $F$ be the current frame.
Assert: due to validation, $F. locals [x]$ exists and is non-empty.
Let $val$ be the value $F. locals [x]$ .
Push the value $val$ to the stack.

F; (local.get x) ↪ F; val (if F . locals [x] = val)

4.6.5.2. $local.set x$

Let $F$ be the current frame.
Assert: due to validation, $F. locals [x]$ exists.
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Replace $F. locals [x]$ with the value $val$ .

F; val (local.set x) ↪ F^{'}; ϵ (if F^{'} = F with locals [x] = val)

4.6.5.3. $local.tee x$

Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Push the value $val$ to the stack.
Push the value $val$ to the stack.
Execute the instruction $local.set x$ .

val (local.tee x) ↪ val val (local.set x)

4.6.5.4. $global.get x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . globaladdrs [x]$ exists.
Let $a$ be the global address $F. module . globaladdrs [x]$ .
Assert: due to validation, $S. globals [a]$ exists.
Let $glob$ be the global instance $S. globals [a]$ .
Let $val$ be the value $glob . value$ .
Push the value $val$ to the stack.

S; F; (global.get x) ↪ S; F; val (if S . globals [F . module . globaladdrs [x]] . value = val)

4.6.5.5. $global.set x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . globaladdrs [x]$ exists.
Let $a$ be the global address $F. module . globaladdrs [x]$ .
Assert: due to validation, $S. globals [a]$ exists.
Let $glob$ be the global instance $S. globals [a]$ .
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Replace $glob . value$ with the value $val$ .

S; F; val (global.set x) ↪ S^{'}; F; ϵ (if S^{'} = S with globals [F . module . globaladdrs [x]] . value = val)

Note

Validation ensures that the global is, in fact, marked as mutable.

4.6.6. Table Instructions

4.6.6.1. $table.get x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $a$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [a]$ exists.
Let $tab$ be the table instance $S. tables [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
If $i$ is not smaller than the length of $tab . elem$ , then:
1. Trap.
Let $val$ be the value $tab . elem [i]$ .
Push the value $val$ to the stack.

S; F; (at . const i) (table.get x) ↪ S; F; val (if S . tables [F . module . tableaddrs [x]] . elem [i] = val) S; F; (at . const i) (table.get x) ↪ S; F; trap (otherwise)

4.6.6.2. $table.set x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $a$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [a]$ exists.
Let $tab$ be the table instance $S. tables [a]$ .
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
If $i$ is not smaller than the length of $tab . elem$ , then:
1. Trap.
Replace the element $tab . elem [i]$ with $val$ .

S; F; (at . const i) val (table.set x) ↪ S^{'}; F; ϵ (if S^{'} = S with tables [F . module . tableaddrs [x]] . elem [i] = val) S; F; (at . const i) val (table.set x) ↪ S; F; trap (otherwise)

4.6.6.3. $table.size x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $a$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [a]$ exists.
Let $tab$ be the table instance $S. tables [a]$ .
Let $at limits$ be the table type $tab . type$ .
Let $sz$ be the length of $tab . elem$ .
Push the value $at . const sz$ to the stack.

S; F; (table.size x) ↪ S; F; (at . const sz) (if ∣ S . tables [F . module . tableaddrs [x]] . elem ∣ = sz \land S . tables [F . module . tableaddrs [x]] . type = at lim t)

4.6.6.4. $table.grow x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $a$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [a]$ exists.
Let $tab$ be the table instance $S. tables [a]$ .
Let $sz$ be the length of $S. tables [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $t. const n$ from the stack.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $val$ from the stack.
Let $err$ be the value $2^{∣ at ∣} - 1$ , for which $signed_{∣ at ∣} (err)$ is $- 1$ .
Either:

If growing $tab$ by $n$ entries with initialization value $val$ succeeds, then:

Push the value $at . const sz$ to the stack.

Else:

Push the value $at . const err$ to the stack.

push the value $at . const err$ to the stack.

S; F; val (at . const n) (table.grow x) ↪ S^{'}; F; (at . const sz) (if \land \land F . module . tableaddrs [x] = a sz = ∣ S . tables [a] . elem ∣ S^{'} = S with tables [a] = growtable (S . tables [a], n, val)) 1 e x] 1 e x] S; F; val (at . const n) (table.grow x) ↪ S; F; (at . const signed_{∣ at ∣}^{- 1} (- 1))

Note

The $table.grow$ instruction is non-deterministic. It may either succeed, returning the old table size $sz$ , or fail, returning $- 1$ . Failure must occur if the referenced table instance has a maximum size defined that would be exceeded. However, failure can occur in other cases as well. In practice, the choice depends on the resources available to the embedder.

4.6.6.5. $table.fill x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $ta$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [ta]$ exists.
Let $tab$ be the table instance $S. tables [ta]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const n$ from the stack.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
If $i + n$ is larger than the length of $tab . elem$ , then:
1. Trap.
If $n$ is $0$ , then:
1. Return.
Push the value $at . const i$ to the stack.
Push the value $val$ to the stack.
Execute the instruction $table.set x$ .
Push the value $at . const (i + 1)$ to the stack.
Push the value $val$ to the stack.
Push the value $at . const (n - 1)$ to the stack.
Execute the instruction $table.fill x$ .

S; F; (at . const i) val (at . const n) (table.fill x) ↪ S; F; trap (if i + n > ∣ S . tables [F . module . tableaddrs [x]] . elem ∣) 1 e x] 1 e x] S; F; (at . const i) val (at . const 0) (table.fill x) ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at . const i) val (at . const n + 1) (table.fill x) ↪ S; F; (at . const i) val (table.set x) (at . const i + 1) val (at . const n) (table.fill x) (otherwise)

4.6.6.6. $table.copy x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $ta_{x}$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [ta_{x}]$ exists.
Let $tab_{x}$ be the table instance $S. tables [ta_{x}]$ .
Assert: due to validation, $F. module . tableaddrs [y]$ exists.
Let $ta_{y}$ be the table address $F. module . tableaddrs [y]$ .
Assert: due to validation, $S. tables [ta_{y}]$ exists.
Let $tab_{y}$ be the table instance $S. tables [ta_{y}]$ .
Assert: due to validation, a value of some address type $at_{n}$ is on the top of the stack.
Pop the value $at_{n} . const n$ from the stack.
Assert: due to validation, a value of some address type $at_{s}$ is on the top of the stack.
Pop the value $at_{s} . const s$ from the stack.
Assert: due to validation, a value of some address type $at_{d}$ is on the top of the stack.
Pop the value $at_{d} . const d$ from the stack.
If $s + n$ is larger than the length of $tab_{y} . elem$ or $d + n$ is larger than the length of $tab_{x} . elem$ , then:
1. Trap.

If $n = 0$ , then:

Return.

If $d \leq s$ , then:

Push the value $at_{d} . const d$ to the stack.

Push the value $at_{s} . const s$ to the stack.

Execute the instruction $table.get y$ .

Execute the instruction $table.set x$ .

Assert: due to the earlier check against the table size, $d + 1 < 2^{32}$ .

Push the value $at_{d} . const (d + 1)$ to the stack.

Assert: due to the earlier check against the table size, $s + 1 < 2^{32}$ .

Push the value $at_{s} . const (s + 1)$ to the stack.

Else:

Assert: due to the earlier check against the table size, $d + n - 1 < 2^{32}$ .

Push the value $at_{d} . const (d + n - 1)$ to the stack.

Assert: due to the earlier check against the table size, $s + n - 1 < 2^{32}$ .

Push the value $at_{s} . const (s + n - 1)$ to the stack.

Execute the instruction $table.get y$ .

Execute the instruction $table.set x$ .

Push the value $at_{d} . const d$ to the stack.

Push the value $at_{s} . const s$ to the stack.

Push the value $at_{n} . const (n - 1)$ to the stack.
Execute the instruction $table.copy x y$ .

S; F; (at_{d} . const d) (at_{s} . const s) (at_{n} . const n) (table.copy x y) ↪ S; F; trap (if \lor s + n > ∣ S . tables [F . module . tableaddrs [y]] . elem ∣ d + n > ∣ S . tables [F . module . tableaddrs [x]] . elem ∣) 1 e x] 1 e x] S; F; (at_{d} . const d) (at_{s} . const s) (at_{n} . const 0) (table.copy x y) ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at_{d} . const d) (at_{s} . const s) (at_{n} . const n + 1) (table.copy x y) ↪ S; F; (at_{d} . const d) (at_{s} . const s) (table.get y) (table.set x) (at_{d} . const d + 1) (at_{s} . const s + 1) (at_{n} . const n) (table.copy x y) (otherwise, if d \leq s) 1 e x] S; F; (at_{d} . const d) (at_{s} . const s) (at_{n} . const n + 1) (table.copy x y) ↪ S; F; (at_{d} . const d + n) (at_{s} . const s + n) (table.get y) (table.set x) (at_{d} . const d) (at_{s} . const s) (at_{n} . const n) (table.copy x y) (otherwise, if d > s)

4.6.6.7. $table.init x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $ta$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [ta]$ exists.
Let $tab$ be the table instance $S. tables [ta]$ .
Assert: due to validation, $F. module . elemaddrs [y]$ exists.
Let $ea$ be the element address $F. module . elemaddrs [y]$ .
Assert: due to validation, $S. elems [ea]$ exists.
Let $elem$ be the element instance $S. elems [ea]$ .
Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const s$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const d$ from the stack.
If $s + n$ is larger than the length of $elem . elem$ or $d + n$ is larger than the length of $tab . elem$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Let $val$ be the reference value $elem . elem [s]$ .
Push the value $at . const d$ to the stack.
Push the value $val$ to the stack.
Execute the instruction $table.set x$ .
Assert: due to the earlier check against the table size, $d + 1 < 2^{32}$ .
Push the value $at . const (d + 1)$ to the stack.
Assert: due to the earlier check against the segment size, $s + 1 < 2^{32}$ .
Push the value $i32 . const (s + 1)$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $table.init x y$ .

S; F; (at . const d) (i32 . const s) (i32 . const n) (table.init x y) ↪ S; F; trap (if \lor s + n > ∣ S . elems [F . module . elemaddrs [y]] . elem ∣ d + n > ∣ S . tables [F . module . tableaddrs [x]] . elem ∣) 1 e x] 1 e x] S; F; (at . const d) (i32 . const s) (i32 . const 0) (table.init x y) ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at . const d) (i32 . const s) (i32 . const n + 1) (table.init x y) ↪ S; F; (at . const d) val (table.set x) (at . const d + 1) (i32 . const s + 1) (i32 . const n) (table.init x y) (otherwise, if val = S . elems [F . module . elemaddrs [y]] . elem [s])

4.6.6.8. $elem.drop x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . elemaddrs [x]$ exists.
Let $a$ be the element address $F. module . elemaddrs [x]$ .
Assert: due to validation, $S. elems [a]$ exists.
Replace $S. elems [a] . elem$ with $ϵ$ .

S; F; (elem.drop x) ↪ S^{'}; F; ϵ (if S^{'} = S with elems [F . module . elemaddrs [x]] . elem = ϵ)

4.6.7. Memory Instructions

Note

The alignment $memarg . align$ in load and store instructions does not affect the semantics. It is an indication that the offset $ea$ at which the memory is accessed is intended to satisfy the property $ea mod 2^{memarg . align} = 0$ . A WebAssembly implementation can use this hint to optimize for the intended use. Unaligned access violating that property is still allowed and must succeed regardless of the annotation. However, it may be substantially slower on some hardware.

4.6.7.1. $t . load x memarg$ and $t . load N_sx x memarg$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $N$ is not part of the instruction, then:
1. Let $N$ be the bit width $∣t∣$ of number type $t$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $mem . data [ea : N/8]$ .
If $N$ and $sx$ are part of the instruction, then:
1. Let $n$ be the integer for which $bytes_{i N} (n) = b^{*}$ .
2. Let $c$ be the result of computing $extend_{N, ∣t∣}^{sx} (n)$ .
Else:
1. Let $c$ be the constant for which $bytes_{t} (c) = b^{*}$ .
Push the value $t. const c$ to the stack.

S; F; (at . const i) (t . load x memarg) ↪ S; F; (t . const c) (if \land \land ea = i + memarg . offset ea + ∣ t ∣/8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{t} (c) = S . mems [F . module . memaddrs [x]] . data [ea : ∣ t ∣/8]) 1 e x] 1 e x] S; F; (at . const i) (t . load N_sx x memarg) ↪ S; F; (t . const extend_{N, ∣ t ∣}^{sx} (n)) (if \land \land ea = i + memarg . offset ea + N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{i N} (n) = S . mems [F . module . memaddrs [x]] . data [ea : N /8]) 1 e x] 1 e x] S; F; (at . const i) (t . load (N_sx)^{?} x memarg) ↪ S; F; trap (otherwise)

4.6.7.2. $v128 . load M x N_sx x memarg$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $ea + M \cdot N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $mem . data [ea : M \cdot N/8]$ .
Let $m_{k}$ be the integer for which $bytes_{i M} (m_{k}) = b^{*} [k \cdot M/8 : M/8]$ .
Let $W$ be the integer $M \cdot 2$ .
Let $n_{k}$ be the result of computing $extend_{M, W}^{sx} (m_{k})$ .
Let $c$ be the result of computing $lanes_{i W x N}^{- 1} (n_{0} \dots n_{N - 1})$ .
Push the value $v128 . const c$ to the stack.

S; F; (at . const i) (v128 . load M x N_sx x memarg) ↪ S; F; (v128 . const c) (if \land \land \land \land ea = i + memarg . offset ea + M \cdot N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{i M} (m_{k}) = S . mems [F . module . memaddrs [x]] . data [ea + k \cdot M /8 : M /8]) W = M \cdot 2 c = lanes_{i W x N}^{- 1} (extend_{M, W}^{sx} (m_{0}) \dots extend_{M, W}^{sx} (m_{N - 1}))) 1 e x] S; F; (at . const i) (v128 . load M x N_sx x memarg) ↪ S; F; trap (otherwise)

4.6.7.3. $v128 . load N_splat x memarg$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $mem . data [ea : N/8]$ .
Let $n$ be the integer for which $bytes_{i N} (n) = b^{*}$ .
Let $L$ be the integer $128/N$ .
Let $c$ be the result of computing $lanes_{i N x L}^{- 1} (n^{L})$ .
Push the value $v128 . const c$ to the stack.

S; F; (at . const i) (v128 . load N_splat x memarg) ↪ S; F; (v128 . const c) (if \land \land \land ea = i + memarg . offset ea + N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{i N} (n) = S . mems [F . module . memaddrs [x]] . data [ea : N /8] c = lanes_{i N x L}^{- 1} (n^{L})) 1 e x] S; F; (at . const i) (v128 . load N_splat x memarg) ↪ S; F; trap (otherwise)

4.6.7.4. $v128 . load N_zero x memarg$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $mem . data [ea : N/8]$ .
Let $n$ be the integer for which $bytes_{i N} (n) = b^{*}$ .
Let $c$ be the result of computing $extend^{u}_{N, 128} (n)$ .
Push the value $v128 . const c$ to the stack.

S; F; (at . const i) (v128 . load N_zero x memarg) ↪ S; F; (v128 . const c) (if \land \land \land ea = i + memarg . offset ea + N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{i N} (n) = S . mems [F . module . memaddrs [x]] . data [ea : N /8]) c = extend^{u}_{N, 128} (n) 1 e x] S; F; (at . const i) (v128 . load N_zero x memarg) ↪ S; F; trap (otherwise)

4.6.7.5. $v128 . load N_lane x memarg y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const v$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $b^{*}$ be the byte sequence $mem . data [ea : N/8]$ .
Let $r$ be the constant for which $bytes_{i N} (r) = b^{*}$ .
Let $L$ be $128/N$ .
Let $j^{*}$ be the result of computing $lanes_{i N x L} (v)$ .
Let $c$ be the result of computing $lanes_{i N x L}^{- 1} (j^{*} with [y] = r)$ .
Push the value $v128 . const c$ to the stack.

S; F; (at . const i) (v128 . const v) (v128 . load N_lane x memarg y) ↪ S; F; (v128 . const c) (if \land \land \land \land ea = i + memarg . offset ea + N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ bytes_{i N} (r) = S . mems [F . module . memaddrs [x]] . data [ea : N /8]) L = 128/ N c = lanes_{i N x L}^{- 1} (lanes_{i N x L} (v) with [y] = r)) 1 e x] S; F; (at . const i) (v128 . const v) (v128 . load N_lane x memarg y) ↪ S; F; trap (otherwise)

4.6.7.6. $t . store x memarg$ and $t . store N x memarg$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of value type $t$ is on the top of the stack.
Pop the value $t. const c$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $N$ is not part of the instruction, then:
1. Let $N$ be the bit width $∣t∣$ of number type $t$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
If $N$ is part of the instruction, then:
1. Let $n$ be the result of computing $wrap_{∣t∣, N} (c)$ .
2. Let $b^{*}$ be the byte sequence $bytes_{i N} (n)$ .
Else:
1. Let $b^{*}$ be the byte sequence $bytes_{t} (c)$ .
Replace the bytes $mem . data [ea : N/8]$ with $b^{*}$ .

S; F; (at . const i) (t . const c) (t . store x memarg) ↪ S^{'}; F; ϵ (if \land \land ea = i + memarg . offset ea + ∣ t ∣/8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ S^{'} = S with mems [F . module . memaddrs [x]] . data [ea : ∣ t ∣/8] = bytes_{t} (c)) 1 e x] 1 e x] S; F; (at . const i) (t . const c) (t . store N x memarg) ↪ S^{'}; F; ϵ (if \land \land ea = i + memarg . offset ea + N /8 \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ S^{'} = S with mems [F . module . memaddrs [x]] . data [ea : N /8] = bytes_{i N} (wrap_{∣ t ∣, N} (c)) 1 e x] 1 e x] S; F; (at . const i) (t . const c) (t . store N^{?} x memarg) ↪ S; F; trap (otherwise)

4.6.7.7. $v128 . store N_lane x memarg y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Assert: due to validation, a value of value type $v128$ is on the top of the stack.
Pop the value $v128 . const c$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const i$ from the stack.
Let $ea$ be the integer $i + memarg . offset$ .
If $ea + N/8$ is larger than the length of $mem . data$ , then:
1. Trap.
Let $L$ be $128/N$ .
Let $j^{*}$ be the result of computing $lanes_{i N x L} (c)$ .
Let $b^{*}$ be the result of computing $bytes_{i N} (j^{*} [y])$ .
Replace the bytes $mem . data [ea : N/8]$ with $b^{*}$ .

S; F; (at . const i) (v128 . const c) (v128 . store N_lane x memarg y) ↪ S^{'}; F; ϵ (if \land \land \land ea = i + memarg . offset ea + N \leq ∣ S . mems [F . module . memaddrs [x]] . data ∣ L = 128/ N S^{'} = S with mems [F . module . memaddrs [x]] . data [ea : N /8] = bytes_{i N} (lanes_{i N x L} (c) [y])) 1 e x] S; F; (at . const i) (v128 . const c) (v128 . store N_lane x memarg y) ↪ S; F; trap (otherwise)

4.6.7.8. $memory.size x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Let $at limits$ be the memory type $mem . type$ .
Let $sz$ be the length of $mem . data$ divided by the page size.
Push the value $at . const sz$ to the stack.

S; F; (memory.size x) ↪ S; F; (at . const sz) (if ∣ S . mems [F . module . memaddrs [x]] . data ∣ = sz \cdot 64 Ki \land S . mems [F . module . memaddrs [x]] . type = at lim)

4.6.7.9. $memory.grow x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $a$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [a]$ exists.
Let $mem$ be the memory instance $S. mems [a]$ .
Let $sz$ be the length of $S. mems [a]$ divided by the page size.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const n$ from the stack.
Let $err$ be the $at$ value $2^{∣ at ∣} - 1$ , for which $signed_{∣ at ∣} (err)$ is $- 1$ .
Either:

If growing $mem$ by $n$ pages succeeds, then:

Push the value $at . const sz$ to the stack.

Else:

Push the value $at . const err$ to the stack.

Push the value $at . const err$ to the stack.

S; F; (at . const n) (memory.grow x) ↪ S^{'}; F; (at . const sz) (if \land \land F . module . memaddrs [x] = a sz = ∣ S . mems [a] . data ∣/64 Ki S^{'} = S with mems [a] = growmem (S . mems [a], n)) 1 e x] 1 e x] S; F; (at . const n) (memory.grow x) ↪ S; F; (at . const signed_{∣ at ∣}^{- 1} (- 1))

Note

The $memory.grow$ instruction is non-deterministic. It may either succeed, returning the old memory size $sz$ , or fail, returning $- 1$ . Failure must occur if the referenced memory instance has a maximum size defined that would be exceeded. However, failure can occur in other cases as well. In practice, the choice depends on the resources available to the embedder.

4.6.7.10. $memory.fill x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $ma$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [ma]$ exists.
Let $mem$ be the memory instance $S. mems [ma]$ .
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const n$ from the stack.
Assert: due to validation, a value is on the top of the stack.
Pop the value $val$ from the stack.
Assert: due to validation, a value of address type $at$ is on the top of the stack.
Pop the value $at . const d$ from the stack.
If $d + n$ is larger than the length of $mem . data$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Push the value $i32 . const d$ to the stack.
Push the value $val$ to the stack.
Execute the instruction $at . store 8 {offset 0, align 0}$ .
Assert: due to the earlier check against the memory size, $d + 1 < 2^{32}$ .
Push the value $at . const (d + 1)$ to the stack.
Push the value $val$ to the stack.
Push the value $at . const (n - 1)$ to the stack.
Execute the instruction $memory.fill x$ .

S; F; (at . const d) val (at . const n) memory.fill x ↪ S; F; trap (if d + n > ∣ S . mems [F . module . memaddrs [x]] . data ∣) 1 e x] S; F; (at . const d) val (at . const 0) memory.fill x ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at . const d) val (at . const n + 1) memory.fill x ↪ S; F; (at . const d) val (at . store 8 x {offset 0, align 0}) (at . const d + 1) val (at . const n) memory.fill x (otherwise)

4.6.7.11. $memory.copy x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Assert: due to validation, $F. module . memaddrs [y]$ exists.
Let $da$ be the memory address $F. module . memaddrs [x]$ .
Let $sa$ be the memory address $F. module . memaddrs [y]$ .
Assert: due to validation, $S. mems [da]$ exists.
Assert: due to validation, $S. mems [sa]$ exists.
Let $mem_{d}$ be the memory instance $S. mems [da]$ .
Let $mem_{s}$ be the memory instance $S. mems [sa]$ .
Assert: due to validation, a value of some address type $at_{n}$ is on the top of the stack.
Pop the value $at_{n} . const n$ from the stack.
Assert: due to validation, a value of some address type $at_{s}$ is on the top of the stack.
Pop the value $at_{s} . const s$ from the stack.
Assert: due to validation, a value of some address type $at_{d}$ is on the top of the stack.
Pop the value $at_{d} . const d$ from the stack.
If $s + n$ is larger than the length of $mem_{s} . data$ or $d + n$ is larger than the length of $mem_{d} . data$ , then:
1. Trap.
If $n = 0$ , then:

Return.

If $d \leq s$ , then:

Push the value $at_{d} . const d$ to the stack.

Push the value $at_{s} . const s$ to the stack.

Execute the instruction $i32 . load 8_u y {offset 0, align 0}$ .

Execute the instruction $i32 . store 8 x {offset 0, align 0}$ .

Assert: due to the earlier check against the memory size, $d + 1 < 2^{32}$ .

Push the value $at_{d} . const (d + 1)$ to the stack.

Assert: due to the earlier check against the memory size, $s + 1 < 2^{32}$ .

Push the value $at_{s} . const (s + 1)$ to the stack.

Else:

Assert: due to the earlier check against the memory size, $d + n - 1 < 2^{32}$ .

Push the value $at_{d} . const (d + n - 1)$ to the stack.

Assert: due to the earlier check against the memory size, $s + n - 1 < 2^{32}$ .

Push the value $at_{s} . const (s + n - 1)$ to the stack.

Execute the instruction $i32 . load 8_u y {offset 0, align 0}$ .

Execute the instruction $i32 . store 8 x {offset 0, align 0}$ .

Push the value $at_{d} . const d$ to the stack.

Push the value $at_{s} . const s$ to the stack.

Push the value $at_{n} . const (n - 1)$ to the stack.
Execute the instruction $memory.copy x y$ .

S; F; (at_{x} . const d) (at_{y} . const s) (at_{n} . const n) memory.copy x y ↪ S; F; trap (if \lor (d + n > ∣ S . mems [F . module . memaddrs [x]] . data ∣ s + n > ∣ S . mems [F . module . memaddrs [y]] . data ∣)) 1 e x] S; F; (at_{x} . const d) (at_{y} . const s) (at_{n} . const 0) memory.copy x y ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at_{x} . const d) (at_{y} . const s) (at_{n} . const n + 1) memory.copy x y ↪ S; F; (at_{x} . const d) (at_{y} . const s) (i32 . load 8_u y {offset 0, align 0}) (i32 . store 8 x {offset 0, align 0}) (at_{x} . const d + 1) (at_{y} . const s + 1) (at_{n} . const n) memory.copy x y (otherwise, if d \leq s) 1 e x] S; F; (at_{x} . const d) (at_{y} . const s) (at_{n} . const n + 1) memory.copy x y ↪ S; F; (at_{x} . const d + n) (at_{y} . const s + n) (i32 . load 8_u y {offset 0, align 0}) (i32 . store 8 x {offset 0, align 0}) (at_{x} . const d) (at_{y} . const s) (at_{n} . const n) memory.copy x y (otherwise, if d > s)

4.6.7.12. $memory.init x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . memaddrs [x]$ exists.
Let $ma$ be the memory address $F. module . memaddrs [x]$ .
Assert: due to validation, $S. mems [ma]$ exists.
Let $mem$ be the memory instance $S. mems [ma]$ .
Assert: due to validation, $F. module . dataaddrs [y]$ exists.
Let $da$ be the data address $F. module . dataaddrs [y]$ .
Assert: due to validation, $S. datas [da]$ exists.
Let $data$ be the data instance $S. datas [da]$ .
Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const n$ from the stack.
Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const s$ from the stack.
Assert: due to validation, a value of some address type $at$ is on the top of the stack.
Pop the value $at . const d$ from the stack.
If $s + n$ is larger than the length of $data . data$ or $d + n$ is larger than the length of $mem . data$ , then:
1. Trap.
If $n = 0$ , then:
1. Return.
Let $b$ be the byte $data . data [s]$ .
Push the value $at . const d$ to the stack.
Push the value $i32 . const b$ to the stack.
Execute the instruction $i32 . store 8 x {offset 0, align 0}$ .
Assert: due to the earlier check against the memory size, $d + 1 < 2^{32}$ .
Push the value $at . const (d + 1)$ to the stack.
Assert: due to the earlier check against the memory size, $s + 1 < 2^{32}$ .
Push the value $i32 . const (s + 1)$ to the stack.
Push the value $i32 . const (n - 1)$ to the stack.
Execute the instruction $memory.init x y$ .

S; F; (at . const d) (i32 . const s) (i32 . const n) (memory.init x y) ↪ S; F; trap (if \lor d + n > ∣ S . mems [F . module . memaddrs [x]] . data ∣ s + n > ∣ S . datas [F . module . dataaddrs [y]] . data ∣) 1 e x] 1 e x] S; F; (at . const d) (i32 . const s) (i32 . const 0) (memory.init x y) ↪ S; F; ϵ (otherwise) 1 e x] S; F; (at . const d) (i32 . const s) (i32 . const n + 1) (memory.init x y) ↪ S; F; (at . const d) (i32 . const b) (i32 . store 8 x {offset 0, align 0}) (at . const d + 1) (i32 . const s + 1) (i32 . const n) (memory.init x y) (otherwise, if b = S . datas [F . module . dataaddrs [y]] . data [s])

4.6.7.13. $data.drop x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . dataaddrs [x]$ exists.
Let $a$ be the data address $F. module . dataaddrs [x]$ .
Assert: due to validation, $S. datas [a]$ exists.
Replace $S. datas [a]$ with the data instance ${data ϵ}$ .

S; F; (data.drop x) ↪ S^{'}; F; ϵ (if S^{'} = S with datas [F . module . dataaddrs [x]] = {data ϵ})

4.6.8. Control Instructions

4.6.8.1. $nop$

Do nothing.

nop ↪ ϵ

4.6.8.2. $unreachable$

Trap.

unreachable ↪ trap

4.6.8.3. $block blocktype instr^{*} end$

Let $F$ be the current frame.
Assert: due to validation, $instrtype_{S; F} (blocktype)$ is defined.
Let $[t_{1}^{m}] \to [t_{2}^{n}]$ be the instruction type $instrtype_{S; F} (blocktype)$ .
Let $L$ be the label whose arity is $n$ and whose continuation is the end of the block.
Assert: due to validation, there are at least $m$ values on the top of the stack.
Pop the values $val^{m}$ from the stack.
Enter the block $val^{m} instr^{*}$ with label $L$ .

S; F; val^{m} block bt instr^{*} end ↪ S; F; label_{n} {ϵ} val^{m} instr^{*} end (if instrtype_{S; F} (bt) = [t_{1}^{m}] \to [t_{2}^{n}])

4.6.8.4. $loop blocktype instr^{*} end$

Let $F$ be the current frame.
Assert: due to validation, $instrtype_{S; F} (blocktype)$ is defined.
Let $[t_{1}^{m}] \to [t_{2}^{n}]$ be the instruction type $instrtype_{S; F} (blocktype)$ .
Let $L$ be the label whose arity is $m$ and whose continuation is the start of the loop.
Assert: due to validation, there are at least $m$ values on the top of the stack.
Pop the values $val^{m}$ from the stack.
Enter the block $val^{m} instr^{*}$ with label $L$ .

S; F; val^{m} loop bt instr^{*} end ↪ S; F; label_{m} {loop bt instr^{*} end} val^{m} instr^{*} end (if instrtype_{S; F} (bt) = [t_{1}^{m}] \to [t_{2}^{n}])

4.6.8.5. $if blocktype instr_{1}^{} else instr_{2}^{} end$

Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const c$ from the stack.
If $c$ is non-zero, then:
1. Execute the block instruction $block blocktype instr_{1}^{*} end$ .
Else:
1. Execute the block instruction $block blocktype instr_{2}^{*} end$ .

(i32 . const c) if bt instr_{1}^{*} else instr_{2}^{*} end (i32 . const c) if bt instr_{1}^{*} else instr_{2}^{*} end ↪ ↪ block bt instr_{1}^{*} end (if c \neq = 0) block bt instr_{2}^{*} end (if c = 0)

4.6.8.6. $throw x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tagaddrs [x]$ exists.
Let $ta$ be the tag address $F. module . tagaddrs [x]$ .
Assert: due to validation, $S. tags [ta]$ exists.
Let $ti$ be the tag instance $S. tags [ta]$ .
Let $[t^{n}] \to [t^{'}^{*}]$ be the tag type $ti . type$ .
Assert: due to validation, there are at least $n$ values on the top of the stack.
Pop the $n$ values $val^{n}$ from the stack.
Let $ea$ be the exception address resulting from allocating an exception instance with tag address $ta$ and initializer values $val^{n}$ .
Let $exn$ be $S. exns [ea]$
Push the value $ref . exn ea$ to the stack.
Execute the instruction $throw_ref$ .

S; F; val^{n} (throw x) ↪ S^{'}; F; (ref . exn ∣ S . exns ∣) throw_ref (if \land \land \land F . module . tagaddrs [x] = a S . tags [a] . type = [t^{n}] \to [] exn = {tag a, fields val^{n}} S^{'} = S with exns = S . exns exn)

4.6.8.7. $throw_ref$

Assert: due to validation, a reference is on the top of the stack.
Pop the reference $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Trap.
Assert: due to validation, $ref$ is an exception reference.
Let $ref . exn ea$ be $ref$ .
Assert: due to validation, $S. exns [ea]$ exists.
Let $exn$ be the exception instance $S. exns [ea]$ .
Let $a$ be the tag address $exn . tag$ .
While the stack is not empty and the top of the stack is not an exception handler, do:
1. Pop the top element from the stack.
Assert: the stack is now either empty, or there is an exception handler on the top of the stack.
If the stack is empty, then:

Return the exception $(ref . exn a)$ as a result.

Assert: there is an exception handler on the top of the stack.
Pop the exception handler $handler_{n} {catch^{*}}$ from the stack.
If $catch^{*}$ is empty, then:
1. Push the exception reference $ref . exn ea$ back to the stack.
2. Execute the instruction $throw_ref$ again.
Else:
1. Let $F$ be the current frame.
2. Let $catch_{1}$ be the first catch clause in $catch^{*}$ and $catch^{'}^{*}$ the remaining clauses.
3. If $catch_{1}$ is of the form $catch x l$ and the tag address $a$ equals $F. module . tagaddrs [x]$ , then:
  1. Push the values $exn . fields$ to the stack.
  2. Execute the instruction $br l$ .
4. Else if $catch_{1}$ is of the form $catch_ref x l$ and the tag address $a$ equals $F. module . tagaddrs [x]$ , then:
  1. Push the values $exn . fields$ to the stack.
  2. Push the exception reference $ref . exn ea$ to the stack.
  3. Execute the instruction $br l$ .
5. Else if $catch_{1}$ is of the form $catch_all l$ , then:
  1. Execute the instruction $br l$ .
6. Else if $catch_{1}$ is of the form $catch_all_ref l$ , then:
  1. Push the exception reference $ref . exn ea$ to the stack.
  2. Execute the instruction $br l$ .
7. Else:
  1. Push the modified handler $handler_{n} {catch^{'}^{*}}$ back to the stack.
  2. Push the exception reference $ref . exn ea$ back to the stack.
  3. Execute the instruction $throw_ref$ again.

(ref.null ht) throw_ref handler_{n} {} T [(ref . exn a) throw_ref] end S; F; handler_{n} {(catch x l) catch^{*}} T [(ref . exn a) throw_ref] end S; F; handler_{n} {(catch_ref x l) catch^{*}} T [(ref . exn a) throw_ref] end handler_{n} {(catch_all l) catch^{*}} T [(ref . exn a) throw_ref] end handler_{n} {(catch_all_ref l) catch^{*}} T [(ref . exn a) throw_ref] end handler_{n} {catch_{1} catch^{*}} T [(ref . exn a) throw_ref] end ↪ ↪ ↪ ↪ ↪ ↪ ↪ trap (ref . exn a) throw_ref exn . fields (br l) (if \land exn = S . exns [a] exn . tag = F . module . tagaddrs [x]) exn . fields (ref . exn a) (br l) (if \land exn = S . exns [a] exn . tag = F . module . tagaddrs [x]) (br l) (ref . exn a) (br l) handler_{n} {catch^{*}} T [(ref . exn a) throw_ref] end (otherwise)

4.6.8.8. $try_table blocktype catch^{} instr^{} end$

Assert: due to validation, $instrtype_{S; F} (blocktype)$ is defined.
Let $[t_{1}^{m}] \to [t_{2}^{n}]$ be the instruction type $instrtype_{S; F} (blocktype)$ .
Assert: due to validation, there are at least $m$ values on the top of the stack.
Pop the values $val^{m}$ from the stack.
Let $L$ be the label whose arity is $n$ and whose continuation is the end of the $try_table$ instruction.
Enter the block $val^{m} instr_{1}^{*}$ with label $L$ and exception handler $handler_{n} {catch^{*}}$ .

F; val^{m} (try_table bt catch^{*} instr^{*} end ↪ F; handler_{n} {catch^{*}} (label_{n} {ϵ} val^{m} instr^{*} end) end (if instrtype_{S; F} (bt) = [t_{1}^{m}] \to [t_{2}^{n}] \land (F . module . tagaddrs [x] = a_{x})^{*})

4.6.8.9. $br l$

Assert: due to validation, the stack contains at least $l + 1$ labels.
Let $L$ be the $l$ -th label appearing on the stack, starting from the top and counting from zero.
Let $n$ be the arity of $L$ .
Assert: due to validation, there are at least $n$ values on the top of the stack.
Pop the values $val^{n}$ from the stack.
Repeat $l + 1$ times:
1. While the top of the stack is a value or a handler, do:
  1. Pop the value or handler from the stack.
2. Assert: due to validation, the top of the stack now is a label.
3. Pop the label from the stack.
Push the values $val^{n}$ to the stack.
Jump to the continuation of $L$ .

label_{n} {instr^{*}} B^{l} [val^{n} (br l)] end ↪ val^{n} instr^{*}

4.6.8.10. $br_if l$

Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const c$ from the stack.
If $c$ is non-zero, then:
1. Execute the instruction $br l$ .
Else:
1. Do nothing.

(i32 . const c) (br_if l) (i32 . const c) (br_if l) ↪ ↪ (br l) ϵ (if c \neq = 0) (if c = 0)

4.6.8.11. $br_table l^{*} l_{N}$

Assert: due to validation, a value of value type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
If $i$ is smaller than the length of $l^{*}$ , then:
1. Let $l_{i}$ be the label $l^{*} [i]$ .
2. Execute the instruction $br l_{i}$ .
Else:
1. Execute the instruction $br l_{N}$ .

(i32 . const i) (br_table l^{*} l_{N}) (i32 . const i) (br_table l^{*} l_{N}) ↪ ↪ (br l_{i}) (br l_{N}) (if l^{*} [i] = l_{i}) (if ∣ l^{*} ∣ \leq i)

4.6.8.12. $br_on_null l$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Execute the instruction $(br l)$ .
Else:
1. Push the value $ref$ back to the stack.

ref (br_on_null l) ref (br_on_null l) ↪ ↪ (br l) ref (if ref = ref.null ht) (otherwise)

4.6.8.13. $br_on_non_null l$

Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
If $ref$ is $ref.null ht$ , then:
1. Do nothing.
Else:
1. Push the value $ref$ back to the stack.
2. Execute the instruction $(br l)$ .

ref (br_on_non_null l) ref (br_on_non_null l) ↪ ↪ ϵ ref (br l) (if ref = ref.null ht) (otherwise)

4.6.8.14. $br_on_cast l rt_{1} rt_{2}$

Let $F$ be the current frame.
Let $rt_{2}^{'}$ be the reference type $clos_{F. module} (rt_{2})$ .
Assert: due to validation, $rt_{2}^{'}$ is closed.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
Assert: due to validation, the reference value is valid with some reference type.
Let $rt$ be the reference type of $ref$ .
Push the value $ref$ back to the stack.
If the reference type $rt$ matches $rt_{2}^{'}$ , then:
1. Execute the instruction $(br l)$ .

S; F; ref (br_on_cast l rt_{1} rt_{2}) S; F; ref (br_on_cast l rt_{1} rt_{2}) ↪ ↪ ref (br l) ref (if S ⊢ ref : rt \land ⊢ rt \leq clos_{F . module} (rt_{2})) (otherwise)

4.6.8.15. $br_on_cast_fail l rt_{1} rt_{2}$

Let $F$ be the current frame.
Let $rt_{2}^{'}$ be the reference type $clos_{F. module} (rt_{2})$ .
Assert: due to validation, $rt_{2}^{'}$ is closed.
Assert: due to validation, a reference value is on the top of the stack.
Pop the value $ref$ from the stack.
Assert: due to validation, the reference value is valid with some reference type.
Let $rt$ be the reference type of $ref$ .
Push the value $ref$ back to the stack.
If the reference type $rt$ does not match $rt_{2}^{'}$ , then:
1. Execute the instruction $(br l)$ .

S; F; ref (br_on_cast_fail l rt_{1} rt_{2}) S; F; ref (br_on_cast_fail l rt_{1} rt_{2}) ↪ ↪ ref ref (br l) (if S ⊢ ref : rt \land ⊢ rt \leq clos_{F . module} (rt_{2})) (otherwise)

4.6.8.16. $return$

Let $F$ be the current frame.
Let $n$ be the arity of $F$ .
Assert: due to validation, there are at least $n$ values on the top of the stack.
Pop the results $val^{n}$ from the stack.
Assert: due to validation, the stack contains at least one frame.
While the top of the stack is not a frame, do:
1. Pop the top element from the stack.
Assert: the top of the stack is the frame $F$ .
Pop the frame from the stack.
Push $val^{n}$ to the stack.
Jump to the instruction after the original call that pushed the frame.

frame_{n} {F} B^{*} [val^{n} return] end ↪ val^{n}

4.6.8.17. $call x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . funcaddrs [x]$ exists.
Let $a$ be the function address $F. module . funcaddrs [x]$ .
Invoke the function instance at address $a$ .

F; (call x) ↪ F; (invoke a) (if F . module . funcaddrs [x] = a)

4.6.8.18. $call_ref x$

Assert: due to validation, a null or function reference is on the top of the stack.
Pop the reference value $r$ from the stack.
If $r$ is $ref.null ht$ , then:
1. Trap.
Assert: due to validation, $r$ is a function reference.
Let $ref . func a$ be the reference $r$ .
Invoke the function instance at address $a$ .

F; (ref . func a) (call_ref x) F; (ref.null ht) (call_ref x) ↪ ↪ F; (invoke a) F; trap

4.6.8.19. $call_indirect x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $ta$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [ta]$ exists.
Let $tab$ be the table instance $S. tables [ta]$ .
Assert: due to validation, $F. module . types [y]$ is defined.
Let $dt_{expect}$ be the defined type $F. module . types [y]$ .
Assert: due to validation, a value with value type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
If $i$ is not smaller than the length of $tab . elem$ , then:
1. Trap.
Let $r$ be the reference $tab . elem [i]$ .
If $r$ is $ref.null ht$ , then:
1. Trap.
Assert: due to validation of table mutation, $r$ is a function reference.
Let $ref . func a$ be the function reference $r$ .
Assert: due to validation of table mutation, $S. funcs [a]$ exists.
Let $f$ be the function instance $S. funcs [a]$ .
Let $dt_{actual}$ be the defined type $f . type$ .
If $dt_{actual}$ does not match $dt_{expect}$ , then:
1. Trap.
Invoke the function instance at address $a$ .

S; F; (i32 . const i) (call_indirect x y) ↪ S; F; (invoke a) (if \land \land S . tables [F . module . tableaddrs [x]] . elem [i] = ref . func a S . funcs [a] = f S ⊢ F . module . types [y] \leq f . type) 1 e x] S; F; (i32 . const i) (call_indirect x y) ↪ S; F; trap (otherwise)

4.6.8.20. $return_call x$

Let $F$ be the current frame.
Assert: due to validation, $F. module . funcaddrs [x]$ exists.
Let $a$ be the function address $F. module . funcaddrs [x]$ .
Tail-invoke the function instance at address $a$ .

(return_call x) ↪ (return_invoke a) (if (call x) ↪ (invoke a))

4.6.8.21. $return_call_ref x$

Assert: due to validation, a function reference is on the top of the stack.
Pop the reference value $r$ from the stack.
If $r$ is $ref.null ht$ , then:
1. Trap.
Assert: due to validation, $r$ is a function reference.
Let $ref . func a$ be the reference $r$ .
Tail-invoke the function instance at address $a$ .

val (return_call_ref x) val (return_call_ref x) ↪ ↪ (return_invoke a) trap (if val (call_ref x) ↪ (invoke a)) (if val (call_ref x) ↪ trap)

4.6.8.22. $return_call_indirect x y$

Let $F$ be the current frame.
Assert: due to validation, $F. module . tableaddrs [x]$ exists.
Let $ta$ be the table address $F. module . tableaddrs [x]$ .
Assert: due to validation, $S. tables [ta]$ exists.
Let $tab$ be the table instance $S. tables [ta]$ .
Assert: due to validation, $F. module . types [y]$ exists.
Let $dt_{expect}$ be the defined type $F. module . types [y]$ .
Assert: due to validation, a value with value type $i32$ is on the top of the stack.
Pop the value $i32 . const i$ from the stack.
If $i$ is not smaller than the length of $tab . elem$ , then:
1. Trap.
If $tab . elem [i]$ is uninitialized, then:
1. Trap.
Let $a$ be the function address $tab . elem [i]$ .
Assert: due to validation, $S. funcs [a]$ exists.
Let $f$ be the function instance $S. funcs [a]$ .
Let $dt_{actual}$ be the defined type $f . type$ .
If $dt_{actual}$ does not match $dt_{expect}$ , then:
1. Trap.
Tail-invoke the function instance at address $a$ .

val (return_call_indirect x y) val (return_call_indirect x y) ↪ ↪ (return_invoke a) trap (if val (call_indirect x y) ↪ (invoke a)) (if val (call_indirect x y) ↪ trap)

4.6.9. Blocks

The following auxiliary rules define the semantics of executing an instruction sequence that forms a block.

4.6.9.1. Entering $instr^{*}$ with label $L$

Push $L$ to the stack.
Jump to the start of the instruction sequence $instr^{*}$ .

Note

No formal reduction rule is needed for entering an instruction sequence, because the label $L$ is embedded in the administrative instruction that structured control instructions reduce to directly.

4.6.9.2. Exiting $instr^{*}$ with label $L$

When the end of a block is reached without a jump, exception, or trap aborting it, then the following steps are performed.

Pop all values $val^{*}$ from the top of the stack.
Assert: due to validation, the label $L$ is now on the top of the stack.
Pop the label from the stack.
Push $val^{*}$ back to the stack.
Jump to the position after the $end$ of the structured control instruction associated with the label $L$ .

label_{n} {instr^{*}} val^{*} end ↪ val^{*}

Note

This semantics also applies to the instruction sequence contained in a $loop$ instruction. Therefore, execution of a loop falls off the end, unless a backwards branch is performed explicitly.

4.6.10. Exception Handling

The following auxiliary rules define the semantics of entering and exiting $try_table$ blocks.

4.6.10.1. Entering $instr^{*}$ with label $L$ and exception handler $H$

Push $H$ to the stack.
Push $L$ onto the stack.
Jump to the start of the instruction sequence $instr^{*}$ .

Note

No formal reduction rule is needed for entering an exception handler because it is an administrative instruction that the $try_table$ instruction reduces to directly.

4.6.10.2. Exiting an exception handler

When the end of a $try_table$ block is reached without a jump, exception, or trap, then the following steps are performed.

Let $m$ be the number of values on the top of the stack.
Pop the values $val^{m}$ from the stack.
Assert: due to validation, a handler and a label are now on the top of the stack.
Pop the label from the stack.
Pop the handler $H$ from the stack.
Push $val^{m}$ back to the stack.
Jump to the position after the $end$ of the administrative instruction associated with the handler $H$ .

handler_{m} {catch^{*}} val^{m} end ↪ val^{m}

4.6.11. Function Calls

The following auxiliary rules define the semantics of invoking a function instance through one of the call instructions and returning from it.

4.6.11.1. Invocation of function address $a$

Assert: due to validation, $S. funcs [a]$ exists.
Let $f$ be the function instance, $S. funcs [a]$ .
Let $func [t_{1}^{n}] \to [t_{2}^{m}]$ be the composite type $expand (f . type)$ .
Let $local^{*}$ be the list of locals $f. code . locals$ .
Let $instr^{*} end$ be the expression $f. code . body$ .
Assert: due to validation, $n$ values are on the top of the stack.
Pop the values $val^{n}$ from the stack.
Let $F$ be the frame ${module f. module, locals val^{n} (default_{t})^{*}}$ .
Push the activation of $F$ with arity $m$ to the stack.
Let $L$ be the label whose arity is $m$ and whose continuation is the end of the function.
Enter the instruction sequence $instr^{*}$ with label $L$ .

S; val^{n} (invoke a) ↪ S; frame_{m} {F} label_{m} {} instr^{*} end end (if \land \land \land S . funcs [a] = f expand (f . type) = func [t_{1}^{n}] \to [t_{2}^{m}] f . code = {type x, locals {type t}^{k}, body instr^{*} end} F = {module f . module, locals val^{n} (default_{t})^{k}})

Note

For non-defaultable types, the respective local is left uninitialized by these rules.

4.6.11.2. Tail-invocation of function address $a$

Assert: due to validation, $S. funcs [a]$ exists.
Let $func [t_{1}^{n}] \to [t_{2}^{m}]$ be the composite type $expand (S. funcs [a] . type)$ .
Assert: due to validation, there are at least $n$ values on the top of the stack.
Pop the results $val^{n}$ from the stack.
Assert: due to validation, the stack contains at least one frame.
While the top of the stack is not a frame, do:
1. Pop the top element from the stack.
Assert: the top of the stack is a frame.
Pop the frame from the stack.
Push $val^{n}$ to the stack.
Invoke the function instance at address $a$ .

S; frame_{m} {F} B^{*} [val^{n} (return_invoke a)] end ↪ val^{n} (invoke a) (if expand (S . funcs [a] . type) = func [t_{1}^{n}] \to [t_{2}^{m}])

4.6.11.3. Returning from a function

When the end of a function is reached without a jump (including through $return$ ), or an exception or trap aborting it, then the following steps are performed.

Let $F$ be the current frame.
Let $n$ be the arity of the activation of $F$ .
Assert: due to validation, there are $n$ values on the top of the stack.
Pop the results $val^{n}$ from the stack.
Assert: due to validation, the frame $F$ is now on the top of the stack.
Pop the frame from the stack.
Push $val^{n}$ back to the stack.
Jump to the instruction after the original call.

frame_{n} {F} val^{n} end ↪ val^{n}

4.6.11.4. Host Functions

Invoking a host function has non-deterministic behavior. It may either terminate with a trap, an exception, or return regularly. However, in the latter case, it must consume and produce the right number and types of WebAssembly values on the stack, according to its function type.

A host function may also modify the store. However, all store modifications must result in an extension of the original store, i.e., they must only modify mutable contents and must not have instances removed. Furthermore, the resulting store must be valid, i.e., all data and code in it is well-typed.

S; val^{n} (invoke a) ↪ S^{'}; result (if \land \land S . funcs [a] = {type deftype, hostcode hf} expand (deftype) = func [t_{1}^{n}] \to [t_{2}^{m}] (S^{'}; result) \in hf (S; val^{n})) S; val^{n} (invoke a) ↪ S; val^{n} (invoke a) (if \land \land S . funcs [a] = {type deftype, hostcode hf} expand (deftype) = func [t_{1}^{n}] \to [t_{2}^{m}] ⊥ \in hf (S; val^{n}))

Here, $hf (S; val^{n})$ denotes the implementation-defined execution of host function $hf$ in current store $S$ with arguments $val^{n}$ . It yields a set of possible outcomes, where each element is either a pair of a modified store $S^{'}$ and a result or the special value $⊥$ indicating divergence. A host function is non-deterministic if there is at least one argument for which the set of outcomes is not singular.

For a WebAssembly implementation to be sound in the presence of host functions, every host function instance must be valid, which means that it adheres to suitable pre- and post-conditions: under a valid store $S$ , and given arguments $val^{n}$ matching the ascribed parameter types $t_{1}^{n}$ , executing the host function must yield a non-empty set of possible outcomes each of which is either divergence or consists of a valid store $S^{'}$ that is an extension of $S$ and a result matching the ascribed return types $t_{2}^{m}$ . All these notions are made precise in the Appendix.

Note

A host function can call back into WebAssembly by invoking a function exported from a module. However, the effects of any such call are subsumed by the non-deterministic behavior allowed for the host function.

4.6.12. Expressions

An expression is evaluated relative to a current frame pointing to its containing module instance.

Jump to the start of the instruction sequence $instr^{*}$ of the expression.
Execute the instruction sequence.
Assert: due to validation, the top of the stack contains a value.
Pop the value $val$ from the stack.

The value $val$ is the result of the evaluation.

[S; F; instr^{*} ↪ S^{'}; F^{'}; instr^{' *} (if S; F; instr^{*} end ↪ S^{'}; F^{'}; instr^{' *} end)

Note

Evaluation iterates this reduction rule until reaching a value. Expressions constituting function bodies are executed during function invocation.

4.7. Modules

For modules, the execution semantics primarily defines instantiation, which allocates instances for a module and its contained definitions, initializes tables and memories from contained element and data segments, and invokes the start function if present. It also includes invocation of exported functions.

4.7.1. Allocation

New instances of functions, tables, memories, globals, tags, element segments, and data segments, as well as dynamic data types like structures, arrays, or exceptions, are allocated in a store $S$ , as defined by the following auxiliary functions.

4.7.1.1. Functions

Let $func$ be the function to allocate and $moduleinst$ its module instance.
Let $deftype$ be the defined type $moduleinst . types [func . type]$ .
Let $a$ be the first free function address in $S$ .
Let $funcinst$ be the function instance ${type deftype, module moduleinst, code func}$ .

Append $funcinst$ to the $funcs$ of $S$ .
Return $a$ .

allocfunc (S, func, moduleinst) deftype funcaddr funcinst S^{'} = = = = = S^{'}, funcaddr 1 e x] where: moduleinst . types [func . type] ∣ S . funcs ∣ {type deftype, module moduleinst, code func} S \oplus {funcs funcinst}

4.7.1.2. Host Functions

Let $hostfunc$ be the host function to allocate and $deftype$ its defined type.
Let $a$ be the first free function address in $S$ .
Let $funcinst$ be the function instance ${type deftype, hostcode hostfunc}$ .
Append $funcinst$ to the $funcs$ of $S$ .
Return $a$ .

allochostfunc (S, deftype, hostfunc) funcaddr funcinst S^{'} = = = = S^{'}, funcaddr 1 e x] where: ∣ S . funcs ∣ {type deftype, hostcode hostfunc} S \oplus {funcs funcinst}

Note

Host functions are never allocated by the WebAssembly semantics itself, but may be allocated by the embedder.

4.7.1.3. Tables

Let $tabletype$ be the table type of the table to allocate and $ref$ the initialization value.
Let $(addrtype {min n, max m^{?}} reftype)$ be the structure of table type $tabletype$ .
Let $a$ be the first free table address in $S$ .
Let $tableinst$ be the table instance ${type tabletype, elem ref^{n}}$ with $n$ elements set to $ref$ .
Append $tableinst$ to the $tables$ of $S$ .
Return $a$ .

alloctable (S, tabletype, ref) tabletype tableaddr tableinst S^{'} = = = = = S^{'}, tableaddr 1 e x] where: addrtype {min n, max m^{?}} reftype ∣ S . tables ∣ {type tabletype, elem ref^{n}} S \oplus {tables tableinst}

4.7.1.4. Memories

Let $memtype$ be the memory type of the memory to allocate.
Let $(addrtype {min n, max m^{?}})$ be the structure of memory type $memtype$ .
Let $a$ be the first free memory address in $S$ .
Let $meminst$ be the memory instance ${type memtype, data (0x 00)^{n \cdot 64 Ki}}$ that contains $n$ pages of zeroed bytes.
Append $meminst$ to the $mems$ of $S$ .
Return $a$ .

allocmem (S, memtype) memtype memaddr meminst S^{'} = = = = = S^{'}, memaddr 1 e x] where: addrtype {min n, max m^{?}} ∣ S . mems ∣ {type memtype, data (0x 00)^{n \cdot 64 Ki}} S \oplus {mems meminst}

4.7.1.5. Tags

Let $tagtype$ be the tag type to allocate.
Let $a$ be the first free tag address in $S$ .
Let $taginst$ be the tag instance ${type tagtype}$ .
Append $taginst$ to the $tags$ of $S$ .
Return $a$ .

alloctag (S, tagtype) tagaddr taginst S^{'} = = = = S^{'}, tagaddr 1 e x] where: ∣ S . tags ∣ {type tagtype} S \oplus {tags taginst}

4.7.1.6. Exceptions

Let $ta$ be the tag address associated with the exception to allocate and $fields val^{*}$ be the values to initialize the exception with.
Let $a$ be the first free exception address in $S$ .
Let $exninst$ be the exception instance ${tag ta, fields val^{*}}$ .
Append $exninst$ to the $exns$ of $S$ .
Return $a$ .

allocexn (S, tagaddr, val^{*}) exnaddr exninst S^{'} = = = = S^{'}, exnaddr 1 e x] where: ∣ S . exns ∣ {tag tagaddr, fields val^{*}} S \oplus {exns exninst}

4.7.1.7. Globals

Let $globaltype$ be the global type of the global to allocate and $val$ its initialization value.
Let $a$ be the first free global address in $S$ .
Let $globalinst$ be the global instance ${type globaltype, value val}$ .
Append $globalinst$ to the $globals$ of $S$ .
Return $a$ .

allocglobal (S, globaltype, val) globaladdr globalinst S^{'} = = = = S^{'}, globaladdr 1 e x] where: ∣ S . globals ∣ {type globaltype, value val} S \oplus {globals globalinst}

4.7.1.8. Element segments

Let $reftype$ be the elements’ type and $ref^{*}$ the vector of references to allocate.
Let $a$ be the first free element address in $S$ .
Let $eleminst$ be the element instance ${type reftype, elem ref^{*}}$ .
Append $eleminst$ to the $elems$ of $S$ .
Return $a$ .

allocelem (S, reftype, ref^{*}) elemaddr eleminst S^{'} = = = = S^{'}, elemaddr 1 e x] where: ∣ S . elems ∣ {type reftype, elem ref^{*}} S \oplus {elems eleminst}

4.7.1.9. Data segments

Let $b^{*}$ be the vector of bytes to allocate.
Let $a$ be the first free data address in $S$ .
Let $datainst$ be the data instance ${data b^{*}}$ .
Append $datainst$ to the $datas$ of $S$ .
Return $a$ .

allocdata (S, b^{*}) dataaddr datainst S^{'} = = = = S^{'}, dataaddr 1 e x] where: ∣ S . datas ∣ {data b^{*}} S \oplus {datas datainst}

4.7.1.10. Growing tables

Let $tableinst$ be the table instance to grow, $n$ the number of elements by which to grow it, and $ref$ the initialization value.
Let $len$ be $n$ added to the length of $tableinst . elem$ .
Let $(addrtype limits reftype)$ be the structure of table type $tableinst . type$ .
Let $limits^{'}$ be $limits$ with $min$ updated to $len$ .
If the table type $(addrtype limits^{'} reftype)$ is not valid, then fail.
Append $ref^{n}$ to $tableinst . elem$ .
Set $tableinst . type$ to the table type $(addrtype limits^{'} reftype)$ .

growtable (tableinst, n, ref) = tableinst with type = addrtype limits^{'} reftype with elem = tableinst . elem ref^{n} (if \land \land \land len = n + ∣ tableinst . elem ∣ addrtype limits reftype = tableinst . type limits^{'} = limits with min = len ⊢ addrtype limits^{'} reftype ok)

4.7.1.11. Growing memories

Let $meminst$ be the memory instance to grow and $n$ the number of pages by which to grow it.
Assert: The length of $meminst . data$ is divisible by the page size $64 Ki$ .
Let $len$ be $n$ added to the length of $meminst . data$ divided by the page size $64 Ki$ .
Let $(addrtype limits)$ be the structure of memory type $meminst . type$ .
Let $limits^{'}$ be $limits$ with $min$ updated to $len$ .
If the memory type $(addrtype limits^{'})$ is not valid, then fail.
Append $n$ times $64 Ki$ bytes with value $0x 00$ to $meminst . data$ .
Set $meminst . type$ to the memory type $(addrtype limits^{'})$ .

growmem (meminst, n) = meminst with type = addrtype limits^{'} with data = meminst . data (0x 00)^{n \cdot 64 Ki} (if \land \land \land len = n + ∣ meminst . data ∣/64 Ki addrtype limits = meminst . type limits^{'} = limits with min = len ⊢ addrtype limits^{'} ok)

4.7.1.12. Modules

Todo

update prose for types

The allocation function for modules requires a suitable list of external values that are assumed to match the import vector of the module, a list of initialization values for the module’s globals, and list of reference vectors for the module’s element segments.

Let $module$ be the module to allocate and $externval_{im}^{*}$ the vector of external values providing the module’s imports, $val_{g}^{*}$ the initialization values of the module’s globals, $ref_{t}^{*}$ the initializer reference of the module’s tables, and $(ref_{e}^{*})^{*}$ the reference vectors of the module’s element segments.
For each defined type $deftype_{i}^{'}$ in $module . types$ , do:
1. Let $deftype_{i}$ be the instantiation $deftype_{i}^{'}$ in $moduleinst$ defined below.
For each function $func_{i}$ in $module . funcs$ , do:
1. Let $funcaddr_{i}$ be the function address resulting from allocating $func_{i}$ for the module instance $moduleinst$ defined below.
For each table $table_{i}$ in $module . tables$ , do:
1. Let $limits_{i} t_{i}$ be the table type obtained by instantiating $table_{i} . type$ in $moduleinst$ defined below.
2. Let $tableaddr_{i}$ be the table address resulting from allocating $table_{i} . type$ with initialization value $ref_{t}^{*} [i]$ .
For each memory $mem_{i}$ in $module . mems$ , do:
1. Let $memtype_{i}$ be the memory type obtained by insantiating $mem_{i} . type$ in $moduleinst$ defined below.
2. Let $memaddr_{i}$ be the memory address resulting from allocating $memtype_{i}$ .
For each global $global_{i}$ in $module . globals$ , do:
1. Let $globaltype_{i}$ be the global type obtained by instantiating $global_{i} . type$ in $moduleinst$ defined below.
2. Let $globaladdr_{i}$ be the global address resulting from allocating $globaltype_{i}$ with initializer value $val_{g}^{*} [i]$ .
For each tag $tag_{i}$ in $module . tags$ , do:
1. Let $tagtype$ be the tag type $module . types [tag_{i} . type]$ .
2. Let $tagaddr_{i}$ be the tag address resulting from allocating $tagtype$ .
For each element segment $elem_{i}$ in $module . elems$ , do:
1. Let $reftype_{i}$ be the element reference type obtained by instantiating <type-inst> $elem_{i} . type$ in $moduleinst$ defined below.
2. Let $elemaddr_{i}$ be the element address resulting from allocating a element instance of reference type $reftype_{i}$ with contents $(ref_{e}^{*})^{*} [i]$ .
For each data segment $data_{i}$ in $module . datas$ , do:
1. Let $dataaddr_{i}$ be the data address resulting from allocating a data instance with contents $data_{i} . init$ .
Let $deftype^{*}$ be the concatenation of the defined types $deftype_{i}$ in index order.
Let $funcaddr^{*}$ be the concatenation of the function addresses $funcaddr_{i}$ in index order.
Let $tableaddr^{*}$ be the concatenation of the table addresses $tableaddr_{i}$ in index order.
Let $memaddr^{*}$ be the concatenation of the memory addresses $memaddr_{i}$ in index order.
Let $globaladdr^{*}$ be the concatenation of the global addresses $globaladdr_{i}$ in index order.
Let $tagaddr^{*}$ be the concatenation of the tag addresses $tagaddr_{i}$ in index order.
Let $elemaddr^{*}$ be the concatenation of the element addresses $elemaddr_{i}$ in index order.
Let $dataaddr^{*}$ be the concatenation of the data addresses $dataaddr_{i}$ in index order.
Let $funcaddr_{mod}^{*}$ be the list of function addresses extracted from $externval_{im}^{*}$ , concatenated with $funcaddr^{*}$ .
Let $tableaddr_{mod}^{*}$ be the list of table addresses extracted from $externval_{im}^{*}$ , concatenated with $tableaddr^{*}$ .
Let $memaddr_{mod}^{*}$ be the list of memory addresses extracted from $externval_{im}^{*}$ , concatenated with $memaddr^{*}$ .
Let $globaladdr_{mod}^{*}$ be the list of global addresses extracted from $externval_{im}^{*}$ , concatenated with $globaladdr^{*}$ .
Let $tagaddr_{mod}^{*}$ be the list of tag addresses extracted from $externval_{im}^{*}$ , concatenated with $tagaddr^{*}$ .
For each export $export_{i}$ in $module . exports$ , do:
1. If $export_{i}$ is a function export for function index $x$ , then let $externval_{i}$ be the external value $func (funcaddr_{mod}^{*} [x])$ .
2. Else, if $export_{i}$ is a table export for table index $x$ , then let $externval_{i}$ be the external value $table (tableaddr_{mod}^{*} [x])$ .
3. Else, if $export_{i}$ is a memory export for memory index $x$ , then let $externval_{i}$ be the external value $mem (memaddr_{mod}^{*} [x])$ .
4. Else, if $export_{i}$ is a global export for global index $x$ , then let $externval_{i}$ be the external value $global (globaladdr_{mod}^{*} [x])$ .
5. Else, if $export_{i}$ is a tag export for tag index $x$ , then let $externval_{i}$ be the external value $tag (tagaddr_{mod}^{*} [x])$ .
6. Let $exportinst_{i}$ be the export instance ${name (export_{i} . name), value externval_{i}}$ .
Let $exportinst^{*}$ be the concatenation of the export instances $exportinst_{i}$ in index order.
Let $moduleinst$ be the module instance ${types deftype^{*},$ $funcaddrs funcaddr_{mod}^{*},$ $tableaddrs tableaddr_{mod}^{*},$ $memaddrs memaddr_{mod}^{*},$ $globaladdrs globaladdr_{mod}^{*},$ $tagaddrs tagaddr_{mod}^{*}$ , $exports exportinst^{*}}$ .
Return $moduleinst$ .

allocmodule (S, module, externval_{im}^{*}, val_{g}^{*}, ref_{t}^{*}, (ref_{e}^{*})^{*}) = S^{'}, moduleinst

where:

table^{*} mem^{*} global^{*} elem^{*} data^{*} export^{*} S_{1}, funcaddr^{*} S_{2}, tableaddr^{*} S_{3}, memaddr^{*} S_{4}, globaladdr^{*} S_{5}, tagaddr^{*} S_{6}, elemaddr^{*} S^{'}, dataaddr^{*} exportinst^{*} tables (externval_{ex}^{*}) mems (externval_{ex}^{*}) globals (externval_{ex}^{*}) tags (externval_{ex}^{*}) = = = = = = = = = = = = = = = = = = module . tables module . mems module . globals module . elems module . datas module . exports 1 e x] moduleinst allocfunc^{*} (S, module . funcs, moduleinst) alloctable^{*} (S_{1}, clos_{moduleinst} (table . type)^{*}, ref_{t}^{*}) (where (table . type)^{*} = (limits t)^{*}) allocmem^{*} (S_{2}, clos_{moduleinst} (mem . type)^{*}) allocglobal^{*} (S_{3}, clos_{moduleinst} (global . type)^{*}, val_{g}^{*}) alloctag^{*} (S_{4}, clos_{moduleinst} (tag)^{*}) (where tag^{*} = module . tags) allocelem^{*} (S_{5}, clos_{moduleinst} (elem . type)^{*}, (ref_{e}^{*})^{*}) allocdata^{*} (S_{6}, data . init^{*}) {name (export . name), value externval_{ex}}^{*} 1 e x] funcs (externval_{ex}^{*}) (moduleinst . tableaddrs [x])^{*} (where x^{*} = tables (export^{*})) (moduleinst . memaddrs [x])^{*} (where x^{*} = mems (export^{*})) (moduleinst . globaladdrs [x])^{*} (where x^{*} = globals (export^{*})) (moduleinst . tagaddrs [x])^{*} (where x^{*} = tags (export^{*})) = = {types deftype^{*}, funcaddrs funcs (externval_{im}^{*}) funcaddr^{*}, tableaddrs tables (externval_{im}^{*}) tableaddr^{*}, memaddrs mems (externval_{im}^{*}) memaddr^{*}, globaladdrs globals (externval_{im}^{*}) globaladdr^{*}, tagaddrs tags (externval_{im}^{*}) tagaddr^{*}, elemaddrs elemaddr^{*}, dataaddrs dataaddr^{*}, exports exportinst^{*}} 1 e x] deftype^{*} (moduleinst . funcaddrs [x])^{*} (where x^{*} = funcs (export^{*})) = alloctype^{*} (module . types)

Here, the notation $allocx^{*}$ is shorthand for multiple allocations of object kind $X$ , defined as follows:

allocx^{*} (S_{0}, X^{n}, \dots) S_{i + 1}, a^{n} [i] = = S_{n}, a^{n} 1 e x] where for all i < n: allocx (S_{i}, X^{n} [i], \dots)

Moreover, if the dots $\dots$ are a sequence $A^{n}$ (as for globals or tables), then the elements of this sequence are passed to the allocation function pointwise.

For types, however, allocation is defined in terms of rolling and substitution of all preceding types to produce a list of closed defined types:

alloctype^{*} (rectype^{n}) = deftype^{*} 1 e x] where for all i < n: rectype^{n} [i] deftype^{*} [x_{i} : m_{i}] x_{i + 1} x_{n} = = = = rec subtype_{i}^{m_{i}} roll^{*}_{x_{i}} (rec subtype_{i}^{m_{i}}) [:= deftype^{*} [0 : x_{i}]] x_{i} + m_{i} ∣ deftype^{*} ∣

Note

The definition of module allocation is mutually recursive with the allocation of its associated functions, because the resulting module instance $moduleinst$ is passed to the allocators as an argument, in order to form the necessary closures. In an implementation, this recursion is easily unraveled by mutating one or the other in a secondary step.

4.7.2. Instantiation

Given a store $S$ , a module $module$ is instantiated with a list of external values $externval^{n}$ supplying the required imports as follows.

Instantiation checks that the module is valid and the provided imports match the declared types, and may fail with an error otherwise. Instantiation can also result in an exception or trap when initializing a table or memory from an active segment or when executing the start function. It is up to the embedder to define how such conditions are reported.

If $module$ is not valid, then:
1. Fail.
Assert: $module$ is valid with external types $externtype_{im}^{m}$ classifying its imports.
If the number $m$ of imports is not equal to the number $n$ of provided external values, then:
1. Fail.
For each external value $externval_{i}$ in $externval^{n}$ and external type $externtype_{i}^{'}$ in $externtype_{im}^{n}$ , do:
1. If $externval_{i}$ is not valid with an external type $externtype_{i}$ in store $S$ , then:
  1. Fail.
2. Let $externtype_{i}^{''}$ be the external type obtained by instantiating $externtype_{i}^{'}$ in $moduleinst$ defined below.
3. If $externtype_{i}$ does not match $externtype_{i}^{''}$ , then:
  1. Fail.

Let $F$ be the auxiliary frame ${module moduleinst, locals ϵ}$ , that consists of the final module instance $moduleinst$ , defined below.
Push the frame $F$ to the stack.
Let $val_{g}^{*}$ be the vector of global initialization values determined by $module$ and $externval^{n}$ . These may be calculated as follows.
1. For each global $global_{i}$ in $module . globals$ , do:
  1. Let $val_{gi}$ be the result of evaluating the initializer expression $global_{i} . init$ .
2. Assert: due to validation, the frame $F$ is now on the top of the stack.
3. Let $val_{g}^{*}$ be the concatenation of $val_{gi}$ in index order.
Let $ref_{t}^{*}$ be the vector of table initialization references determined by $module$ and $externval^{n}$ . These may be calculated as follows.
1. For each table $table_{i}$ in $module . tables$ , do:
  1. Let $val_{ti}$ be the result of evaluating the initializer expression $table_{i} . init$ .
  2. Assert: due to validation, $val_{ti}$ is a reference.
  3. Let $ref_{ti}$ be the reference $val_{ti}$ .
2. Assert: due to validation, the frame $F$ is now on the top of the stack.
3. Let $ref_{t}^{*}$ be the concatenation of $ref_{ti}$ in index order.
Let $(ref_{e}^{*})^{*}$ be the list of reference vectors determined by the element segments in $module$ . These may be calculated as follows.
1. For each element segment $elem_{i}$ in $module . elems$ , and for each element expression $expr_{ij}$ in $elem_{i} . init$ , do:
  1. Let $ref_{ij}$ be the result of evaluating the initializer expression $expr_{ij}$ .
2. Let $ref_{i}^{*}$ be the concatenation of function elements $ref_{ij}$ in order of index $j$ .
3. Let $(ref_{e}^{*})^{*}$ be the concatenation of function element vectors $ref_{i}^{*}$ in order of index $i$ .
Let $moduleinst$ be a new module instance allocated from $module$ in store $S$ with imports $externval^{n}$ , global initializer values $val_{g}^{*}$ , table initializer values $ref_{t}^{*}$ , and element segment contents $(ref_{e}^{*})^{*}$ , and let $S^{'}$ be the extended store produced by module allocation.
For each element segment $elem_{i}$ in $module . elems$ whose mode is of the form $active {table tableidx_{i}, offset einstr_{i}^{*} end}$ , do:
1. Let $n$ be the length of the vector $elem_{i} . init$ .
2. Execute the instruction sequence $einstr_{i}^{*}$ .
3. Execute the instruction $i32 . const 0$ .
4. Execute the instruction $i32 . const n$ .
5. Execute the instruction $table.init tableidx_{i} i$ .
6. Execute the instruction $elem.drop i$ .
For each element segment $elem_{i}$ in $module . elems$ whose mode is of the form $declarative$ , do:
1. Execute the instruction $elem.drop i$ .
For each data segment $data_{i}$ in $module . datas$ whose mode is of the form $active {memory memidx_{i}, offset dinstr_{i}^{*} end}$ , do:
1. Let $n$ be the length of the vector $data_{i} . init$ .
2. Execute the instruction sequence $dinstr_{i}^{*}$ .
3. Execute the instruction $i32 . const 0$ .
4. Execute the instruction $i32 . const n$ .
5. Execute the instruction $memory.init i$ .
6. Execute the instruction $data.drop i$ .
If the start function $module . start$ is not empty, then:
1. Let $start$ be the start function $module . start$ .
2. Execute the instruction $call start . func$ .
Assert: due to validation, the frame $F$ is now on the top of the stack.
Pop the frame $F$ from the stack.

instantiate (S, module, externval^{k}) = (if \land \land \land \land \land \land \land \land \land \land \land S^{'}; F; runelem_{0} (elem^{n} [0]) \dots runelem_{n - 1} (elem^{n} [n - 1]) rundata_{0} (data^{m} [0]) \dots rundata_{m - 1} (data^{m} [m - 1]) (call start . func)^{?} ⊢ module : externtype_{im}^{k} \to externtype_{ex}^{*} (S^{'} ⊢ externval : externtype)^{k} (S^{'} ⊢ externtype \leq clos_{moduleinst} (externtype_{im}))^{k} 1 e x] module . elems = elem^{n} module . datas = data^{m} module . start = start^{?} (expr_{g} = global . init)^{*} (expr_{t} = table . init)^{*} (expr_{e}^{*} = elem . init)^{n} 1 e x] F = {module moduleinst, locals ϵ} 1 e x] (S^{'}; F; expr_{t} ↪^{*} S^{'}; F; ref_{t} end)^{*} ((S^{'}; F; expr_{e} ↪^{*} S^{'}; F; ref_{e} end)^{*})^{n}) \land \land \land module . globals = global^{*} S^{'}, moduleinst = allocmodule (S, module, externval^{k}, val^{*}, (ref^{*})^{n}) (S^{'}; F; expr_{g} ↪^{*} S^{'}; F; val_{g} end)^{*}

where:

runelem_{i} ({type et, init expr^{n}, mode passive}) = ϵ runelem_{i} ({type et, init expr^{n}, mode active {table x, offset instr^{*} end}}) = instr^{*} (i32 . const 0) (i32 . const n) (table.init x i) (elem.drop i) runelem_{i} ({type et, init expr^{n}, mode declarative}) = (elem.drop i) 1 e x] rundata_{i} ({init b^{n}, mode passive}) = ϵ rundata_{i} ({init b^{n}, mode active {memory x, offset instr^{*} end}}) = instr^{*} (i32 . const 0) (i32 . const n) (memory.init x i) (data.drop i)

Note

Checking import types assumes that the module instance has already been allocated to compute the respective closed defined types. However, this forward reference merely is a way to simplify the specification. In practice, implementations will likely allocate or canonicalize types beforehand, when compiling a module, in a stage before instantiation and before imports are checked.

Similarly, module allocation and the evaluation of global and table initializers as well as element segments are mutually recursive because the global initialization values $val_{g}^{*}$ , $ref_{t}$ , and element segment contents $(ref^{*})^{*}$ are passed to the module allocator while depending on the module instance $moduleinst$ and store $S^{'}$ returned by allocation. Again, this recursion is just a specification device. In practice, the initialization values can be determined beforehand by staging module allocation such that first, the module’s own function instances are pre-allocated in the store, then the initializer expressions are evaluated in order, allocating globals on the way, then the rest of the module instance is allocated, and finally the new function instances’ $module$ fields are set to that module instance. This is possible because validation ensures that initialization expressions cannot actually call a function, only take their reference.

All failure conditions are checked before any observable mutation of the store takes place. Store mutation is not atomic; it happens in individual steps that may be interleaved with other threads.

Evaluation of constant expressions does not affect the store.

4.7.3. Invocation

Once a module has been instantiated, any exported function can be invoked externally via its function address $funcaddr$ in the store $S$ and an appropriate list $val^{*}$ of argument values.

Invocation may fail with an error if the arguments do not fit the function type. Invocation can also result in an exception or trap. It is up to the embedder to define how such conditions are reported.

Note

If the embedder API performs type checks itself, either statically or dynamically, before performing an invocation, then no failure other than traps or exceptions can occur.

The following steps are performed:

Assert: $S. funcs [funcaddr]$ exists.
Let $funcinst$ be the function instance $S. funcs [funcaddr]$ .
Let $func [t_{1}^{n}] \to [t_{2}^{m}]$ be the composite type $expand (funcinst . type)$ .
If the length $∣ val^{*} ∣$ of the provided argument values is different from the number $n$ of expected arguments, then:
1. Fail.
For each value type $t_{i}$ in $t_{1}^{n}$ and corresponding value $va l_{i}$ in $val^{*}$ , do:
1. If $val_{i}$ is not valid with value type $t_{i}$ , then:
  1. Fail.
Let $F$ be the dummy frame ${module {}, locals ϵ}$ .
Push the frame $F$ to the stack.
Push the values $val^{*}$ to the stack.
Invoke the function instance at address $funcaddr$ .

Once the function has returned, the following steps are executed:

Assert: due to validation, $m$ values are on the top of the stack.
Pop $val_{res}^{m}$ from the stack.
Assert: due to validation, the frame $F$ is now on the top of the stack.
Pop the frame $F$ from the stack.

The values $val_{res}^{m}$ are returned as the results of the invocation.

invoke (S, funcaddr, val^{n}) = (if \land \land S; F; val^{n} (invoke funcaddr) expand (S . funcs [funcaddr] . type) = func [t_{1}^{n}] \to [t_{2}^{m}] (S ⊢ val : t_{1})^{n} F = {module {}, locals ϵ})

5. Binary Format

5.1. Conventions

The binary format for WebAssembly modules is a dense linear encoding of their abstract syntax. [1]

The format is defined by an attribute grammar whose only terminal symbols are bytes. A byte sequence is a well-formed encoding of a module if and only if it is generated by the grammar.

Each production of this grammar has exactly one synthesized attribute: the abstract syntax that the respective byte sequence encodes. Thus, the attribute grammar implicitly defines a decoding function (i.e., a parsing function for the binary format).

Except for a few exceptions, the binary grammar closely mirrors the grammar of the abstract syntax.

Note

Some phrases of abstract syntax have multiple possible encodings in the binary format. For example, numbers may be encoded as if they had optional leading zeros. Implementations of decoders must support all possible alternatives; implementations of encoders can pick any allowed encoding.

The recommended extension for files containing WebAssembly modules in binary format is “ $.wasm$ ” and the recommended Media Type is “ $application/wasm$ ”.

5.1.1. Grammar

The following conventions are adopted in defining grammar rules for the binary format. They mirror the conventions used for abstract syntax. In order to distinguish symbols of the binary syntax from symbols of the abstract syntax, $typewriter$ font is adopted for the former.

Terminal symbols are bytes expressed in hexadecimal notation: $0x 0F$ .
Nonterminal symbols are written in typewriter font: $valtype, instr$ .
$B^{n}$ is a sequence of $n \geq 0$ iterations of $B$ .
$B^{*}$ is a possibly empty sequence of iterations of $B$ . (This is a shorthand for $B^{n}$ used where $n$ is not relevant.)
$B^{?}$ is an optional occurrence of $B$ . (This is a shorthand for $B^{n}$ where $n \leq 1$ .)
$x : B$ denotes the same language as the nonterminal $B$ , but also binds the variable $x$ to the attribute synthesized for $B$ . A pattern may also be used instead of a variable, e.g., $7 : B$ .
Productions are written $sym ::= B_{1} \Rightarrow A_{1} ∣ \dots ∣ B_{n} \Rightarrow A_{n}$ , where each $A_{i}$ is the attribute that is synthesized for $sym$ in the given case, usually from attribute variables bound in $B_{i}$ .
Some productions are augmented by side conditions in parentheses, which restrict the applicability of the production. They provide a shorthand for a combinatorial expansion of the production into many separate cases.
If the same meta variable or non-terminal symbol appears multiple times in a production (in the syntax or in an attribute), then all those occurrences must have the same instantiation. (This is a shorthand for a side condition requiring multiple different variables to be equal.)

Note

For example, the binary grammar for number types is given as follows:

numtype ::= ∣ ∣ ∣ 0x 7F 0x 7E 0x 7D 0x 7C \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 i64 f32 f64

Consequently, the byte $0x 7F$ encodes the type $i32$ , $0x 7E$ encodes the type $i64$ , and so forth. No other byte value is allowed as the encoding of a number type.

The binary grammar for limits is defined as follows:

limits ::= ∣ 0x 00 n : u 32 0x 01 n : u 32 m : u 32 \Rightarrow \Rightarrow {min n, max ϵ} {min n, max m}

That is, a limits pair is encoded as either the byte $0x 00$ followed by the encoding of a $u32$ value, or the byte $0x 01$ followed by two such encodings. The variables $n$ and $m$ name the attributes of the respective $u 32$ nonterminals, which in this case are the actual unsigned integers those decode into. The attribute of the complete production then is the abstract syntax for the limit, expressed in terms of the former values.

5.1.2. Auxiliary Notation

When dealing with binary encodings the following notation is also used:

$ϵ$ denotes the empty byte sequence.
$∣∣B∣∣$ is the length of the byte sequence generated from the production $B$ in a derivation.

5.1.3. Vectors

Vectors are encoded with their $u 32$ length followed by the encoding of their element sequence.

vec (B) ::= n : u 32 (x : B)^{n} \Rightarrow x^{n}

5.2. Values

5.2.1. Bytes

Bytes encode themselves.

byte ::= ∣ ∣ 0x 00 0x FF \Rightarrow \dots \Rightarrow 0x 00 0x FF

5.2.2. Integers

All integers are encoded using the LEB128 variable-length integer encoding, in either unsigned or signed variant.

Unsigned integers are encoded in unsigned LEB128 format. As an additional constraint, the total number of bytes encoding a value of type $u N$ must not exceed $ceil (N/7)$ bytes.

u N ::= ∣ n : byte n : byte m : u (N - 7) \Rightarrow \Rightarrow n 2^{7} \cdot m + (n - 2^{7}) (if n < 2^{7} \land n < 2^{N}) (if n \geq 2^{7} \land N > 7)

Signed integers are encoded in signed LEB128 format, which uses a two’s complement representation. As an additional constraint, the total number of bytes encoding a value of type $s N$ must not exceed $ceil (N/7)$ bytes.

s N ::= ∣ ∣ n : byte n : byte n : byte m : s (N - 7) \Rightarrow \Rightarrow \Rightarrow n n - 2^{7} 2^{7} \cdot m + (n - 2^{7}) (if n < 2^{6} \land n < 2^{N - 1}) (if 2^{6} \leq n < 2^{7} \land n \geq 2^{7} - 2^{N - 1}) (if n \geq 2^{7} \land N > 7)

Uninterpreted integers are encoded as signed integers.

i N ::= n : s N \Rightarrow i (if n = signed_{N} (i))

Note

The side conditions $N > 7$ in the productions for non-terminal bytes of the $u$ and $s$ encodings restrict the encoding’s length. However, “trailing zeros” are still allowed within these bounds. For example, $0x 03$ and $0x 83 0x 00$ are both well-formed encodings for the value $3$ as a $u8$ . Similarly, either of $0x 7e$ and $0x FE 0x 7F$ and $0x FE 0x FF 0x 7F$ are well-formed encodings of the value $- 2$ as a $s16$ .

The side conditions on the value $n$ of terminal bytes further enforce that any unused bits in these bytes must be $0$ for positive values and $1$ for negative ones. For example, $0x 83 0x 10$ is malformed as a $u8$ encoding. Similarly, both $0x 83 0x 3E$ and $0x FF 0x 7B$ are malformed as $s8$ encodings.

5.2.3. Floating-Point

Floating-point values are encoded directly by their [IEEE-754-2019] (Section 3.4) bit pattern in little endian byte order:

f N ::= b^{*} : byte^{N /8} \Rightarrow bytes_{f N}^{- 1} (b^{*})

5.2.4. Names

Names are encoded as a vector of bytes containing the [UNICODE] (Section 3.9) UTF-8 encoding of the name’s character sequence.

name ::= b^{*} : vec (byte) \Rightarrow name (if utf8 (name) = b^{*})

The auxiliary $utf8$ function expressing this encoding is defined as follows:

utf8 (c^{*}) utf8 (c) utf8 (c) utf8 (c) = = = = (utf8 (c))^{*} 1 e x] utf8 (c) b_{1} b_{2} b_{1} b_{2} b_{3} b_{1} b_{2} b_{3} b_{4} = (if \land U + 80 \leq c < U + 800 c = 2^{6} (b_{1} - 0x C0) + (b_{2} - 0x 80)) (if \land U + 800 \leq c < U + D800 \lor U + E000 \leq c < U + 10000 c = 2^{12} (b_{1} - 0x E0) + 2^{6} (b_{2} - 0x 80) + (b_{3} - 0x 80)) (if \land U + 10000 \leq c < U + 110000 c = 2^{18} (b_{1} - 0x F0) + 2^{12} (b_{2} - 0x 80) + 2^{6} (b_{3} - 0x 80) + (b_{4} - 0x 80)) b (if \land c < U + 80 c = b) where b_{2}, b_{3}, b_{4} < 0x C0

Note

Unlike in some other formats, name strings are not 0-terminated.

5.3. Types

Note

In some places, possible types include both type constructors or types denoted by type indices. Thus, the binary format for type constructors corresponds to the encodings of small negative $s N$ values, such that they can unambiguously occur in the same place as (positive) type indices.

5.3.1. Number Types

Number types are encoded by a single byte.

numtype ::= ∣ ∣ ∣ 0x 7F 0x 7E 0x 7D 0x 7C \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 i64 f32 f64

5.3.2. Vector Types

Vector types are also encoded by a single byte.

vectype ::= 0x 7B \Rightarrow v128

5.3.3. Heap Types

Heap types are encoded as either a single byte, or as a type index encoded as a positive signed integer.

absheaptype heaptype ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= ∣ 0x 74 0x 73 0x 72 0x 71 0x 70 0x 6F 0x 6E 0x 6D 0x 6C 0x 6B 0x 6A 0x 69 ht : absheaptype x : s 33 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow noexn nofunc noextern none func extern any eq i31 struct array exn ht x (if x \geq 0)

5.3.4. Reference Types

Reference types are either encoded by a single byte followed by a heap type, or, as a short form, directly as an abstract heap type.

reftype ::= ∣ ∣ 0x 64 ht : heaptype 0x 63 ht : heaptype ht : absheaptype \Rightarrow \Rightarrow \Rightarrow ref ht ref null ht ref null ht

5.3.5. Value Types

Value types are encoded with their respective encoding as a number type, vector type, or reference type.

valtype ::= ∣ ∣ t : numtype t : vectype t : reftype \Rightarrow \Rightarrow \Rightarrow t t t

Note

The type $bot$ cannot occur in a module.

Value types can occur in contexts where type indices are also allowed, such as in the case of block types. Thus, the binary format for types corresponds to the signed LEB128 encoding of small negative $s N$ values, so that they can coexist with (positive) type indices in the future.

5.3.6. Result Types

Result types are encoded by the respective vectors of value types.

resulttype ::= t^{*} : vec (valtype) \Rightarrow [t^{*}]

5.3.7. Function Types

Function types are encoded by the respective vectors of parameter and result types.

functype ::= rt_{1} : resulttype rt_{2} : resulttype \Rightarrow rt_{1} \to rt_{2}

5.3.8. Aggregate Types

Aggregate types are encoded with their respective field types.

arraytype structtype fieldtype storagetype packedtype ::= ::= ::= ::= ∣ ::= ∣ ft : fieldtype ft^{*} : vec (fieldtype) st : storagetype m : mut t : valtype t : packedtype 0x 78 0x 77 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow ft ft^{*} m st t t i8 i16

5.3.9. Composite Types

Composite types are encoded by a distinct byte followed by a type encoding of the respective form.

comptype ::= ∣ ∣ 0x 5E at : arraytype 0x 5F st : structtype 0x 60 ft : functype \Rightarrow \Rightarrow \Rightarrow array at struct st func ft

5.3.10. Recursive Types

Recursive types are encoded by the byte $0x 4E$ followed by a vector of sub types. Additional shorthands are recognized for unary recursions and sub types without super types.

rectype subtype ::= ∣ ::= ∣ ∣ 0x 4E st^{*} : vec (subtype) st : subtype 0x 50 x^{*} : vec (typeidx) ct : comptype 0x 4F x^{*} : vec (typeidx) ct : comptype ct : comptype \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow rec st^{*} rec st sub x^{*} ct sub final x^{*} ct sub final ϵ ct

5.3.11. Limits

Limits are encoded with a preceding flag indicating whether a maximum is present, and a flag for the address type.

limits ::= ∣ ∣ ∣ 0x 00 n : u 64 0x 01 n : u 64 m : u 64 0x 04 n : u 64 0x 05 n : u 64 m : u 64 \Rightarrow \Rightarrow \Rightarrow \Rightarrow (i32, {min n, max ϵ}) (i32, {min n, max m}) (i64, {min n, max ϵ}) (i64, {min n, max m})

5.3.12. Memory Types

Memory types are encoded with their limits.

memtype ::= (at, lim) : limits \Rightarrow at lim

5.3.13. Table Types

Table types are encoded with their limits and the encoding of their element reference type.

tabletype ::= et : reftype (at, lim) : limits \Rightarrow at lim et

5.3.14. Global Types

Global types are encoded by their value type and a flag for their mutability.

globaltype mut ::= ::= ∣ t : valtype m : mut 0x 00 0x 01 \Rightarrow \Rightarrow \Rightarrow m t const var

5.3.15. Tag Types

Tag types are encoded by a type index denoting a function type.

tagtype ::= 0x 00 x : typeidx \Rightarrow x

Note

In future versions of WebAssembly, the preceding zero byte may encode additional flags.

5.4. Instructions

Instructions are encoded by opcodes. Each opcode is represented by a single byte, and is followed by the instruction’s immediate arguments, where present. The only exception are structured control instructions, which consist of several opcodes bracketing their nested instruction sequences.

Note

Gaps in the byte code ranges for encoding instructions are reserved for future extensions.

5.4.1. Control Instructions

Control instructions have varying encodings. For structured instructions, the instruction sequences forming nested blocks are delimited with explicit opcodes for $end$ and $else$ .

Block types are encoded in special compressed form, by either the byte $0x 40$ indicating the empty type, as a single value type, or as a type index encoded as a positive signed integer.

Note

The $else$ opcode $0x 05$ in the encoding of an $if$ instruction can be omitted if the following instruction sequence is empty.

Unlike any other occurrence, the type index in a block type is encoded as a positive signed integer, so that its signed LEB128 bit pattern cannot collide with the encoding of value types or the special code $0x 40$ , which correspond to the LEB128 encoding of negative integers. To avoid any loss in the range of allowed indices, it is treated as a 33 bit signed integer.

5.4.2. Reference Instructions

Generic reference instructions are represented by single byte codes, others use prefixes and type operands.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x D0 t : heaptype 0x D1 0x D2 x : funcidx 0x D3 0x D4 0x FB 0 : u 32 x : typeidx 0x FB 1 : u 32 x : typeidx 0x FB 2 : u 32 x : typeidx y : fieldidx 0x FB 3 : u 32 x : typeidx y : fieldidx 0x FB 4 : u 32 x : typeidx y : fieldidx 0x FB 5 : u 32 x : typeidx y : fieldidx 0x FB 6 : u 32 x : typeidx 0x FB 7 : u 32 x : typeidx 0x FB 8 : u 32 x : typeidx n : u 32 0x FB 9 : u 32 x : typeidx y : dataidx 0x FB 10 : u 32 x : typeidx y : elemidx 0x FB 11 : u 32 x : typeidx 0x FB 12 : u 32 x : typeidx 0x FB 13 : u 32 x : typeidx 0x FB 14 : u 32 x : typeidx 0x FB 15 : u 32 0x FB 16 : u 32 x : typeidx 0x FB 17 : u 32 x : typeidx y : typeidx 0x FB 18 : u 32 x : typeidx y : dataidx 0x FB 19 : u 32 x : typeidx y : elemidx 0x FB 20 : u 32 ht : heaptype 0x FB 21 : u 32 ht : heaptype 0x FB 22 : u 32 ht : heaptype 0x FB 23 : u 32 ht : heaptype 0x FB 26 : u 32 0x FB 27 : u 32 0x FB 28 : u 32 0x FB 29 : u 32 0x FB 30 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow ref.null t ref.is_null ref.func x ref.eq ref.as_non_null struct.new x struct.new_default x struct.get x y struct.get_s x y struct.get_u x y struct.set x y array.new x array.new_default x array.new_fixed x n array.new_data x y array.new_elem x y array.get x array.get_s x array.get_u x array.set x array.len array.fill x array.copy x y array.init_data x y array.init_elem x y ref.test (ref ht) ref.test (ref null ht) ref.cast (ref ht) ref.cast (ref null ht) any.convert_extern extern.convert_any ref.i31 i31.get_s i31.get_u

5.4.3. Parametric Instructions

Parametric instructions are represented by single byte codes, possibly followed by a type annotation.

instr ::= ∣ ∣ ∣ \dots 0x 1A 0x 1B 0x 1C t^{*} : vec (valtype) \Rightarrow \Rightarrow \Rightarrow drop select select t^{*}

5.4.4. Variable Instructions

Variable instructions are represented by byte codes followed by the encoding of the respective index.

instr ::= ∣ ∣ ∣ ∣ ∣ \dots 0x 20 x : localidx 0x 21 x : localidx 0x 22 x : localidx 0x 23 x : globalidx 0x 24 x : globalidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow local.get x local.set x local.tee x global.get x global.set x

5.4.5. Table Instructions

Table instructions are represented either by a single byte or a one byte prefix followed by a variable-length unsigned integer.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 25 x : tableidx 0x 26 x : tableidx 0x FC 12 : u 32 y : elemidx x : tableidx 0x FC 13 : u 32 x : elemidx 0x FC 14 : u 32 x : tableidx y : tableidx 0x FC 15 : u 32 x : tableidx 0x FC 16 : u 32 x : tableidx 0x FC 17 : u 32 x : tableidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow table.get x table.set x table.init x y elem.drop x table.copy x y table.grow x table.size x table.fill x

5.4.6. Memory Instructions

Each variant of memory instruction is encoded with a different byte code. Loads and stores are followed by the encoding of their $memarg$ immediate, which includes the memory index if bit 6 of the flags field containing alignment is set; the memory index defaults to 0 otherwise.

memarg instr ::= ∣ ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a : u 32 o : u 64 a : u 32 x : memidx o : u 64 \dots 0x 28 m : memarg 0x 29 m : memarg 0x 2A m : memarg 0x 2B m : memarg 0x 2C m : memarg 0x 2D m : memarg 0x 2E m : memarg 0x 2F m : memarg 0x 30 m : memarg 0x 31 m : memarg 0x 32 m : memarg 0x 33 m : memarg 0x 34 m : memarg 0x 35 m : memarg 0x 36 m : memarg 0x 37 m : memarg 0x 38 m : memarg 0x 39 m : memarg 0x 3A m : memarg 0x 3B m : memarg 0x 3C m : memarg 0x 3D m : memarg 0x 3E m : memarg 0x 3F x : memidx 0x 40 x : memidx 0x FC 8 : u 32 y : dataidx x : memidx 0x FC 9 : u 32 x : dataidx 0x FC 10 : u 32 x : memidx y : memidx 0x FC 11 : u 32 x : memidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow 0 {align a, offset o} x {align (a - 2^{6}), offset o} i32 . load m i64 . load m f32 . load m f64 . load m i32 . load 8_s m i32 . load 8_u m i32 . load 16_s m i32 . load 16_u m i64 . load 8_s m i64 . load 8_u m i64 . load 16_s m i64 . load 16_u m i64 . load 32_s m i64 . load 32_u m i32 . store m i64 . store m f32 . store m f64 . store m i32 . store 8 m i32 . store 16 m i64 . store 8 m i64 . store 16 m i64 . store 32 m memory.size x memory.grow x memory.init x y data.drop x memory.copy x y memory.fill x (if a < 2^{6}) (if 2^{6} \leq a < 2^{7})

5.4.7. Numeric Instructions

All variants of numeric instructions are represented by separate byte codes.

The $const$ instructions are followed by the respective literal.

instr ::= ∣ ∣ ∣ ∣ \dots 0x 41 n : i 32 0x 42 n : i 64 0x 43 z : f 32 0x 44 z : f 64 \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 . const n i64 . const n f32 . const z f64 . const z

All other numeric instructions are plain opcodes without any immediates.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 45 0x 46 0x 47 0x 48 0x 49 0x 4A 0x 4B 0x 4C 0x 4D 0x 4E 0x 4F \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . eqz i32 . eq i32 . ne i32 . lt_s i32 . lt_u i32 . gt_s i32 . gt_u i32 . le_s i32 . le_u i32 . ge_s i32 . ge_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 50 0x 51 0x 52 0x 53 0x 54 0x 55 0x 56 0x 57 0x 58 0x 59 0x 5A \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i64 . eqz i64 . eq i64 . ne i64 . lt_s i64 . lt_u i64 . gt_s i64 . gt_u i64 . le_s i64 . le_u i64 . ge_s i64 . ge_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 5B 0x 5C 0x 5D 0x 5E 0x 5F 0x 60 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f32 . eq f32 . ne f32 . lt f32 . gt f32 . le f32 . ge

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 61 0x 62 0x 63 0x 64 0x 65 0x 66 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f64 . eq f64 . ne f64 . lt f64 . gt f64 . le f64 . ge

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 67 0x 68 0x 69 0x 6A 0x 6B 0x 6C 0x 6D 0x 6E 0x 6F 0x 70 0x 71 0x 72 0x 73 0x 74 0x 75 0x 76 0x 77 0x 78 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . clz i32 . ctz i32 . popcnt i32 . add i32 . sub i32 . mul i32 . div_s i32 . div_u i32 . rem_s i32 . rem_u i32 . and i32 . or i32 . xor i32 . shl i32 . shr_s i32 . shr_u i32 . rotl i32 . rotr

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 79 0x 7A 0x 7B 0x 7C 0x 7D 0x 7E 0x 7F 0x 80 0x 81 0x 82 0x 83 0x 84 0x 85 0x 86 0x 87 0x 88 0x 89 0x 8A \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i64 . clz i64 . ctz i64 . popcnt i64 . add i64 . sub i64 . mul i64 . div_s i64 . div_u i64 . rem_s i64 . rem_u i64 . and i64 . or i64 . xor i64 . shl i64 . shr_s i64 . shr_u i64 . rotl i64 . rotr

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 8B 0x 8C 0x 8D 0x 8E 0x 8F 0x 90 0x 91 0x 92 0x 93 0x 94 0x 95 0x 96 0x 97 0x 98 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f32 . abs f32 . neg f32 . ceil f32 . floor f32 . trunc f32 . nearest f32 . sqrt f32 . add f32 . sub f32 . mul f32 . div f32 . min f32 . max f32 . copysign

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x 99 0x 9A 0x 9B 0x 9C 0x 9D 0x 9E 0x 9F 0x A0 0x A1 0x A2 0x A3 0x A4 0x A5 0x A6 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f64 . abs f64 . neg f64 . ceil f64 . floor f64 . trunc f64 . nearest f64 . sqrt f64 . add f64 . sub f64 . mul f64 . div f64 . min f64 . max f64 . copysign

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x A7 0x A8 0x A9 0x AA 0x AB 0x AC 0x AD 0x AE 0x AF 0x B0 0x B1 0x B2 0x B3 0x B4 0x B5 0x B6 0x B7 0x B8 0x B9 0x BA 0x BB 0x BC 0x BD 0x BE 0x BF \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . wrap_i64 i32 . trunc_f32_s i32 . trunc_f32_u i32 . trunc_f64_s i32 . trunc_f64_u i64 . extend_i32_s i64 . extend_i32_u i64 . trunc_f32_s i64 . trunc_f32_u i64 . trunc_f64_s i64 . trunc_f64_u f32 . convert_i32_s f32 . convert_i32_u f32 . convert_i64_s f32 . convert_i64_u f32 . demote_f64 f64 . convert_i32_s f64 . convert_i32_u f64 . convert_i64_s f64 . convert_i64_u f64 . promote_f32 i32 . reinterpret_f32 i64 . reinterpret_f64 f32 . reinterpret_i32 f64 . reinterpret_i64

instr ::= ∣ ∣ ∣ ∣ ∣ \dots 0x C0 0x C1 0x C2 0x C3 0x C4 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . extend 8_s i32 . extend 16_s i64 . extend 8_s i64 . extend 16_s i64 . extend 32_s

The saturating truncation instructions all have a one byte prefix, whereas the actual opcode is encoded by a variable-length unsigned integer.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FC 0 : u 32 0x FC 1 : u 32 0x FC 2 : u 32 0x FC 3 : u 32 0x FC 4 : u 32 0x FC 5 : u 32 0x FC 6 : u 32 0x FC 7 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . trunc_sat_f32_s i32 . trunc_sat_f32_u i32 . trunc_sat_f64_s i32 . trunc_sat_f64_u i64 . trunc_sat_f32_s i64 . trunc_sat_f32_u i64 . trunc_sat_f64_s i64 . trunc_sat_f64_u

5.4.8. Vector Instructions

All variants of vector instructions are represented by separate byte codes. They all have a one byte prefix, whereas the actual opcode is encoded by a variable-length unsigned integer.

Vector loads and stores are followed by the encoding of their $memarg$ immediate.

laneidx instr ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ l : byte \dots 0x FD 0 : u 32 m : memarg 0x FD 1 : u 32 m : memarg 0x FD 2 : u 32 m : memarg 0x FD 3 : u 32 m : memarg 0x FD 4 : u 32 m : memarg 0x FD 5 : u 32 m : memarg 0x FD 6 : u 32 m : memarg 0x FD 7 : u 32 m : memarg 0x FD 8 : u 32 m : memarg 0x FD 9 : u 32 m : memarg 0x FD 10 : u 32 m : memarg 0x FD 92 : u 32 m : memarg 0x FD 93 : u 32 m : memarg 0x FD 11 : u 32 m : memarg 0x FD 84 : u 32 m : memarg l : laneidx 0x FD 85 : u 32 m : memarg l : laneidx 0x FD 86 : u 32 m : memarg l : laneidx 0x FD 87 : u 32 m : memarg l : laneidx 0x FD 88 : u 32 m : memarg l : laneidx 0x FD 89 : u 32 m : memarg l : laneidx 0x FD 90 : u 32 m : memarg l : laneidx 0x FD 91 : u 32 m : memarg l : laneidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow l v128 . load m v128 . load 8x8_s m v128 . load 8x8_u m v128 . load 16x4_s m v128 . load 16x4_u m v128 . load 32x2_s m v128 . load 32x2_u m v128 . load 8_splat m v128 . load 16_splat m v128 . load 32_splat m v128 . load 64_splat m v128 . load 32_zero m v128 . load 64_zero m v128 . store m v128 . load 8_lane m l v128 . load 16_lane m l v128 . load 32_lane m l v128 . load 64_lane m l v128 . store 8_lane m l v128 . store 16_lane m l v128 . store 32_lane m l v128 . store 64_lane m l

The $const$ instruction is followed by 16 immediate bytes, which are converted into a $i128$ in $littleendian$ byte order:

instr ::= ∣ \dots 0x FD 12 : u 32 (b : byte)^{16} \Rightarrow v128 . const bytes_{i128}^{- 1} (b_{0} \dots b_{15})

The $shuffle$ instruction is also followed by the encoding of 16 $laneidx$ immediates.

instr ::= ∣ \dots 0x FD 13 : u 32 (l : laneidx)^{16} \Rightarrow i8x16 . shuffle l^{16}

$extract_lane$ and $replace_lane$ instructions are followed by the encoding of a $laneidx$ immediate.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 21 : u 32 l : laneidx 0x FD 22 : u 32 l : laneidx 0x FD 23 : u 32 l : laneidx 0x FD 24 : u 32 l : laneidx 0x FD 25 : u 32 l : laneidx 0x FD 26 : u 32 l : laneidx 0x FD 27 : u 32 l : laneidx 0x FD 28 : u 32 l : laneidx 0x FD 29 : u 32 l : laneidx 0x FD 30 : u 32 l : laneidx 0x FD 31 : u 32 l : laneidx 0x FD 32 : u 32 l : laneidx 0x FD 33 : u 32 l : laneidx 0x FD 34 : u 32 l : laneidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow i8x16 . extract_lane_s l i8x16 . extract_lane_u l i8x16 . replace_lane l i16x8 . extract_lane_s l i16x8 . extract_lane_u l i16x8 . replace_lane l i32x4 . extract_lane l i32x4 . replace_lane l i64x2 . extract_lane l i64x2 . replace_lane l f32x4 . extract_lane l f32x4 . replace_lane l f64x2 . extract_lane l f64x2 . replace_lane l

All other vector instructions are plain opcodes without any immediates.

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 14 : u 32 0x FD 15 : u 32 0x FD 16 : u 32 0x FD 17 : u 32 0x FD 18 : u 32 0x FD 19 : u 32 0x FD 20 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i8x16 . swizzle i8x16 . splat i16x8 . splat i32x4 . splat i64x2 . splat f32x4 . splat f64x2 . splat

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 35 : u 32 0x FD 36 : u 32 0x FD 37 : u 32 0x FD 38 : u 32 0x FD 39 : u 32 0x FD 40 : u 32 0x FD 41 : u 32 0x FD 42 : u 32 0x FD 43 : u 32 0x FD 44 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i8x16 . eq i8x16 . ne i8x16 . lt_s i8x16 . lt_u i8x16 . gt_s i8x16 . gt_u i8x16 . le_s i8x16 . le_u i8x16 . ge_s i8x16 . ge_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 45 : u 32 0x FD 46 : u 32 0x FD 47 : u 32 0x FD 48 : u 32 0x FD 49 : u 32 0x FD 50 : u 32 0x FD 51 : u 32 0x FD 52 : u 32 0x FD 53 : u 32 0x FD 54 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i16x8 . eq i16x8 . ne i16x8 . lt_s i16x8 . lt_u i16x8 . gt_s i16x8 . gt_u i16x8 . le_s i16x8 . le_u i16x8 . ge_s i16x8 . ge_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 55 : u 32 0x FD 56 : u 32 0x FD 57 : u 32 0x FD 58 : u 32 0x FD 59 : u 32 0x FD 60 : u 32 0x FD 61 : u 32 0x FD 62 : u 32 0x FD 63 : u 32 0x FD 64 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i32x4 . eq i32x4 . ne i32x4 . lt_s i32x4 . lt_u i32x4 . gt_s i32x4 . gt_u i32x4 . le_s i32x4 . le_u i32x4 . ge_s i32x4 . ge_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 214 : u 32 0x FD 215 : u 32 0x FD 216 : u 32 0x FD 217 : u 32 0x FD 218 : u 32 0x FD 219 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i64x2 . eq i64x2 . ne i64x2 . lt_s i64x2 . gt_s i64x2 . le_s i64x2 . ge_s

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 65 : u 32 0x FD 66 : u 32 0x FD 67 : u 32 0x FD 68 : u 32 0x FD 69 : u 32 0x FD 70 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es f32x4 . eq f32x4 . ne f32x4 . lt f32x4 . gt f32x4 . le f32x4 . ge

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 71 : u 32 0x FD 72 : u 32 0x FD 73 : u 32 0x FD 74 : u 32 0x FD 75 : u 32 0x FD 76 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es f64x2 . eq f64x2 . ne f64x2 . lt f64x2 . gt f64x2 . le f64x2 . ge

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 77 : u 32 0x FD 78 : u 32 0x FD 79 : u 32 0x FD 80 : u 32 0x FD 81 : u 32 0x FD 82 : u 32 0x FD 83 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es v128 . not v128 . and v128 . andnot v128 . or v128 . xor v128 . bitselect v128 . any_true

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 96 : u 32 0x FD 97 : u 32 0x FD 98 : u 32 0x FD 99 : u 32 0x FD 100 : u 32 0x FD 101 : u 32 0x FD 102 : u 32 0x FD 107 : u 32 0x FD 108 : u 32 0x FD 109 : u 32 0x FD 110 : u 32 0x FD 111 : u 32 0x FD 112 : u 32 0x FD 113 : u 32 0x FD 114 : u 32 0x FD 115 : u 32 0x FD 118 : u 32 0x FD 119 : u 32 0x FD 120 : u 32 0x FD 121 : u 32 0x FD 123 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i8x16 . abs i8x16 . neg i8x16 . popcnt i8x16 . all_true i8x16 . bitmask i8x16 . narrow_i16x8_s i8x16 . narrow_i16x8_u i8x16 . shl i8x16 . shr_s i8x16 . shr_u i8x16 . add i8x16 . add_sat_s i8x16 . add_sat_u i8x16 . sub i8x16 . sub_sat_s i8x16 . sub_sat_u i8x16 . min_s i8x16 . min_u i8x16 . max_s i8x16 . max_u i8x16 . avgr_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 124 : u 32 0x FD 125 : u 32 0x FD 128 : u 32 0x FD 129 : u 32 0x FD 130 : u 32 0x FD 131 : u 32 0x FD 132 : u 32 0x FD 133 : u 32 0x FD 134 : u 32 0x FD 135 : u 32 0x FD 136 : u 32 0x FD 137 : u 32 0x FD 138 : u 32 0x FD 139 : u 32 0x FD 140 : u 32 0x FD 141 : u 32 0x FD 142 : u 32 0x FD 143 : u 32 0x FD 144 : u 32 0x FD 145 : u 32 0x FD 146 : u 32 0x FD 147 : u 32 0x FD 149 : u 32 0x FD 150 : u 32 0x FD 151 : u 32 0x FD 152 : u 32 0x FD 153 : u 32 0x FD 155 : u 32 0x FD 156 : u 32 0x FD 157 : u 32 0x FD 158 : u 32 0x FD 159 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i16x8 . extadd_pairwise_i8x16_s i16x8 . extadd_pairwise_i8x16_u i16x8 . abs i16x8 . neg i16x8 . q15mulr_sat_s i16x8 . all_true i16x8 . bitmask i16x8 . narrow_i32x4_s i16x8 . narrow_i32x4_u i16x8 . extend_low_i8x16_s i16x8 . extend_high_i8x16_s i16x8 . extend_low_i8x16_u i16x8 . extend_high_i8x16_u i16x8 . shl i16x8 . shr_s i16x8 . shr_u i16x8 . add i16x8 . add_sat_s i16x8 . add_sat_u i16x8 . sub i16x8 . sub_sat_s i16x8 . sub_sat_u i16x8 . mul i16x8 . min_s i16x8 . min_u i16x8 . max_s i16x8 . max_u i16x8 . avgr_u i16x8 . extmul_low_i8x16_s i16x8 . extmul_high_i8x16_s i16x8 . extmul_low_i8x16_u i16x8 . extmul_high_i8x16_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 126 : u 32 0x FD 127 : u 32 0x FD 160 : u 32 0x FD 161 : u 32 0x FD 163 : u 32 0x FD 164 : u 32 0x FD 167 : u 32 0x FD 168 : u 32 0x FD 169 : u 32 0x FD 170 : u 32 0x FD 171 : u 32 0x FD 172 : u 32 0x FD 173 : u 32 0x FD 174 : u 32 0x FD 177 : u 32 0x FD 181 : u 32 0x FD 182 : u 32 0x FD 183 : u 32 0x FD 184 : u 32 0x FD 185 : u 32 0x FD 186 : u 32 0x FD 188 : u 32 0x FD 189 : u 32 0x FD 190 : u 32 0x FD 191 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i32x4 . extadd_pairwise_i16x8_s i32x4 . extadd_pairwise_i16x8_u i32x4 . abs i32x4 . neg i32x4 . all_true i32x4 . bitmask i32x4 . extend_low_i16x8_s i32x4 . extend_high_i16x8_s i32x4 . extend_low_i16x8_u i32x4 . extend_high_i16x8_u i32x4 . shl i32x4 . shr_s i32x4 . shr_u i32x4 . add i32x4 . sub i32x4 . mul i32x4 . min_s i32x4 . min_u i32x4 . max_s i32x4 . max_u i32x4 . dot_i16x8_s i32x4 . extmul_low_i16x8_s i32x4 . extmul_high_i16x8_s i32x4 . extmul_low_i16x8_u i32x4 . extmul_high_i16x8_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 192 : u 32 0x FD 193 : u 32 0x FD 195 : u 32 0x FD 196 : u 32 0x FD 199 : u 32 0x FD 200 : u 32 0x FD 201 : u 32 0x FD 202 : u 32 0x FD 203 : u 32 0x FD 204 : u 32 0x FD 205 : u 32 0x FD 206 : u 32 0x FD 209 : u 32 0x FD 213 : u 32 0x FD 220 : u 32 0x FD 221 : u 32 0x FD 222 : u 32 0x FD 223 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i64x2 . abs i64x2 . neg i64x2 . all_true i64x2 . bitmask i64x2 . extend_low_i32x4_s i64x2 . extend_high_i32x4_s i64x2 . extend_low_i32x4_u i64x2 . extend_high_i32x4_u i64x2 . shl i64x2 . shr_s i64x2 . shr_u i64x2 . add i64x2 . sub i64x2 . mul i64x2 . extmul_low_i32x4_s i64x2 . extmul_high_i32x4_s i64x2 . extmul_low_i32x4_u i64x2 . extmul_high_i32x4_u

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 103 : u 32 0x FD 104 : u 32 0x FD 105 : u 32 0x FD 106 : u 32 0x FD 224 : u 32 0x FD 225 : u 32 0x FD 227 : u 32 0x FD 228 : u 32 0x FD 229 : u 32 0x FD 230 : u 32 0x FD 231 : u 32 0x FD 232 : u 32 0x FD 233 : u 32 0x FD 234 : u 32 0x FD 235 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es f32x4 . ceil f32x4 . floor f32x4 . trunc f32x4 . nearest f32x4 . abs f32x4 . neg f32x4 . sqrt f32x4 . add f32x4 . sub f32x4 . mul f32x4 . div f32x4 . min f32x4 . max f32x4 . pmin f32x4 . pmax

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 116 : u 32 0x FD 117 : u 32 0x FD 122 : u 32 0x FD 148 : u 32 0x FD 236 : u 32 0x FD 237 : u 32 0x FD 239 : u 32 0x FD 240 : u 32 0x FD 241 : u 32 0x FD 242 : u 32 0x FD 243 : u 32 0x FD 244 : u 32 0x FD 245 : u 32 0x FD 246 : u 32 0x FD 247 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es f64x2 . ceil f64x2 . floor f64x2 . trunc f64x2 . nearest f64x2 . abs f64x2 . neg f64x2 . sqrt f64x2 . add f64x2 . sub f64x2 . mul f64x2 . div f64x2 . min f64x2 . max f64x2 . pmin f64x2 . pmax

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 248 : u 32 0x FD 249 : u 32 0x FD 250 : u 32 0x FD 251 : u 32 0x FD 252 : u 32 0x FD 253 : u 32 0x FD 254 : u 32 0x FD 255 : u 32 0x FD 94 : u 32 0x FD 95 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i32x4 . trunc_sat_f32x4_s i32x4 . trunc_sat_f32x4_u f32x4 . convert_i32x4_s f32x4 . convert_i32x4_u i32x4 . trunc_sat_f64x2_s_zero i32x4 . trunc_sat_f64x2_u_zero f64x2 . convert_low_i32x4_s f64x2 . convert_low_i32x4_u f32x4 . demote_f64x2_zero f64x2 . promote_low_f32x4

instr ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots 0x FD 256 : u 32 0x FD 257 : u 32 0x FD 258 : u 32 0x FD 259 : u 32 0x FD 260 : u 32 0x FD 261 : u 32 0x FD 262 : u 32 0x FD 263 : u 32 0x FD 264 : u 32 0x FD 265 : u 32 0x FD 266 : u 32 0x FD 267 : u 32 0x FD 268 : u 32 0x FD 269 : u 32 0x FD 270 : u 32 0x FD 271 : u 32 0x FD 272 : u 32 0x FD 273 : u 32 0x FD 274 : u 32 0x FD 275 : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha s l o n g er in s t r u c t i o nnam es i16x8 . relaxed_swizzle i32x4 . relaxed_trunc_f32x4_s i32x4 . relaxed_trunc_f32x4_u i32x4 . relaxed_trunc_f32x4_s_zero i32x4 . relaxed_trunc_f32x4_u_zero f32x4 . relaxed_madd f32x4 . relaxed_nmadd f64x2 . relaxed_madd f64x2 . relaxed_nmadd i8x16 . relaxed_laneselect i16x8 . relaxed_laneselect i32x4 . relaxed_laneselect i64x2 . relaxed_laneselect f32x4 . relaxed_min f32x4 . relaxed_max f64x2 . relaxed_min f64x2 . relaxed_max i16x8 . relaxed_q15mulr_s i16x8 . relaxed_dot_i8x16_i7x16_s i16x8 . relaxed_dot_i8x16_i7x16_add_s

5.4.9. Expressions

Expressions are encoded by their instruction sequence terminated with an explicit $0x 0B$ opcode for $end$ .

expr ::= (in : instr)^{*} 0x 0B \Rightarrow in^{*} end

5.5. Modules

The binary encoding of modules is organized into sections. Most sections correspond to one component of a module record, except that function definitions are split into two sections, separating their type declarations in the function section from their bodies in the code section.

Note

This separation enables parallel and streaming compilation of the functions in a module.

5.5.1. Indices

All indices are encoded with their respective value.

typeidx funcidx tableidx memidx globalidx tagidx elemidx dataidx localidx labelidx fieldidx ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= ::= x : u 32 x : u 32 x : u 32 x : u 32 x : u 32 x : u 32 x : u 32 x : u 32 x : u 32 l : u 32 x : u 32 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow x x x x x x x x x l x

5.5.2. Sections

Each section consists of

a one-byte section id,
the $u32$ size of the contents, in bytes,
the actual contents, whose structure is dependent on the section id.

Every section is optional; an omitted section is equivalent to the section being present with empty contents.

The following parameterized grammar rule defines the generic structure of a section with id $N$ and contents described by the grammar $B$ .

section_{N} (B) ::= ∣ N : byte size : u 32 cont : B ϵ \Rightarrow \Rightarrow cont ϵ (if size = ∣∣ B ∣∣)

For most sections, the contents $B$ encodes a vector. In these cases, the empty result $ϵ$ is interpreted as the empty vector.

Note

Other than for unknown custom sections, the $size$ is not required for decoding, but can be used to skip sections when navigating through a binary. The module is malformed if the size does not match the length of the binary contents $B$ .

The following section ids are used:

Id	Section
0	custom section
1	type section
2	import section
3	function section
4	table section
5	memory section
6	global section
7	export section
8	start section
9	element section
10	code section
11	data section
12	data count section
13	tag section

Note

Section ids do not always correspond to the order of sections in the encoding of a module.

5.5.3. Custom Section

Custom sections have the id 0. They are intended to be used for debugging information or third-party extensions, and are ignored by the WebAssembly semantics. Their contents consist of a name further identifying the custom section, followed by an uninterpreted sequence of bytes for custom use.

customsec custom ::= ::= section_{0} (custom) name byte^{*}

Note

If an implementation interprets the data of a custom section, then errors in that data, or the placement of the section, must not invalidate the module.

5.5.4. Type Section

The type section has the id 1. It decodes into a vector of recursive types that represent the $types$ component of a module.

typesec ::= rt^{*} : section_{1} (vec (rectype)) \Rightarrow rt^{*}

5.5.5. Import Section

The import section has the id 2. It decodes into a vector of imports that represent the $imports$ component of a module.

importsec import importdesc ::= ::= ::= ∣ ∣ ∣ ∣ im^{*} : section_{2} (vec (import)) mod : name nm : name d : importdesc 0x 00 x : typeidx 0x 01 tt : tabletype 0x 02 mt : memtype 0x 03 gt : globaltype 0x 04 x : tagtype \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow im^{*} {module mod, name nm, desc d} func x table tt mem mt global gt tag x

5.5.6. Function Section

The function section has the id 3. It decodes into a vector of type indices that represent the $type$ fields of the functions in the $funcs$ component of a module. The $locals$ and $body$ fields of the respective functions are encoded separately in the code section.

funcsec ::= x^{*} : section_{3} (vec (typeidx)) \Rightarrow x^{*}

5.5.7. Table Section

The table section has the id 4. It decodes into a vector of tables that represent the $tables$ component of a module.

tablesec table ::= ::= ∣ tab^{*} : section_{4} (vec (table)) tt : tabletype 0x 40 0x 00 tt : tabletype e : expr \Rightarrow \Rightarrow \Rightarrow tab^{*} {type tt, init (ref.null ht)} if tt = limits (ref null^{?} ht) {type tt, init e}

Note

The encoding of a table type cannot start with byte $0x 40$ , hence decoding is unambiguous. The zero byte following it is reserved for future extensions.

5.5.8. Memory Section

The memory section has the id 5. It decodes into a vector of memories that represent the $mems$ component of a module.

memsec mem ::= ::= mem^{*} : section_{5} (vec (mem)) mt : memtype \Rightarrow \Rightarrow mem^{*} {type mt}

5.5.9. Global Section

The global section has the id 6. It decodes into a vector of globals that represent the $globals$ component of a module.

globalsec global ::= ::= glob^{*} : section_{6} (vec (global)) gt : globaltype e : expr \Rightarrow \Rightarrow glob^{*} {type gt, init e}

5.5.10. Export Section

The export section has the id 7. It decodes into a vector of exports that represent the $exports$ component of a module.

exportsec export exportdesc ::= ::= ::= ∣ ∣ ∣ ∣ ex^{*} : section_{7} (vec (export)) nm : name d : exportdesc 0x 00 x : funcidx 0x 01 x : tableidx 0x 02 x : memidx 0x 03 x : globalidx 0x 04 x : tagidx \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow ex^{*} {name nm, desc d} func x table x mem x global x tag x

5.5.11. Start Section

The start section has the id 8. It decodes into an optional start function that represents the $start$ component of a module.

startsec start ::= ::= st^{?} : section_{8} (start) x : funcidx \Rightarrow \Rightarrow st^{?} {func x}

5.5.12. Element Section

The element section has the id 9. It decodes into a vector of element segments that represent the $elems$ component of a module.

elemsec elem elemkind ::= ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= seg^{*} : section_{9} (vec (elem)) 0 : u 32 e : expr y^{*} : vec (funcidx) {type (ref func), init ((ref.func y) end)^{*}, mode active {table 0, offset e}} 1 : u 32 et : elemkind y^{*} : vec (funcidx) {type et, init ((ref.func y) end)^{*}, mode passive} 2 : u 32 x : tableidx e : expr et : elemkind y^{*} : vec (funcidx) {type et, init ((ref.func y) end)^{*}, mode active {table x, offset e}} 3 : u 32 et : elemkind y^{*} : vec (funcidx) {type et, init ((ref.func y) end)^{*}, mode declarative} 4 : u 32 e : expr el^{*} : vec (expr) {type (ref null func), init el^{*}, mode active {table 0, offset e}} 5 : u 32 et : reftype el^{*} : vec (expr) {type e t, init el^{*}, mode passive} 6 : u 32 x : tableidx e : expr et : reftype el^{*} : vec (expr) {type e t, init el^{*}, mode active {table x, offset e}} 7 : u 32 et : reftype el^{*} : vec (expr) {type e t, init el^{*}, mode declarative} 0x 00 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow seg^{*} (ref func)

Note

The initial integer can be interpreted as a bitfield. Bit 0 distinguishes a passive or declarative segment from an active segment, bit 1 indicates the presence of an explicit table index for an active segment and otherwise distinguishes passive from declarative segments, bit 2 indicates the use of element type and element expressions instead of element kind and element indices.

Additional element kinds may be added in future versions of WebAssembly.

5.5.13. Code Section

The code section has the id 10. It decodes into a vector of code entries that are pairs of value type vectors and expressions. They represent the $locals$ and $body$ field of the functions in the $funcs$ component of a module. The $type$ fields of the respective functions are encoded separately in the function section.

The encoding of each code entry consists of

the $u32$ size of the function code in bytes,
the actual function code, which in turn consists of
- the declaration of locals,
- the function body as an expression.

Local declarations are compressed into a vector whose entries consist of

a $u32$ count,
a value type,

denoting count locals of the same value type.

codesec code func locals ::= ::= ::= ::= code^{*} : section_{10} (vec (code)) size : u 32 code : func (local^{*})^{*} : vec (locals) e : expr n : u 32 t : valtype \Rightarrow \Rightarrow \Rightarrow \Rightarrow code^{*} code concat ((local^{*})^{*}), e {type t}^{n} (if size = ∣∣ func ∣∣) (if ∣ concat ((local^{*})^{*}) ∣ < 2^{32})

Here, $code$ ranges over pairs $(valtype^{*}, expr)$ . The meta function $concat ((local^{*})^{*})$ concatenates all sequences $local_{i}^{*}$ in $(local^{*})^{*}$ . Any code for which the length of the resulting sequence is out of bounds of the maximum size of a vector is malformed.

Note

Like with sections, the code $size$ is not needed for decoding, but can be used to skip functions when navigating through a binary. The module is malformed if a size does not match the length of the respective function code.

5.5.14. Data Section

The data section has the id 11. It decodes into a vector of data segments that represent the $datas$ component of a module.

datasec data ::= ::= ∣ ∣ seg^{*} : section_{11} (vec (data)) 0 : u 32 e : expr b^{*} : vec (byte) 1 : u 32 b^{*} : vec (byte) 2 : u 32 x : memidx e : expr b^{*} : vec (byte) \Rightarrow \Rightarrow \Rightarrow \Rightarrow seg^{*} {init b^{*}, mode active {memory 0, offset e}} {init b^{*}, mode passive} {init b^{*}, mode active {memory x, offset e}}

Note

The initial integer can be interpreted as a bitfield. Bit 0 indicates a passive segment, bit 1 indicates the presence of an explicit memory index for an active segment.

In the current version of WebAssembly, at most one memory may be defined or imported in a single module, so all valid active data segments have a $memory$ value of $0$ .

5.5.15. Data Count Section

The data count section has the id 12. It decodes into an optional u32 that represents the number of data segments in the data section. If this count does not match the length of the data segment vector, the module is malformed.

datacountsec ::= n^{?} : section_{12} (u 32) \Rightarrow n^{?}

Note

The data count section is used to simplify single-pass validation. Since the data section occurs after the code section, the $memory.init$ and $data.drop$ instructions would not be able to check whether the data segment index is valid until the data section is read. The data count section occurs before the code section, so a single-pass validator can use this count instead of deferring validation.

5.5.16. Tag Section

The tag section has the id 13. It decodes into a vector of tags that represent the $tags$ component of a module.

tagsec tag ::= ::= tag^{*} : section_{13} (vec (tag)) 0x 00 x : typeidx \Rightarrow \Rightarrow tag^{*} {type x}

5.5.17. Modules

The encoding of a module starts with a preamble containing a 4-byte magic number (the string $‘ \0asm ’$ ) and a version field. The current version of the WebAssembly binary format is 1.

The preamble is followed by a sequence of sections. Custom sections may be inserted at any place in this sequence, while other sections must occur at most once and in the prescribed order. All sections can be empty.

The lengths of vectors produced by the (possibly empty) function and code section must match up.

Similarly, the optional data count must match the length of the data segment vector. Furthermore, it must be present if any data index occurs in the code section.

magic version module ::= ::= ::= 0x 00 0x 61 0x 73 0x 6D 0x 01 0x 00 0x 00 0x 00 magic version customsec^{*} rectype^{*} : typesec customsec^{*} import^{*} : importsec customsec^{*} typeidx^{n} : funcsec customsec^{*} table^{*} : tablesec customsec^{*} mem^{*} : memsec customsec^{*} tag^{*} : tagsec customsec^{*} global^{*} : globalsec customsec^{*} export^{*} : exportsec customsec^{*} start^{?} : startsec customsec^{*} elem^{*} : elemsec customsec^{*} m^{?} : datacountsec customsec^{*} code^{n} : codesec customsec^{*} data^{m} : datasec customsec^{*} \Rightarrow {types rectype^{*}, funcs func^{n}, tables table^{*}, mems mem^{*}, globals global^{*}, tags tag^{*}, elems elem^{*}, datas data^{m}, start start^{?}, imports import^{*}, exports export^{*}} (if m^{?} \neq = ϵ \lor dataidx (code^{n}) = \emptyset)

where for each $t_{i}^{*}, e_{i}$ in $code^{n}$ ,

func^{n} [i] = {type typeidx^{n} [i], locals t_{i}^{*}, body e_{i}}

Note

The version of the WebAssembly binary format may increase in the future if backward-incompatible changes have to be made to the format. However, such changes are expected to occur very infrequently, if ever. The binary format is intended to be forward-compatible, such that future extensions can be made without incrementing its version.

6. Text Format

6.1. Conventions

The textual format for WebAssembly modules is a rendering of their abstract syntax into S-expressions.

Like the binary format, the text format is defined by an attribute grammar. A text string is a well-formed description of a module if and only if it is generated by the grammar. Each production of this grammar has at most one synthesized attribute: the abstract syntax that the respective character sequence expresses. Thus, the attribute grammar implicitly defines a parsing function. Some productions also take a context as an inherited attribute that records bound identifiers.

Except for a few exceptions, the core of the text grammar closely mirrors the grammar of the abstract syntax. However, it also defines a number of abbreviations that are “syntactic sugar” over the core syntax.

The recommended extension for files containing WebAssembly modules in text format is “ $.wat$ ”. Files with this extension are assumed to be encoded in UTF-8, as per [UNICODE] (Section 2.5).

6.1.1. Grammar

The following conventions are adopted in defining grammar rules of the text format. They mirror the conventions used for abstract syntax and for the binary format. In order to distinguish symbols of the textual syntax from symbols of the abstract syntax, $typewriter$ font is adopted for the former.

Terminal symbols are either literal strings of characters enclosed in quotes or expressed as [UNICODE] scalar values: $‘ module ’$ , $U + 0A$ . (All characters written literally are unambiguously drawn from the 7-bit ASCII subset of Unicode.)
Nonterminal symbols are written in typewriter font: $valtype, instr$ .
$T^{n}$ is a sequence of $n \geq 0$ iterations of $T$ .
$T^{*}$ is a possibly empty sequence of iterations of $T$ . (This is a shorthand for $T^{n}$ used where $n$ is not relevant.)
$T^{+}$ is a sequence of one or more iterations of $T$ . (This is a shorthand for $T^{n}$ where $n \geq 1$ .)
$T^{?}$ is an optional occurrence of $T$ . (This is a shorthand for $T^{n}$ where $n \leq 1$ .)
$x : T$ denotes the same language as the nonterminal $T$ , but also binds the variable $x$ to the attribute synthesized for $T$ . A pattern may also be used instead of a variable, e.g., $(x, y) : T$ .
Productions are written $sym ::= T_{1} \Rightarrow A_{1} ∣ \dots ∣ T_{n} \Rightarrow A_{n}$ , where each $A_{i}$ is the attribute that is synthesized for $sym$ in the given case, usually from attribute variables bound in $T_{i}$ .
Some productions are augmented by side conditions in parentheses, which restrict the applicability of the production. They provide a shorthand for a combinatorial expansion of the production into many separate cases.
If the same meta variable or non-terminal symbol appears multiple times in a production (in the syntax or in an attribute), then all those occurrences must have the same instantiation.

A distinction is made between lexical and syntactic productions. For the latter, arbitrary white space is allowed in any place where the grammar contains spaces. The productions defining lexical syntax and the syntax of values are considered lexical, all others are syntactic.

Note

For example, the textual grammar for number types is given as follows:

numtype ::= ∣ ∣ ∣ ‘ i32 ’ ‘ i64 ’ ‘ f32 ’ ‘ f64 ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 i64 f32 f64

The textual grammar for limits is defined as follows:

limits ::= ∣ n : u 32 n : u 32 m : u 32 \Rightarrow \Rightarrow {min n, max ϵ} {min n, max m}

The variables $n$ and $m$ name the attributes of the respective $u 32$ nonterminals, which in this case are the actual unsigned integers those parse into. The attribute of the complete production then is the abstract syntax for the limit, expressed in terms of the former values.

6.1.2. Abbreviations

In addition to the core grammar, which corresponds directly to the abstract syntax, the textual syntax also defines a number of abbreviations that can be used for convenience and readability.

Abbreviations are defined by rewrite rules specifying their expansion into the core syntax:

abbreviation syntax \equiv expanded syntax

These expansions are assumed to be applied, recursively and in order of appearance, before applying the core grammar rules to construct the abstract syntax.

6.1.3. Contexts

The text format allows the use of symbolic identifiers in place of indices. To resolve these identifiers into concrete indices, some grammar productions are indexed by an identifier context $I$ as a synthesized attribute that records the declared identifiers in each index space. In addition, the context records the types defined in the module, so that parameter indices can be computed for functions.

It is convenient to define identifier contexts as records $I$ with abstract syntax as follows:

I ::= {types funcs tables mems globals tags elem data locals labels fields typedefs (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, (name^{?})^{*}, ((name^{?})^{*})^{*}} subtype^{*}}

For each index space, such a context contains the list of names assigned to the defined indices, which were denoted by the corresponding identifiers. Unnamed indices are associated with empty ( $ϵ$ ) entries in these lists. Fields have dependent name spaces, and hence a separate list of field identifiers per type.

An identifier context is well-formed if no index space contains duplicate identifiers. For fields, names need only be unique within a single type.

6.1.3.1. Conventions

To avoid unnecessary clutter, empty components are omitted when writing out identifier contexts. For example, the record ${}$ is shorthand for an identifier context whose components are all empty.

6.1.4. Vectors

Vectors are written as plain sequences, but with a restriction on the length of these sequence.

vec (A) ::= (x : A)^{n} \Rightarrow x^{n} (if n < 2^{32})

6.2. Lexical Format

6.2.1. Characters

The text format assigns meaning to source text, which consists of a sequence of characters. Characters are assumed to be represented as valid [UNICODE] (Section 2.4) scalar values.

source char ::= ::= char^{*} U + 00 ∣ \dots ∣ U + D7FF ∣ U + E000 ∣ \dots ∣ U + 10FFFF

Note

While source text may contain any Unicode character in comments or string literals, the rest of the grammar is formed exclusively from the characters supported by the 7-bit ASCII subset of Unicode.

6.2.2. Tokens

The character stream in the source text is divided, from left to right, into a sequence of tokens, as defined by the following grammar.

token keyword reserved ::= ::= ::= keyword ∣ u N ∣ s N ∣ f N ∣ string ∣ id ∣ ‘ (’ ∣ ‘) ’ ∣ reserved (‘ a ’ ∣ \dots ∣ ‘ z ’) idchar^{*} (if occurring as a literal terminal in the grammar) (idchar ∣ string ∣ ‘, ’ ∣ ‘; ’ ∣ ‘ [’ ∣ ‘] ’ ∣ ‘ {∣ ‘} ’ ’)^{+}

Tokens are formed from the input character stream according to the longest match rule. That is, the next token always consists of the longest possible sequence of characters that is recognized by the above lexical grammar. Tokens can be separated by white space, but except for strings, they cannot themselves contain whitespace.

Keyword tokens are defined either implicitly by an occurrence of a terminal symbol in literal form, such as $‘ keyword ’$ , in a syntactic production of this chapter, or explicitly where they arise in this chapter.

Any token that does not fall into any of the other categories is considered reserved, and cannot occur in source text.

Note

The effect of defining the set of reserved tokens is that all tokens must be separated by either parentheses, white space, or comments. For example, $‘ 0$x ’$ is a single reserved token, as is $‘ "a""b" ’$ . Consequently, they are not recognized as two separate tokens $‘ 0 ’$ and $‘ $x ’$ , or $"a"$ and $"b"$ , respectively, but instead disallowed. This property of tokenization is not affected by the fact that the definition of reserved tokens overlaps with other token classes.

6.2.3. White Space

White space is any sequence of literal space characters, formatting characters, comments, or annotations. The allowed formatting characters correspond to a subset of the ASCII format effectors, namely, horizontal tabulation ( $U + 09$ ), line feed ( $U + 0A$ ), and carriage return ( $U + 0D$ ).

space format newline ::= ::= ::= (‘ ’ ∣ format ∣ comment)^{*} newline ∣ U + 09 U + 0A ∣ U + 0D ∣ U + 0D U + 0A

The only relevance of white space is to separate tokens. It is otherwise ignored.

6.2.4. Comments

A comment can either be a line comment, started with a double semicolon $‘;; ’$ and extending to the end of the line, or a block comment, enclosed in delimiters $‘ (; ’ \dots ‘;) ’$ . Block comments can be nested.

comment linecomment linechar blockcomment blockchar ::= ::= ::= ::= ::= ∣ ∣ ∣ linecomment ∣ blockcomment ‘;; ’ linechar^{*} (newline ∣ eof) c : char ‘ (; ’ blockchar^{*} ‘;) ’ c : char ‘; ’ ‘ (’ blockcomment (if c \neq = U + 0A \land c \neq = U + 0D) (if c \neq = ‘; ’ \land c \neq = ‘ (’) (if the next character is not ‘) ’) (if the next character is not ‘; ’)

Here, the pseudo token $eof$ indicates the end of the input. The look-ahead restrictions on the productions for $blockchar$ disambiguate the grammar such that only well-bracketed uses of block comment delimiters are allowed.

Note

Any formatting and control characters are allowed inside comments.

6.2.5. Annotations

An annotation is a bracketed token sequence headed by an annotation id of the form $‘ @id ’$ or $‘ @"..." ’$ . No space is allowed between the opening parenthesis and this id. Annotations are intended to be used for third-party extensions; they can appear anywhere in a program but are ignored by the WebAssembly semantics itself, which treats them as white space.

Annotations can contain other parenthesized token sequences (including nested annotations), as long as they are well-nested. String literals and comments occurring in an annotation must also be properly nested and closed.

annot annotid ::= ::= ‘ (@ ’ annotid (space ∣ token)^{*} ‘) ’ idchar^{+} ∣ name

Note

The annotation id is meant to be an identifier categorising the extension, and plays a role similar to the name of a custom section. By convention, annotations corresponding to a custom section should use the custom section’s name as an id.

Implementations are expected to ignore annotations with ids that they do not recognize. On the other hand, they may impose restrictions on annotations that they do recognize, e.g., requiring a specific structure by superimposing a more concrete grammar. It is up to an implementation how it deals with errors in such annotations.

6.3. Values

The grammar productions in this section define lexical syntax, hence no white space is allowed.

6.3.1. Integers

All integers can be written in either decimal or hexadecimal notation. In both cases, digits can optionally be separated by underscores.

sign digit hexdigit hexnum ::= ::= ::= ∣ ∣ ∣ ::= ∣ ϵ \Rightarrow + ∣ ‘ + ’ \Rightarrow + ∣ ‘ - ’ \Rightarrow - ‘ 0 ’ \Rightarrow 0 ∣ \dots ∣ ‘ 9 ’ \Rightarrow 9 d : digit \Rightarrow d ‘ A ’ \Rightarrow 10 ∣ \dots ∣ ‘ F ’ \Rightarrow 15 ‘ a ’ \Rightarrow 10 ∣ \dots ∣ ‘ f ’ \Rightarrow 151 e x] n : num ‘_’^{?} d : digit h : hexdigit n : hexnum ‘_’^{?} h : hexdigit num \Rightarrow \Rightarrow \Rightarrow ::= 10 \cdot n + d h 16 \cdot n + h d : digit \Rightarrow d

The allowed syntax for integer literals depends on size and signedness. Moreover, their value must lie within the range of the respective type.

u N s N ::= ∣ ::= ∣ n : num ‘ 0x ’ n : hexnum \pm : sign n : num \pm : sign ‘ 0x ’ n : hexnum \Rightarrow \Rightarrow \Rightarrow \Rightarrow n n \pm n \pm n (if n < 2^{N}) (if n < 2^{N}) (if - 2^{N - 1} \leq \pm n < 2^{N - 1}) (if - 2^{N - 1} \leq \pm n < 2^{N - 1})

Uninterpreted integers can be written as either signed or unsigned, and are normalized to unsigned in the abstract syntax.

i N ::= ∣ n : u N i : s N \Rightarrow \Rightarrow n n (if i = signed (n))

6.3.2. Floating-Point

Floating-point values can be represented in either decimal or hexadecimal notation.

frac hexfrac float hexfloat ::= ∣ ::= ∣ ::= ∣ ∣ ∣ ::= ∣ ∣ ∣ d : digit d : digit ‘_’^{?} p : frac h : hexdigit h : hexdigit ‘_’^{?} p : hexfrac p : num ‘ . ’^{?} p : num ‘ . ’ q : frac p : num ‘ . ’^{?} (‘ E ’ ∣ ‘ e ’) \pm : sign e : num p : num ‘ . ’ q : frac (‘ E ’ ∣ ‘ e ’) \pm : sign e : num ‘ 0x ’ p : hexnum ‘ . ’^{?} ‘ 0x ’ p : hexnum ‘ . ’ q : hexfrac ‘ 0x ’ p : hexnum ‘ . ’^{?} (‘ P ’ ∣ ‘ p ’) \pm : sign e : num ‘ 0x ’ p : hexnum ‘ . ’ q : hexfrac (‘ P ’ ∣ ‘ p ’) \pm : sign e : num \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow d /10 (d + p /10) /10 h /16 (h + p /16) /16 p p + q p \cdot 1 0^{\pm e} (p + q) \cdot 1 0^{\pm e} p p + q p \cdot 2^{\pm e} (p + q) \cdot 2^{\pm e}

The value of a literal must not lie outside the representable range of the corresponding [IEEE-754-2019] type (that is, a numeric value must not overflow to $\pm infinity$ ), but it may be rounded to the nearest representable value.

Note

Rounding can be prevented by using hexadecimal notation with no more significant bits than supported by the required type.

Floating-point values may also be written as constants for infinity or canonical NaN (not a number). Furthermore, arbitrary NaN values may be expressed by providing an explicit payload value.

f N f N mag ::= ::= ∣ ∣ ∣ ∣ \pm : sign z : f N mag z : float z : hexfloat ‘ inf ’ ‘ nan ’ ‘ nan : 0x ’ n : hexnum \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \pm z float_{N} (z) float_{N} (z) \infty nan (canon_{N}) nan (n) (if float_{N} (z) \neq = \pm \infty) (if float_{N} (z) \neq = \pm \infty) (if 1 \leq n < 2^{signif (N)})

6.3.3. Strings

Strings denote sequences of bytes that can represent both textual and binary data. They are enclosed in quotation marks and may contain any character other than ASCII control characters, quotation marks ( $‘ " ’$ ), or backslash ( $‘ \ ’$ ), except when expressed with an escape sequence.

string stringelem ::= ::= ∣ ‘ " ’ (b^{*} : stringelem)^{*} ‘ " ’ c : stringchar ‘ \ ’ n : hexdigit m : hexdigit \Rightarrow \Rightarrow \Rightarrow concat ((b^{*})^{*}) utf8 (c) 16 \cdot n + m (if ∣ concat ((b^{*})^{*}) ∣ < 2^{32})

Each character in a string literal represents the byte sequence corresponding to its UTF-8 [UNICODE] (Section 2.5) encoding, except for hexadecimal escape sequences $‘ \hh ’$ , which represent raw bytes of the respective value.

stringchar ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ c : char ‘ \t ’ ‘ \n ’ ‘ \r ’ ‘ \ " ’ ‘ \^{'} ’ ‘ \\ ’ ‘ \u {n : hexnum ‘} ’ ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow c U + 09 U + 0A U + 0D U + 22 U + 27 U + 5C U + (n) (if c \geq U + 20 \land c \neq = U + 7F \land c \neq = ‘ " ’ \land c \neq = ‘ \ ’) (if n < 0x D800 \lor 0x E000 \leq n < 0x 110000)

6.3.4. Names

Names are strings denoting a literal character sequence. A name string must form a valid UTF-8 encoding as defined by [UNICODE] (Section 2.5) and is interpreted as a string of Unicode scalar values.

name ::= b^{*} : string \Rightarrow c^{*} (if b^{*} = utf8 (c^{*}))

Note

Presuming the source text is itself encoded correctly, strings that do not contain any uses of hexadecimal byte escapes are always valid names.

6.3.5. Identifiers

Indices can be given in both numeric and symbolic form. Symbolic identifiers that stand in lieu of indices start with $‘ $ ’$ , followed by eiter a sequence of printable ASCII characters that does not contain a space, quotation mark, comma, semicolon, or bracket, or by a quoted name.

id idchar ::= ∣ ::= ∣ ∣ ∣ ∣ ‘ $ ’ c^{*} : idchar^{+} ‘ $ ’ c^{*} : name ‘ 0 ’ ∣ \dots ∣ ‘ 9 ’ ‘ A ’ ∣ \dots ∣ ‘ Z ’ ‘ a ’ ∣ \dots ∣ ‘ z ’ ‘! ’ ∣ ‘ # ’ ∣ ‘ $ ’ ∣ ‘ % ’ ∣ ‘ & ’ ∣ ‘^{'} ’ ∣ ‘ * ’ ∣ ‘ + ’ ∣ ‘ - ’ ∣ ‘ . ’ ∣ ‘ / ’ ‘ : ’ ∣ ‘ < ’ ∣ ‘ = ’ ∣ ‘ > ’ ∣ ‘ ? ’ ∣ ‘ @ ’ ∣ ‘ \ ’ ∣ ‘^’ ∣ ‘_’ ∣ ‘ ˋ ’ ∣ ‘ ∣ ’ ∣ ‘ ~ ’ \Rightarrow \Rightarrow c^{*} c^{*} (if ∣ c^{*} ∣ > 0)

Note

The value of an identifier character is the Unicode codepoint denoting it.

6.3.5.1. Conventions

The expansion rules of some abbreviations require insertion of a fresh identifier. That may be any syntactically valid identifier that does not already occur in the given source text.

6.4. Types

6.4.1. Number Types

numtype_{I} ::= ∣ ∣ ∣ ‘ i32 ’ ‘ i64 ’ ‘ f32 ’ ‘ f64 ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 i64 f32 f64

6.4.2. Vector Types

vectype_{I} ::= ‘ v128 ’ \Rightarrow v128

6.4.3. Heap Types

absheaptype heaptype_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ::= ∣ ‘ any ’ ‘ eq ’ ‘ i31 ’ ‘ struct ’ ‘ array ’ ‘ none ’ ‘ func ’ ‘ nofunc ’ ‘ extern ’ ‘ noexn ’ ‘ exn ’ ‘ noextern ’ t : absheaptype x : typeidx_{I} \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow any eq i31 struct array none func nofunc extern noexn exn noextern y x

6.4.4. Reference Types

reftype_{I} ::= ∣ ‘ (’ ‘ ref ’ ht : heaptype ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ht : heaptype ‘) ’ \Rightarrow \Rightarrow ref ht ref null ht

6.4.4.1. Abbreviations

There are shorthands for references to abstract heap types.

‘ eqref ’ ‘ i31ref ’ ‘ structref ’ ‘ arrayref ’ ‘ nullref ’ ‘ funcref ’ ‘ nullfuncref ’ ‘ exnref ’ ‘ nullexnref ’ ‘ externref ’ ‘ nullexternref ’ ‘ anyref ’ \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv ‘ (’ ‘ ref ’ ‘ null ’ ‘ eq ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ i31 ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ struct ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ array ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ none ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ func ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ nofunc ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ exn ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ noexn ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ extern ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ noextern ’ ‘) ’ ‘ (’ ‘ ref ’ ‘ null ’ ‘ any ’ ‘) ’

6.4.5. Value Types

valtype_{I} ::= ∣ ∣ t : numtype_{I} t : vectype_{I} t : reftype_{I} \Rightarrow \Rightarrow \Rightarrow t t t

6.4.6. Function Types

functype_{I} param_{I} result_{I} ::= ::= ::= ‘ (’ ‘ func ’ t_{1}^{*} : vec (param_{I}) t_{2}^{*} : vec (result_{I}) ‘) ’ ‘ (’ ‘ param ’ id^{?} t : valtype_{I} ‘) ’ ‘ (’ ‘ result ’ t : valtype_{I} ‘) ’ \Rightarrow \Rightarrow \Rightarrow [t_{1}^{*}] \to [t_{2}^{*}] t t

Note

The optional identifier names for parameters in a function type only have documentation purpose. They cannot be referenced from anywhere.

6.4.6.1. Abbreviations

Multiple anonymous parameters or results may be combined into a single declaration:

‘ (’ ‘ param ’ valtype^{*} ‘) ’ ‘ (’ ‘ result ’ valtype^{*} ‘) ’ \equiv \equiv (‘ (’ ‘ param ’ valtype ‘) ’)^{*} (‘ (’ ‘ result ’ valtype ‘) ’)^{*}

6.4.7. Aggregate Types

arraytype_{I} structtype_{I} field_{I} fieldtype_{I} storagetype_{I} packedtype ::= ::= ::= ::= ∣ ::= ∣ ::= ∣ ‘ (’ ‘ array ’ ft : fieldtype_{I} ‘) ’ ‘ (’ ‘ struct ’ ft^{*} : vec (field_{I}) ‘) ’ ‘ (’ ‘ field ’ id^{?} ft : fieldtype_{I} ‘) ’ st : storagetype ‘ (’ ‘ mut ’ st : storagetype ‘) ’ t : valtype_{I} t : packedtype ‘ i8 ’ ‘ i16 ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow ft ft^{*} ft const st var st t t i8 i16

6.4.7.1. Abbreviations

Multiple anonymous structure fields may be combined into a single declaration:

‘ (’ ‘ field ’ fieldtype^{*} ‘) ’ \equiv (‘ (’ ‘ field ’ fieldtype ‘) ’)^{*}

6.4.8. Composite Types

comptype_{I} ::= ∣ ∣ at : arraytype_{I} st : structtype_{I} ft : functype_{I} \Rightarrow \Rightarrow \Rightarrow array at struct at func ft

6.4.9. Recursive Types

rectype_{I} typedef_{I} subtype_{I} ::= ::= ::= ‘ (’ ‘ rec ’ st^{*} : vec (typedef_{I}) ‘) ’ ‘ (’ ‘ type ’ id^{?} st : subtype_{I} ‘) ’ ‘ (’ ‘ sub ’ ‘ final ’^{?} x^{*} : vec (typeidx_{I}) ct : comptype_{I} ‘) ’ \Rightarrow \Rightarrow \Rightarrow rec st^{*} st sub final^{?} x^{*} ct

6.4.9.1. Abbreviations

Singular recursive types can omit the $‘ rec ’$ keyword:

typedef \equiv ‘ (’ ‘ rec ’ typedef ‘) ’

Similarly, final sub types with no super-types can omit the $sub$ keyword and arguments:

comptype \equiv ‘ (’ ‘ sub ’ ‘ final ’ ϵ comptype ‘) ’

6.4.10. Address Types

addrtype ::= ∣ ‘ i32 ’ ‘ i64 ’ \Rightarrow \Rightarrow i32 i64

6.4.10.1. Abbreviations

The address type can be omited, in which case it defaults $i32$ :

‘ ’ \equiv ‘ i32 ’

6.4.11. Limits

limits ::= ∣ n : u 32 n : u 32 m : u 32 \Rightarrow \Rightarrow {min n, max ϵ} {min n, max m}

6.4.12. Memory Types

memtype_{I} ::= at : addrtype lim : limits \Rightarrow at lim

6.4.13. Table Types

tabletype_{I} ::= at : addrtype lim : limits et : reftype_{I} \Rightarrow at lim et

6.4.14. Global Types

globaltype_{I} ::= ∣ t : valtype ‘ (’ ‘ mut ’ t : valtype_{I} ‘) ’ \Rightarrow \Rightarrow const t var t

6.5. Instructions

Instructions are syntactically distinguished into plain and structured instructions.

instr_{I} ::= ∣ in : plaininstr_{I} in : blockinstr_{I} \Rightarrow \Rightarrow in in

In addition, as a syntactic abbreviation, instructions can be written as S-expressions in folded form, to group them visually.

6.5.1. Labels

Structured control instructions can be annotated with a symbolic label identifier. They are the only symbolic identifiers that can be bound locally in an instruction sequence. The following grammar handles the corresponding update to the identifier context by composing the context with an additional label entry.

label_{I} ::= ∣ ∣ v : id v : id ϵ \Rightarrow \Rightarrow \Rightarrow v, {labels v} \oplus I v, {labels v} \oplus (I with labels [i] = ϵ) ϵ, {labels (ϵ)} \oplus I (if v \in / I . labels) (if I . labels [i] = v)

Note

The new label entry is inserted at the beginning of the label list in the identifier context. This effectively shifts all existing labels up by one, mirroring the fact that control instructions are indexed relatively not absolutely.

If a label with the same name already exists, then it is shadowed and the earlier label becomes inaccessible.

6.5.2. Control Instructions

Structured control instructions can bind an optional symbolic label identifier. The same label identifier may optionally be repeated after the corresponding $end$ or $else$ keywords, to indicate the matching delimiters.

Their block type is given as a type use, analogous to the type of functions. However, the special case of a type use that is syntactically empty or consists of only a single result is not regarded as an abbreviation for an inline function type, but is parsed directly into an optional value type.

blocktype_{I} blockinstr_{I} catch_{I} ::= ∣ ::= ∣ ∣ ∣ ::= ∣ ∣ ∣ (t : result_{I})^{?} x, I^{'} : typeuse_{I} \Rightarrow \Rightarrow t^{?} x (if I^{'} = {locals (ϵ)^{*}}) ‘ block ’ (v^{?}, I^{'}) : label_{I} bt : blocktype_{I} (in : instr_{I^{'}})^{*} ‘ end ’ v^{'}^{?} : id^{?} \Rightarrow block bt in^{*} end (if v^{'}^{?} = ϵ \lor v^{'}^{?} = v^{?}) ‘ loop ’ (v^{?}, I^{'}) : label_{I} bt : blocktype_{I} (in : instr_{I^{'}})^{*} ‘ end ’ v^{'}^{?} : id^{?} \Rightarrow loop bt in^{*} end (if v^{'}^{?} = ϵ \lor v^{'}^{?} = v^{?}) ‘ if ’ (v^{?}, I^{'}) : label_{I} bt : blocktype_{I} (in_{1} : instr_{I^{'}})^{*} ‘ else ’ v_{1}^{?} : id_{1}^{?} (in_{2} : instr_{I^{'}})^{*} ‘ end ’ v_{2}^{?} : id_{2}^{?} \Rightarrow if bt in_{1}^{*} else in_{2}^{*} end (if v_{1}^{?} = ϵ \lor v_{1}^{?} = v^{?}, v_{2}^{?} = ϵ \lor v_{2}^{?} = v^{?}) ‘ try_table ’ I^{'} : label_{I} bt : blocktype (c : catch_{I})^{*} (in : instr_{I^{'}})^{*} ‘ end ’ id^{?} \Rightarrow try_table bt c^{*} in^{*} end (if id^{?} = ϵ \lor id^{?} = label) ‘ (’ ‘ catch ’ x : tagidx_{I} l : labelidx_{I} ‘) ’ ‘ (’ ‘ catch_ref ’ x : tagidx_{I} l : labelidx_{I} ‘) ’ ‘ (’ ‘ catch_all ’ l : labelidx_{I} ‘) ’ ‘ (’ ‘ catch_all_ref ’ l : labelidx_{I} ‘) ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow catch x l catch_ref x l catch_all l catch_all_ref l

Note

The side condition stating that the identifier context $I^{'}$ must only contain unnamed entries in the rule for $typeuse$ block types enforces that no identifier can be bound in any $param$ declaration for a block type.

All other control instruction are represented verbatim.

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ‘ unreachable ’ ‘ nop ’ ‘ br ’ l : labelidx_{I} ‘ br_if ’ l : labelidx_{I} ‘ br_table ’ l^{*} : vec (labelidx_{I}) l_{N} : labelidx_{I} ‘ br_on_null ’ l : labelidx_{I} ‘ br_on_non_null ’ l : labelidx_{I} ‘ br_on_cast ’ l : labelidx_{I} t_{1} : reftype t_{2} : reftype ‘ br_on_cast_fail ’ l : labelidx_{I} t_{1} : reftype t_{2} : reftype ‘ return ’ ‘ call ’ x : funcidx_{I} ‘ call_ref ’ x : typeidx ‘ call_indirect ’ x : tableidx y, I^{'} : typeuse_{I} ‘ return_call ’ x : funcidx_{I} ‘ return_call_ref ’ x : typeidx ‘ return_call_indirect ’ x : tableidx y, I^{'} : typeuse_{I} ‘ throw ’ x : tagidx_{I} ‘ throw_ref ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow unreachable nop br l br_if l br_table l^{*} l_{N} br_on_null l br_on_non_null l br_on_cast l t_{1} t_{2} br_on_cast_fail l t_{1} t_{2} return call x call_ref x call_indirect x y return_call x return_call_ref x return_call_indirect x y throw x throw_ref (if I^{'} = {locals (ϵ)^{*}}) (if I^{'} = {locals (ϵ)^{*}})

Note

The side condition stating that the identifier context $I^{'}$ must only contain unnamed entries in the rule for $call_indirect$ enforces that no identifier can be bound in any $param$ declaration appearing in the type annotation.

6.5.2.1. Abbreviations

The $‘ else ’$ keyword of an $‘ if ’$ instruction can be omitted if the following instruction sequence is empty.

‘ if ’ label blocktype_{I} instr^{*} ‘ end ’ \equiv ‘ if ’ label blocktype_{I} instr^{*} ‘ else ’ ‘ end ’

Also, for backwards compatibility, the table index to $‘ call_indirect ’$ and $‘ return_call_indirect ’$ can be omitted, defaulting to $0$ .

‘ return_call_indirect ’ typeuse ‘ call_indirect ’ typeuse \equiv \equiv ‘ return_call_indirect ’ 0 typeuse ‘ call_indirect ’ 0 typeuse

6.5.3. Reference Instructions

6.5.4. Parametric Instructions

plaininstr_{I} ::= ∣ ∣ \dots ‘ drop ’ ‘ select ’ ((t : result_{I})^{*})^{?} \Rightarrow \Rightarrow drop select (t^{*})^{?}

6.5.5. Variable Instructions

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ \dots ‘ local.get ’ x : localidx_{I} ‘ local.set ’ x : localidx_{I} ‘ local.tee ’ x : localidx_{I} ‘ global.get ’ x : globalidx_{I} ‘ global.set ’ x : globalidx_{I} \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow local.get x local.set x local.tee x global.get x global.set x

6.5.6. Table Instructions

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ \dots ‘ table.get ’ x : tableidx_{I} ‘ table.set ’ x : tableidx_{I} ‘ table.size ’ x : tableidx_{I} ‘ table.grow ’ x : tableidx_{I} ‘ table.fill ’ x : tableidx_{I} ‘ table.copy ’ x : tableidx_{I} y : tableidx_{I} ‘ table.init ’ x : tableidx_{I} y : elemidx_{I} ‘ elem.drop ’ x : elemidx_{I} \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow table.get x table.set x table.size x table.grow x table.fill x table.copy x y table.init x y elem.drop x

6.5.6.1. Abbreviations

For backwards compatibility, all table indices may be omitted from table instructions, defaulting to $0$ .

‘ table.get ’ ‘ table.set ’ ‘ table.size ’ ‘ table.grow ’ ‘ table.fill ’ ‘ table.copy ’ ‘ table.init ’ x : elemidx_{I} \equiv \equiv \equiv \equiv \equiv \equiv \equiv ‘ table.get ’ ‘ 0 ’ ‘ table.set ’ ‘ 0 ’ ‘ table.size ’ ‘ 0 ’ ‘ table.grow ’ ‘ 0 ’ ‘ table.fill ’ ‘ 0 ’ ‘ table.copy ’ ‘ 0 ’ ‘ 0 ’ ‘ table.init ’ ‘ 0 ’ x : elemidx_{I}

6.5.7. Memory Instructions

The offset and alignment immediates to memory instructions are optional. The offset defaults to $0$ , the alignment to the storage size of the respective memory access, which is its natural alignment. Lexically, an $offset$ or $align$ phrase is considered a single keyword token, so no white space is allowed around the $‘ = ’$ .

6.5.7.1. Abbreviations

As an abbreviation, the memory index can be omitted in all memory instructions, defaulting to $0$ .

numtype ‘ .load ’ memarg vectype ‘ .load ’ memarg numtype ‘ .load ’ N ‘_’ sx memarg vectype ‘ .load ’ N x M ‘_’ sx memarg vectype ‘ .load ’ N ‘_splat ’ memarg vectype ‘ .load ’ N ‘_zero ’ memarg vectype ‘ .load ’ N ‘_lane ’ memarg u 8 numtype ‘ .store ’ memarg vectype ‘ .store ’ memarg numtype ‘ .store ’ N memarg vectype ‘ .store ’ N ‘_lane ’ memarg u 8 ‘ memory.size ’ ‘ memory.grow ’ ‘ memory.fill ’ ‘ memory.copy ’ ‘ memory.init ’ x : elemidx_{I} \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv \equiv numtype ‘ .load ’ ‘ 0 ’ memarg vectype ‘ .load ’ ‘ 0 ’ memarg numtype ‘ .load ’ N ‘_’ sx ‘ 0 ’ memarg vectype ‘ .load ’ N x M ‘_’ sx ‘ 0 ’ memarg vectype ‘ .load ’ N ‘_splat ’ ‘ 0 ’ memarg vectype ‘ .load ’ N ‘_zero ’ ‘ 0 ’ memarg vectype ‘ .load ’ N ‘_lane ’ ‘ 0 ’ memarg u 8 numtype ‘ .store ’ ‘ 0 ’ memarg vectype ‘ .store ’ ‘ 0 ’ memarg numtype ‘ .store ’ N ‘ 0 ’ memarg vectype ‘ .store ’ N ‘_lane ’ ‘ 0 ’ memarg u 8 ‘ memory.size ’ ‘ 0 ’ ‘ memory.grow ’ ‘ 0 ’ ‘ memory.fill ’ ‘ 0 ’ ‘ memory.copy ’ ‘ 0 ’ ‘ 0 ’ ‘ memory.init ’ ‘ 0 ’ x : elemidx_{I}

6.5.8. Numeric Instructions

plaininstr_{I} ::= ∣ ∣ ∣ ∣ \dots ‘ i32.const ’ n : i 32 ‘ i64.const ’ n : i 64 ‘ f32.const ’ z : f 32 ‘ f64.const ’ z : f 64 \Rightarrow \Rightarrow \Rightarrow \Rightarrow i32 . const n i64 . const n f32 . const z f64 . const z

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ i32.clz ’ ‘ i32.ctz ’ ‘ i32.popcnt ’ ‘ i32.add ’ ‘ i32.sub ’ ‘ i32.mul ’ ‘ i32.div_s ’ ‘ i32.div_u ’ ‘ i32.rem_s ’ ‘ i32.rem_u ’ ‘ i32.and ’ ‘ i32.or ’ ‘ i32.xor ’ ‘ i32.shl ’ ‘ i32.shr_s ’ ‘ i32.shr_u ’ ‘ i32.rotl ’ ‘ i32.rotr ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . clz i32 . ctz i32 . popcnt i32 . add i32 . sub i32 . mul i32 . div_s i32 . div_u i32 . rem_s i32 . rem_u i32 . and i32 . or i32 . xor i32 . shl i32 . shr_s i32 . shr_u i32 . rotl i32 . rotr

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ i64.clz ’ ‘ i64.ctz ’ ‘ i64.popcnt ’ ‘ i64.add ’ ‘ i64.sub ’ ‘ i64.mul ’ ‘ i64.div_s ’ ‘ i64.div_u ’ ‘ i64.rem_s ’ ‘ i64.rem_u ’ ‘ i64.and ’ ‘ i64.or ’ ‘ i64.xor ’ ‘ i64.shl ’ ‘ i64.shr_s ’ ‘ i64.shr_u ’ ‘ i64.rotl ’ ‘ i64.rotr ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i64 . clz i64 . ctz i64 . popcnt i64 . add i64 . sub i64 . mul i64 . div_s i64 . div_u i64 . rem_s i64 . rem_u i64 . and i64 . or i64 . xor i64 . shl i64 . shr_s i64 . shr_u i64 . rotl i64 . rotr

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ f32.abs ’ ‘ f32.neg ’ ‘ f32.ceil ’ ‘ f32.floor ’ ‘ f32.trunc ’ ‘ f32.nearest ’ ‘ f32.sqrt ’ ‘ f32.add ’ ‘ f32.sub ’ ‘ f32.mul ’ ‘ f32.div ’ ‘ f32.min ’ ‘ f32.max ’ ‘ f32.copysign ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f32 . abs f32 . neg f32 . ceil f32 . floor f32 . trunc f32 . nearest f32 . sqrt f32 . add f32 . sub f32 . mul f32 . div f32 . min f32 . max f32 . copysign

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ f64.abs ’ ‘ f64.neg ’ ‘ f64.ceil ’ ‘ f64.floor ’ ‘ f64.trunc ’ ‘ f64.nearest ’ ‘ f64.sqrt ’ ‘ f64.add ’ ‘ f64.sub ’ ‘ f64.mul ’ ‘ f64.div ’ ‘ f64.min ’ ‘ f64.max ’ ‘ f64.copysign ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f64 . abs f64 . neg f64 . ceil f64 . floor f64 . trunc f64 . nearest f64 . sqrt f64 . add f64 . sub f64 . mul f64 . div f64 . min f64 . max f64 . copysign

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ i32.eqz ’ ‘ i32.eq ’ ‘ i32.ne ’ ‘ i32.lt_s ’ ‘ i32.lt_u ’ ‘ i32.gt_s ’ ‘ i32.gt_u ’ ‘ i32.le_s ’ ‘ i32.le_u ’ ‘ i32.ge_s ’ ‘ i32.ge_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . eqz i32 . eq i32 . ne i32 . lt_s i32 . lt_u i32 . gt_s i32 . gt_u i32 . le_s i32 . le_u i32 . ge_s i32 . ge_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ i64.eqz ’ ‘ i64.eq ’ ‘ i64.ne ’ ‘ i64.lt_s ’ ‘ i64.lt_u ’ ‘ i64.gt_s ’ ‘ i64.gt_u ’ ‘ i64.le_s ’ ‘ i64.le_u ’ ‘ i64.ge_s ’ ‘ i64.ge_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i64 . eqz i64 . eq i64 . ne i64 . lt_s i64 . lt_u i64 . gt_s i64 . gt_u i64 . le_s i64 . le_u i64 . ge_s i64 . ge_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ f32.eq ’ ‘ f32.ne ’ ‘ f32.lt ’ ‘ f32.gt ’ ‘ f32.le ’ ‘ f32.ge ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f32 . eq f32 . ne f32 . lt f32 . gt f32 . le f32 . ge

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ f64.eq ’ ‘ f64.ne ’ ‘ f64.lt ’ ‘ f64.gt ’ ‘ f64.le ’ ‘ f64.ge ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h f64 . eq f64 . ne f64 . lt f64 . gt f64 . le f64 . ge

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ t hi s i se n o ug h ‘ i32.extend8_s ’ ‘ i32.extend16_s ’ ‘ i64.extend8_s ’ ‘ i64.extend16_s ’ ‘ i64.extend32_s ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow t hi ss h o u l d b ee n o ug h i32 . extend 8_s i32 . extend 16_s i64 . extend 8_s i64 . extend 16_s i64 . extend 32_s

6.5.9. Vector Instructions

Vector constant instructions have a mandatory shape descriptor, which determines how the following values are parsed.

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ v128.const ’ ‘ i8x16 ’ (n : i 8)^{16} ‘ v128.const ’ ‘ i16x8 ’ (n : i 16)^{8} ‘ v128.const ’ ‘ i32x4 ’ (n : i 32)^{4} ‘ v128.const ’ ‘ i64x2 ’ (n : i 64)^{2} ‘ v128.const ’ ‘ f32x4 ’ (z : f 32)^{4} ‘ v128.const ’ ‘ f64x2 ’ (z : f 64)^{2} \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es v128 . const bytes_{i 128}^{- 1} (bytes_{i 8} (n)^{16}) v128 . const bytes_{i 128}^{- 1} (bytes_{i 16} (n)^{8}) v128 . const bytes_{i 128}^{- 1} (bytes_{i 32} (n)^{4}) v128 . const bytes_{i 128}^{- 1} (bytes_{i 64} (n)^{2}) v128 . const bytes_{i 128}^{- 1} (bytes_{f 32} (z)^{4}) v128 . const bytes_{i 128}^{- 1} (bytes_{f 64} (z)^{2})

plaininstr_{I} ::= ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i8x16.shuffle ’ (l an e i d x : u 8)^{16} ‘ i8x16.swizzle ’ \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i8x16 . shuffle l an e i d x^{16} i8x16 . swizzle

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i8x16.splat ’ ‘ i16x8.splat ’ ‘ i32x4.splat ’ ‘ i64x2.splat ’ ‘ f32x4.splat ’ ‘ f64x2.splat ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i8x16 . splat i16x8 . splat i32x4 . splat i64x2 . splat f32x4 . splat f64x2 . splat

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i8x16.extract_lane_s ’ l an e i d x : u 8 ‘ i8x16.extract_lane_u ’ l an e i d x : u 8 ‘ i8x16.replace_lane ’ l an e i d x : u 8 ‘ i16x8.extract_lane_s ’ l an e i d x : u 8 ‘ i16x8.extract_lane_u ’ l an e i d x : u 8 ‘ i16x8.replace_lane ’ l an e i d x : u 8 ‘ i32x4.extract_lane ’ l an e i d x : u 8 ‘ i32x4.replace_lane ’ l an e i d x : u 8 ‘ i64x2.extract_lane ’ l an e i d x : u 8 ‘ i64x2.replace_lane ’ l an e i d x : u 8 ‘ f32x4.extract_lane ’ l an e i d x : u 8 ‘ f32x4.replace_lane ’ l an e i d x : u 8 ‘ f64x2.extract_lane ’ l an e i d x : u 8 ‘ f64x2.replace_lane ’ l an e i d x : u 8 \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i8x16 . extract_lane_s l an e i d x i8x16 . extract_lane_u l an e i d x i8x16 . replace_lane l an e i d x i16x8 . extract_lane_s l an e i d x i16x8 . extract_lane_u l an e i d x i16x8 . replace_lane l an e i d x i32x4 . extract_lane l an e i d x i32x4 . replace_lane l an e i d x i64x2 . extract_lane l an e i d x i64x2 . replace_lane l an e i d x f32x4 . extract_lane l an e i d x f32x4 . replace_lane l an e i d x f64x2 . extract_lane l an e i d x f64x2 . replace_lane l an e i d x

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i8x16.eq ’ ‘ i8x16.ne ’ ‘ i8x16.lt_s ’ ‘ i8x16.lt_u ’ ‘ i8x16.gt_s ’ ‘ i8x16.gt_u ’ ‘ i8x16.le_s ’ ‘ i8x16.le_u ’ ‘ i8x16.ge_s ’ ‘ i8x16.ge_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i8x16 . eq i8x16 . ne i8x16 . lt_s i8x16 . lt_u i8x16 . gt_s i8x16 . gt_u i8x16 . le_s i8x16 . le_u i8x16 . ge_s i8x16 . ge_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i16x8.eq ’ ‘ i16x8.ne ’ ‘ i16x8.lt_s ’ ‘ i16x8.lt_u ’ ‘ i16x8.gt_s ’ ‘ i16x8.gt_u ’ ‘ i16x8.le_s ’ ‘ i16x8.le_u ’ ‘ i16x8.ge_s ’ ‘ i16x8.ge_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i16x8 . eq i16x8 . ne i16x8 . lt_s i16x8 . lt_u i16x8 . gt_s i16x8 . gt_u i16x8 . le_s i16x8 . le_u i16x8 . ge_s i16x8 . ge_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i32x4.eq ’ ‘ i32x4.ne ’ ‘ i32x4.lt_s ’ ‘ i32x4.lt_u ’ ‘ i32x4.gt_s ’ ‘ i32x4.gt_u ’ ‘ i32x4.le_s ’ ‘ i32x4.le_u ’ ‘ i32x4.ge_s ’ ‘ i32x4.ge_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i32x4 . eq i32x4 . ne i32x4 . lt_s i32x4 . lt_u i32x4 . gt_s i32x4 . gt_u i32x4 . le_s i32x4 . le_u i32x4 . ge_s i32x4 . ge_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i64x2.eq ’ ‘ i64x2.ne ’ ‘ i64x2.lt_s ’ ‘ i64x2.gt_s ’ ‘ i64x2.le_s ’ ‘ i64x2.ge_s ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i64x2 . eq i64x2 . ne i64x2 . lt_s i64x2 . gt_s i64x2 . le_s i64x2 . ge_s

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ f32x4.eq ’ ‘ f32x4.ne ’ ‘ f32x4.lt ’ ‘ f32x4.gt ’ ‘ f32x4.le ’ ‘ f32x4.ge ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es f32x4 . eq f32x4 . ne f32x4 . lt f32x4 . gt f32x4 . le f32x4 . ge

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ f64x2.eq ’ ‘ f64x2.ne ’ ‘ f64x2.lt ’ ‘ f64x2.gt ’ ‘ f64x2.le ’ ‘ f64x2.ge ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es f64x2 . eq f64x2 . ne f64x2 . lt f64x2 . gt f64x2 . le f64x2 . ge

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ v128.not ’ ‘ v128.and ’ ‘ v128.andnot ’ ‘ v128.or ’ ‘ v128.xor ’ ‘ v128.bitselect ’ ‘ v128.any_true ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es v128 . not v128 . and v128 . andnot v128 . or v128 . xor v128 . bitselect v128 . any_true

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i8x16.abs ’ ‘ i8x16.neg ’ ‘ i8x16.all_true ’ ‘ i8x16.bitmask ’ ‘ i8x16.narrow_i16x8_s ’ ‘ i8x16.narrow_i16x8_u ’ ‘ i8x16.shl ’ ‘ i8x16.shr_s ’ ‘ i8x16.shr_u ’ ‘ i8x16.add ’ ‘ i8x16.add_sat_s ’ ‘ i8x16.add_sat_u ’ ‘ i8x16.sub ’ ‘ i8x16.sub_sat_s ’ ‘ i8x16.sub_sat_u ’ ‘ i8x16.min_s ’ ‘ i8x16.min_u ’ ‘ i8x16.max_s ’ ‘ i8x16.max_u ’ ‘ i8x16.avgr_u ’ ‘ i8x16.popcnt ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i8x16 . abs i8x16 . neg i8x16 . all_true i8x16 . bitmask i8x16 . narrow_i16x8_s i8x16 . narrow_i16x8_u i8x16 . shl i8x16 . shr_s i8x16 . shr_u i8x16 . add i8x16 . add_sat_s i8x16 . add_sat_u i8x16 . sub i8x16 . sub_sat_s i8x16 . sub_sat_u i8x16 . min_s i8x16 . min_u i8x16 . max_s i8x16 . max_u i8x16 . avgr_u i8x16 . popcnt

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i32x4.abs ’ ‘ i32x4.neg ’ ‘ i32x4.all_true ’ ‘ i32x4.bitmask ’ ‘ i32x4.extadd_pairwise_i16x8_s ’ ‘ i32x4.extadd_pairwise_i16x8_u ’ ‘ i32x4.extend_low_i16x8_s ’ ‘ i32x4.extend_high_i16x8_s ’ ‘ i32x4.extend_low_i16x8_u ’ ‘ i32x4.extend_high_i16x8_u ’ ‘ i32x4.shl ’ ‘ i32x4.shr_s ’ ‘ i32x4.shr_u ’ ‘ i32x4.add ’ ‘ i32x4.sub ’ ‘ i32x4.mul ’ ‘ i32x4.min_s ’ ‘ i32x4.min_u ’ ‘ i32x4.max_s ’ ‘ i32x4.max_u ’ ‘ i32x4.dot_i16x8_s ’ ‘ i32x4.extmul_low_i16x8_s ’ ‘ i32x4.extmul_high_i16x8_s ’ ‘ i32x4.extmul_low_i16x8_u ’ ‘ i32x4.extmul_high_i16x8_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i32x4 . abs i32x4 . neg i32x4 . all_true i32x4 . bitmask i32x4 . extadd_pairwise_i16x8_s i32x4 . extadd_pairwise_i16x8_u i32x4 . extend_low_i16x8_s i32x4 . extend_high_i16x8_s i32x4 . extend_low_i16x8_u i32x4 . extend_high_i16x8_u i32x4 . shl i32x4 . shr_s i32x4 . shr_u i32x4 . add i32x4 . sub i32x4 . mul i32x4 . min_s i32x4 . min_u i32x4 . max_s i32x4 . max_u i32x4 . dot_i16x8_s i32x4 . extmul_low_i16x8_s i32x4 . extmul_high_i16x8_s i32x4 . extmul_low_i16x8_u i32x4 . extmul_high_i16x8_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i64x2.abs ’ ‘ i64x2.neg ’ ‘ i64x2.all_true ’ ‘ i64x2.bitmask ’ ‘ i64x2.extend_low_i32x4_s ’ ‘ i64x2.extend_high_i32x4_s ’ ‘ i64x2.extend_low_i32x4_u ’ ‘ i64x2.extend_high_i32x4_u ’ ‘ i64x2.shl ’ ‘ i64x2.shr_s ’ ‘ i64x2.shr_u ’ ‘ i64x2.add ’ ‘ i64x2.sub ’ ‘ i64x2.mul ’ ‘ i64x2.extmul_low_i32x4_s ’ ‘ i64x2.extmul_high_i32x4_s ’ ‘ i64x2.extmul_low_i32x4_u ’ ‘ i64x2.extmul_high_i32x4_u ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i64x2 . abs i64x2 . neg i64x2 . all_true i64x2 . bitmask i64x2 . extend_low_i32x4_s i64x2 . extend_high_i32x4_s i64x2 . extend_low_i32x4_u i64x2 . extend_high_i32x4_u i64x2 . shl i64x2 . shr_s i64x2 . shr_u i64x2 . add i64x2 . sub i64x2 . mul i64x2 . extmul_low_i32x4_s i64x2 . extmul_high_i32x4_s i64x2 . extmul_low_i32x4_u i64x2 . extmul_high_i32x4_u

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ f32x4.abs ’ ‘ f32x4.neg ’ ‘ f32x4.sqrt ’ ‘ f32x4.ceil ’ ‘ f32x4.floor ’ ‘ f32x4.trunc ’ ‘ f32x4.nearest ’ ‘ f32x4.add ’ ‘ f32x4.sub ’ ‘ f32x4.mul ’ ‘ f32x4.div ’ ‘ f32x4.min ’ ‘ f32x4.max ’ ‘ f32x4.pmin ’ ‘ f32x4.pmax ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es f32x4 . abs f32x4 . neg f32x4 . sqrt f32x4 . ceil f32x4 . floor f32x4 . trunc f32x4 . nearest f32x4 . add f32x4 . sub f32x4 . mul f32x4 . div f32x4 . min f32x4 . max f32x4 . pmin f32x4 . pmax

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ f64x2.abs ’ ‘ f64x2.neg ’ ‘ f64x2.sqrt ’ ‘ f64x2.ceil ’ ‘ f64x2.floor ’ ‘ f64x2.trunc ’ ‘ f64x2.nearest ’ ‘ f64x2.add ’ ‘ f64x2.sub ’ ‘ f64x2.mul ’ ‘ f64x2.div ’ ‘ f64x2.min ’ ‘ f64x2.max ’ ‘ f64x2.pmin ’ ‘ f64x2.pmax ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es f64x2 . abs f64x2 . neg f64x2 . sqrt f64x2 . ceil f64x2 . floor f64x2 . trunc f64x2 . nearest f64x2 . add f64x2 . sub f64x2 . mul f64x2 . div f64x2 . min f64x2 . max f64x2 . pmin f64x2 . pmax

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i32x4.trunc_sat_f32x4_s ’ ‘ i32x4.trunc_sat_f32x4_u ’ ‘ i32x4.trunc_sat_f64x2_s_zero ’ ‘ i32x4.trunc_sat_f64x2_u_zero ’ ‘ f32x4.convert_i32x4_s ’ ‘ f32x4.convert_i32x4_u ’ ‘ f64x2.convert_low_i32x4_s ’ ‘ f64x2.convert_low_i32x4_u ’ ‘ f32x4.demote_f64x2_zero ’ ‘ f64x2.promote_low_f32x4 ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll y l o n g in s t r u c t i o nnam es i32x4 . trunc_sat_f32x4_s i32x4 . trunc_sat_f32x4_u i32x4 . trunc_sat_f64x2_s_zero i32x4 . trunc_sat_f64x2_u_zero f32x4 . convert_i32x4_s f32x4 . convert_i32x4_u f64x2 . convert_low_i32x4_s f64x2 . convert_low_i32x4_u f32x4 . demote_f64x2_zero f64x2 . promote_low_f32x4

plaininstr_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ a v ery l o n g in s t r u c t i o nnam e f or v ec t e x t ‘ i16x8.relaxed_swizzle ’ ‘ i32x4.relaxed_trunc_f32x4_s ’ ‘ i32x4.relaxed_trunc_f32x4_u ’ ‘ i32x4.relaxed_trunc_f32x4_s_zero ’ ‘ i32x4.relaxed_trunc_f32x4_u_zero ’ ‘ f32x4.relaxed_madd ’ ‘ f32x4.relaxed_nmadd ’ ‘ f64x2.relaxed_madd ’ ‘ f64x2.relaxed_nmadd ’ ‘ i8x16.relaxed_laneselect ’ ‘ i16x8.relaxed_laneselect ’ ‘ i32x4.relaxed_laneselect ’ ‘ i64x2.relaxed_laneselect ’ ‘ f32x4.relaxed_min ’ ‘ f32x4.relaxed_max ’ ‘ f64x2.relaxed_min ’ ‘ f64x2.relaxed_max ’ ‘ i16x8.relaxed_q15mulr_s ’ ‘ i16x8.relaxed_dot_i8x16_i7x16_s ’ ‘ i16x8.relaxed_dot_i8x16_i7x16_add_s ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow v ec ha sre a ll yre a ll yre a ll y l o n g in s t r u c t i o nnam es i16x8 . relaxed_swizzle i32x4 . relaxed_trunc_f32x4_s i32x4 . relaxed_trunc_f32x4_u i32x4 . relaxed_trunc_f32x4_s_zero i32x4 . relaxed_trunc_f32x4_u_zero f32x4 . relaxed_madd f32x4 . relaxed_nmadd f64x2 . relaxed_madd f64x2 . relaxed_nmadd i8x16 . relaxed_laneselect i16x8 . relaxed_laneselect i32x4 . relaxed_laneselect i64x2 . relaxed_laneselect f32x4 . relaxed_min f32x4 . relaxed_max f64x2 . relaxed_min f64x2 . relaxed_max i16x8 . relaxed_q15mulr_s i16x8 . relaxed_dot_i8x16_i7x16_s i16x8 . relaxed_dot_i8x16_i7x16_add_s

6.5.10. Folded Instructions

Instructions can be written as S-expressions by grouping them into folded form. In that notation, an instruction is wrapped in parentheses and optionally includes nested folded instructions to indicate its operands.

In the case of block instructions, the folded form omits the $‘ end ’$ delimiter. For $if$ instructions, both branches have to be wrapped into nested S-expressions, headed by the keywords $‘ then ’$ and $‘ else ’$ .

The set of all phrases defined by the following abbreviations recursively forms the auxiliary syntactic class $foldedinstr$ . Such a folded instruction can appear anywhere a regular instruction can.

‘ (’ plaininstr foldedinstr^{*} ‘) ’ ‘ (’ ‘ block ’ label blocktype instr^{*} ‘) ’ ‘ (’ ‘ loop ’ label blocktype instr^{*} ‘) ’ ‘ (’ ‘ if ’ label blocktype foldedinstr^{*} foldedinstr^{*} ‘ if ’ label ‘ (’ ‘ try_table ’ label blocktype catch^{*} instr^{*} ‘) ’ \equiv ‘ try_table ’ label blocktype catch^{*} instr^{*} ‘ end ’ \equiv foldedinstr^{*} plaininstr \equiv ‘ block ’ label blocktype instr^{*} ‘ end ’ \equiv ‘ loop ’ label blocktype instr^{*} ‘ end ’ ‘ (’ ‘ then ’ instr_{1}^{*} ‘) ’ (‘ (’ ‘ else ’ instr_{2}^{*} ‘) ’)^{?} ‘) ’ \equiv blocktype instr_{1}^{*} ‘ else ’ (instr_{2}^{*})^{?} ‘ end ’

Note

For example, the instruction sequence

(local.get $x) (i32.const 2) i32.add (i32.const 3) i32.mul

can be folded into

(i32.mul (i32.add (local.get $x) (i32.const 2)) (i32.const 3))

Folded instructions are solely syntactic sugar, no additional syntactic or type-based checking is implied.

6.5.11. Expressions

Expressions are written as instruction sequences. No explicit $‘ end ’$ keyword is included, since they only occur in bracketed positions.

expr_{I} ::= (in : instr_{I})^{*} \Rightarrow in^{*} end

6.6. Modules

6.6.1. Indices

Indices can be given either in raw numeric form or as symbolic identifiers when bound by a respective construct. Such identifiers are looked up in the suitable space of the identifier context $I$ .

typeidx_{I} funcidx_{I} tableidx_{I} memidx_{I} globalidx_{I} tagidx_{I} elemidx_{I} dataidx_{I} localidx_{I} labelidx_{I} fieldidx_{I, x} ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ ::= ∣ x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id x : u 32 v : id l : u 32 v : id i : u 32 v : id \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow x x x x x x x x x x x x x x x x x x l l i i (if I . types [x] = v) (if I . funcs [x] = v) (if I . tables [x] = v) (if I . mems [x] = v) (if I . globals [x] = v) (if I . tags [x] = v) (if I . elem [x] = v) (if I . data [x] = v) (if I . locals [x] = v) (if I . labels [l] = v) (if I . fields [x] [i] = v)

6.6.2. Type Uses

A type use is a reference to a function type definition. It may optionally be augmented by explicit inlined parameter and result declarations. That allows binding symbolic identifiers to name the local indices of parameters. If inline declarations are given, then their types must match the referenced function type.

typeuse_{I} ::= ‘ (’ ‘ type ’ x : typeidx_{I} ‘) ’ \Rightarrow x, I^{'} (if I . typedefs [x] = sub final (func [t_{1}^{n}] \to [t_{2}^{*}]) \land I^{'} = {locals (ϵ)^{n}}) 1 e x] (if I . typedefs [x] = sub final (func [t_{1}^{*}] \to [t_{2}^{*}]) \land I^{'} = {locals id (param)^{*}} well-formed) ∣ ‘ (’ ‘ type ’ x : typeidx_{I} ‘) ’ (t_{1} : param)^{*} (t_{2} : result)^{*} \Rightarrow x, I^{'}

Note

If inline declarations are given, their types must be syntactically equal to the types from the indexed definition; possible type substitutions from other definitions that might make them equal are not taken into account. This is to simplify syntactic pre-processing.

The synthesized attribute of a $typeuse$ is a pair consisting of both the used type index and the local identifier context containing possible parameter identifiers. The following auxiliary function extracts optional identifiers from parameters:

id (‘ (’ ‘ param ’ id^{?} \dots ‘) ’) = id^{?}

Note

Both productions overlap for the case that the function type is $[] \to []$ . However, in that case, they also produce the same results, so that the choice is immaterial.

The well-formedness condition on $I^{'}$ ensures that the parameters do not contain duplicate identifiers.

6.6.2.1. Abbreviations

A $typeuse$ may also be replaced entirely by inline parameter and result declarations. In that case, a type index is automatically inserted:

(t_{1} : param)^{*} (t_{2} : result)^{*} \equiv ‘ (’ ‘ type ’ x ‘) ’ param^{*} result^{*}

where $x$ is the smallest existing type index whose recursive type definition in the current module is of the form

‘ (’ ‘ rec ’ ‘ (’ ‘ type ’ ‘ (’ ‘ sub ’ ‘ final ’ ‘ (’ ‘ func ’ param^{*} result^{*} ‘) ’ ‘) ’ ‘) ’ ‘) ’

If no such index exists, then a new recursive type of the same form is inserted at the end of the module.

Abbreviations are expanded in the order they appear, such that previously inserted type definitions are reused by consecutive expansions.

6.6.3. Imports

The descriptors in imports can bind a symbolic function, table, memory, tag, or global identifier.

import_{I} ::= ∣ ∣ ∣ ∣ ‘ (’ ‘ import ’ mod : name nm : name d : importdesc_{I} ‘) ’ \Rightarrow {module mod, name nm, desc d} 1 e x] ‘ (’ ‘ table ’ id^{?} tt : tabletype_{I} ‘) ’ ‘ (’ ‘ memory ’ id^{?} mt : memtype_{I} ‘) ’ ‘ (’ ‘ global ’ id^{?} gt : globaltype_{I} ‘) ’ ‘ (’ ‘ tag ’ id^{?} tt : tag ‘) ’ importdesc_{I} \Rightarrow \Rightarrow \Rightarrow \Rightarrow ::= table tt mem mt global gt tag tt ‘ (’ ‘ func ’ id^{?} x, I^{'} : typeuse_{I} ‘) ’ \Rightarrow func x

6.6.3.1. Abbreviations

As an abbreviation, imports may also be specified inline with function, table, memory, global, or tag definitions; see the respective sections.

6.6.4. Functions

Function definitions can bind a symbolic function identifier, and local identifiers for its parameters and locals.

func_{I} ::= ‘ (’ ‘ func ’ id^{?} x, I^{'} : typeuse_{I} (loc : local_{I})^{*} (in : instr_{I^{''}})^{*} ‘) ’ \Rightarrow {type x, locals loc^{*}, body in^{*} end} (if I^{''} = I \oplus I^{'} \oplus {locals id (local)^{*}} well-formed) 1 e x] local_{I} ::= ‘ (’ ‘ local ’ id^{?} t : valtype_{I} ‘) ’ \Rightarrow {type t}

The definition of the local identifier context $I^{''}$ uses the following auxiliary function to extract optional identifiers from locals:

id (‘ (’ ‘ local ’ id^{?} \dots ‘) ’) = id^{?}

Note

The well-formedness condition on $I^{''}$ ensures that parameters and locals do not contain duplicate identifiers.

6.6.4.1. Abbreviations

Multiple anonymous locals may be combined into a single declaration:

‘ (’ ‘ local ’ valtype^{*} ‘) ’ \equiv (‘ (’ ‘ local ’ valtype ‘) ’)^{*}

Functions can be defined as imports or exports inline:

‘ (’ ‘ func ’ id^{?} ‘ (’ ‘ import ’ name_{1} name_{2} ‘) ’ typeuse ‘) ’ \equiv ‘ (’ ‘ import ’ name_{1} name_{2} ‘ (’ ‘ func ’ id^{?} typeuse ‘) ’ ‘) ’ 1 e x] ‘ (’ ‘ export ’ name ‘ (’ ‘ func ’ id^{'} ‘) ’ ‘) ’ ‘ (’ ‘ func ’ id^{'} \dots ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh) ‘ (’ ‘ func ’ id^{?} ‘ (’ ‘ export ’ name ‘) ’ \dots ‘) ’ \equiv

Note

The latter abbreviation can be applied repeatedly, if “ $\dots$ ” contains additional export clauses. Consequently, a function declaration can contain any number of exports, possibly followed by an import.

6.6.5. Tables

Table definitions can bind a symbolic table identifier.

table_{I} ::= ‘ (’ ‘ table ’ id^{?} tt : tabletype_{I} e : expr_{I} ‘) ’ \Rightarrow {type tt, init e}

6.6.5.1. Abbreviations

A table’s initialization expression can be omitted, in which case it defaults to $ref.null$ :

‘ (’ ‘ table ’ id^{?} tabletype ‘) ’ \equiv ‘ (’ ‘ table ’ id^{?} tabletype ‘ (’ ref.null ht ‘) ’ ‘) ’ (if tabletype = limits ‘ (’ ‘ ref ’ ‘ null ’^{?} ht ‘) ’)

An element segment can be given inline with a table definition, in which case its offset is $0$ and the limits of the table type are inferred from the length of the given segment:

‘ (’ ‘ table ’ id^{?} addrtype^{?} reftype ‘ (’ ‘ elem ’ x^{n} : vec (funcidx) ‘) ’ ‘) ’ \equiv ‘ (’ ‘ table ’ id^{'} addrtype^{?} n n reftype ‘) ’ ‘ (’ ‘ elem ’ ‘ (’ ‘ table ’ id^{'} ‘) ’ ‘ (’ addrtype^{'} ‘ .const ’ ‘ 0 ’ ‘) ’ reftype vec (‘ (’ ‘ ref.func ’ funcidx ‘) ’) ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh, if addrtype ? \neq = ϵ \land addrtype^{'} = addrtype^{?} \lor addrtype^{?} = ϵ \land addrtype^{'} = ‘ i32 ’)

Tables can be defined as imports or exports inline:

‘ (’ ‘ table ’ id^{?} ‘ (’ ‘ import ’ name_{1} name_{2} ‘) ’ tabletype ‘) ’ \equiv ‘ (’ ‘ import ’ name_{1} name_{2} ‘ (’ ‘ table ’ id^{?} tabletype ‘) ’ ‘) ’ 1 e x] ‘ (’ ‘ export ’ name ‘ (’ ‘ table ’ id^{'} ‘) ’ ‘) ’ ‘ (’ ‘ table ’ id^{'} \dots ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh) ‘ (’ ‘ table ’ id^{?} ‘ (’ ‘ export ’ name ‘) ’ \dots ‘) ’ \equiv

Note

The latter abbreviation can be applied repeatedly, if “ $\dots$ ” contains additional export clauses. Consequently, a table declaration can contain any number of exports, possibly followed by an import.

6.6.6. Memories

Memory definitions can bind a symbolic memory identifier.

mem_{I} ::= ‘ (’ ‘ memory ’ id^{?} mt : memtype_{I} ‘) ’ \Rightarrow {type mt}

6.6.6.1. Abbreviations

A data segment can be given inline with a memory definition, in which case its offset is $0$ and the limits of the memory type are inferred from the length of the data, rounded up to page size:

‘ (’ ‘ memory ’ id^{?} addrtype^{?} ‘ (’ ‘ data ’ b^{n} : datastring ‘) ’ ‘) ’ \equiv ‘ (’ ‘ memory ’ id^{'} addrtype^{?} m m ‘) ’ ‘ (’ ‘ data ’ ‘ (’ ‘ memory ’ id^{'} ‘) ’ ‘ (’ addrtype^{'} ‘ .const ’ ‘ 0 ’ ‘) ’ datastring ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh, if addrtype ? \neq = ϵ \land addrtype^{'} = addrtype^{?} \lor addrtype^{?} = ϵ \land addrtype^{'} = ‘ i32 ’, m = ceil (n /64 Ki))

Memories can be defined as imports or exports inline:

‘ (’ ‘ memory ’ id^{?} ‘ (’ ‘ import ’ name_{1} name_{2} ‘) ’ memtype ‘) ’ \equiv ‘ (’ ‘ import ’ name_{1} name_{2} ‘ (’ ‘ memory ’ id^{?} memtype ‘) ’ ‘) ’ 1 e x] ‘ (’ ‘ export ’ name ‘ (’ ‘ memory ’ id^{'} ‘) ’ ‘) ’ ‘ (’ ‘ memory ’ id^{'} \dots ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh) ‘ (’ ‘ memory ’ id^{?} ‘ (’ ‘ export ’ name ‘) ’ \dots ‘) ’ \equiv

Note

The latter abbreviation can be applied repeatedly, if “ $\dots$ ” contains additional export clauses. Consequently, a memory declaration can contain any number of exports, possibly followed by an import.

6.6.7. Globals

Global definitions can bind a symbolic global identifier.

global_{I} ::= ‘ (’ ‘ global ’ id^{?} gt : globaltype_{I} e : expr_{I} ‘) ’ \Rightarrow {type gt, init e}

6.6.7.1. Abbreviations

Globals can be defined as imports or exports inline:

‘ (’ ‘ global ’ id^{?} ‘ (’ ‘ import ’ name_{1} name_{2} ‘) ’ globaltype ‘) ’ \equiv ‘ (’ ‘ import ’ name_{1} name_{2} ‘ (’ ‘ global ’ id^{?} globaltype ‘) ’ ‘) ’ 1 e x] ‘ (’ ‘ export ’ name ‘ (’ ‘ global ’ id^{'} ‘) ’ ‘) ’ ‘ (’ ‘ global ’ id^{'} \dots ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh) ‘ (’ ‘ global ’ id^{?} ‘ (’ ‘ export ’ name ‘) ’ \dots ‘) ’ \equiv

Note

The latter abbreviation can be applied repeatedly, if “ $\dots$ ” contains additional export clauses. Consequently, a global declaration can contain any number of exports, possibly followed by an import.

6.6.8. Tags

An tag definition can bind a symbolic tag identifier.

tag_{I} ::= ‘ (’ ‘ tag ’ id^{?} x, I^{'} : typeuse_{I} ‘) ’ \Rightarrow {type x}

6.6.8.1. Abbreviations

Tags can be defined as imports or exports inline:

‘ (’ ‘ tag ’ id^{?} ‘ (’ ‘ import ’ name_{1} name_{2} ‘) ’ typeuse ‘) ’ \equiv ‘ (’ ‘ import ’ name_{1} name_{2} ‘ (’ ‘ tag ’ id^{?} typeuse ‘) ’ ‘) ’ 1 e x] ‘ (’ ‘ export ’ name ‘ (’ ‘ tag ’ id^{'} ‘) ’ ‘) ’ ‘ (’ ‘ tag ’ id^{'} \dots ‘) ’ (if id^{?} \neq = ϵ \land id^{'} = id^{?} \lor id^{?} = ϵ \land id^{'} fresh) ‘ (’ ‘ tag ’ id^{?} ‘ (’ ‘ export ’ name ‘) ’ \dots ‘) ’ \equiv

Note

6.6.9. Exports

The syntax for exports mirrors their abstract syntax directly.

export_{I} exportdesc_{I} ::= ::= ∣ ∣ ∣ ∣ ‘ (’ ‘ export ’ nm : name d : exportdesc_{I} ‘) ’ ‘ (’ ‘ func ’ x : funcidx_{I} ‘) ’ ‘ (’ ‘ table ’ x : tableidx_{I} ‘) ’ ‘ (’ ‘ memory ’ x : memidx_{I} ‘) ’ ‘ (’ ‘ global ’ x : globalidx_{I} ‘) ’ ‘ (’ ‘ tag ’ x : tagidx_{I} ‘) ’ \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow {name nm, desc d} func x table x mem x global x tag x

6.6.9.1. Abbreviations

As an abbreviation, exports may also be specified inline with function, table, memory, global, or tag definitions; see the respective sections.

6.6.10. Start Function

A start function is defined in terms of its index.

start_{I} ::= ‘ (’ ‘ start ’ x : funcidx_{I} ‘) ’ \Rightarrow {func x}

Note

At most one start function may occur in a module, which is ensured by a suitable side condition on the $module$ grammar.

6.6.11. Element Segments

Element segments allow for an optional table index to identify the table to initialize.

elem_{I} elemlist_{I} elemexpr_{I} tableuse_{I} ::= ∣ ::= ::= ::= ‘ (’ ‘ elem ’ id^{?} (e t, y^{*}) : elemlist_{I} ‘) ’ \Rightarrow {type e t, init y^{*}, mode passive} ‘ (’ ‘ elem ’ id^{?} x : tableuse_{I} ‘ (’ ‘ offset ’ e : expr_{I} ‘) ’ (e t, y^{*}) : elemlist_{I} ‘) ’ \Rightarrow {type e t, init y^{*}, mode active {table x, offset e}} ‘ (’ ‘ elem ’ id^{?} ‘ declare ’ (e t, y^{*}) : elemlist_{I} ‘) ’ \Rightarrow {type e t, init y^{*}, mode declarative} t : reftype_{I} y^{*} : vec (elemexpr_{I}) \Rightarrow (type t, init y^{*}) ‘ (’ ‘ item ’ e : expr_{I} ‘) ’ \Rightarrow e ‘ (’ ‘ table ’ x : tableidx_{I} ‘) ’ \Rightarrow x

6.6.11.1. Abbreviations

As an abbreviation, a single instruction may occur in place of the offset of an active element segment or as an element expression:

‘ (’ instr ‘) ’ ‘ (’ instr ‘) ’ \equiv \equiv ‘ (’ ‘ offset ’ instr ‘) ’ ‘ (’ ‘ item ’ instr ‘) ’

Also, the element list may be written as just a sequence of function indices:

‘ func ’ vec (funcidx_{I}) \equiv ‘ (ref ’ ‘ func) ’ vec (‘ (’ ‘ ref.func ’ funcidx_{I} ‘) ’)

A table use can be omitted, defaulting to $0$ . Furthermore, for backwards compatibility with earlier versions of WebAssembly, if the table use is omitted, the $‘ func ’$ keyword can be omitted as well.

ϵ ‘ (’ ‘ elem ’ id^{?} ‘ (’ ‘ offset ’ expr_{I} ‘) ’ vec (funcidx_{I}) ‘) ’ \equiv \equiv ‘ (’ ‘ table ’ ‘ 0 ’ ‘) ’ ‘ (’ ‘ elem ’ id^{?} ‘ (’ ‘ table ’ ‘ 0 ’ ‘) ’ ‘ (’ ‘ offset ’ expr_{I} ‘) ’ ‘ func ’ vec (funcidx_{I}) ‘) ’

As another abbreviation, element segments may also be specified inline with table definitions; see the respective section.

6.6.12. Data Segments

Data segments allow for an optional memory index to identify the memory to initialize. The data is written as a string, which may be split up into a possibly empty sequence of individual string literals.

data_{I} datastring memuse_{I} ::= ∣ ::= ::= ‘ (’ ‘ data ’ id^{?} b^{*} : datastring ‘) ’ \Rightarrow {init b^{*}, mode passive} ‘ (’ ‘ data ’ id^{?} x : memuse_{I} ‘ (’ ‘ offset ’ e : expr_{I} ‘) ’ b^{*} : datastring ‘) ’ \Rightarrow {init b^{*}, mode active {memory x^{'}, offset e}} (b^{*} : string)^{*} \Rightarrow concat ((b^{*})^{*}) ‘ (’ ‘ memory ’ x : memidx_{I} ‘) ’ \Rightarrow x

Note

In the current version of WebAssembly, the only valid memory index is 0 or a symbolic memory identifier resolving to the same value.

6.6.12.1. Abbreviations

As an abbreviation, a single instruction may occur in place of the offset of an active data segment:

‘ (’ instr ‘) ’ \equiv ‘ (’ ‘ offset ’ instr ‘) ’

Also, a memory use can be omitted, defaulting to $0$ .

ϵ \equiv ‘ (’ ‘ memory ’ ‘ 0 ’ ‘) ’

As another abbreviation, data segments may also be specified inline with memory definitions; see the respective section.

6.6.13. Modules

A module consists of a sequence of fields that can occur in any order. All definitions and their respective bound identifiers scope over the entire module, including the text preceding them.

A module may optionally bind an identifier that names the module. The name serves a documentary role only.

Note

Tools may include the module name in the name section of the binary format.

module ::= ‘ (’ ‘ module ’ id^{?} (m : modulefield_{I})^{*} ‘) ’ \Rightarrow ⨁ m^{*} (if I = ⨁ idc (modulefield)^{*} well-formed) 1 e x] modulefield_{I} ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ty^{*} : rectype_{I} im : import_{I} fn : func_{I} ta : table_{I} me : mem_{I} gl : global_{I} tg : tag_{I} el : elem_{I} da : data_{I} st : start_{I} ex : export_{I} \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow \Rightarrow {types ty^{*}} {imports im} {funcs fn} {tables ta} {mems me} {globals gl} {tags tg} {elems el} {datas da} {start st} {exports ex}

The following restrictions are imposed on the composition of modules: $m_{1} \oplus m_{2}$ is defined if and only if

$m_{1} . start = ϵ \lor m_{2} . start = ϵ$
$m_{1} . funcs = m_{1} . tables = m_{1} . mems = m_{1} . globals = m_{1} . tags = ϵ \lor m_{2} . imports = ϵ$

Note

The first condition ensures that there is at most one start function. The second condition enforces that all imports must occur before any regular definition of a function, table, memory, global, or tag, thereby maintaining the ordering of the respective index spaces.

The well-formedness condition on $I$ in the grammar for $module$ ensures that no namespace contains duplicate identifiers.

The definition of the initial identifier context $I$ uses the following auxiliary definition which maps each relevant definition to a singular context with one (possibly empty) identifier:

idc (‘ (’ ‘ rec ’ typedef^{*} ‘) ’) idc (‘ (’ ‘ type ’ v^{?} : id^{?} subtype ‘) ’) idc (‘ (’ ‘ func ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ table ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ memory ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ global ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ tag ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ elem ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ data ’ v^{?} : id^{?} \dots ‘) ’) idc (‘ (’ ‘ import ’ \dots ‘ (’ ‘ func ’ v^{?} : id^{?} \dots ‘) ’ ‘) ’) idc (‘ (’ ‘ import ’ \dots ‘ (’ ‘ table ’ v^{?} : id^{?} \dots ‘) ’ ‘) ’) idc (‘ (’ ‘ import ’ \dots ‘ (’ ‘ memory ’ v^{?} : id^{?} \dots ‘) ’ ‘) ’) idc (‘ (’ ‘ import ’ \dots ‘ (’ ‘ global ’ v^{?} : id^{?} \dots ‘) ’ ‘) ’) idc (‘ (’ \dots ‘) ’) idf (‘ (’ ‘ struct ’ Tfield^{*} ‘) ’) idf (‘ (’ ‘ array ’ \dots ‘) ’) idf (‘ (’ ‘ func ’ \dots ‘) ’) idf (‘ (’ ‘ field ’ v^{?} : id^{?} \dots ‘) ’) = = = = = = = = = = = = = = = = = = ⨁ idc (typedef)^{*} {types (v^{?}), fields idf (subtype), typedefs st} {funcs (v^{?})} {tables (v^{?})} {mems (v^{?})} {globals (v^{?})} {tags (v^{?})} {elem (v^{?})} {data (v^{?})} {funcs (v^{?})} {tables (v^{?})} {mems (v^{?})} {globals (v^{?})} {} 2 e x] idf (‘ (’ ‘ sub ’ \dots comptype ‘) ’) ⨁ idf (field)^{*} ϵ ϵ v^{?} = idf (comptype)

6.6.13.1. Abbreviations

In a source file, the toplevel $(module \dots)$ surrounding the module body may be omitted.

modulefield^{*} \equiv ‘ (’ ‘ module ’ modulefield^{*} ‘) ’

A Appendix

A.1 Embedding

A WebAssembly implementation will typically be embedded into a host environment. An embedder implements the connection between such a host environment and the WebAssembly semantics as defined in the main body of this specification. An embedder is expected to interact with the semantics in well-defined ways.

This section defines a suitable interface to the WebAssembly semantics in the form of entry points through which an embedder can access it. The interface is intended to be complete, in the sense that an embedder does not need to reference other functional parts of the WebAssembly specification directly.

Note

On the other hand, an embedder does not need to provide the host environment with access to all functionality defined in this interface. For example, an implementation may not support parsing of the text format.

Types

In the description of the embedder interface, syntactic classes from the abstract syntax and the runtime’s abstract machine are used as names for variables that range over the possible objects from that class. Hence, these syntactic classes can also be interpreted as types.

For numeric parameters, notation like $n : u32$ is used to specify a symbolic name in addition to the respective value range.

Booleans

Interface operation that are predicates return Boolean values:

bool ::= false ∣ true

Exceptions and Errors

Invoking an exported function may throw or propagate exceptions, expressed by an auxiliary syntactic class:

exception ::= THROW exnaddr

The exception address $exnaddr$ identifies the exception thrown.

Failure of an interface operation is also indicated by an auxiliary syntactic class:

error ::= error

In addition to the error conditions specified explicitly in this section, such as invalid arguments or exceptions and traps resulting from execution, implementations may also return errors when specific implementation limitations are reached.

Note

Errors are abstract and unspecific with this definition. Implementations can refine it to carry suitable classifications and diagnostic messages.

Pre- and Post-Conditions

Some operations state pre-conditions about their arguments or post-conditions about their results. It is the embedder’s responsibility to meet the pre-conditions. If it does, the post conditions are guaranteed by the semantics.

In addition to pre- and post-conditions explicitly stated with each operation, the specification adopts the following conventions for runtime objects ( $store$ , $moduleinst$ , $externval$ , addresses):

Every runtime object passed as a parameter must be valid per an implicit pre-condition.
Every runtime object returned as a result is valid per an implicit post-condition.

Note

As long as an embedder treats runtime objects as abstract and only creates and manipulates them through the interface defined here, all implicit pre-conditions are automatically met.

Store

$store_init () : store$

Return the empty store.

store_init () = {}

Modules

$module_decode (byte^{*}) : module ∣ error$

If there exists a derivation for the byte sequence $byte^{*}$ as a $module$ according to the binary grammar for modules, yielding a module $m$ , then return $m$ .
Else, return $error$ .

module_decode (b^{*}) module_decode (b^{*}) = = m error (if module ⟹ * m : b^{*}) (otherwise)

$module_parse (char^{*}) : module ∣ error$

If there exists a derivation for the source $char^{*}$ as a $module$ according to the text grammar for modules, yielding a module $m$ , then return $m$ .
Else, return $error$ .

module_parse (c^{*}) module_parse (c^{*}) = = m error (if module ⟹ * m : c^{*}) (otherwise)

$module_validate (module) : error^{?}$

If $module$ is valid, then return nothing.
Else, return $error$ .

module_validate (m) module_validate (m) = = ϵ error (if ⊢ m : externtype^{*} \to externtype^{'}^{*}) (otherwise)

$module_instantiate (store, module, externval^{*}) : (store, moduleinst ∣ exception ∣ error)$

Try instantiating $module$ in $store$ with external values $externval^{*}$ as imports:

If it succeeds with a module instance $moduleinst$ , then let $result$ be $moduleinst$ .

Else, let $result$ be $error$ .

Return the new store paired with $result$ .

module_instantiate (S, m, ev^{*}) module_instantiate (S, m, ev^{*}) = = (S^{'}, F . module) (S^{'}, error) (if instantiate (S, m, ev^{*}) ↪^{*} S^{'}; F; ϵ) (otherwise, if instantiate (S, m, ev^{*}) ↪^{*} S^{'}; F; result)

Note

The store may be modified even in case of an error.

$module_imports (module) : (name, name, externtype)^{*}$

Pre-condition: $module$ is valid with the external import types $externtype^{*}$ and external export types $externtype^{'}^{*}$ .
Let $import^{*}$ be the imports $module . imports$ .
Assert: the length of $import^{*}$ equals the length of $externtype^{*}$ .
For each $import_{i}$ in $import^{*}$ and corresponding $externtype_{i}$ in $externtype^{*}$ , do:

Let $result_{i}$ be the triple $(import_{i} . module, import_{i} . name, externtype_{i})$ .

Return the concatenation of all $result_{i}$ , in index order.
Post-condition: each $externtype_{i}$ is valid under the empty context.

module_imports (m) = (im . module, im . name, externtype)^{*} (if im^{*} = m . imports \land ⊢ m : externtype^{*} \to externtype^{'}^{*})

$module_exports (module) : (name, externtype)^{*}$

Pre-condition: $module$ is valid with the external import types $externtype^{*}$ and external export types $externtype^{'}^{*}$ .
Let $export^{*}$ be the exports $module . exports$ .
Assert: the length of $export^{*}$ equals the length of $externtype^{'}^{*}$ .
For each $export_{i}$ in $export^{*}$ and corresponding $externtype_{i}^{'}$ in $externtype^{'}^{*}$ , do:

Let $result_{i}$ be the pair $(export_{i} . name, externtype_{i}^{'})$ .

Return the concatenation of all $result_{i}$ , in index order.
Post-condition: each $externtype_{i}^{'}$ is valid under the empty context.

module_exports (m) = (ex . name, externtype^{'})^{*} (if ex^{*} = m . exports \land ⊢ m : externtype^{*} \to externtype^{'}^{*})

Module Instances

$instance_export (moduleinst, name) : externval ∣ error$

Assert: due to validity of the module instance $moduleinst$ , all its export names are different.
If there exists an $exportinst_{i}$ in $moduleinst . exports$ such that name $exportinst_{i} . name$ equals $name$ , then:
1. Return the external value $exportinst_{i} . value$ .
Else, return $error$ .

instance_export (m, name) instance_export (m, name) = = m . exports [i] . value error (if m . exports [i] . name = name) (otherwise)

Functions

$func_alloc (store, functype, hostfunc) : (store, funcaddr)$

Pre-condition: the $functype$ is valid under the empty context.
Let $funcaddr$ be the result of allocating a host function in $store$ with function type $functype$ and host function code $hostfunc$ .
Return the new store paired with $funcaddr$ .

func_alloc (S, ta, code) = (S^{'}, a) (if allochostfunc (S, ta, code) = S^{'}, a)

Note

This operation assumes that $hostfunc$ satisfies the pre- and post-conditions required for a function instance with type $functype$ .

Regular (non-host) function instances can only be created indirectly through module instantiation.

$func_type (store, funcaddr) : functype$

Let $functype$ be the function type $S. funcs [a] . type$ .
Return $functype$ .
Post-condition: the returned function type is valid.

func_type (S, a) = S . funcs [a] . type

$func_invoke (store, funcaddr, val^{}) : (store, val^{} ∣ exception ∣ error)$

Try invoking the function $funcaddr$ in $store$ with values $val^{*}$ as arguments:

If it succeeds with values $val^{'}^{*}$ as results, then let $result$ be $val^{'}^{*}$ .

Else if the outcome is an exception with a thrown exception $ref . exn exnaddr$ as the result, then let $result$ be $THROW exnaddr$

Else it has trapped, hence let $result$ be $error$ .

Return the new store paired with $result$ .

func_invoke (S, a, v^{*}) func_invoke (S, a, v^{*}) func_invoke (S, a, v^{*}) = = = (S^{'}, v^{'}^{*}) (S^{'}, THROW a^{'}) (S^{'}, error) (if invoke (S, a, v^{*}) ↪^{*} S^{'}; F; v^{'}^{*}) (if invoke (S, a, v^{*}) ↪^{*} S^{'}; F; T [(ref . exn a^{'}) throw_ref] (if invoke (S, a, v^{*}) ↪^{*} S^{'}; F; trap)

Note

The store may be modified even in case of an error.

Tables

$table_alloc (store, tabletype, ref) : (store, tableaddr)$

Pre-condition: the $tabletype$ is valid under the empty context.
Let $tableaddr$ be the result of allocating a table in $store$ with table type $tabletype$ and initialization value $ref$ .
Return the new store paired with $tableaddr$ .

table_alloc (S, tt, r) = (S^{'}, a) (if alloctable (S, tt, r) = S^{'}, a)

$table_type (store, tableaddr) : tabletype$

Return $S. tables [a] . type$ .
Post-condition: the returned table type is valid under the empty context.

table_type (S, a) = S . tables [a] . type

$table_read (store, tableaddr, i : u64) : ref ∣ error$

Let $ti$ be the table instance $store . tables [tableaddr]$ .
If $i$ is larger than or equal to the length of $ti . elem$ , then return $error$ .
Else, return the reference value $ti . elem [i]$ .

table_read (S, a, i) table_read (S, a, i) = = r error (if S . tables [a] . elem [i] = r) (otherwise)

$table_write (store, tableaddr, i : u64, ref) : store ∣ error$

Let $ti$ be the table instance $store . tables [tableaddr]$ .
If $i$ is larger than or equal to the length of $ti . elem$ , then return $error$ .
Replace $ti . elem [i]$ with the reference value $ref$ .
Return the updated store.

table_write (S, a, i, r) table_write (S, a, i, r) = = S^{'} error (if S^{'} = S with tables [a] . elem [i] = r) (otherwise)

$table_size (store, tableaddr) : u64$

Return the length of $store . tables [tableaddr] . elem$ .

table_size (S, a) = n (if ∣ S . tables [a] . elem ∣ = n)

$table_grow (store, tableaddr, n : u64, ref) : store ∣ error$

Try growing the table instance $store . tables [tableaddr]$ by $n$ elements with initialization value $ref$ :
1. If it succeeds, return the updated store.
2. Else, return $error$ .

table_grow (S, a, n, r) table_grow (S, a, n, r) = = S^{'} error (if S^{'} = S with tables [a] = growtable (S . tables [a], n, r)) (otherwise)

Memories

$mem_alloc (store, memtype) : (store, memaddr)$

Pre-condition: the $memtype$ is valid under the empty context.
Let $memaddr$ be the result of allocating a memory in $store$ with memory type $memtype$ .
Return the new store paired with $memaddr$ .

mem_alloc (S, mt) = (S^{'}, a) (if allocmem (S, mt) = S^{'}, a)

$mem_type (store, memaddr) : memtype$

Return $S. mems [a] . type$ .
Post-condition: the returned memory type is valid under the empty context.

mem_type (S, a) = S . mems [a] . type

$mem_read (store, memaddr, i : u64) : byte ∣ error$

Let $mi$ be the memory instance $store . mems [memaddr]$ .
If $i$ is larger than or equal to the length of $mi . data$ , then return $error$ .
Else, return the byte $mi . data [i]$ .

mem_read (S, a, i) mem_read (S, a, i) = = b error (if S . mems [a] . data [i] = b) (otherwise)

$mem_write (store, memaddr, i : u64, byte) : store ∣ error$

Let $mi$ be the memory instance $store . mems [memaddr]$ .
If $i$ is larger than or equal to the length of $mi . data$ , then return $error$ .
Replace $mi . data [i]$ with $byte$ .
Return the updated store.

mem_write (S, a, i, b) mem_write (S, a, i, b) = = S^{'} error (if S^{'} = S with mems [a] . data [i] = b) (otherwise)

$mem_size (store, memaddr) : u64$

Return the length of $store . mems [memaddr] . data$ divided by the page size.

mem_size (S, a) = n (if ∣ S . mems [a] . data ∣ = n \cdot 64 Ki)

$mem_grow (store, memaddr, n : u64) : store ∣ error$

Try growing the memory instance $store . mems [memaddr]$ by $n$ pages:
1. If it succeeds, return the updated store.
2. Else, return $error$ .

mem_grow (S, a, n) mem_grow (S, a, n) = = S^{'} error (if S^{'} = S with mems [a] = growmem (S . mems [a], n)) (otherwise)

Exceptions

$exn_alloc (store, tagaddr, val^{*}) : (store, exnaddr)$

Pre-condition: $tagaddr$ is an allocated tag address.
Let $exnaddr$ be the result of allocating an exception instance in $store$ with tag address $tagaddr$ and initialization values $val^{*}$ .
Return the new store paired with $exnaddr$ .

exn_alloc (S, tagaddr, val^{*}) = (S \oplus {exns exninst}, ∣ S . exns ∣) (if exninst = {tag tagaddr, fields val^{*}}

$exn_tag (store, exnaddr) : tagaddr$

Let $exninst$ be the exception instance $store . exns [exnaddr]$ .
Return the tag address $exninst . tag$ .

exn_tag (S, a) = exninst . tag (if exninst = S . exns [a])

$exn_read (store, exnaddr) : val^{*}$

Let $exninst$ be the exception instance $store . exns [exnaddr]$ .
Return the values $exninst . fields$ .

exn_read (S, a) = exninst . fields (if exninst = S . exns [a])

Globals

$global_alloc (store, globaltype, val) : (store, globaladdr)$

Pre-condition: the $globaltype$ is valid under the empty context.
Let $globaladdr$ be the result of allocating a global in $store$ with global type $globaltype$ and initialization value $val$ .
Return the new store paired with $globaladdr$ .

global_alloc (S, gt, v) = (S^{'}, a) (if allocglobal (S, gt, v) = S^{'}, a)

$global_type (store, globaladdr) : globaltype$

Return $S. globals [a] . type$ .
Post-condition: the returned global type is valid under the empty context.

global_type (S, a) = S . globals [a] . type

$global_read (store, globaladdr) : val$

Let $gi$ be the global instance $store . globals [globaladdr]$ .
Return the value $gi . value$ .

global_read (S, a) = v (if S . globals [a] . value = v)

$global_write (store, globaladdr, val) : store ∣ error$

Let $gi$ be the global instance $store . globals [globaladdr]$ .
Let $mut t$ be the structure of the global type $gi . type$ .
If $mut$ is not $var$ , then return $error$ .
Replace $gi . value$ with the value $val$ .
Return the updated store.

global_write (S, a, v) global_write (S, a, v) = = S^{'} error (if S . globals [a] . type = var t \land S^{'} = S with globals [a] . value = v) (otherwise)

Values

$ref_type (store, ref) : reftype$

Pre-condition: the reference $ref$ is valid under store $S$ .
Return the reference type $t$ with which $ref$ is valid.
Post-condition: the returned reference type is valid under the empty context.

ref_type (S, r) = t (if S ⊢ r : t)

Note

In future versions of WebAssembly, not all references may carry precise type information at run time. In such cases, this function may return a less precise supertype.

$val_default (valtype) : val$

If $default_{valtype}$ is not defined, then return $error$ .

Else, return the value $default_{valtype}$ .

val_default (t) val_default (t) = = v error (if default_{t} = v) (if default_{t} = ϵ)

Matching

$match_valtype (valtype_{1}, valtype_{2}) : bool$

Pre-condition: the value types $valtype_{1}$ and $valtype_{2}$ are valid under the empty context.
If $valtype_{1}$ matches $valtype_{2}$ , then return $true$ .
Else, return $false$ .

match_reftype (t_{1}, t_{2}) match_reftype (t_{1}, t_{2}) = = true false (if ⊢ t_{1} \leq t_{2}) (otherwise)

$match_externtype (externtype_{1}, externtype_{2}) : bool$

Pre-condition: the extern types $externtype_{1}$ and $externtype_{2}$ are valid under the empty context.
If $externtype_{1}$ matches $externtype_{2}$ , then return $true$ .
Else, return $false$ .

match_externtype (et_{1}, et_{2}) match_externtype (et_{1}, et_{2}) = = true false (if ⊢ et_{1} \leq et_{2}) (otherwise)

A.2 Profiles

To enable the use of WebAssembly in as many environments as possible, profiles specify coherent language subsets that fit constraints imposed by common classes of host environments. A host platform can thereby decide to support the language only under a restricted profile, or even the intersection of multiple profiles.

Conventions

A profile modification is specified by decorating selected rules in the main body of this specification with a profile annotation that defines them as conditional on the choice of profile.

For that purpose, every profile defines a profile marker, an alphanumeric short-hand like $ABC$ . A profile annotation of the form $^{[! ABC XYZ]}$ on a rule indicates that this rule is excluded for either of the profiles whose marker is $ABC$ or $XYZ$ .

There are two ways of subsetting the language in a profile:

Syntactic, by omitting a feature, in which case certain constructs are removed from the syntax altogether.
Semantic, by restricting a feature, in which case certain constructs are still present but some behaviours are ruled out.

Syntax Annotations

To omit a construct from a profile syntactically, respective productions in the grammar of the abstract syntax are annotated with an associated profile marker. This is defined to have the following implications:

Any production in the binary or textual syntax that produces abstract syntax with a marked construct is omitted by extension.
Any validation or execution rule that handles a marked construct is omitted by extension.

The overall effect is that the respective construct is no longer part of the language under a respective profile.

Note

For example, a “busy” profile marked $BUSY$ could rule out the $nop$ instruction by marking the production for it in the abstract syntax as follows:

instr^{[! BUSY]} ::= ∣ ∣ \dots nop unreachable

A rule may be annotated by multiple markers, which could be the case if a construct is in the intersection of multiple features.

Semantics Annotations

To restrict certain behaviours in a profile, individual validation or reduction rules or auxiliary definitions are annotated with an associated marker.

This has the consequence that the respective rule is no longer applicable under the given profile.

Note

For example, an “infinite” profile marked $INF$ could define that growing memory never fails:

S; F; (i32 . const n) memory.grow x ↪ S^{'}; F; (i32 . const sz) (if \land \land F . module . memaddrs [x] = a sz = ∣ S . mems [a] . data ∣/64 Ki S^{'} = S with mems [a] = growmem (S . mems [a], n)) 1 e x] 1 e x]^{[! INF]} S; F; (i32 . const n) memory.grow x ↪ S; F; (i32 . const signed_{32}^{- 1} (- 1))

Properties

All profiles are defined such that the following properties are preserved:

All profiles represent syntactic and semantic subsets of the full profile, i.e., they do not add syntax or alter behaviour.
All profiles are mutually compatible, i.e., no two profiles subset semantic behaviour in inconsistent or ambiguous ways, and any intersection of profiles preserves the properties described here.
Profiles do not violate soundness, i.e., all configurations valid under that profile still have well-defined execution behaviour.

Note

Tools are generally expected to handle and produce code for the full profile by default. In particular, producers should not generate code that depends on specific profiles. Instead, all code should preserve correctness when executed under the full profile.

Moreover, profiles should be considered static and fixed for a given platform or ecosystem. Runtime conditioning on the “current” profile is not intended and should be avoided.

Defined Profiles

Note

The number of defined profiles is expected to remain small in the future. Profiles are intended for broad and permanent use cases only. In particular, profiles are not intended for language versioning.

Full Profile ( $FUL$ )

The full profile contains the complete language and all possible behaviours. It imposes no restrictions, i.e., all rules and definitions are active. All other profiles define sub-languages of this profile.

Deterministic Profile ( $DET$ )

The deterministic profile excludes all rules marked $^{[! DET]}$ . It defines a sub-language that does not exhibit any incidental non-deterministic behaviour:

All NaN values generated by floating-point instructions are canonical and positive.
All relaxed vector instructions have a fixed behaviour that does not depend on the implementation.

Even under this profile, the $memory.grow$ and $table.grow$ instructions technically remain non-deterministic, in order to be able to indicate resource exhaustion.

Note

In future versions of WebAssembly, new non-deterministic behaviour may be added to the language, such that the deterministic profile will induce additional restrictions.

A.3 Implementation Limitations

Implementations typically impose additional restrictions on a number of aspects of a WebAssembly module or execution. These may stem from:

physical resource limits,
constraints imposed by the embedder or its environment,
limitations of selected implementation strategies.

This section lists allowed limitations. Where restrictions take the form of numeric limits, no minimum requirements are given, nor are the limits assumed to be concrete, fixed numbers. However, it is expected that all implementations have “reasonably” large limits to enable common applications.

Note

A conforming implementation is not allowed to leave out individual features. However, designated subsets of WebAssembly may be specified in the future.

Syntactic Limits

Structure

An implementation may impose restrictions on the following dimensions of a module:

the number of types in a module
the number of functions in a module, including imports
the number of tables in a module, including imports
the number of memories in a module, including imports
the number of globals in a module, including imports
the number of tags in a module, including imports
the number of element segments in a module
the number of data segments in a module
the number of imports to a module
the number of exports from a module
the number of sub types in a recursive type
the subtyping depth of a sub type
the number of fields in a structure type
the number of parameters in a function type
the number of results in a function type
the number of parameters in a block type
the number of results in a block type
the number of locals in a function
the number of instructions in a function body
the number of instructions in a structured control instruction
the number of structured control instructions in a function
the nesting depth of structured control instructions
the number of label indices in a $br_table$ instruction
the number of instructions in a constant expression
the length of the array in a $array.new_fixed$ instruction
the length of an element segment
the length of a data segment
the length of a name
the range of characters in a name

If the limits of an implementation are exceeded for a given module, then the implementation may reject the validation, compilation, or instantiation of that module with an embedder-specific error.

Note

The last item allows embedders that operate in limited environments without support for [UNICODE] to limit the names of imports and exports to common subsets like ASCII.

Binary Format

For a module given in binary format, additional limitations may be imposed on the following dimensions:

the size of a module
the size of any section
the size of an individual function’s code
the size of a structured control instruction
the size of an individual constant expression’s instruction sequence
the number of sections

Text Format

For a module given in text format, additional limitations may be imposed on the following dimensions:

the size of the source text
the size of any syntactic element
the size of an individual token
the nesting depth of folded instructions
the length of symbolic identifiers
the range of literal characters allowed in the source text

Validation

An implementation may defer validation of individual functions until they are first invoked.

If a function turns out to be invalid, then the invocation, and every consecutive call to the same function, results in a trap.

Note

This is to allow implementations to use interpretation or just-in-time compilation for functions. The function must still be fully validated before execution of its body begins.

Execution

Restrictions on the following dimensions may be imposed during execution of a WebAssembly program:

the number of allocated module instances
the number of allocated function instances
the number of allocated table instances
the number of allocated memory instances
the number of allocated global instances
the number of allocated tag instances
the number of allocated structure instances
the number of allocated array instances
the number of allocated exception instances
the size of a table instance
the size of a memory instance
the size of an array instance
the number of frames on the stack
the number of labels on the stack
the number of values on the stack

If the runtime limits of an implementation are exceeded during execution of a computation, then it may terminate that computation and report an embedder-specific error to the invoking code.

Some of the above limits may already be verified during instantiation, in which case an implementation may report exceedance in the same manner as for syntactic limits.

Note

Concrete limits are usually not fixed but may be dependent on specifics, interdependent, vary over time, or depend on other implementation- or embedder-specific situations or events.

Type Soundness

The type system of WebAssembly is sound, implying both type safety and memory safety with respect to the WebAssembly semantics. For example:

All types declared and derived during validation are respected at run time; e.g., every local or global variable will only contain type-correct values, every instruction will only be applied to operands of the expected type, and every function invocation always evaluates to a result of the right type (if it does not diverge, throw an exception, or trap).
No memory location will be read or written except those explicitly defined by the program, i.e., as a local, a global, an element in a table, or a location within a linear memory.
There is no undefined behavior, i.e., the execution rules cover all possible cases that can occur in a valid program, and the rules are mutually consistent.

Soundness also is instrumental in ensuring additional properties, most notably, encapsulation of function and module scopes: no locals can be accessed outside their own function and no module components can be accessed outside their own module unless they are explicitly exported or imported.

The typing rules defining WebAssembly validation only cover the static components of a WebAssembly program. In order to state and prove soundness precisely, the typing rules must be extended to the dynamic components of the abstract runtime, that is, the store, configurations, and administrative instructions. [1]

Contexts

In order to check rolled up recursive types, the context is locally extended with an additional component that records the sub type corresponding to each recursive type index within the current recursive type:

C ::= {\dots, recs subtype^{*}}

Types

Well-formedness for extended type forms is defined as follows.

Heap Type $bot$

The heap type is valid.

C ⊢ bot ok

Heap Type $rec i$

The recursive type index $i$ must exist in $C. recs$ .
Then the heap type is valid.

\frac{C. recs [ i ] = subtype}{C ⊢ rec i ok}

Value Type $bot$

The value type is valid.

C ⊢ bot ok

Recursive Types $rec subtype^{*}$

Let $C^{'}$ be the current context $C$ , but where $recs$ is $subtype^{*}$ .
There must be a type index $x$ , such that for each sub type $subtype_{i}$ in $subtype^{*}$ :
- Under the context $C^{'}$ , the sub type $subtype_{i}$ must be valid for type index $x + i$ and recursive type index $i$ .
Then the recursive type is valid for the type index $x$ .

\frac{C , recs subtype ^{*} ⊢ rec subtype ^{*} ok ( x , 0 )}{C ⊢ rec subtype ^{*} ok ( x )}

C ⊢ rec ϵ ok ( x , i ) \frac{C ⊢ subtype ok ( x , i ) C ⊢ rec subtype ^{'} ^{*} ok ( x + 1 , i + 1 )}{C ⊢ rec subtype subtype ^{'} ^{*} ok ( x , i )}

Note

These rules are a generalisation of the ones previously given.

Sub types $sub final^{?} ht^{*} comptype$

The composite type $comptype$ must be valid.
The sequence $ht^{*}$ may be no longer than $1$ .
For every heap type $ht_{k}$ in $ht^{*}$ :
- The heap type $ht_{k}$ must be ordered before a type index $x$ and recursive type index a $i$ , meaning:
  - Either $ht_{k}$ is a defined type.
  - Or $ht_{k}$ is a type index $y_{k}$ that is smaller than $x$ .
  - Or $ht_{k}$ is a recursive type index $rec j_{k}$ where $j_{k}$ is smaller than $i$ .
- Let sub type $subtype_{k}$ be the unrolling of the heap type $ht_{k}$ , meaning:
  - Either $ht_{k}$ is a defined type $deftype_{k}$ , then $subtype_{k}$ must be the unrolling of $deftype_{k}$ .
  - Or $ht_{k}$ is a type index $y_{k}$ , then $subtype_{k}$ must be the unrolling of the defined type $C. types [y_{k}]$ .
  - Or $ht_{k}$ is a recursive type index $rec j_{k}$ , then $subtype_{k}$ must be $C. recs [j_{k}]$ .
- The sub type $subtype_{k}$ must not contain $final$ .
- Let $comptype_{k}^{'}$ be the composite type in $subtype_{k}$ .
- The composite type $comptype$ must match $comptype_{k}^{'}$ .
Then the sub type is valid for the type index $x$ and recursive type index $i$ .

\frac{∣ ht ^{*} ∣ \leq 1 ( ht ≺ x , i ) ^{*} ( unroll _{C} ( ht ) = sub ht ^{'} ^{*} comptype ^{'} ) ^{*} C ⊢ comptype ok ( C ⊢ comptype \leq comptype ^{'} ) ^{*}}{C ⊢ sub final ^{?} ht ^{*} comptype ok ( x , i )}

where:

(deftype ≺ x, i) (y ≺ x, i) (rec j ≺ x, i) [2 e x] unroll_{C} (deftype) unroll_{C} (y) unroll_{C} (rec j) = = = = = = true y < x j < i unroll (deftype) unroll (C . types [y]) C . recs [j]

Note

This rule is a generalisation of the ones previously given, which only allowed type indices as supertypes.

Subtyping

In a rolled-up recursive type, a recursive type indices $rec i$ matches another heap type $ht$ if:

Let $sub final^{?} ht^{'}^{*} comptype$ be the sub type $C. recs [i]$ .
The heap type $ht$ is contained in $ht^{'}^{*}$ .

\frac{C. recs [ i ] = sub final ^{?} ( ht _{1}^{*} ht ht _{2}^{*} ) comptype}{C ⊢ rec i \leq ht}

Note

This rule is only invoked when checking validity of rolled-up recursive types.

Results

Results can be classified by result types as follows.

Results $val^{*}$

For each value $val_{i}$ in $val^{*}$ :
- The value $val_{i}$ is valid with some value type $t_{i}$ .
Let $t^{*}$ be the concatenation of all $t_{i}$ .
Then the result is valid with result type $[t^{*}]$ .

\frac{( S ⊢ val : t ) ^{*}}{S ⊢ val ^{*} : [ t ^{*} ]}

Results $T [(ref . exn a) throw_ref]$

The value $ref . exn a$ must be valid.
Then the result is valid with result type $[t^{*}]$ , for any sequence $t^{'}^{*}$ of value types.

Results $trap$

The result is valid with result type $[t^{*}]$ , for any valid closed result types.

\frac{⊢ [ t ^{*} ] ok}{S ⊢ trap : [ t ^{*} ]}

\frac{S ⊢ tag tagaddr : tag [ t ^{*} ] \to [ ] ( S ⊢ val : t ) ^{*}}{S ⊢ T [( ref . exn a ) throw_ref ] : [ t ^{'} ^{*} ]}

Store Validity

The following typing rules specify when a runtime store $S$ is valid. A valid store must consist of function, table, memory, global, tag, element, data, structure, array, exception, and module instances that are themselves valid, relative to $S$ .

To that end, each kind of instance is classified by a respective function, table, memory, global, tag, element, or data type, or just $ok$ in the case of structures, arrays, or exceptions. Module instances are classified by module contexts, which are regular contexts repurposed as module types describing the index spaces defined by a module.

Store $S$

Each function instance $funcinst_{i}$ in $S. funcs$ must be valid with some function type $functype_{i}$ .
Each table instance $tableinst_{i}$ in $S. tables$ must be valid with some table type $tabletype_{i}$ .
Each memory instance $meminst_{i}$ in $S. mems$ must be valid with some memory type $memtype_{i}$ .
Each global instance $globalinst_{i}$ in $S. globals$ must be valid with some global type $globaltype_{i}$ .
Each tag instance $taginst_{i}$ in $S. tags$ must be valid with some tag type $tagtype_{i}$ .
Each element instance $eleminst_{i}$ in $S. elems$ must be valid with some reference type $reftype_{i}$ .
Each data instance $datainst_{i}$ in $S. datas$ must be valid.
Each structure instance $structinst_{i}$ in $S. structs$ must be valid.
Each array instance $arrayinst_{i}$ in $S. arrays$ must be valid.
Each exception instance $exninst_{i}$ in $S. exns$ must be valid.
No reference to a bound structure address must be reachable from itself through a path consisting only of indirections through immutable structure, or array fields or fields of exception instances.
No reference to a bound array address must be reachable from itself through a path consisting only of indirections through immutable structure or array fields or fields of exception instances.
No reference to a bound exception address must be reachable from itself through a path consisting only of indirections through immutable structure or array fields or fields of exception instances.
Then the store is valid.

\frac{( S ⊢ funcinst : deftype ) ^{*} ( S ⊢ tableinst : tabletype ) ^{*} ( S ⊢ meminst : memtype ) ^{*} ( S ⊢ globalinst : globaltype ) ^{*} ( S ⊢ taginst : tagtype ) ^{*} ( S ⊢ eleminst : reftype ) ^{*} ( S ⊢ datainst ok ) ^{*} ( S ⊢ structinst ok ) ^{*} ( S ⊢ arrayinst ok ) ^{*} ( S ⊢ exninst ok ) ^{*} S = { funcs funcinst ^{*} , globals globalinst ^{*} , tables tableinst ^{*} , mems meminst ^{*} , tags taginst ^{*} , elems eleminst ^{*} , datas datainst ^{*} , structs structinst ^{*} , arrays arrayinst ^{*} , exns exninst ^{*} } ( S . structs [ a _{s} ] = structinst ) ^{*} (( ref . struct a _{s} ) \neq ≫ _{S}^{+} ( ref . struct a _{s} ) ) ^{*} ( S . arrays [ a _{a} ] = arrayinst ) ^{*} (( ref . array a _{a} ) \neq ≫ _{S}^{+} ( ref . array a _{a} ) ) ^{*} ( S . exns [ a _{e} ] = exninst ) ^{*} (( ref . exn a _{e} ) \neq ≫ _{S}^{+} ( ref . exn a _{e} ) ) ^{*}}{⊢ S ok}

where $val_{1} ≫_{S}^{+} val_{2}$ denotes the transitive closure of the following immutable reachability relation on values:

(ref . struct a) (ref . array a) (ref . exn a) (ref . extern ref) ≫_{S} ≫_{S} ≫_{S} ≫_{S} S . structs [a] . fields [i] S . arrays [a] . fields [i] S . exns [a] . fields [i] ref if expand (S . structs [a] . type) = struct ft_{1}^{i} (const st) ft_{2}^{*} if expand (S . arrays [a] . type) = array (const st)

Note

The constraint on reachability through immutable fields prevents the presence of cyclic data structures that can not be constructed in the language. Cycles can only be formed using mutation.

Function Instances ${type functype, module moduleinst, code func}$

The function type $functype$ must be valid under an empty context.
The module instance $moduleinst$ must be valid with some context $C$ .
Under context $C$ :
- The function $func$ must be valid with some function type $functype^{'}$ .
- The function type $functype^{'}$ must match $functype$ .
Then the function instance is valid with function type $functype$ .

\frac{⊢ functype ok S ⊢ moduleinst : C C ⊢ func : functype ^{'} C ⊢ functype ^{'} \leq functype}{S ⊢ { type functype , module moduleinst , code func } : functype}

Host Function Instances ${type functype, hostcode hf}$

The function type $functype$ must be valid under an empty context.
Let $[t_{1}^{*}] \to [t_{2}^{*}]$ be the function type $functype$ .
For every valid store $S_{1}$ extending $S$ and every sequence $val^{*}$ of values whose types coincide with $t_{1}^{*}$ :
- Executing $hf$ in store $S_{1}$ with arguments $val^{*}$ has a non-empty set of possible outcomes.
- For every element $R$ of this set:
  - Either $R$ must be $⊥$ (i.e., divergence).
  - Or $R$ consists of a valid store $S_{2}$ extending $S_{1}$ and a result $result$ whose type coincides with $[t_{2}^{*}]$ .
Then the function instance is valid with function type $functype$ .

\frac{⊢ [ t _{1}^{*} ] \to [ t _{2}^{*} ] ok \forall S _{1} , val ^{*} , ⊢ S _{1} ok \land ⊢ S ⪯ S _{1} \land S _{1} ⊢ val ^{*} : [ t _{1}^{*} ] ⟹ hf ( S _{1} ; val ^{*} ) \supset \emptyset \land \forall R \in hf ( S _{1} ; val ^{*} ) , R = ⊥ \lor \exists S _{2} , result , ⊢ S _{2} ok \land ⊢ S _{1} ⪯ S _{2} \land S _{2} ⊢ result : [ t _{2}^{*} ] \land R = ( S _{2} ; result )}{S ⊢ { type [ t _{1}^{*} ] \to [ t _{2}^{*} ] , hostcode hf } : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

Note

This rule states that, if appropriate pre-conditions about store and arguments are satisfied, then executing the host function must satisfy appropriate post-conditions about store and results. The post-conditions match the ones in the execution rule for invoking host functions.

Any store under which the function is invoked is assumed to be an extension of the current store. That way, the function itself is able to make sufficient assumptions about future stores.

Table Instances ${type addrtype limits t, elem ref^{*}}$

The table type $addrtype limits t$ must be valid under the empty context.
The length of $ref^{*}$ must equal $limits . min$ .
For each reference $ref_{i}$ in the table’s elements $ref^{n}$ :
- The reference $ref_{i}$ must be valid with some reference type $t ’_{i}$ .
- The reference type $t ’_{i}$ must match the reference type $t$ .
Then the table instance is valid with table type $addrtype limits t$ .

\frac{⊢ addrtype limits t ok n = limits . min ( S ⊢ ref : t ^{'} ) ^{n} ( ⊢ t ^{'} \leq t ) ^{n}}{S ⊢ { type addrtype limits t , elem ref ^{n} } : addrtype limits t}

Memory Instances ${type addrtype limits, data b^{*}}$

The memory type $addrtype limits$ must be valid under the empty context.
The length of $b^{*}$ must equal $limits . min$ multiplied by the page size $64 Ki$ .
Then the memory instance is valid with memory type $addrtype limits$ .

\frac{⊢ addrtype limits ok n = limits . min \cdot 64 Ki}{S ⊢ { type addrtype limits , data b ^{n} } : addrtype limits}

Global Instances ${type mut t, value val}$

The global type $mut t$ must be valid under the empty context.
The value $val$ must be valid with some value type $t^{'}$ .
The value type $t^{'}$ must match the value type $t$ .
Then the global instance is valid with global type $mut t$ .

\frac{⊢ mut t ok S ⊢ val : t ^{'} ⊢ t ^{'} \leq t}{S ⊢ { type mut t , value val } : mut t}

Tag Instances ${type tagtype}$

The tag type $tagtype$ must be valid under the empty context.
Then the tag instance is valid with tag type $tagtype$ .

\frac{⊢ tagtype ok}{S ⊢ { type tagtype } : tagtype}

Element Instances ${type t, elem ref^{*}}$

The reference type $t$ must be valid under the empty context.
For each reference $ref_{i}$ in the elements $ref^{n}$ :
- The reference $ref_{i}$ must be valid with some reference type $t ’_{i}$ .
- The reference type $t ’_{i}$ must match the reference type $t$ .
Then the element instance is valid with reference type $t$ .

\frac{⊢ t ok ( S ⊢ ref : t ^{'} ) ^{*} ( ⊢ t ^{'} \leq t ) ^{*}}{S ⊢ { type t , elem ref ^{*} } : t}

Data Instances ${data b^{*}}$

The data instance is valid.

S ⊢ { data b ^{*} } ok

Structure Instances ${type deftype, fields fieldval^{*}}$

The defined type $deftype$ must be valid under the empty context.
The expansion of $deftype$ must be a structure type $struct fieldtype^{*}$ .
The length of the sequence of field values $fieldval^{*}$ must be the same as the length of the sequence of field types $fieldtype^{*}$ .
For each field value $fieldval_{i}$ in $fieldval^{*}$ and corresponding field type $fieldtype_{i}$ in $fieldtype^{*}$ :
- Let $fieldtype_{i}$ be $mut storagetype_{i}$ .
- The field value $fieldval_{i}$ must be valid with storage type $storagetype_{i}$ .
Then the structure instance is valid.

\frac{⊢ dt ok expand ( dt ) = struct ( mut st ) ^{*} ( S ⊢ fv : st ) ^{*}}{S ⊢ { type dt , fields fv ^{*} } ok}

Array Instances ${type deftype, fields fieldval^{*}}$

The defined type $deftype$ must be valid under the empty context.
The expansion of $deftype$ must be an array type $array fieldtype$ .
Let $fieldtype$ be $mut storagetype$ .
For each field value $fieldval_{i}$ in $fieldval^{*}$ :
- The field value $fieldval_{i}$ must be valid with storage type $storagetype$ .
Then the array instance is valid.

\frac{⊢ dt ok expand ( dt ) = array ( mut st ) ( S ⊢ fv : st ) ^{*}}{S ⊢ { type dt , fields fv ^{*} } ok}

Field Values $fieldval$

If $fieldval$ is a value $val$ , then:
- The value $val$ must be valid with value type $t$ .
- Then the field value is valid with value type $t$ .
Else, $fieldval$ is a packed value $packedval$ :
- Let $packedtype . pack i$ be the field value $fieldval$ .
- Then the field value is valid with packed type $packedtype$ .

S ⊢ pt . pack i : pt

Exception Instances ${tag a, fields val^{*}}$

The store entry $S. tags [a]$ must exist.
Let $[t^{*}] \to [t^{'}^{*}]$ be the tag type $S. tags [a] . type$ .
The result type $[t^{'}^{*}]$ must be empty.
The sequence $val^{a} st$ of values must have the same length as the sequence $t^{*}$ of value types.
For each value $val_{i}$ in $val^{a} st$ and corresponding value type $t_{i}$ in $t^{*}$ , the value $val_{i}$ must be valid with type $t_{i}$ .
Then the exception instance is valid.

\frac{S. tags [ a ] = { type = [ t ^{*} ] \to [ ]} ( S ⊢ val : t ) ^{*}}{S ⊢ { tag a , fields val ^{*} } ok}

Export Instances ${name name, value externval}$

The external value $externval$ must be valid with some external type $externtype$ .
Then the export instance is valid.

\frac{S ⊢ externval : externtype}{S ⊢ { name name , value externval } ok}

Module Instances $moduleinst$

Each defined type $deftype_{i}$ in $moduleinst . types$ must be valid under the empty context.
For each function address $funcaddr_{i}$ in $moduleinst . funcaddrs$ , the external value $func funcaddr_{i}$ must be valid with some external type $func functype_{i}$ .
For each table address $tableaddr_{i}$ in $moduleinst . tableaddrs$ , the external value $table tableaddr_{i}$ must be valid with some external type $table tabletype_{i}$ .
For each memory address $memaddr_{i}$ in $moduleinst . memaddrs$ , the external value $mem memaddr_{i}$ must be valid with some external type $mem memtype_{i}$ .
For each global address $globaladdr_{i}$ in $moduleinst . globaladdrs$ , the external value $global globaladdr_{i}$ must be valid with some external type $global globaltype_{i}$ .
For each tag address $tagaddr_{i}$ in $moduleinst . tagaddrs$ , the external value $tag tagaddr_{i}$ must be valid with some external type $tag tagtype_{i}$ .
For each element address $elemaddr_{i}$ in $moduleinst . elemaddrs$ , the element instance $S. elems [elemaddr_{i}]$ must be valid with some reference type $reftype_{i}$ .
For each data address $dataaddr_{i}$ in $moduleinst . dataaddrs$ , the data instance $S. datas [dataaddr_{i}]$ must be valid.
Each export instance $exportinst_{i}$ in $moduleinst . exports$ must be valid.
For each export instance $exportinst_{i}$ in $moduleinst . exports$ , the name $exportinst_{i} . name$ must be different from any other name occurring in $moduleinst . exports$ .
Let $deftype^{*}$ be the concatenation of all $deftype_{i}$ in order.
Let $functype^{*}$ be the concatenation of all $functype_{i}$ in order.
Let $tabletype^{*}$ be the concatenation of all $tabletype_{i}$ in order.
Let $memtype^{*}$ be the concatenation of all $memtype_{i}$ in order.
Let $globaltype^{*}$ be the concatenation of all $globaltype_{i}$ in order.
Let $tagtype^{*}$ be the concatenation of all $tagtype_{i}$ in order.
Let $reftype^{*}$ be the concatenation of all $reftype_{i}$ in order.
Let $m$ be the length of $moduleinst . funcaddrs$ .
Let $n$ be the length of $moduleinst . dataaddrs$ .
Let $x^{*}$ be the sequence of function indices from $0$ to $m - 1$ .
Then the module instance is valid with context ${types deftype^{*},$ $funcs functype^{*},$ $tables tabletype^{*},$ $mems memtype^{*},$ $globals globaltype^{*},$ CTAGS~tagtype^ast, $elems reftype^{*},$ $datas ok^{n},$ $refs x^{*}}$ .

\frac{( ⊢ deftype ok ) ^{*} ( S ⊢ func funcaddr : func functype ) ^{*} ( S ⊢ table tableaddr : table tabletype ) ^{*} ( S ⊢ mem memaddr : mem memtype ) ^{*} ( S ⊢ global globaladdr : global globaltype ) ^{*} ( S ⊢ tag tagaddr : tag tagtype ) ^{*} ( S ⊢ S . elems [ elemaddr ] : reftype ) ^{*} ( S ⊢ S . datas [ dataaddr ] ok ) ^{n} ( S ⊢ exportinst ok ) ^{*} ( exportinst . name ) ^{*} disjoint}{S ⊢ { types funcaddrs tableaddrs memaddrs globaladdrs tagaddrs elemaddrs dataaddrs exports deftype ^{*} , funcaddr ^{*} , tableaddr ^{*} , memaddr ^{*} , globaladdr ^{*} , tagaddr ^{*} , elemaddr ^{*} , dataaddr ^{n} , exportinst ^{*} } : { types funcs tables mems globals tags elems datas refs deftype ^{*} , functype ^{*} , tabletype ^{*} , memtype ^{*} , globaltype ^{*} , tagtype ^{*} , reftype ^{*} , ok ^{n} , 0 \dots ( ∣ funcaddr ^{*} ∣ - 1 ) }}

Configuration Validity

To relate the WebAssembly type system to its execution semantics, the typing rules for instructions must be extended to configurations $S; T$ , which relates the store to execution threads.

Configurations and threads are classified by their result type. In addition to the store $S$ , threads are typed under a return type $resulttype^{?}$ , which controls whether and with which type a $return$ instruction is allowed. This type is absent ( $ϵ$ ) except for instruction sequences inside an administrative $frame$ instruction.

Finally, frames are classified with frame contexts, which extend the module contexts of a frame’s associated module instance with the locals that the frame contains.

Configurations $S; T$

The store $S$ must be valid.
Under no allowed return type, the thread $T$ must be valid with some result type $[t^{*}]$ .
Then the configuration is valid with the result type $[t^{*}]$ .

\frac{⊢ S ok S ; ϵ ⊢ T : [ t ^{*} ]}{⊢ S ; T : [ t ^{*} ]}

Threads $F; instr^{*}$

Let $resulttype^{?}$ be the current allowed return type.
The frame $F$ must be valid with a context $C$ .
Let $C^{'}$ be the same context as $C$ , but with $return$ set to $resulttype^{?}$ .
Under context $C^{'}$ , the instruction sequence $instr^{*}$ must be valid with some type $[] \to [t^{*}]$ .
Then the thread is valid with the result type $[t^{*}]$ .

\frac{S ⊢ F : C S ; C , return resulttype ^{?} ⊢ instr ^{*} : [ ] \to [ t ^{*} ]}{S ; resulttype ^{?} ⊢ F ; instr ^{*} : [ t ^{*} ]}

Frames ${locals val^{*}, module moduleinst}$

The module instance $moduleinst$ must be valid with some module context $C$ .
Each value $val_{i}$ in $val^{*}$ must be valid with some value type $t_{i}$ .
Let $t^{*}$ be the concatenation of all $t_{i}$ in order.
Let $C^{'}$ be the same context as $C$ , but with the value types $t^{*}$ prepended to the $locals$ vector.
Then the frame is valid with frame context $C^{'}$ .

\frac{S ⊢ moduleinst : C ( S ⊢ val : t ) ^{*}}{S ⊢ { locals val ^{*} , module moduleinst } : ( C , locals t ^{*} )}

Administrative Instructions

Typing rules for administrative instructions are specified as follows. In addition to the context $C$ , typing of these instructions is defined under a given store $S$ .

To that end, all previous typing judgements $C ⊢ prop$ are generalized to include the store, as in $S; C ⊢ prop$ , by implicitly adding $S$ to all rules – $S$ is never modified by the pre-existing rules, but it is accessed in the extra rules for administrative instructions given below.

$trap$

The instruction is valid with any valid instruction type of the form $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{C ⊢ [ t _{1}^{*} ] \to [ t _{2}^{*} ] ok}{S ; C ⊢ trap : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

$val$

The value $val$ must be valid with value type $t$ .
Then it is valid as an instruction with type $[] \to [t]$ .

\frac{S ⊢ val : t}{S ; C ⊢ val : [ ] \to [ t ]}

$invoke funcaddr$

The external function value $func funcaddr$ must be valid with external function type $func functype^{'}$ .
Let $[t_{1}^{*}] \to [t_{2}^{*}])$ be the function type $functype$ .
Then the instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{S ⊢ func funcaddr : func [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{S ; C ⊢ invoke funcaddr : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

$label_{n} {instr_{0}^{}} instr^{} end$

The instruction sequence $instr_{0}^{*}$ must be valid with some type $[t_{1}^{n}] \to_{x^{*}} [t_{2}^{*}]$ .
Let $C^{'}$ be the same context as $C$ , but with the result type $[t_{1}^{n}]$ prepended to the $labels$ vector.
Under context $C^{'}$ , the instruction sequence $instr^{*}$ must be valid with type $[] \to_{x^{'}^{*}} [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[] \to [t_{2}^{*}]$ .

\frac{S ; C ⊢ instr _{0}^{*} : [ t _{1}^{n} ] \to _{x^{*}} [ t _{2}^{*} ] S ; C , labels [ t _{1}^{n} ] ⊢ instr ^{*} : [ ] \to _{x^{'}^{*}} [ t _{2}^{*} ]}{S ; C ⊢ label _{n} { instr _{0}^{*} } instr ^{*} end : [ ] \to [ t _{2}^{*} ]}

$handler_{n} {catch^{}} instr^{} end$

For every catch clause $catch_{i}$ in $catch^{*}$ , $catch_{i}$ must be valid.
The instruction sequence $instr^{*}$ must be valid with some type $[t_{1}^{*}] \to [t_{2}^{*}]$ .
Then the compound instruction is valid with type $[t_{1}^{*}] \to [t_{2}^{*}]$ .

\frac{( C ⊢ catch ok ) ^{*} S ; C ⊢ instr ^{*} : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}{S ; C ⊢ handler _{n} { catch ^{*} } instr ^{*} end : [ t _{1}^{*} ] \to [ t _{2}^{*} ]}

$frame_{n} {F} instr^{*} end$

Under the valid return type $[t^{n}]$ , the thread $F; instr^{*}$ must be valid with result type $[t^{n}]$ .
Then the compound instruction is valid with type $[] \to [t^{n}]$ .

\frac{C ⊢ [ t ^{n} ] ok S ; [ t ^{n} ] ⊢ F ; instr ^{*} : [ t ^{n} ]}{S ; C ⊢ frame _{n} { F } instr ^{*} end : [ ] \to [ t ^{n} ]}

Store Extension

Programs can mutate the store and its contained instances. Any such modification must respect certain invariants, such as not removing allocated instances or changing immutable definitions. While these invariants are inherent to the execution semantics of WebAssembly instructions and modules, host functions do not automatically adhere to them. Consequently, the required invariants must be stated as explicit constraints on the invocation of host functions. Soundness only holds when the embedder ensures these constraints.

The necessary constraints are codified by the notion of store extension: a store state $S^{'}$ extends state $S$ , written $S ⪯ S^{'}$ , when the following rules hold.

Note

Extension does not imply that the new store is valid, which is defined separately above.

Store $S$

The length of $S. funcs$ must not shrink.
The length of $S. tables$ must not shrink.
The length of $S. mems$ must not shrink.
The length of $S. globals$ must not shrink.
The length of $S. tags$ must not shrink.
The length of $S. elems$ must not shrink.
The length of $S. datas$ must not shrink.
The length of $S. structs$ must not shrink.
The length of $S. arrays$ must not shrink.
The length of $S. exns$ must not shrink.
For each function instance $funcinst_{i}$ in the original $S. funcs$ , the new function instance must be an extension of the old.
For each table instance $tableinst_{i}$ in the original $S. tables$ , the new table instance must be an extension of the old.
For each memory instance $meminst_{i}$ in the original $S. mems$ , the new memory instance must be an extension of the old.
For each global instance $globalinst_{i}$ in the original $S. globals$ , the new global instance must be an extension of the old.
For each tag instance $taginst_{i}$ in the original $S. tags$ , the new tag instance must be an extension of the old.
For each element instance $eleminst_{i}$ in the original $S. elems$ , the new element instance must be an extension of the old.
For each data instance $datainst_{i}$ in the original $S. datas$ , the new data instance must be an extension of the old.
For each structure instance $structinst_{i}$ in the original $S. structs$ , the new structure instance must be an extension of the old.
For each array instance $arrayinst_{i}$ in the original $S. arrays$ , the new array instance must be an extension of the old.
For each exception instance $exninst_{i}$ in the original $S. exns$ , the new exception instance must be an extension of the old.

\frac{S _{1} . funcs = funcinst _{1}^{*} S _{1} . tables = tableinst _{1}^{*} S _{1} . mems = meminst _{1}^{*} S _{1} . globals = globalinst _{1}^{*} S _{1} . tags = taginst _{1}^{*} S _{1} . elems = eleminst _{1}^{*} S _{1} . datas = datainst _{1}^{*} S _{1} . structs = structinst _{1}^{*} S _{1} . arrays = arrayinst _{1}^{*} S _{1} . exns = exninst _{1}^{*} S _{2} . funcs = funcinst _{1}^{'} ^{*} funcinst _{2}^{*} S _{2} . tables = tableinst _{1}^{'} ^{*} tableinst _{2}^{*} S _{2} . mems = meminst _{1}^{'} ^{*} meminst _{2}^{*} S _{2} . globals = globalinst _{1}^{'} ^{*} globalinst _{2}^{*} S _{2} . tags = taginst _{1}^{'} ^{*} taginst _{2}^{*} S _{2} . elems = eleminst _{1}^{'} ^{*} eleminst _{2}^{*} S _{2} . datas = datainst _{1}^{'} ^{*} datainst _{2}^{*} S _{2} . structs = structinst _{1}^{'} ^{*} structinst _{2}^{*} S _{2} . arrays = arrayinst _{1}^{'} ^{*} arrayinst _{2}^{*} S _{2} . exns = exninst _{1}^{'} ^{*} exninst _{2}^{*} ( ⊢ funcinst _{1} ⪯ funcinst _{1}^{'} ) ^{*} ( ⊢ tableinst _{1} ⪯ tableinst _{1}^{'} ) ^{*} ( ⊢ meminst _{1} ⪯ meminst _{1}^{'} ) ^{*} ( ⊢ globalinst _{1} ⪯ globalinst _{1}^{'} ) ^{*} ( ⊢ taginst _{1} ⪯ taginst _{1}^{'} ) ^{*} ( ⊢ eleminst _{1} ⪯ eleminst _{1}^{'} ) ^{*} ( ⊢ datainst _{1} ⪯ datainst _{1}^{'} ) ^{*} ( ⊢ structinst _{1} ⪯ structinst _{1}^{'} ) ^{*} ( ⊢ arrayinst _{1} ⪯ arrayinst _{1}^{'} ) ^{*} ( ⊢ exninst _{1} ⪯ exninst _{1}^{'} ) ^{*}}{⊢ S _{1} ⪯ S _{2}}

Function Instance $funcinst$

A function instance must remain unchanged.

⊢ funcinst ⪯ funcinst

Table Instance $tableinst$

The table type $tableinst . type$ must remain unchanged.
The length of $tableinst . elem$ must not shrink.

\frac{n _{1} \leq n _{2}}{⊢ { type tt , elem ( fa _{1}^{?} ) ^{n_{1}} } ⪯ { type tt , elem ( fa _{2}^{?} ) ^{n_{2}} }}

Memory Instance $meminst$

The memory type $meminst . type$ must remain unchanged.
The length of $meminst . data$ must not shrink.

\frac{n _{1} \leq n _{2}}{⊢ { type mt , data b _{1}^{n_{1}} } ⪯ { type mt , data b _{2}^{n_{2}} }}

Global Instance $globalinst$

The global type $globalinst . type$ must remain unchanged.
Let $mut t$ be the structure of $globalinst . type$ .
If $mut$ is $const$ , then the value $globalinst . value$ must remain unchanged.

\frac{mut = var \lor val _{1} = val _{2}}{⊢ { type ( mut t ) , value val _{1} } ⪯ { type ( mut t ) , value val _{2} }}

Tag Instance $taginst$

A tag instance must remain unchanged.

⊢ taginst ⪯ taginst

Element Instance $eleminst$

The reference type $eleminst . type$ must remain unchanged.
The vector $eleminst . elem$ must:
- either remain unchanged,
- or shrink to length $0$ .

⊢ { type t , elem a ^{*} } ⪯ { type t , elem a ^{*} }

⊢ { type t , elem a ^{*} } ⪯ { type t , elem ϵ }

Data Instance $datainst$

The vector $datainst . data$ must:
- either remain unchanged,
- or shrink to length $0$ .

⊢ { data b ^{*} } ⪯ { data b ^{*} }

⊢ { data b ^{*} } ⪯ { data ϵ }

Structure Instance $structinst$

The defined type $structinst . type$ must remain unchanged.
Assert: due to store well-formedness, the expansion of $structinst . type$ is a structure type.
Let $struct fieldtype^{*}$ be the expansion of $structinst . type$ .
The length of the vector $structinst . fields$ must remain unchanged.
Assert: due to store well-formedness, the length of $structinst . fields$ is the same as the length of $fieldtype^{*}$ .
For each field value $fieldval_{i}$ in $structinst . fields$ and corresponding field type $fieldtype_{i}$ in $fieldtype^{*}$ :
- Let $mut_{i} st_{i}$ be the structure of $fieldtype_{i}$ .
- If $mut_{i}$ is $const$ , then the field value $fieldval_{i}$ must remain unchanged.

\frac{( mut = var \lor fieldval _{1} = fieldval _{2} ) ^{*}}{⊢ { type ( mut st ) ^{*} , fields fieldval _{1}^{*} } ⪯ { type ( mut st ) ^{*} , fields fieldval _{2}^{*} }}

Array Instance $arrayinst$

The defined type $arrayinst . type$ must remain unchanged.
Assert: due to store well-formedness, the expansion of $arrayinst . type$ is an array type.
Let $array fieldtype$ be the expansion of $arrayinst . type$ .
The length of the vector $arrayinst . fields$ must remain unchanged.
Let $mut st$ be the structure of $fieldtype$ .
If $mut$ is $const$ , then the sequence of field values $arrayinst . fields$ must remain unchanged.

\frac{mut = var \lor fieldval _{1}^{*} = fieldval _{2}^{*}}{⊢ { type ( mut st ) , fields fieldval _{1}^{*} } ⪯ { type ( mut st ) , fields fieldval _{2}^{*} }}

Exception Instance $exninst$

An exception instance must remain unchanged.

⊢ exninst ⪯ exninst

Theorems

Given the definition of valid configurations, the standard soundness theorems hold. [2] [3]

Theorem (Preservation). If a configuration $S; T$ is valid with result type $[t^{*}]$ (i.e., $⊢ S; T : [t^{*}]$ ), and steps to $S^{'}; T^{'}$ (i.e., $S; T ↪ S^{'}; T^{'}$ ), then $S^{'}; T^{'}$ is a valid configuration with the same result type (i.e., $⊢ S^{'}; T^{'} : [t^{*}]$ ). Furthermore, $S^{'}$ is an extension of $S$ (i.e., $⊢ S ⪯ S^{'}$ ).

A terminal thread is one whose sequence of instructions is a result. A terminal configuration is a configuration whose thread is terminal.

Theorem (Progress). If a configuration $S; T$ is valid (i.e., $⊢ S; T : [t^{*}]$ for some result type $[t^{*}]$ ), then either it is terminal, or it can step to some configuration $S^{'}; T^{'}$ (i.e., $S; T ↪ S^{'}; T^{'}$ ).

From Preservation and Progress the soundness of the WebAssembly type system follows directly.

Corollary (Soundness). If a configuration $S; T$ is valid (i.e., $⊢ S; T : [t^{*}]$ for some result type $[t^{*}]$ ), then it either diverges or takes a finite number of steps to reach a terminal configuration $S^{'}; T^{'}$ (i.e., $S; T ↪^{*} S^{'}; T^{'}$ ) that is valid with the same result type (i.e., $⊢ S^{'}; T^{'} : [t^{*}]$ ) and where $S^{'}$ is an extension of $S$ (i.e., $⊢ S ⪯ S^{'}$ ).

In other words, every thread in a valid configuration either runs forever, traps, throws an exception, or terminates with a result that has the expected type. Consequently, given a valid store, no computation defined by instantiation or invocation of a valid module can “crash” or otherwise (mis)behave in ways not covered by the execution semantics given in this specification.

Type System Properties

Principal Types

The type system of WebAssembly features both subtyping and simple forms of polymorphism for instruction types. That has the effect that every instruction or instruction sequence can be classified with multiple different instruction types.

However, the typing rules still allow deriving principal types for instruction sequences. That is, every valid instruction sequence has one particular type scheme, possibly containing some unconstrained place holder type variables, that is a subtype of all its valid instruction types, after substituting its type variables with suitable specific types.

Moreover, when deriving an instruction type in a “forward” manner, i.e., the input of the instruction sequence is already fixed to specific types, then it has a principal output type expressible without type variables, up to a possibly polymorphic stack bottom representable with one single variable. In other words, “forward” principal types are effectively closed.

Note

For example, in isolation, the instruction $ref.as_non_null$ has the type $[(ref null ht)] \to [(ref ht)]$ for any choice of valid heap type $ht$ . Moreover, if the input type $[(ref null ht)]$ is already determined, i.e., a specific $ht$ is given, then the output type $[(ref ht)]$ is fully determined as well.

The implication of the latter property is that a validator for complete instruction sequences (as they occur in valid modules) can be implemented with a simple left-to-right algorithm that does not require the introduction of type variables.

A typing algorithm capable of handling partial instruction sequences (as might be considered for program analysis or program manipulation) needs to introduce type variables and perform substitutions, but it does not need to perform backtracking or record any non-syntactic constraints on these type variables.

Technically, the syntax of heap, value, and result types can be enriched with type variables as follows:

null heaptype reftype valtype resulttype ::= ::= ::= ::= ::= null^{?} ∣ α_{null} \dots ∣ α_{heaptype} ref null heaptype \dots ∣ α_{valtype} ∣ α_{numvectype} [α_{valtype^{*}}^{?} valtype^{*}]

where each $α_{xyz}$ ranges over a set of type variables for syntactic class $xyz$ , respectively. The special class $numvectype$ is defined as $numtype ∣ vectype ∣ bot$ , and is only needed to handle unannotated $select$ instructions.

A type is closed when it does not contain any type variables, and open otherwise. A type substitution $σ$ is a finite mapping from type variables to closed types of the respective syntactic class. When applied to an open type, it replaces the type variables $α$ from its domain with the respective $σ (α)$ .

Theorem (Principal Types). If an instruction sequence $instr^{*}$ is valid with some closed instruction type $instrtype$ (i.e., $C ⊢ instr^{*} : instrtype$ ), then it is also valid with a possibly open instruction type $instrtype_{m i n}$ (i.e., $C ⊢ instr^{*} : instrtype_{m i n}$ ), such that for every closed type $instrtype^{'}$ with which $instr^{*}$ is valid (i.e., for all $C ⊢ instr^{*} : instrtype^{'}$ ), there exists a substitution $σ$ , such that $σ (instrtype_{m i n})$ is a subtype of $instrtype^{'}$ (i.e., $C ⊢ σ (instrtype_{m i n}) \leq instrtype^{'}$ ). Furthermore, $instrtype_{m i n}$ is unique up to the choice of type variables.

Theorem (Closed Principal Forward Types). If closed input type $[t_{1}^{*}]$ is given and the instruction sequence $instr^{*}$ is valid with instruction type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ (i.e., $C ⊢ instr^{*} : [t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ ), then it is also valid with instruction type $[t_{1}^{*}] \to_{x^{*}} [α_{valtype^{*}} t^{*}]$ (i.e., $C ⊢ instr^{*} : [t_{1}^{*}] \to_{x^{*}} [α_{valtype^{*}} t^{*}]$ ), where all $t^{*}$ are closed, such that for every closed result type $[t ’_{2}^{*}]$ with which $instr^{*}$ is valid (i.e., for all $C ⊢ instr^{*} : [t_{1}^{*}] \to_{x^{*}} [t ’_{2}^{*}]$ ), there exists a substitution $σ$ , such that $[t ’_{2}^{*}] = [σ (α_{valtype^{*}}) t^{*}]$ .

Type Lattice

The Principal Types property depends on the existence of a greatest lower bound for any pair of types.

Theorem (Greatest Lower Bounds for Value Types). For any two value types $t_{1}$ and $t_{2}$ that are valid (i.e., $C ⊢ t_{1} ok$ and $C ⊢ t_{2} ok$ ), there exists a valid value type $t$ that is a subtype of both $t_{1}$ and $t_{2}$ (i.e., $C ⊢ t ok$ and $C ⊢ t \leq t_{1}$ and $C ⊢ t \leq t_{2}$ ), such that every valid value type $t^{'}$ that also is a subtype of both $t_{1}$ and $t_{2}$ (i.e., for all $C ⊢ t^{'} ok$ and $C ⊢ t^{'} \leq t_{1}$ and $C ⊢ t^{'} \leq t_{2}$ ), is a subtype of $t$ (i.e., $C ⊢ t^{'} \leq t$ ).

Note

The greatest lower bound of two types may be $bot$ .

Theorem (Conditional Least Upper Bounds for Value Types). Any two value types $t_{1}$ and $t_{2}$ that are valid (i.e., $C ⊢ t_{1} ok$ and $C ⊢ t_{2} ok$ ) either have no common supertype, or there exists a valid value type $t$ that is a supertype of both $t_{1}$ and $t_{2}$ (i.e., $C ⊢ t ok$ and $C ⊢ t_{1} \leq t$ and $C ⊢ t_{2} \leq t$ ), such that every valid value type $t^{'}$ that also is a supertype of both $t_{1}$ and $t_{2}$ (i.e., for all $C ⊢ t^{'} ok$ and $C ⊢ t_{1} \leq t^{'}$ and $C ⊢ t_{2} \leq t^{'}$ ), is a supertype of $t$ (i.e., $C ⊢ t \leq t^{'}$ ).

Note

If a top type was added to the type system, a least upper bound would exist for any two types.

Corollary (Type Lattice). Assuming the addition of a provisional top type, value types form a lattice with respect to their subtype relation.

Finally, value types can be partitioned into multiple disjoint hierarchies that are not related by subtyping, except through $bot$ .

Theorem (Disjoint Subtype Hierarchies). The greatest lower bound of two value types is $bot$ or $ref bot$ if and only if they do not have a least upper bound.

In other words, types that do not have common supertypes, do not have common subtypes either (other than $bot$ or $ref bot$ ), and vice versa.

Note

Types from disjoint hierarchies can safely be represented in mutually incompatible ways in an implementation, because their values can never flow to the same place.

Compositionality

Valid instruction sequences can be freely composed, as long as their types match up.

Theorem (Composition). If two instruction sequences $instr_{1}^{*}$ and $instr_{2}^{*}$ are valid with types $[t_{1}^{*}] \to_{x_{1}^{*}} [t^{*}]$ and $[t^{*}] \to_{x_{2}^{*}} [t_{2}^{*}]$ , respectively (i.e., $C ⊢ instr_{1}^{*} : [t_{1}^{*}] \to_{x_{1}^{*}} [t^{*}]$ and $C ⊢ instr_{1}^{*} : [t^{*}] \to_{x_{2}^{*}} [t_{2}^{*}]$ ), then the concatenated instruction sequence $(instr_{1}^{*} instr_{2}^{*})$ is valid with type $[t_{1}^{*}] \to_{x_{1}^{*} x_{2}^{*}} [t_{2}^{*}]$ (i.e., $C ⊢ instr_{1}^{*} instr_{2}^{*} : [t_{1}^{*}] \to_{x_{1}^{*} x_{2}^{*}} [t_{2}^{*}]$ ).

Note

More generally, instead of a shared type $[t^{*}]$ , it suffices if the output type of $instr_{1}^{*}$ is a subtype of the input type of $instr_{1}^{*}$ , since the subtype can always be weakened to its supertype by subsumption.

Inversely, valid instruction sequences can also freely be decomposed, that is, splitting them anywhere produces two instruction sequences that are both valid.

Theorem (Decomposition). If an instruction sequence $instr^{*}$ that is valid with type $[t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ (i.e., $C ⊢ instr^{*} : [t_{1}^{*}] \to_{x^{*}} [t_{2}^{*}]$ ) is split into two instruction sequences $instr_{1}^{*}$ and $instr_{2}^{*}$ at any point (i.e., $instr^{*} = instr_{1}^{*} instr_{2}^{*}$ ), then these are separately valid with some types $[t_{1}^{*}] \to_{x_{1}^{*}} [t^{*}]$ and $[t^{*}] \to_{x_{2}^{*}} [t_{2}^{*}]$ , respectively (i.e., $C ⊢ instr_{1}^{*} : [t_{1}^{*}] \to_{x_{1}^{*}} [t^{*}]$ and $C ⊢ instr_{1}^{*} : [t^{*}] \to_{x_{2}^{*}} [t_{2}^{*}]$ ), where $x^{*} = x_{1}^{*} x_{2}^{*}$ .

Note

This property holds because validation is required even for unreachable code. Without that, $instr_{2}^{*}$ might not be valid in isolation.

A.4 Validation Algorithm

The specification of WebAssembly validation is purely declarative. It describes the constraints that must be met by a module or instruction sequence to be valid.

This section sketches the skeleton of a sound and complete algorithm for effectively validating code, i.e., sequences of instructions. (Other aspects of validation are straightforward to implement.)

In fact, the algorithm is expressed over the flat sequence of opcodes as occurring in the binary format, and performs only a single pass over it. Consequently, it can be integrated directly into a decoder.

The algorithm is expressed in typed pseudo code whose semantics is intended to be self-explanatory.

Data Structures

Types

Value types are representable as sets of enumerations:

type num_type = I32 | I64 | F32 | F64type vec_type = V128
type heap_type =
  Any | Eq | I31 | Struct | Array | None |
  Func | Nofunc | Exn | Noexn | Extern | Noextern | Bot |
  Def(def : def_type)
type ref_type = Ref(heap : heap_type, null : bool)
type val_type = num_type | vec_type | ref_type | Bot

func is_num(t : val_type) : bool =
  return t = I32 || t = I64 || t = F32 || t = F64 || t = Bot

func is_vec(t : val_type) : bool =
  return t = V128 || t = Bot

func is_ref(t : val_type) : bool =
  return not (is_num t || is_vec t) || t = Bot

          

Similarly, defined types def_type can be represented:

type packed_type = I8 | I16type field_type = Field(val : val_type | packed_type, mut : bool)

type struct_type = Struct(fields : list(field_type))
type array_type = Array(fields : field_type)
type func_type = Func(params : list(val_type), results : list(val_type))
type comp_type = struct_type | array_type | func_type

type sub_type = Sub(super : list(def_type), body : comp_type, final : bool)
type rec_type = Rec(types : list(sub_type))

type def_type = Def(rec : rec_type, proj : int32)

func unpack_field(t : field_type) : val_type =
  if (it = I8 || t = I16) return I32
  return t

func expand_def(t : def_type) : comp_type =
  return t.rec.types[t.proj].body

          

These representations assume that all types have been closed by substituting all type indices (in concrete heap types and in sub types) with their respective defined types. This includes recursive references to enclosing defined types, such that type representations form graphs and may be cyclic for recursive types.

We assume that all types have been canonicalized, such that equality on two type representations holds if and only if their closures are syntactically equivalent, making it a constant-time check.

Note

For the purpose of type canonicalization, recursive references from a heap type to an enclosing recursive type (i.e., forward edges in the graph that form a cycle) need to be distinguished from references to previously defined types. However, this distinction does not otherwise affect validation, so is ignored here. In the graph representation, all recursive types are effectively infinitely unrolled.

We further assume that validation and subtyping checks are defined on value types, as well as a few auxiliary functions on composite types:

func validate_val_type(t : val_type)func validate_ref_type(t : ref_type)

func matches_val(t1 : val_type, t2 : val_type) : bool
func matches_ref(t1 : val_type, t2 : val_type) : bool

func is_func(t : comp_type) : bool
func is_struct(t : comp_type) : bool
func is_array(t : comp_type) : bool

          

Finally, the following function computes the least precise supertype of a given heap type (its corresponding top type):

func top_heap_type(t : heap_type) : heap_type =switch (t)
  case (Any | Eq | I31 | Struct | Array | None)
    return Any
  case (Func | Nofunc)
    return Func
  case (Extern | Noextern)
    return Extern
  case (Def(dt))
    switch (dt.rec.types[dt.proj].body)
      case (Struct(_) | Array(_))
        return Any
      case (Func(_))
        return Func
  case (Bot)
    raise CannotOccurInSource

          

Context

Validation requires a context for checking uses of indices. For the purpose of presenting the algorithm, it is maintained in a set of global variables:

var return_type : list(val_type)var types : array(def_type)
var locals : array(val_type)
var locals_init : array(bool)
var globals : array(global_type)
var funcs : array(func_type)
var tables : array(table_type)
var mems : array(mem_type)

          

This assumes suitable representations for the various types besides val_type, which are omitted here.

For locals, there is an additional array recording the initialization status of each local.

Stacks

The algorithm uses three separate stacks: the value stack, the control stack, and the initialization stack. The value stack tracks the types of operand values on the stack. The control stack tracks surrounding structured control instructions and their associated blocks. The initialization stack records all locals that have been initialized since the beginning of the function.

type val_stack = stack(val_type)type init_stack = stack(u32)

type ctrl_stack = stack(ctrl_frame)
type ctrl_frame = {
  opcode : opcode
  start_types : list(val_type)
  end_types : list(val_type)
  val_height : nat
  init_height : nat
  unreachable : bool
}

          

For each entered block, the control stack records a control frame with the originating opcode, the types on the top of the operand stack at the start and end of the block (used to check its result as well as branches), the height of the operand stack at the start of the block (used to check that operands do not underflow the current block), the height of the initialization stack at the start of the block (used to reset initialization status at the end of the block), and a flag recording whether the remainder of the block is unreachable (used to handle stack-polymorphic typing after branches).

For the purpose of presenting the algorithm, these stacks are simply maintained as global variables:

var vals : val_stackvar inits : init_stack
var ctrls : ctrl_stack

However, these variables are not manipulated directly by the main checking function, but through a set of auxiliary functions:

func push_val(type : val_type) =  vals.push(type)

func pop_val() : val_type =
  if (vals.size() = ctrls[0].height && ctrls[0].unreachable) return Bot
  error_if(vals.size() = ctrls[0].height)
  return vals.pop()

func pop_val(expect : val_type) : val_type =
  let actual = pop_val()
  error_if(not matches_val(actual, expect))
  return actual

func pop_num() : num_type | Bot =
  let actual = pop_val()
  error_if(not is_num(actual))
  return actual

func pop_ref() : ref_type =
  let actual = pop_val()
  error_if(not is_ref(actual))
  if (actual = Bot) return Ref(Bot, false)
  return actual

func push_vals(types : list(val_type)) = foreach (t in types) push_val(t)
func pop_vals(types : list(val_type)) : list(val_type) =
  var popped := []
  foreach (t in reverse(types)) popped.prepend(pop_val(t))
  return popped

          

Pushing an operand value simply pushes the respective type to the value stack.

Popping an operand value checks that the value stack does not underflow the current block and then removes one type. But first, a special case is handled where the block contains no known values, but has been marked as unreachable. That can occur after an unconditional branch, when the stack is typed polymorphically. In that case, the Bot type is returned, because that is a principal choice trivially satisfying all use constraints.

A second function for popping an operand value takes an expected type, which the actual operand type is checked against. The types may differ by subtyping, including the case where the actual type is Bot, and thereby matches unconditionally. The function returns the actual type popped from the stack.

Finally, there are accumulative functions for pushing or popping multiple operand types.

Note

The notation stack[i] is meant to index the stack from the top, so that, e.g., ctrls[0] accesses the element pushed last.

The initialization stack and the initialization status of locals is manipulated through the following functions:

func get_local(idx : u32) =  error_if(not locals_init[idx])

func set_local(idx : u32) =
  if (not locals_init[idx])
    inits.push(idx)
    locals_init[idx] := true

func reset_locals(height : nat) =
  while (inits.size() > height)
    locals_init[inits.pop()] := false

          

Getting a local verifies that it is known to be initialized. When a local is set that was not set already, then its initialization status is updated and the change is recorded in the initialization stack. Thus, the initialization status of all locals can be reset to a previous state by denoting a specific height in the initialization stack.

The size of the initialization stack is bounded by the number of (non-defaultable) locals in a function, so can be preallocated by an algorithm.

The control stack is likewise manipulated through auxiliary functions:

func push_ctrl(opcode : opcode, in : list(val_type), out : list(val_type)) =  let frame = ctrl_frame(opcode, in, out, vals.size(), inits.size(), false)
  ctrls.push(frame)
  push_vals(in)

func pop_ctrl() : ctrl_frame =
  error_if(ctrls.is_empty())
  let frame = ctrls[0]
  pop_vals(frame.end_types)
  error_if(vals.size() =/= frame.val_height)
  reset_locals(frame.init_height)
  ctrls.pop()
  return frame

func label_types(frame : ctrl_frame) : list(val_types) =
  return (if (frame.opcode = loop) frame.start_types else frame.end_types)

func unreachable() =
  vals.resize(ctrls[0].height)
  ctrls[0].unreachable := true

          

Pushing a control frame takes the types of the label and result values. It allocates a new frame record recording them along with the current height of the operand stack and marks the block as reachable.

Popping a frame first checks that the control stack is not empty. It then verifies that the operand stack contains the right types of values expected at the end of the exited block and pops them off the operand stack. Afterwards, it checks that the stack has shrunk back to its initial height. Finally, it undoes all changes to the initialization status of locals that happend inside the block.

The type of the label associated with a control frame is either that of the stack at the start or the end of the frame, determined by the opcode that it originates from.

Finally, the current frame can be marked as unreachable. In that case, all existing operand types are purged from the value stack, in order to allow for the stack-polymorphism logic in pop_val to take effect. Because every function has an implicit outermost label that corresponds to an implicit block frame, it is an invariant of the validation algorithm that there always is at least one frame on the control stack when validating an instruction, and hence, ctrls[0] is always defined.

Note

Even with the unreachable flag set, consecutive operands are still pushed to and popped from the operand stack. That is necessary to detect invalid examples like $(unreachable (i32 . const) i64 . add)$ . However, a polymorphic stack cannot underflow, but instead generates Bot types as needed.

Validation of Opcode Sequences

The following function shows the validation of a number of representative instructions that manipulate the stack. Other instructions are checked in a similar manner.

func validate(opcode) =switch (opcode)
  case (i32.add)
    pop_val(I32)
    pop_val(I32)
    push_val(I32)

  case (drop)
    pop_val()

  case (select)
    pop_val(I32)
    let t1 = pop_val()
    let t2 = pop_val()
    error_if(not (is_num(t1) && is_num(t2) || is_vec(t1) && is_vec(t2)))
    error_if(t1 =/= t2 && t1 =/= Bot && t2 =/= Bot)
    push_val(if (t1 = Bot) t2 else t1)

  case (select t)
    pop_val(I32)
    pop_val(t)
    pop_val(t)
    push_val(t)

  case (ref.is_null)
    pop_ref()
    push_val(I32)

  case (ref.as_non_null)
    let rt = pop_ref()
    push_val(Ref(rt.heap, false))

  case (ref.test rt)
    validate_ref_type(rt)
    pop_val(Ref(top_heap_type(rt), true))
    push_val(I32)

  case (local.get x)
    get_local(x)
    push_val(locals[x])

  case (local.set x)
    pop_val(locals[x])
    set_local(x)

  case (unreachable)
    unreachable()

  case (block t1*->t2*)
    pop_vals([t1*])
    push_ctrl(block, [t1*], [t2*])

  case (loop t1*->t2*)
    pop_vals([t1*])
    push_ctrl(loop, [t1*], [t2*])

  case (if t1*->t2*)
    pop_val(I32)
    pop_vals([t1*])
    push_ctrl(if, [t1*], [t2*])

  case (end)
    let frame = pop_ctrl()
    push_vals(frame.end_types)

  case (else)
    let frame = pop_ctrl()
    error_if(frame.opcode =/= if)
    push_ctrl(else, frame.start_types, frame.end_types)

  case (br n)
    error_if(ctrls.size() < n)
    pop_vals(label_types(ctrls[n]))
    unreachable()

  case (br_if n)
    error_if(ctrls.size() < n)
    pop_val(I32)
    pop_vals(label_types(ctrls[n]))
    push_vals(label_types(ctrls[n]))

  case (br_table n* m)
    pop_val(I32)
    error_if(ctrls.size() < m)
    let arity = label_types(ctrls[m]).size()
    foreach (n in n*)
      error_if(ctrls.size() < n)
      error_if(label_types(ctrls[n]).size() =/= arity)
      push_vals(pop_vals(label_types(ctrls[n])))
    pop_vals(label_types(ctrls[m]))
    unreachable()

  case (br_on_null n)
    error_if(ctrls.size() < n)
    let rt = pop_ref()
    pop_vals(label_types(ctrls[n]))
    push_vals(label_types(ctrls[n]))
    push_val(Ref(rt.heap, false))

  case (br_on_cast n rt1 rt2)
    validate_ref_type(rt1)
    validate_ref_type(rt2)
    pop_val(rt1)
    push_val(rt2)
    pop_vals(label_types(ctrls[n]))
    push_vals(label_types(ctrls[n]))
    pop_val(rt2)
    push_val(diff_ref_type(rt2, rt1))

  case (return)
    pop_vals(return_types)
    unreachable()

  case (call_ref x)
    let t = expand_def(types[x])
    error_if(not is_func(t))
    pop_vals(t.params)
    pop_val(Ref(Def(types[x])))
    push_vals(t.results)

  case (return_call_ref x)
    let t = expand_def(types[x])
    error_if(not is_func(t))
    pop_vals(t.params)
    pop_val(Ref(Def(types[x])))
    error_if(t.results.len() =/= return_types.len())
    push_vals(t.results)
    pop_vals(return_types)
    unreachable()

  case (struct.new x)
    let t = expand_def(types[x])
    error_if(not is_struct(t))
    for (ti in reverse(t.fields))
      pop_val(unpack_field(ti))
    push_val(Ref(Def(types[x])))

  case (struct.set x n)
    let t = expand_def(types[x])
    error_if(not is_struct(t) || n >= t.fields.len())
    pop_val(Ref(Def(types[x])))
    pop_val(unpack_field(st.fields[n]))

  case (throw x)
     pop_vals(tags[x].type.params)
     unreachable()

  case (try_table t1*->t2* handler*)
    pop_vals([t1*])
    foreach (handler in handler*)
      error_if(ctrls.size() < handler.label)
      push_ctrl(catch, [], label_types(ctrls[handler.label]))
      switch (handler.clause)
        case (catch x)
          push_vals(tags[x].type.params)
        case (catch_ref x)
          push_vals(tags[x].type.params)
          push_val(Exnref)
        case (catch_all)
          skip
        case (catch_all_ref)
          push_val(Exnref)
      pop_ctrl()
    push_ctrl(try_table, [t1*], [t2*])

         

Note

It is an invariant under the current WebAssembly instruction set that an operand of Bot type is never duplicated on the stack. This would change if the language were extended with stack instructions like dup. Under such an extension, the above algorithm would need to be refined by replacing the Bot type with proper type variables to ensure that all uses are consistent.

Custom Sections and Annotations

This appendix defines dedicated custom sections for WebAssembly’s binary format and annotations for the text format. Such sections or annotations do not contribute to, or otherwise affect, the WebAssembly semantics, and may be ignored by an implementation. However, they provide useful meta data that implementations can make use of to improve user experience or take compilation hints.

Name Section

The name section is a custom section whose name string is itself $‘ name ’$ . The name section should appear only once in a module, and only after the data section.

The purpose of this section is to attach printable names to definitions in a module, which e.g. can be used by a debugger or when parts of the module are to be rendered in text form.

Note

All names are represented in [UNICODE] encoded in UTF-8. Names need not be unique.

Subsections

The data of a name section consists of a sequence of subsections. Each subsection consists of a

a one-byte subsection id,
the $u32$ size of the contents, in bytes,
the actual contents, whose structure is dependent on the subsection id.

namesec namedata namesubsection_{N} (B) ::= ::= ::= section_{0} (namedata) n : name modulenamesubsec^{?} funcnamesubsec^{?} localnamesubsec^{?} typenamesubsec^{?} fieldnamesubsec^{?} tagnamesubsec^{?} N : byte size : u 32 B (if n = ‘ name ’) (if size = ∣∣ B ∣∣)

The following subsection ids are used:

Id	Subsection
0	module name
1	function names
2	local names
4	type names
10	field names
11	tag names

Each subsection may occur at most once, and in order of increasing id.

Name Maps

A name map assigns names to indices in a given index space. It consists of a vector of index/name pairs in order of increasing index value. Each index must be unique, but the assigned names need not be.

namemap nameassoc ::= ::= vec (nameassoc) idx name

An indirect name map assigns names to a two-dimensional index space, where secondary indices are grouped by primary indices. It consists of a vector of primary index/name map pairs in order of increasing index value, where each name map in turn maps secondary indices to names. Each primary index must be unique, and likewise each secondary index per individual name map.

indirectnamemap indirectnameassoc ::= ::= vec (indirectnameassoc) idx namemap

Module Names

The module name subsection has the id 0. It simply consists of a single name that is assigned to the module itself.

modulenamesubsec ::= namesubsection_{0} (name)

Function Names

The function name subsection has the id 1. It consists of a name map assigning function names to function indices.

funcnamesubsec ::= namesubsection_{1} (namemap)

Local Names

The local name subsection has the id 2. It consists of an indirect name map assigning local names to local indices grouped by function indices.

localnamesubsec ::= namesubsection_{2} (indirectnamemap)

Type Names

The type name subsection has the id 4. It consists of a name map assigning type names to type indices.

typenamesubsec ::= namesubsection_{4} (namemap)

Field Names

The field name subsection has the id 10. It consists of an indirect name map assigning field names to field indices grouped by the type indices of their respective structure types.

fieldnamesubsec ::= namesubsection_{1} 0 (indirectnamemap)

Tag Names

The tag name subsection has the id 11. It consists of a name map assigning tag names to tag indices.

tagnamesubsec ::= namesubsection_{1} (namemap)

Name Annotations

Name annotations are the textual analogue to the name section and provide a textual representation for it. Consequently, their id is $@name$ .

Analogous to the name section, name annotations are allowed on modules, functions, and locals (including parameters). They can be placed where the text format allows binding occurrences of respective identifiers. If both an identifier and a name annotation are given, the annotation is expected after the identifier. In that case, the annotation takes precedence over the identifier as a textual representation of the binding’s name. At most one name annotation may be given per binding.

All name annotations have the following format:

nameannot ::= ‘ (@name ’ string ‘) ’

Note

All name annotations can be arbitrary UTF-8 strings. Names need not be unique.

Module Names

A module name annotation must be placed on a module definition, directly after the $‘ module ’$ keyword, or if present, after the following module identifier.

modulenameannot ::= nameannot

Function Names

A function name annotation must be placed on a function definition or function import, directly after the $‘ func ’$ keyword, or if present, after the following function identifier or.

funcnameannot ::= nameannot

Parameter Names

A parameter name annotation must be placed on a parameter declaration, directly after the $‘ param ’$ keyword, or if present, after the following parameter identifier. It may only be placed on a declaration that declares exactly one parameter.

paramnameannot ::= nameannot

Local Names

A local name annotation must be placed on a local declaration, directly after the $‘ local ’$ keyword, or if present, after the following local identifier. It may only be placed on a declaration that declares exactly one local.

localnameannot ::= nameannot

Type Names

A type name annotation must be placed on a type declaration, directly after the $‘ type ’$ keyword, or if present, after the following type identifier.

typenameannot ::= nameannot

Field Names

A field name annotation must be placed on the field of a structure type, directly after the $‘ field ’$ keyword, or if present, after the following field identifier. It may only be placed on a declaration that declares exactly one field.

fieldnameannot ::= nameannot

Tag Names

A tag name annotation must be placed on a tag declaration or tag import, directly after the $‘ tag ’$ keyword, or if present, after the following tag identifier.

tagnameannot ::= nameannot

Custom Annotations

Custom annotations are a generic textual representation for any custom section. Their id is $@custom$ . By generating custom annotations, tools converting between binary format and text format can maintain and round-trip the content of custom sections even when they do not recognize them.

Custom annotations must be placed inside a module definition. They must occur anywhere after the $‘ module ’$ keyword, or if present, after the following module identifier. They must not be nested into other constructs.

customannot customplace sec ::= ::= ∣ ∣ ∣ ::= ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ∣ ‘ (@custom ’ string customplace^{?} datastring ‘) ’ ‘ (’ ‘ before ’ ‘ first ’ ‘) ’ ‘ (’ ‘ before ’ sec ‘) ’ ‘ (’ ‘ after ’ sec ‘) ’ ‘ (’ ‘ after ’ ‘ last ’ ‘) ’ ‘ type ’ ‘ import ’ ‘ func ’ ‘ table ’ ‘ memory ’ ‘ global ’ ‘ export ’ ‘ start ’ ‘ elem ’ ‘ code ’ ‘ data ’ ‘ datacount ’

The first string in a custom annotation denotes the name of the custom section it represents. The remaining strings collectively represent the section’s payload data, written as a data string, which can be split up into a possibly empty sequence of individual string literals (similar to data segments).

An arbitrary number of custom annotations (even of the same name) may occur in a module, each defining a separate custom section when converting to binary format. Placement of the sections in the binary can be customized via explicit placement directives, that position them either directly before or directly after a known section. That section must exist and be non-empty in the binary encoding of the annotated module. The placements $(before first)$ and $(after last)$ denote virtual sections before the first and after the last known section, respectively. When the placement directive is omitted, it defaults to $(after last)$ .

If multiple placement directives appear for the same position, then the sections are all placed there, in order of their appearance in the text. For this purpose, the position $after$ a section is considered different from the position $before$ the consecutive section, and the former occurs before the latter.

Note

Future versions of WebAssembly may introduce additional sections between others or at the beginning or end of a module. Using $first$ and $last$ guarantees that placement will still go before or after any future section, respectively.

If a custom section with a specific section id is given as well as annotations representing the same custom section (e.g., $@name$ annotations as well as a $@custom$ annotation for a $name$ section), then two sections are assumed to be created. Their relative placement will depend on the placement directive given for the $@custom$ annotation as well as the implicit placement requirements of the custom section, which are applied to the other annotation.

Note

For example, the following module,

(module  (@custom "A" "aaa")
  (type $t (func))
  (@custom "B" (after func) "bbb")
  (@custom "C" (before func) "ccc")
  (@custom "D" (after last) "ddd")
  (table 10 funcref)
  (func (type $t))
  (@custom "E" (after import) "eee")
  (@custom "F" (before type) "fff")
  (@custom "G" (after data) "ggg")
  (@custom "H" (after code) "hhh")
  (@custom "I" (after func) "iii")
  (@custom "J" (before func) "jjj")
  (@custom "K" (before first) "kkk")
)

          

will result in the following section ordering:

custom section "K"custom section "F"
type section
custom section "E"
custom section "C"
custom section "J"
function section
custom section "B"
custom section "I"
table section
code section
custom section "H"
custom section "G"
custom section "A"
custom section "D"

          

Change History

Since the original release 1.0 of the WebAssembly specification, a number of proposals for extensions have been integrated. The following sections provide an overview of what has changed.

Release 2.0

Sign Extension Instructions

Added new numeric instructions for performing sign extension within integer representations. [1]

New numeric instructions:
- $i nn . extend N_s$

Non-trapping Float-to-Int Conversions

Added new conversion instructions that avoid trapping when converting a floating-point number to an integer. [2]

New numeric instructions:
- $i nn . trunc_sat_f mm_sx$

Multiple Values

Generalized the result type of blocks and functions to allow for multiple values; in addition, introduced the ability to have block parameters. [3]

Function types allow more than one result
Block types can be arbitrary function types

Reference Types

Added $funcref$ and $externref$ as new value types and respective instructions. [4]

New reference value types:
- $funcref$
- $externref$
New reference instructions:
- $ref.null$
- $ref.func$
- $ref.is_null$
Extended parametric instruction:
- $select$ with optional type immediate
New declarative form of element segment

Table Instructions

Added instructions to directly access and modify tables. [4]

Table types allow any reference type as element type
New table instructions:
- $table.get$
- $table.set$
- $table.size$
- $table.grow$

Multiple Tables

Added the ability to use multiple tables per module. [4]

Modules may
- define multiple tables
- import multiple tables
- export multiple tables
Table instructions take a table index immediate:
- $table.get$
- $table.set$
- $table.size$
- $table.grow$
- $call_indirect$
Element segments take a table index

Bulk Memory and Table Instructions

Added instructions that modify ranges of memory or table entries. [4] [5]

New memory instructions:
- $memory.fill$
- $memory.init$
- $memory.copy$
- $data.drop$
New table instructions:
- $table.fill$
- $table.init$
- $table.copy$
- $elem.drop$
New passive form of data segment
New passive form of element segment
New data count section in binary format
Active data and element segments boundaries are no longer checked at compile time but may trap instead

Vector Instructions

Added vector type and instructions that manipulate multiple numeric values in parallel (also known as SIMD, single instruction multiple data) [6]

New value type:
- $v128$
New memory instructions:
- $v128. load$
- $v128. load N x M_sx$
- $v128. load N_zero$
- $v128. load N_splat$
- $v128. load N_lane$
- $v128. store$
- $v128. store N_lane$
New constant vector instruction:
- $v128. const$
New unary vector instructions:
- $v128.not$
- $i N x M .abs$
- $i N x M .neg$
- $i8x16.popcnt$
- $f N x M .abs$
- $f N x M .neg$
- $f N x M .sqrt$
- $f N x M .ceil$
- $f N x M .floor$
- $f N x M .trunc$
- $f N x M .nearest$
New binary vector instructions:
- $v128.and$
- $v128.andnot$
- $v128.or$
- $v128.xor$
- $i N x M .add$
- $i N x M .sub$
- $i N x M .mul$
- $i N x M .add_sat_sx$
- $i N x M .sub_sat_sx$
- $i N x M .min_sx$
- $i N x M .max_sx$
- $i N x M .shl$
- $i N x M .shr_sx$
- $f N x M .add$
- $f N x M .sub$
- $f N x M .mul$
- $f N x M .div$
- $i16x8.extadd_pairwise_i8x16_sx$
- $i32x4.extadd_pairwise_i16x8_sx$
- $i N x M .extmul_half_i N^{'} x M^{'}_sx$
- $i16x8.q15mulr_sat_s$
- $i32x4.dot_i16x8_s$
- $i8x16.avgr_u$
- $i16x8.avgr_u$
- $f N x M .min$
- $f N x M .max$
- $f N x M .pmin$
- $f N x M .pmax$
New ternary vector instruction:
- $v128.bitselect$
New test vector instructions:
- $v128.any_true$
- $i N x M .all_true$
New relational vector instructions:
- $i N x M .eq$
- $i N x M .ne$
- $i N x M .lt_sx$
- $i N x M .gt_sx$
- $i N x M .le_sx$
- $i N x M .ge_sx$
- $f N x M .eq$
- $f N x M .ne$
- $f N x M .lt$
- $f N x M .gt$
- $f N x M .le$
- $f N x M .ge$
New conversion vector instructions:
- $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$
New lane access vector instructions:
- $i N x M .extract_lane_sx^{?}$
- $i N x M .replace_lane$
- $f N x M .extract_lane$
- $f N x M .replace_lane$
New lane splitting/combining vector instructions:
- $i N x M .extend_half_i N^{'} x M^{'}_sx$
- $i8x16.narrow_i16x8_sx$
- $i16x8.narrow_i32x4_sx$
New byte reordering vector instructions:
- $i8x16.shuffle$
- $i8x16.swizzle$
New injection/projection vector instructions:
- $i N x M .splat$
- $f N x M .splat$
- $i N x M .bitmask$

Release 3.0

Extended Constant Expressions

Allowed basic numeric computations in constant expressions. [7]

Extended set of constant instructions with:
- $i nn .add$
- $i nn .sub$
- $i nn .mul$
- $global.get$ for any previously declared immutable global

Note

The garbage collection added further constant instructions.

Tail Calls

Added instructions to perform tail calls. [8]

New control instructions:
- $return_call$
- $return_call_indirect$

Exception Handling

Added tag definitions, imports, and exports, and instructions to throw and catch exceptions [9]

Modules may
- define tags
- import tags
- export tags
New heap types:
- $exn$
- $noexn$
New reference type short-hands:
- $exnref$
- $nullexnref$
New control instructions:
- $throw$
- $throw_ref$
- $try_table$
New tag section in binary format.

Multiple Memories

Added the ability to use multiple memories per module. [10]

Modules may
- define multiple memories
- import multiple memories
- export multiple memories
Memory instructions take a memory index immediate:
- $memory.size$
- $memory.grow$
- $memory.fill$
- $memory.copy$
- $memory.init$
- $t .load$
- $t .store$
- $t .load N_sx$
- $t .store N$
- $v128.load N x M_sx$
- $v128.load N_zero$
- $v128.load N_splat$
- $v128.load N_lane$
- $v128.store N_lane$
Data segments take a memory index

64-bit Address Space

Added the ability to declare an $i64$ address type for tables and memories. [11]

Address types denote a subset of the integral number types
Table types include an address type
Memory types include an address type
Operand types of table and memory instructions now depend on the subject’s declared address type:
- $table.get$
- $table.set$
- $table.size$
- $table.grow$
- $table.fill$
- $table.copy$
- $table.init$
- $memory.size$
- $memory.grow$
- $memory.fill$
- $memory.copy$
- $memory.init$
- $t .load$
- $t .store$
- $t .load N_sx$
- $t .store N$
- $v128.load N x M_sx$
- $v128.load N_zero$
- $v128.load N_splat$
- $v128.load N_lane$
- $v128.store N_lane$

Typeful References

Added more precise types for references. [12]

New generalised form of reference types:
- $(ref null^{?} heaptype)$
New class of heap types:
- $func$
- $extern$
- $typeidx$
Basic subtyping on reference and value types
New reference instructions:
- $ref.as_non_null$
- $br_on_null$
- $br_on_non_null$
New control instruction:
- $call_ref$
Refined typing of reference instruction:
- $ref.func$ with more precise result type
Refined typing of local instructions and instruction sequences to track the initialization status of locals with non-defaultable type
Extended table definitions with optional initializer expression

Garbage Collection

Added managed reference types. [13]

New forms of heap types:
- $any$
- $eq$
- $i31$
- $struct$
- $array$
- $none$
- $nofunc$
- $noextern$
New reference type short-hands:
- $anyref$
- $eqref$
- $i31ref$
- $structref$
- $arrayref$
- $nullref$
- $nullfuncref$
- $nullexternref$
New forms of type definitions:
Enriched subtyping based on explicitly declared sub types and the new heap types
New generic reference instructions:
- $ref.eq$
- $ref.test$
- $ref.cast$
- $br_on_cast$
- $br_on_cast_fail$
New reference instructions for unboxed scalars:
- $ref.i31$
- $i31.get_sx$
New reference instructions for structure types:
- $struct.new$
- $struct.new_default$
- $struct.get_sx^{?}$
- $struct.set$
New reference instructions for array types:
- $array.new$
- $array.new_default$
- $array.new_fixed$
- $array.new_data$
- $array.new_elem$
- $array.get_sx^{?}$
- $array.set$
- $array.len$
- $array.fill$
- $array.copy$
- $array.init_data$
- $array.init_elem$
New reference instructions for converting external types:
- $any.convert_extern$
- $extern.convert_any$
Extended set of constant instructions with:
- $ref.i31$
- $struct.new$
- $struct.new_default$
- $array.new$
- $array.new_default$
- $array.new_fixed$
- $any.convert_extern$
- $extern.convert_any$

Relaxed Vector Instructions

Added new relaxed vector instructions, whose behaviour is non-deterministic and implementation-dependent. [14]

New binary vector instruction:
- $f N x M .relaxed_min$
- $f N x M .relaxed_max$
- $i16x8.relaxed_q15mulr_s$
- $i16x8.relaxed_dot_i8x16_i7x16_s$
New ternary vector instruction:
- $f N x M .relaxed_madd$
- $f N x M .relaxed_nmadd$
- $i N x M .relaxed_laneselect$
- $i32x4.relaxed_dot_i8x16_i7x16_add_s$
New conversion vector instructions:
- $i32x4.relaxed_trunc_f32x4_sx$
- $i32x4.relaxed_trunc_f64x2_sx_zero$
New byte reordering vector instruction:
- $i8x16.relaxed_swizzle$

Profiles

Introduced the concept of profile for specifying language subsets.

A new profile defining a deterministic mode of execution.

Custom Annotations

Added generic syntax for custom annotations in the text format, mirroring the role of custom sections in the binary format. [15]

Annotations of the form $‘ (@id \dots) ’$ are allowed anywhere in the text format
Identifiers can be escaped as $‘ @" \dots " ’$ with arbitrary names
Defined name annotations $‘ (@name " \dots ") ’$ for:
Defined custom annotation $‘ (@custom " \dots ") ’$ to represent arbitrary custom sections in the text format

A.8 Index of Types

Category	Constructor	Binary Opcode
Type index	$x$	(positive number as $s 32$ or $u 32$ )
Number type	$i32$	$0x 7F$ (-1 as $s 7$ )
Number type	$i64$	$0x 7E$ (-2 as $s 7$ )
Number type	$f32$	$0x 7D$ (-3 as $s 7$ )
Number type	$f64$	$0x 7C$ (-4 as $s 7$ )
Vector type	$v128$	$0x 7B$ (-5 as $s 7$ )
(reserved)		$0x 7A$ .. $0x 79$
Packed type	$i8$	$0x 78$ (-8 as $s 7$ )
Packed type	$i16$	$0x 77$ (-9 as $s 7$ )
(reserved)		$0x 78$ .. $0x 75$
Heap type	$noexn$	$0x 74$ (-14 as $s 7$ )
Heap type	$nofunc$	$0x 73$ (-13 as $s 7$ )
Heap type	$noextern$	$0x 72$ (-14 as $s 7$ )
Heap type	$none$	$0x 71$ (-15 as $s 7$ )
Heap type	$func$	$0x 70$ (-16 as $s 7$ )
Heap type	$extern$	$0x 6F$ (-17 as $s 7$ )
Heap type	$any$	$0x 6E$ (-18 as $s 7$ )
Heap type	$eq$	$0x 6D$ (-19 as $s 7$ )
Heap type	$i31$	$0x 6C$ (-20 as $s 7$ )
Heap type	$struct$	$0x 6B$ (-21 as $s 7$ )
Heap type	$array$	$0x 6A$ (-22 as $s 7$ )
Heap type	$exn$	$0x 69$ (-23 as $s 7$ )
(reserved)		$0x 68$ .. $0x 65$
Reference type	$ref$	$0x 64$ (-28 as $s 7$ )
Reference type	$ref$ $null$	$0x 63$ (-29 as $s 7$ )
(reserved)		$0x 62$ .. $0x 61$
Composite type	$func [valtype^{}] \to [valtype^{}]$	$0x 60$ (-32 as $s 7$ )
Composite type	$struct fieldtype^{*}$	$0x 5F$ (-33 as $s 7$ )
Composite type	$array fieldtype$	$0x 5E$ (-34 as $s 7$ )
(reserved)		$0x 5D$ .. $0x 51$
Sub type	$sub typeidx^{*} comptype$	$0x 50$ (-48 as $s 7$ )
Sub type	$sub final typeidx^{*} comptype$	$0x 4F$ (-49 as $s 7$ )
Recursive type	$rec subtype^{*}$	$0x 4E$ (-50 as $s 7$ )
(reserved)		$0x 4D$ .. $0x 41$
Result type	$[ϵ]$	$0x 40$ (-64 as $s 7$ )
Table type	$limits reftype$	(none)
Memory type	$limits$	(none)
Global type	$mut valtype$	(none)
Tag type	$functype$	(none)

A.9 Index of Instructions

Instruction	Binary Opcode	Type	Validation	Execution
$unreachable$	$0x 00$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$nop$	$0x 01$	$[] \to []$	validation	execution
$block bt$	$0x 02$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$loop bt$	$0x 03$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$if bt$	$0x 04$	$[t_{1}^{} i32] \to [t_{2}^{}]$	validation	execution
$else$	$0x 05$
(reserved)	$0x 06$
(reserved)	$0x 07$
$throw x$	$0x 08$	$[t_{1}^{} t_{x}^{}] \to [t_{2}^{*}]$	validation	execution
(reserved)	$0x 09$
$throw_ref$	$0x 0A$	$[t_{1}^{} exnref] \to [t_{2}^{}]$	validation	execution
$end$	$0x 0B$
$br l$	$0x 0C$	$[t_{1}^{} t^{}] \to [t_{2}^{*}]$	validation	execution
$br_if l$	$0x 0D$	$[t^{} i32] \to [t^{}]$	validation	execution
$br_table l^{*} l$	$0x 0E$	$[t_{1}^{} t^{} i32] \to [t_{2}^{*}]$	validation	execution
$return$	$0x 0F$	$[t_{1}^{} t^{}] \to [t_{2}^{*}]$	validation	execution
$call x$	$0x 10$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$call_indirect x y$	$0x 11$	$[t_{1}^{} i32] \to [t_{2}^{}]$	validation	execution
$return_call x$	$0x 12$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$return_call_indirect x y$	$0x 13$	$[t_{1}^{} i32] \to [t_{2}^{}]$	validation	execution
$call_ref x$	$0x 14$	$[t_{1}^{} (ref null x)] \to [t_{2}^{}]$	validation	execution
$return_call_ref x$	$0x 15$	$[t_{1}^{} (ref null x)] \to [t_{2}^{}]$	validation	execution
(reserved)	$0x 16$
(reserved)	$0x 17$
(reserved)	$0x 18$
(reserved)	$0x 19$
$drop$	$0x 1A$	$[t] \to []$	validation	execution
$select$	$0x 1B$	$[t t i32] \to [t]$	validation	execution
$select t$	$0x 1C$	$[t t i32] \to [t]$	validation	execution
(reserved)	$0x 1D$
(reserved)	$0x 1E$
$try_table bt$	$0x 1F$	$[t_{1}^{}] \to [t_{2}^{}]$	validation	execution
$local.get x$	$0x 20$	$[] \to [t]$	validation	execution
$local.set x$	$0x 21$	$[t] \to []$	validation	execution
$local.tee x$	$0x 22$	$[t] \to [t]$	validation	execution
$global.get x$	$0x 23$	$[] \to [t]$	validation	execution
$global.set x$	$0x 24$	$[t] \to []$	validation	execution
$table.get x$	$0x 25$	$[i32] \to [t]$	validation	execution
$table.set x$	$0x 26$	$[i32 t] \to []$	validation	execution
(reserved)	$0x 27$
$i32 . load x memarg$	$0x 28$	$[i32] \to [i32]$	validation	execution
$i64 . load x memarg$	$0x 29$	$[i32] \to [i64]$	validation	execution
$f32 . load x memarg$	$0x 2A$	$[i32] \to [f32]$	validation	execution
$f64 . load x memarg$	$0x 2B$	$[i32] \to [f64]$	validation	execution
$i32 . load 8_s x memarg$	$0x 2C$	$[i32] \to [i32]$	validation	execution
$i32 . load 8_u x memarg$	$0x 2D$	$[i32] \to [i32]$	validation	execution
$i32 . load 16_s x memarg$	$0x 2E$	$[i32] \to [i32]$	validation	execution
$i32 . load 16_u x memarg$	$0x 2F$	$[i32] \to [i32]$	validation	execution
$i64 . load 8_s x memarg$	$0x 30$	$[i32] \to [i64]$	validation	execution
$i64 . load 8_u x memarg$	$0x 31$	$[i32] \to [i64]$	validation	execution
$i64 . load 16_s x memarg$	$0x 32$	$[i32] \to [i64]$	validation	execution
$i64 . load 16_u x memarg$	$0x 33$	$[i32] \to [i64]$	validation	execution
$i64 . load 32_s x memarg$	$0x 34$	$[i32] \to [i64]$	validation	execution
$i64 . load 32_u x memarg$	$0x 35$	$[i32] \to [i64]$	validation	execution
$i32 . store x memarg$	$0x 36$	$[i32 i32] \to []$	validation	execution
$i64 . store x memarg$	$0x 37$	$[i32 i64] \to []$	validation	execution
$f32 . store x memarg$	$0x 38$	$[i32 f32] \to []$	validation	execution
$f64 . store x memarg$	$0x 39$	$[i32 f64] \to []$	validation	execution
$i32 . store 8 x memarg$	$0x 3A$	$[i32 i32] \to []$	validation	execution
$i32 . store 16 x memarg$	$0x 3B$	$[i32 i32] \to []$	validation	execution
$i64 . store 8 x memarg$	$0x 3C$	$[i32 i64] \to []$	validation	execution
$i64 . store 16 x memarg$	$0x 3D$	$[i32 i64] \to []$	validation	execution
$i64 . store 32 x memarg$	$0x 3E$	$[i32 i64] \to []$	validation	execution
$memory.size x$	$0x 3F$	$[] \to [i32]$	validation	execution
$memory.grow x$	$0x 40$	$[i32] \to [i32]$	validation	execution
$i32 . const i32$	$0x 41$	$[] \to [i32]$	validation	execution
$i64 . const i64$	$0x 42$	$[] \to [i64]$	validation	execution
$f32 . const f32$	$0x 43$	$[] \to [f32]$	validation	execution
$f64 . const f64$	$0x 44$	$[] \to [f64]$	validation	execution
$i32 . eqz$	$0x 45$	$[i32] \to [i32]$	validation	execution (operator)
$i32 . eq$	$0x 46$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . ne$	$0x 47$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . lt_s$	$0x 48$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . lt_u$	$0x 49$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . gt_s$	$0x 4A$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . gt_u$	$0x 4B$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . le_s$	$0x 4C$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . le_u$	$0x 4D$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . ge_s$	$0x 4E$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . ge_u$	$0x 4F$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i64 . eqz$	$0x 50$	$[i64] \to [i32]$	validation	execution (operator)
$i64 . eq$	$0x 51$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . ne$	$0x 52$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . lt_s$	$0x 53$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . lt_u$	$0x 54$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . gt_s$	$0x 55$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . gt_u$	$0x 56$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . le_s$	$0x 57$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . le_u$	$0x 58$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . ge_s$	$0x 59$	$[i64 i64] \to [i32]$	validation	execution (operator)
$i64 . ge_u$	$0x 5A$	$[i64 i64] \to [i32]$	validation	execution (operator)
$f32 . eq$	$0x 5B$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f32 . ne$	$0x 5C$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f32 . lt$	$0x 5D$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f32 . gt$	$0x 5E$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f32 . le$	$0x 5F$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f32 . ge$	$0x 60$	$[f32 f32] \to [i32]$	validation	execution (operator)
$f64 . eq$	$0x 61$	$[f64 f64] \to [i32]$	validation	execution (operator)
$f64 . ne$	$0x 62$	$[f64 f64] \to [i32]$	validation	execution (operator)
$f64 . lt$	$0x 63$	$[f64 f64] \to [i32]$	validation	execution (operator)
$f64 . gt$	$0x 64$	$[f64 f64] \to [i32]$	validation	execution (operator)
$f64 . le$	$0x 65$	$[f64 f64] \to [i32]$	validation	execution (operator)
$f64 . ge$	$0x 66$	$[f64 f64] \to [i32]$	validation	execution (operator)
$i32 . clz$	$0x 67$	$[i32] \to [i32]$	validation	execution (operator)
$i32 . ctz$	$0x 68$	$[i32] \to [i32]$	validation	execution (operator)
$i32 . popcnt$	$0x 69$	$[i32] \to [i32]$	validation	execution (operator)
$i32 . add$	$0x 6A$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . sub$	$0x 6B$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . mul$	$0x 6C$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . div_s$	$0x 6D$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . div_u$	$0x 6E$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . rem_s$	$0x 6F$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . rem_u$	$0x 70$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . and$	$0x 71$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . or$	$0x 72$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . xor$	$0x 73$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . shl$	$0x 74$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . shr_s$	$0x 75$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . shr_u$	$0x 76$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . rotl$	$0x 77$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i32 . rotr$	$0x 78$	$[i32 i32] \to [i32]$	validation	execution (operator)
$i64 . clz$	$0x 79$	$[i64] \to [i64]$	validation	execution (operator)
$i64 . ctz$	$0x 7A$	$[i64] \to [i64]$	validation	execution (operator)
$i64 . popcnt$	$0x 7B$	$[i64] \to [i64]$	validation	execution (operator)
$i64 . add$	$0x 7C$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . sub$	$0x 7D$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . mul$	$0x 7E$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . div_s$	$0x 7F$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . div_u$	$0x 80$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . rem_s$	$0x 81$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . rem_u$	$0x 82$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . and$	$0x 83$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . or$	$0x 84$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . xor$	$0x 85$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . shl$	$0x 86$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . shr_s$	$0x 87$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . shr_u$	$0x 88$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . rotl$	$0x 89$	$[i64 i64] \to [i64]$	validation	execution (operator)
$i64 . rotr$	$0x 8A$	$[i64 i64] \to [i64]$	validation	execution (operator)
$f32 . abs$	$0x 8B$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . neg$	$0x 8C$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . ceil$	$0x 8D$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . floor$	$0x 8E$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . trunc$	$0x 8F$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . nearest$	$0x 90$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . sqrt$	$0x 91$	$[f32] \to [f32]$	validation	execution (operator)
$f32 . add$	$0x 92$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . sub$	$0x 93$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . mul$	$0x 94$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . div$	$0x 95$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . min$	$0x 96$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . max$	$0x 97$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f32 . copysign$	$0x 98$	$[f32 f32] \to [f32]$	validation	execution (operator)
$f64 . abs$	$0x 99$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . neg$	$0x 9A$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . ceil$	$0x 9B$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . floor$	$0x 9C$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . trunc$	$0x 9D$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . nearest$	$0x 9E$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . sqrt$	$0x 9F$	$[f64] \to [f64]$	validation	execution (operator)
$f64 . add$	$0x A0$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . sub$	$0x A1$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . mul$	$0x A2$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . div$	$0x A3$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . min$	$0x A4$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . max$	$0x A5$	$[f64 f64] \to [f64]$	validation	execution (operator)
$f64 . copysign$	$0x A6$	$[f64 f64] \to [f64]$	validation	execution (operator)
$i32 . wrap_i64$	$0x A7$	$[i64] \to [i32]$	validation	execution (operator)
$i32 . trunc_f32_s$	$0x A8$	$[f32] \to [i32]$	validation	execution (operator)
$i32 . trunc_f32_u$	$0x A9$	$[f32] \to [i32]$	validation	execution (operator)
$i32 . trunc_f64_s$	$0x AA$	$[f64] \to [i32]$	validation	execution (operator)
$i32 . trunc_f64_u$	$0x AB$	$[f64] \to [i32]$	validation	execution (operator)
$i64 . extend_i32_s$	$0x AC$	$[i32] \to [i64]$	validation	execution (operator)
$i64 . extend_i32_u$	$0x AD$	$[i32] \to [i64]$	validation	execution (operator)
$i64 . trunc_f32_s$	$0x AE$	$[f32] \to [i64]$	validation	execution (operator)
$i64 . trunc_f32_u$	$0x AF$	$[f32] \to [i64]$	validation	execution (operator)
$i64 . trunc_f64_s$	$0x B0$	$[f64] \to [i64]$	validation	execution (operator)
$i64 . trunc_f64_u$	$0x B1$	$[f64] \to [i64]$	validation	execution (operator)
$f32 . convert_i32_s$	$0x B2$	$[i32] \to [f32]$	validation	execution (operator)
$f32 . convert_i32_u$	$0x B3$	$[i32] \to [f32]$	validation	execution (operator)
$f32 . convert_i64_s$	$0x B4$	$[i64] \to [f32]$	validation	execution (operator)
$f32 . convert_i64_u$	$0x B5$	$[i64] \to [f32]$	validation	execution (operator)
$f32 . demote_f64$	$0x B6$	$[f64] \to [f32]$	validation	execution (operator)
$f64 . convert_i32_s$	$0x B7$	$[i32] \to [f64]$	validation	execution (operator)
$f64 . convert_i32_u$	$0x B8$	$[i32] \to [f64]$	validation	execution (operator)
$f64 . convert_i64_s$	$0x B9$	$[i64] \to [f64]$	validation	execution (operator)
$f64 . convert_i64_u$	$0x BA$	$[i64] \to [f64]$	validation	execution (operator)
$f64 . promote_f32$	$0x BB$	$[f32] \to [f64]$	validation	execution (operator)
$i32 . reinterpret_f32$	$0x BC$	$[f32] \to [i32]$	validation	execution (operator)
$i64 . reinterpret_f64$	$0x BD$	$[f64] \to [i64]$	validation	execution (operator)
$f32 . reinterpret_i32$	$0x BE$	$[i32] \to [f32]$	validation	execution (operator)
$f64 . reinterpret_i64$	$0x BF$	$[i64] \to [f64]$	validation	execution (operator)
$i32 . extend 8_s$	$0x C0$	$[i32] \to [i32]$	validation	execution (operator)
$i32 . extend 16_s$	$0x C1$	$[i32] \to [i32]$	validation	execution (operator)
$i64 . extend 8_s$	$0x C2$	$[i64] \to [i64]$	validation	execution (operator)
$i64 . extend 16_s$	$0x C3$	$[i64] \to [i64]$	validation	execution (operator)
$i64 . extend 32_s$	$0x C4$	$[i64] \to [i64]$	validation	execution (operator)
(reserved)	$0x C5$
(reserved)	$0x C6$
(reserved)	$0x C7$
(reserved)	$0x C8$
(reserved)	$0x C9$
(reserved)	$0x CA$
(reserved)	$0x CB$
(reserved)	$0x CC$
(reserved)	$0x CD$
(reserved)	$0x CE$
(reserved)	$0x CF$
$ref.null ht$	$0x D0$	$[] \to [(ref null ht)]$	validation	execution
$ref.is_null$	$0x D1$	$[(ref null ht)] \to [i32]$	validation	execution
$ref.func x$	$0x D2$	$[] \to [ref ht]$	validation	execution
$ref.eq$	$0x D3$	$[eqref eqref] \to [i32]$	validation	execution
$ref.as_non_null$	$0x D4$	$[(ref null ht)] \to [(ref ht)]$	validation	execution
$br_on_null l$	$0x D5$	$[t^{} (ref null ht)] \to [t^{} (ref ht)]$	validation	execution
$br_on_non_null l$	$0x D6$	$[t^{} (ref null ht)] \to [t^{}]$	validation	execution
(reserved)	$0x D7$
(reserved)	$0x D8$
(reserved)	$0x D9$
(reserved)	$0x DA$
(reserved)	$0x DB$
(reserved)	$0x DC$
(reserved)	$0x DD$
(reserved)	$0x DE$
(reserved)	$0x DF$
(reserved)	$0x E0$
(reserved)	$0x E1$
(reserved)	$0x E2$
(reserved)	$0x E3$
(reserved)	$0x E4$
(reserved)	$0x E5$
(reserved)	$0x E6$
(reserved)	$0x E7$
(reserved)	$0x E8$
(reserved)	$0x E9$
(reserved)	$0x EA$
(reserved)	$0x EB$
(reserved)	$0x EC$
(reserved)	$0x ED$
(reserved)	$0x EE$
(reserved)	$0x EF$
(reserved)	$0x F0$
(reserved)	$0x F1$
(reserved)	$0x F2$
(reserved)	$0x F3$
(reserved)	$0x F4$
(reserved)	$0x F5$
(reserved)	$0x F6$
(reserved)	$0x F7$
(reserved)	$0x F8$
(reserved)	$0x F9$
(reserved)	$0x FA$
$struct.new x$	$0x FB 0x 00$	$[t^{*}] \to [(ref x)]$	validation	execution
$struct.new_default x$	$0x FB 0x 01$	$[] \to [(ref x)]$	validation	execution
$struct.get x y$	$0x FB 0x 02$	$[(ref null x)] \to [t]$	validation	execution
$struct.get_s x y$	$0x FB 0x 03$	$[(ref null x)] \to [i32]$	validation	execution
$struct.get_u x y$	$0x FB 0x 04$	$[(ref null x)] \to [i32]$	validation	execution
$struct.set x y$	$0x FB 0x 05$	$[(ref null x) t] \to []$	validation	execution
$array.new x$	$0x FB 0x 06$	$[t] \to [(ref x)]$	validation	execution
$array.new_default x$	$0x FB 0x 07$	$[i32] \to [(ref x)]$	validation	execution
$array.new_fixed x n$	$0x FB 0x 08$	$[t^{n}] \to [(ref x)]$	validation	execution
$array.new_data x y$	$0x FB 0x 09$	$[i32 i32] \to [(ref x)]$	validation	execution
$array.new_elem x y$	$0x FB 0x 0A$	$[i32 i32] \to [(ref x)]$	validation	execution
$array.get x$	$0x FB 0x 0B$	$[(ref null x) i32] \to [t]$	validation	execution
$array.get_s x$	$0x FB 0x 0C$	$[(ref null x) i32] \to [i32]$	validation	execution
$array.get_u x$	$0x FB 0x 0D$	$[(ref null x) i32] \to [i32]$	validation	execution
$array.set x$	$0x FB 0x 0E$	$[(ref null x) i32 t] \to []$	validation	execution
$array.len$	$0x FB 0x 0F$	$[(ref null array)] \to [i32]$	validation	execution
$array.fill x$	$0x FB 0x 10$	$[(ref null x) i32 t i32] \to []$	validation	execution
$array.copy x y$	$0x FB 0x 11$	$[(ref null x) i32 (ref null y) i32 i32] \to []$	validation	execution
$array.init_data x y$	$0x FB 0x 12$	$[(ref null x) i32 i32 i32] \to []$	validation	execution
$array.init_elem x y$	$0x FB 0x 13$	$[(ref null x) i32 i32 i32] \to []$	validation	execution
$ref.test (ref t)$	$0x FB 0x 14$	$[(ref t^{'})] \to [i32]$	validation	execution
$ref.test (ref null t)$	$0x FB 0x 15$	$[(ref null t^{'})] \to [i32]$	validation	execution
$ref.cast (ref t)$	$0x FB 0x 16$	$[(ref t^{'})] \to [(ref t)]$	validation	execution
$ref.cast (ref null t)$	$0x FB 0x 17$	$[(ref null t^{'})] \to [(ref null t)]$	validation	execution
$br_on_cast t_{1} t_{2}$	$0x FB 0x 18$	$[t_{1}] \to [t_{1} ∖ t_{2}]$	validation	execution
$br_on_cast_fail t_{1} t_{2}$	$0x FB 0x 19$	$[t_{1}] \to [t_{2}]$	validation	execution
$any.convert_extern$	$0x FB 0x 1A$	$[(ref null extern)] \to [(ref null any)]$	validation	execution
$extern.convert_any$	$0x FB 0x 1B$	$[(ref null any)] \to [(ref null extern)]$	validation	execution
$ref.i31$	$0x FB 0x 1C$	$[i32] \to [(ref i31)]$	validation	execution
$i31.get_s$	$0x FB 0x 1D$	$[i31ref] \to [i32]$	validation	execution
$i31.get_u$	$0x FB 0x 1E$	$[i31ref] \to [i32]$	validation	execution
(reserved)	$0x FB 0x 1E \dots$
$i32 . trunc_sat_f32_s$	$0x FC 0x 00$	$[f32] \to [i32]$	validation	execution (operator)
$i32 . trunc_sat_f32_u$	$0x FC 0x 01$	$[f32] \to [i32]$	validation	execution (operator)
$i32 . trunc_sat_f64_s$	$0x FC 0x 02$	$[f64] \to [i32]$	validation	execution (operator)
$i32 . trunc_sat_f64_u$	$0x FC 0x 03$	$[f64] \to [i32]$	validation	execution (operator)
$i64 . trunc_sat_f32_s$	$0x FC 0x 04$	$[f32] \to [i64]$	validation	execution (operator)
$i64 . trunc_sat_f32_u$	$0x FC 0x 05$	$[f32] \to [i64]$	validation	execution (operator)
$i64 . trunc_sat_f64_s$	$0x FC 0x 06$	$[f64] \to [i64]$	validation	execution (operator)
$i64 . trunc_sat_f64_u$	$0x FC 0x 07$	$[f64] \to [i64]$	validation	execution (operator)
$memory.init x y$	$0x FC 0x 08$	$[i32 i32 i32] \to []$	validation	execution
$data.drop x$	$0x FC 0x 09$	$[] \to []$	validation	execution
$memory.copy x y$	$0x FC 0x 0A$	$[i32 i32 i32] \to []$	validation	execution
$memory.fill y$	$0x FC 0x 0B$	$[i32 i32 i32] \to []$	validation	execution
$table.init x y$	$0x FC 0x 0C$	$[i32 i32 i32] \to []$	validation	execution
$elem.drop x$	$0x FC 0x 0D$	$[] \to []$	validation	execution
$table.copy x y$	$0x FC 0x 0E$	$[i32 i32 i32] \to []$	validation	execution
$table.grow x$	$0x FC 0x 0F$	$[t i32] \to [i32]$	validation	execution
$table.size x$	$0x FC 0x 10$	$[] \to [i32]$	validation	execution
$table.fill x$	$0x FC 0x 11$	$[i32 t i32] \to []$	validation	execution
(reserved)	$0x FC 0x 1E \dots$
$v128 . load x memarg$	$0x FD 0x 00$	$[i32] \to [v128]$	validation	execution
$v128 . load 8x8_s x memarg$	$0x FD 0x 01$	$[i32] \to [v128]$	validation	execution
$v128 . load 8x8_u x memarg$	$0x FD 0x 02$	$[i32] \to [v128]$	validation	execution
$v128 . load 16x4_s x memarg$	$0x FD 0x 03$	$[i32] \to [v128]$	validation	execution
$v128 . load 16x4_u x memarg$	$0x FD 0x 04$	$[i32] \to [v128]$	validation	execution
$v128 . load 32x2_s x memarg$	$0x FD 0x 05$	$[i32] \to [v128]$	validation	execution
$v128 . load 32x2_u x memarg$	$0x FD 0x 06$	$[i32] \to [v128]$	validation	execution
$v128 . load 8_splat x memarg$	$0x FD 0x 07$	$[i32] \to [v128]$	validation	execution
$v128 . load 16_splat x memarg$	$0x FD 0x 08$	$[i32] \to [v128]$	validation	execution
$v128 . load 32_splat x memarg$	$0x FD 0x 09$	$[i32] \to [v128]$	validation	execution
$v128 . load 64_splat x memarg$	$0x FD 0x 0A$	$[i32] \to [v128]$	validation	execution
$v128 . store x memarg$	$0x FD 0x 0B$	$[i32 v128] \to []$	validation	execution
$v128 . const i128$	$0x FD 0x 0C$	$[] \to [v128]$	validation	execution
$i8x16 . shuffle laneidx^{16}$	$0x FD 0x 0D$	$[v128 v128] \to [v128]$	validation	execution
$i8x16 . swizzle$	$0x FD 0x 0E$	$[v128 v128] \to [v128]$	validation	execution
$i8x16 . splat$	$0x FD 0x 0F$	$[i32] \to [v128]$	validation	execution
$i16x8 . splat$	$0x FD 0x 10$	$[i32] \to [v128]$	validation	execution
$i32x4 . splat$	$0x FD 0x 11$	$[i32] \to [v128]$	validation	execution
$i64x2 . splat$	$0x FD 0x 12$	$[i64] \to [v128]$	validation	execution
$f32x4 . splat$	$0x FD 0x 13$	$[f32] \to [v128]$	validation	execution
$f64x2 . splat$	$0x FD 0x 14$	$[f64] \to [v128]$	validation	execution
$i8x16 . extract_lane_s laneidx$	$0x FD 0x 15$	$[v128] \to [i32]$	validation	execution
$i8x16 . extract_lane_u laneidx$	$0x FD 0x 16$	$[v128] \to [i32]$	validation	execution
$i8x16 . replace_lane laneidx$	$0x FD 0x 17$	$[v128 i32] \to [v128]$	validation	execution
$i16x8 . extract_lane_s laneidx$	$0x FD 0x 18$	$[v128] \to [i32]$	validation	execution
$i16x8 . extract_lane_u laneidx$	$0x FD 0x 19$	$[v128] \to [i32]$	validation	execution
$i16x8 . replace_lane laneidx$	$0x FD 0x 1A$	$[v128 i32] \to [v128]$	validation	execution
$i32x4 . extract_lane laneidx$	$0x FD 0x 1B$	$[v128] \to [i32]$	validation	execution
$i32x4 . replace_lane laneidx$	$0x FD 0x 1C$	$[v128 i32] \to [v128]$	validation	execution
$i64x2 . extract_lane laneidx$	$0x FD 0x 1D$	$[v128] \to [i64]$	validation	execution
$i64x2 . replace_lane laneidx$	$0x FD 0x 1E$	$[v128 i64] \to [v128]$	validation	execution
$f32x4 . extract_lane laneidx$	$0x FD 0x 1F$	$[v128] \to [f32]$	validation	execution
$f32x4 . replace_lane laneidx$	$0x FD 0x 20$	$[v128 f32] \to [v128]$	validation	execution
$f64x2 . extract_lane laneidx$	$0x FD 0x 21$	$[v128] \to [f64]$	validation	execution
$f64x2 . replace_lane laneidx$	$0x FD 0x 22$	$[v128 f64] \to [v128]$	validation	execution
$i8x16 . eq$	$0x FD 0x 23$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . ne$	$0x FD 0x 24$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . lt_s$	$0x FD 0x 25$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . lt_u$	$0x FD 0x 26$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . gt_s$	$0x FD 0x 27$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . gt_u$	$0x FD 0x 28$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . le_s$	$0x FD 0x 29$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . le_u$	$0x FD 0x 2A$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . ge_s$	$0x FD 0x 2B$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . ge_u$	$0x FD 0x 2C$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . eq$	$0x FD 0x 2D$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . ne$	$0x FD 0x 2E$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . lt_s$	$0x FD 0x 2F$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . lt_u$	$0x FD 0x 30$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . gt_s$	$0x FD 0x 31$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . gt_u$	$0x FD 0x 32$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . le_s$	$0x FD 0x 33$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . le_u$	$0x FD 0x 34$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . ge_s$	$0x FD 0x 35$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . ge_u$	$0x FD 0x 36$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . eq$	$0x FD 0x 37$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . ne$	$0x FD 0x 38$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . lt_s$	$0x FD 0x 39$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . lt_u$	$0x FD 0x 3A$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . gt_s$	$0x FD 0x 3B$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . gt_u$	$0x FD 0x 3C$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . le_s$	$0x FD 0x 3D$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . le_u$	$0x FD 0x 3E$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . ge_s$	$0x FD 0x 3F$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . ge_u$	$0x FD 0x 40$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . eq$	$0x FD 0x 41$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . ne$	$0x FD 0x 42$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . lt$	$0x FD 0x 43$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . gt$	$0x FD 0x 44$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . le$	$0x FD 0x 45$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . ge$	$0x FD 0x 46$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . eq$	$0x FD 0x 47$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . ne$	$0x FD 0x 48$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . lt$	$0x FD 0x 49$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . gt$	$0x FD 0x 4A$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . le$	$0x FD 0x 4B$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . ge$	$0x FD 0x 4C$	$[v128 v128] \to [v128]$	validation	execution (operator)
$v128 . not$	$0x FD 0x 4D$	$[v128] \to [v128]$	validation	execution (operator)
$v128 . and$	$0x FD 0x 4E$	$[v128 v128] \to [v128]$	validation	execution (operator)
$v128 . andnot$	$0x FD 0x 4F$	$[v128 v128] \to [v128]$	validation	execution (operator)
$v128 . or$	$0x FD 0x 50$	$[v128 v128] \to [v128]$	validation	execution (operator)
$v128 . xor$	$0x FD 0x 51$	$[v128 v128] \to [v128]$	validation	execution (operator)
$v128 . bitselect$	$0x FD 0x 52$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$v128 . any_true$	$0x FD 0x 53$	$[v128] \to [i32]$	validation	execution
$v128 . load 8_lane memarg laneidx$	$0x FD 0x 54$	$[i32 v128] \to [v128]$	validation	execution
$v128 . load 16_lane memarg laneidx$	$0x FD 0x 55$	$[i32 v128] \to [v128]$	validation	execution
$v128 . load 32_lane memarg laneidx$	$0x FD 0x 56$	$[i32 v128] \to [v128]$	validation	execution
$v128 . load 64_lane memarg laneidx$	$0x FD 0x 57$	$[i32 v128] \to [v128]$	validation	execution
$v128 . store 8_lane memarg laneidx$	$0x FD 0x 58$	$[i32 v128] \to []$	validation	execution
$v128 . store 16_lane memarg laneidx$	$0x FD 0x 59$	$[i32 v128] \to []$	validation	execution
$v128 . store 32_lane memarg laneidx$	$0x FD 0x 5A$	$[i32 v128] \to []$	validation	execution
$v128 . store 64_lane memarg laneidx$	$0x FD 0x 5B$	$[i32 v128] \to []$	validation	execution
$v128 . load 32_zero memarg$	$0x FD 0x 5C$	$[i32] \to [v128]$	validation	execution
$v128 . load 64_zero memarg$	$0x FD 0x 5D$	$[i32] \to [v128]$	validation	execution
$f32x4 . demote_f64x2_zero$	$0x FD 0x 5E$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . promote_low_f32x4$	$0x FD 0x 5F$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . abs$	$0x FD 0x 60$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . neg$	$0x FD 0x 61$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . popcnt$	$0x FD 0x 62$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . all_true$	$0x FD 0x 63$	$[v128] \to [i32]$	validation	execution
$i8x16 . bitmask$	$0x FD 0x 64$	$[v128] \to [i32]$	validation	execution
$i8x16 . narrow_i16x8_s$	$0x FD 0x 65$	$[v128 v128] \to [v128]$	validation	execution
$i8x16 . narrow_i16x8_u$	$0x FD 0x 66$	$[v128 v128] \to [v128]$	validation	execution
$f32x4 . ceil$	$0x FD 0x 67$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . floor$	$0x FD 0x 68$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . trunc$	$0x FD 0x 69$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . nearest$	$0x FD 0x 6A$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . shl$	$0x FD 0x 6B$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i8x16 . shr_s$	$0x FD 0x 6C$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i8x16 . shr_u$	$0x FD 0x 6D$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i8x16 . add$	$0x FD 0x 6E$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . add_sat_s$	$0x FD 0x 6F$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . add_sat_u$	$0x FD 0x 70$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . sub$	$0x FD 0x 71$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . sub_sat_s$	$0x FD 0x 72$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . sub_sat_u$	$0x FD 0x 73$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . ceil$	$0x FD 0x 74$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . floor$	$0x FD 0x 75$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . min_s$	$0x FD 0x 76$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . min_u$	$0x FD 0x 77$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . max_s$	$0x FD 0x 78$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . max_u$	$0x FD 0x 79$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . trunc$	$0x FD 0x 7A$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . avgr_u$	$0x FD 0x 7B$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . extadd_pairwise_i8x16_s$	$0x FD 0x 7C$	$[v128] \to [v128]$	validation	execution
$i16x8 . extadd_pairwise_i8x16_u$	$0x FD 0x 7D$	$[v128] \to [v128]$	validation	execution
$i32x4 . extadd_pairwise_i16x8_s$	$0x FD 0x 7E$	$[v128] \to [v128]$	validation	execution
$i32x4 . extadd_pairwise_i16x8_u$	$0x FD 0x 7F$	$[v128] \to [v128]$	validation	execution
$i16x8 . abs$	$0x FD 0x 80 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i16x8 . neg$	$0x FD 0x 81 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i16x8 . q15mulr_sat_s$	$0x FD 0x 82 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . all_true$	$0x FD 0x 83 0x 01$	$[v128] \to [i32]$	validation	execution
$i16x8 . bitmask$	$0x FD 0x 84 0x 01$	$[v128] \to [i32]$	validation	execution
$i16x8 . narrow_i32x4_s$	$0x FD 0x 85 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i16x8 . narrow_i32x4_u$	$0x FD 0x 86 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i16x8 . extend_low_i8x16_s$	$0x FD 0x 87 0x 01$	$[v128] \to [v128]$	validation	execution
$i16x8 . extend_high_i8x16_s$	$0x FD 0x 88 0x 01$	$[v128] \to [v128]$	validation	execution
$i16x8 . extend_low_i8x16_u$	$0x FD 0x 89 0x 01$	$[v128] \to [v128]$	validation	execution
$i16x8 . extend_high_i8x16_u$	$0x FD 0x 8A 0x 01$	$[v128] \to [v128]$	validation	execution
$i16x8 . shl$	$0x FD 0x 8B 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i16x8 . shr_s$	$0x FD 0x 8C 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i16x8 . shr_u$	$0x FD 0x 8D 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i16x8 . add$	$0x FD 0x 8E 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . add_sat_s$	$0x FD 0x 8F 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . add_sat_u$	$0x FD 0x 90 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . sub$	$0x FD 0x 91 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . sub_sat_s$	$0x FD 0x 92 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . sub_sat_u$	$0x FD 0x 93 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . nearest$	$0x FD 0x 94 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i16x8 . mul$	$0x FD 0x 95 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . min_s$	$0x FD 0x 96 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . min_u$	$0x FD 0x 97 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . max_s$	$0x FD 0x 98 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . max_u$	$0x FD 0x 99 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x 9A 0x 01$
$i16x8 . avgr_u$	$0x FD 0x 9B 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . extmul_low_i8x16_s$	$0x FD 0x 9C 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i16x8 . extmul_high_i8x16_s$	$0x FD 0x 9D 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i16x8 . extmul_low_i8x16_u$	$0x FD 0x 9E 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i16x8 . extmul_high_i8x16_u$	$0x FD 0x 9F 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . abs$	$0x FD 0x A0 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . neg$	$0x FD 0x A1 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x A2 0x 01$
$i32x4 . all_true$	$0x FD 0x A3 0x 01$	$[v128] \to [i32]$	validation	execution
$i32x4 . bitmask$	$0x FD 0x A4 0x 01$	$[v128] \to [i32]$	validation	execution
(reserved)	$0x FD 0x A5 0x 01$
(reserved)	$0x FD 0x A6 0x 01$
$i32x4 . extend_low_i16x8_s$	$0x FD 0x A7 0x 01$	$[v128] \to [v128]$	validation	execution
$i32x4 . extend_high_i16x8_s$	$0x FD 0x A8 0x 01$	$[v128] \to [v128]$	validation	execution
$i32x4 . extend_low_i16x8_u$	$0x FD 0x A9 0x 01$	$[v128] \to [v128]$	validation	execution
$i32x4 . extend_high_i16x8_u$	$0x FD 0x AA 0x 01$	$[v128] \to [v128]$	validation	execution
$i32x4 . shl$	$0x FD 0x AB 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i32x4 . shr_s$	$0x FD 0x AC 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i32x4 . shr_u$	$0x FD 0x AD 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i32x4 . add$	$0x FD 0x AE 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x AF 0x 01$
(reserved)	$0x FD 0x B0 0x 01$
$i32x4 . sub$	$0x FD 0x B1 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x B2 0x 01$
(reserved)	$0x FD 0x B3 0x 01$
(reserved)	$0x FD 0x B4 0x 01$
$i32x4 . mul$	$0x FD 0x B5 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . min_s$	$0x FD 0x B6 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . min_u$	$0x FD 0x B7 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . max_s$	$0x FD 0x B8 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . max_u$	$0x FD 0x B9 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . dot_i16x8_s$	$0x FD 0x BA 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . extmul_low_i16x8_s$	$0x FD 0x BC 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . extmul_high_i16x8_s$	$0x FD 0x BD 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . extmul_low_i16x8_u$	$0x FD 0x BE 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . extmul_high_i16x8_u$	$0x FD 0x BF 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i64x2 . abs$	$0x FD 0x C0 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i64x2 . neg$	$0x FD 0x C1 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x C2 0x 01$
$i64x2 . all_true$	$0x FD 0x C3 0x 01$	$[v128] \to [i32]$	validation	execution
$i64x2 . bitmask$	$0x FD 0x C4 0x 01$	$[v128] \to [i32]$	validation	execution
(reserved)	$0x FD 0x C5 0x 01$
(reserved)	$0x FD 0x C6 0x 01$
$i64x2 . extend_low_i32x4_s$	$0x FD 0x C7 0x 01$	$[v128] \to [v128]$	validation	execution
$i64x2 . extend_high_i32x4_s$	$0x FD 0x C8 0x 01$	$[v128] \to [v128]$	validation	execution
$i64x2 . extend_low_i32x4_u$	$0x FD 0x C9 0x 01$	$[v128] \to [v128]$	validation	execution
$i64x2 . extend_high_i32x4_u$	$0x FD 0x CA 0x 01$	$[v128] \to [v128]$	validation	execution
$i64x2 . shl$	$0x FD 0x CB 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i64x2 . shr_s$	$0x FD 0x CC 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i64x2 . shr_u$	$0x FD 0x CD 0x 01$	$[v128 i32] \to [v128]$	validation	execution (operator)
$i64x2 . add$	$0x FD 0x CE 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x CF 0x 01$
(reserved)	$0x FD 0x D0 0x 01$
$i64x2 . sub$	$0x FD 0x D1 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x D2 0x 01$
(reserved)	$0x FD 0x D3 0x 01$
(reserved)	$0x FD 0x D4 0x 01$
$i64x2 . mul$	$0x FD 0x D5 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . eq$	$0x FD 0x D6 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . ne$	$0x FD 0x D7 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . lt_s$	$0x FD 0x D8 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . gt_s$	$0x FD 0x D9 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . le_s$	$0x FD 0x DA 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . ge_s$	$0x FD 0x DB 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . extmul_low_i32x4_s$	$0x FD 0x DC 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i64x2 . extmul_high_i32x4_s$	$0x FD 0x DD 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i64x2 . extmul_low_i32x4_u$	$0x FD 0x DE 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$i64x2 . extmul_high_i32x4_u$	$0x FD 0x DF 0x 01$	$[v128 v128] \to [v128]$	validation	execution
$f32x4 . abs$	$0x FD 0x E0 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . neg$	$0x FD 0x E1 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
(reserved)	$0x FD 0x E2 0x 01$
$f32x4 . sqrt$	$0x FD 0x E3 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . add$	$0x FD 0x E4 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . sub$	$0x FD 0x E5 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . mul$	$0x FD 0x E6 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . div$	$0x FD 0x E7 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . min$	$0x FD 0x E8 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . max$	$0x FD 0x E9 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . pmin$	$0x FD 0x EA 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . pmax$	$0x FD 0x EB 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . abs$	$0x FD 0x EC 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . neg$	$0x FD 0x ED 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . sqrt$	$0x FD 0x EF 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . add$	$0x FD 0x F0 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . sub$	$0x FD 0x F1 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . mul$	$0x FD 0x F2 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . div$	$0x FD 0x F3 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . min$	$0x FD 0x F4 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . max$	$0x FD 0x F5 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . pmin$	$0x FD 0x F6 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . pmax$	$0x FD 0x F7 0x 01$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . trunc_sat_f32x4_s$	$0x FD 0x F8 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . trunc_sat_f32x4_u$	$0x FD 0x F9 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . convert_i32x4_s$	$0x FD 0x FA 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . convert_i32x4_u$	$0x FD 0x FB 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . trunc_sat_f64x2_s_zero$	$0x FD 0x FC 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . trunc_sat_f64x2_u_zero$	$0x FD 0x FD 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . convert_low_i32x4_s$	$0x FD 0x FE 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$f64x2 . convert_low_i32x4_u$	$0x FD 0x FF 0x 01$	$[v128] \to [v128]$	validation	execution (operator)
$i8x16 . relaxed_swizzle$	$0x FD 0x 80 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . relaxed_trunc_f32x4_s$	$0x FD 0x 81 0x 02$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . relaxed_trunc_f32x4_u$	$0x FD 0x 82 0x 02$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . relaxed_trunc_f64x2_s$	$0x FD 0x 83 0x 02$	$[v128] \to [v128]$	validation	execution (operator)
$i32x4 . relaxed_trunc_f64x2_u$	$0x FD 0x 84 0x 02$	$[v128] \to [v128]$	validation	execution (operator)
$f32x4 . relaxed_madd$	$0x FD 0x 85 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . relaxed_nmadd$	$0x FD 0x 86 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . relaxed_madd$	$0x FD 0x 87 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . relaxed_nmadd$	$0x FD 0x 88 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$i8x16 . relaxed_laneselect$	$0x FD 0x 89 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . relaxed_laneselect$	$0x FD 0x 8A 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$i32x4 . relaxed_laneselect$	$0x FD 0x 8B 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$i64x2 . relaxed_laneselect$	$0x FD 0x 8C 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . relaxed_min$	$0x FD 0x 8D 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f32x4 . relaxed_max$	$0x FD 0x 8E 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . relaxed_min$	$0x FD 0x 8F 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$f64x2 . relaxed_max$	$0x FD 0x 90 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . relaxed_q15mulr_s$	$0x FD 0x 91 0x 02$	$[v128 v128] \to [v128]$	validation	execution (operator)
$i16x8 . relaxed_dot_i8x16_i7x16_s$	$0x FD 0x 92 0x 02$	$[v128 v128] \to [v128]$	validation	execution
$i32x4 . relaxed_dot_i8x16_i7x16_add_s$	$0x FD 0x 93 0x 02$	$[v128 v128 v128] \to [v128]$	validation	execution
(reserved)	$0x FE$
(reserved)	$0x FF$

Note

Multi-byte opcodes are given with the shortest possible encoding in the table. However, what is following the first byte is actually a u32 with variable-length encoding and consequently has multiple possible representations.

A.10 Index of Semantic Rules

Well-formedness of Types

Construct	Judgement
Numeric type	$C ⊢ numtype ok$
Vector type	$C ⊢ vectype ok$
Heap type	$C ⊢ heaptype ok$
Reference type	$C ⊢ reftype ok$
Value type	$C ⊢ valtype ok$
Packed type	$C ⊢ packedtype ok$
Storage type	$C ⊢ storagetype ok$
Field type	$C ⊢ fieldtype ok$
Result type	$C ⊢ resulttype ok$
Instruction type	$C ⊢ instrtype ok$
Function type	$C ⊢ functype ok$
Structure type	$C ⊢ structtype ok$
Array type	$C ⊢ arraytype ok$
Composite type	$C ⊢ comptype ok$
Sub type	$C ⊢ subtype ok$
Recursive type	$C ⊢ rectype ok$
Defined type	$C ⊢ deftype ok$
Block type	$C ⊢ blocktype : instrtype$
Table type	$C ⊢ tabletype ok$
Memory type	$C ⊢ memtype ok$
Global type	$C ⊢ globaltype ok$
Tag type	$C ⊢ tagtype ok$
External type	$C ⊢ externtype ok$
Type definitions	$C ⊢ type^{*} ok$

Typing of Static Constructs

Construct	Judgement
Instruction	$S; C ⊢ instr : functype$
Instruction sequence	$S; C ⊢ instr^{*} : functype$
Catch clause	$C ⊢ catch ok$
Expression	$C ⊢ expr : resulttype$
Function	$C ⊢ func : functype$
Local	$C ⊢ local : localtype$
Table	$C ⊢ table : tabletype$
Memory	$C ⊢ mem : memtype$
Limits	$C ⊢ limits : k$
Global	$C ⊢ global : globaltype$
Tag	$C ⊢ tag : tagtype$
Element segment	$C ⊢ elem : reftype$
Element mode	$C ⊢ elemmode : reftype$
Data segment	$C ⊢ data ok$
Data mode	$C ⊢ datamode ok$
Start function	$C ⊢ start ok$
Export	$C ⊢ export : externtype$
Export description	$C ⊢ exportdesc : externtype$
Import	$C ⊢ import : externtype$
Import description	$C ⊢ importdesc : externtype$
Module	$⊢ module : externtype^{} \to externtype^{}$

Typing of Runtime Constructs

Construct	Judgement
Value	$S ⊢ val : valtype$
Result	$S ⊢ result : resulttype$
Packed value	$S ⊢ packedval : packedtype$
Field value	$S ⊢ fieldval : storagetype$
External value	$S ⊢ externval : externtype$
Function instance	$S ⊢ funcinst : functype$
Table instance	$S ⊢ tableinst : tabletype$
Memory instance	$S ⊢ meminst : memtype$
Global instance	$S ⊢ globalinst : globaltype$
Tag instance	$S ⊢ taginst : tagtype$
Element instance	$S ⊢ eleminst : t$
Data instance	$S ⊢ datainst ok$
Structure instance	$S ⊢ structinst ok$
Array instance	$S ⊢ arrayinst ok$
Export instance	$S ⊢ exportinst ok$
Module instance	$S ⊢ moduleinst : C$
Store	$⊢ store ok$
Configuration	$⊢ config ok$
Thread	$S; resulttype^{?} ⊢ thread : resulttype$
Frame	$S ⊢ frame : C$

Defaultability

Construct	Judgement
Defaultable value type	$C ⊢ valtype defaultable$

Constantness

Construct	Judgement
Constant expression	$C ⊢ expr const$
Constant instruction	$C ⊢ instr const$

Matching

Construct	Judgement
Number type	$C ⊢ numtype_{1} \leq numtype_{2}$
Vector type	$C ⊢ vectype_{1} \leq vectype_{2}$
Heap type	$C ⊢ heaptype_{1} \leq heaptype_{2}$
Reference type	$C ⊢ reftype_{1} \leq reftype_{2}$
Value type	$C ⊢ valtype_{1} \leq valtype_{2}$
Packed type	$C ⊢ packedtype_{1} \leq packedtype_{2}$
Storage type	$C ⊢ storagetype_{1} \leq storagetype_{2}$
Field type	$C ⊢ fieldtype_{1} \leq fieldtype_{2}$
Result type	$C ⊢ resulttype_{1} \leq resulttype_{2}$
Instruction type	$C ⊢ instrtype_{1} \leq instrtype_{2}$
Function type	$C ⊢ functype_{1} \leq functype_{2}$
Structure type	$C ⊢ structtype_{1} \leq structtype_{2}$
Array type	$C ⊢ arraytype_{1} \leq arraytype_{2}$
Composite type	$C ⊢ comptype_{1} \leq comptype_{2}$
Defined type	$C ⊢ deftype_{1} \leq deftype_{2}$
Table type	$C ⊢ tabletype_{1} \leq tabletype_{2}$
Memory type	$C ⊢ memtype_{1} \leq memtype_{2}$
Global type	$C ⊢ globaltype_{1} \leq globaltype_{2}$
Tag type	$C ⊢ tagtype_{1} \leq tagtype_{2}$
External type	$C ⊢ externtype_{1} \leq externtype_{2}$
Limits	$C ⊢ limits_{1} \leq limits_{2}$

Store Extension

Construct	Judgement
Function instance	$⊢ funcinst_{1} ⪯ funcinst_{2}$
Table instance	$⊢ tableinst_{1} ⪯ tableinst_{2}$
Memory instance	$⊢ meminst_{1} ⪯ meminst_{2}$
Global instance	$⊢ globalinst_{1} ⪯ globalinst_{2}$
Tag instance	$⊢ taginst_{1} ⪯ taginst_{2}$
Element instance	$⊢ eleminst_{1} ⪯ eleminst_{2}$
Data instance	$⊢ datainst_{1} ⪯ datainst_{2}$
Structure instance	$⊢ structinst_{1} ⪯ structinst_{2}$
Array instance	$⊢ arrayinst_{1} ⪯ arrayinst_{2}$
Store	$⊢ store_{1} ⪯ store_{2}$

Execution

Construct	Judgement
Instruction	$S; F; instr^{} ↪ S^{'}; F^{'}; instr^{'}^{}$
Expression	$S; F; expr ↪ S^{'}; F^{'}; expr^{'}$

WebAssembly Core Specification

Abstract

Status of this document

1. Introduction

1.1. Introduction

1.1.1. Design Goals

1.1.2. Scope

1.1.3. Security Considerations

1.1.4. Dependencies

1.2. Overview

1.2.1. Concepts

1.2.2. Semantic Phases

2. Structure

2.1. Conventions

2.1.1. Grammar Notation

2.1.2. Auxiliary Notation

2.1.3. Vectors

2.2. Values

2.2.1. Bytes

2.2.1.1. Conventions

2.2.2. Integers

2.2.2.1. Conventions

2.2.3. Floating-Point

2.2.3.1. Conventions

2.2.4. Vectors

2.2.5. Names

2.2.5.1. Convention

2.3. Types

2.3.1. Number Types

2.3.1.1. Conventions

2.3.2. Vector Types

2.3.2.1. Conventions

2.3.3. Heap Types

2.3.4. Reference Types

2.3.4.1. Conventions

2.3.5. Value Types

2.3.5.1. Conventions

2.3.6. Result Types

2.3.7. Function Types

2.3.8. Aggregate Types

2.3.8.1. Conventions

2.3.9. Composite Types

2.3.10. Recursive Types

2.3.11. Address Type

2.3.11.1. Conventions

2.3.12. Limits

2.3.13. Memory Types

2.3.14. Table Types

2.3.15. Global Types

2.3.16. Tag Types

2.3.17. External Types

2.3.17.1. Conventions

2.4. Instructions

2.4.1. Numeric Instructions

2.4.1.1. Conventions

2.4.2. Vector Instructions

2.4.2.1. Conventions

2.4.3. Reference Instructions

2.4.4. Aggregate Instructions

2.4.5. Parametric Instructions

2.4.6. Variable Instructions

2.4.7. Table Instructions

2.4.8. Memory Instructions

2.4.9. Control Instructions

2.4.10. Expressions

2.5. Modules

2.5.1. Indices

2.5.1.1. Conventions

2.5.2. Types

2.5.3. Functions

2.5.4. Tables

2.5.5. Memories

2.5.6. Globals

2.5.7. Tags

2.5.8. Element Segments

2.5.9. Data Segments

2.5.10. Start Function

2.5.11. Exports

2.5.11.1. Conventions

2.5.12. Imports

3.2.3.1. $absheaptype$

3.2.3.2. $typeidx$

3.2.4.1. $ref null^{?} heaptype$

3.2.6.1. $typeidx$

3.2.6.2. $[valtype^{?}]$

3.2.7.1. $[t^{*}]$

3.2.8.1. $[t_{1}^{}] \to_{x^{}} [t_{2}^{*}]$

3.2.9.1. $[t_{1}^{}] \to [t_{2}^{}]$

3.2.10.1. $func functype$

3.2.10.2. $struct fieldtype^{*}$

3.2.10.3. $array fieldtype$

3.2.11.1. $mut storagetype$

3.2.11.2. $packedtype$

3.2.12.1. $rec subtype^{*}$

3.2.12.2. $sub final^{?} y^{*} comptype$

3.2.13.1. $rectype .i$

3.2.14.1. ${min n, max m^{?}}$

3.2.15.1. $addrtype limits reftype$

3.2.16.1. $addrtype limits$

3.2.17.1. $[t_{1}^{n}] \to [t_{2}^{m}]$

3.2.18.1. $mut valtype$

3.2.19.1. $func deftype$

3.2.19.2. $table tabletype$

3.2.19.3. $mem memtype$

3.2.19.4. $tag tagtype$

3.2.19.5. $global globaltype$