asm.js

Abstract

This specification defines asm.js, a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. This sublanguage effectively describes a safe virtual machine for memory-unsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ an ahead-of-time (AOT) optimizing compilation strategy for valid asm.js code.

Status

This specification is working towards a candidate draft for asm.js version 1. A prototype implementation of an optimizing backend for asm.js is in progress for Mozilla's SpiderMonkey engine.

Table of Contents

1. 1 Introduction
2. 2 Types
   1. 2.1 Value Types
      1. 2.1.1 void
      2. 2.1.2 double
      3. 2.1.3 signed
      4. 2.1.4 unsigned
      5. 2.1.5 int
      6. 2.1.6 fixnum
      7. 2.1.7 intish
      8. 2.1.8 doublish
      9. 2.1.9 unknown
      10. 2.1.10 extern
   2. 2.2 Global Types
3. 3 Environments
   1. 3.1 Global Environment
   2. 3.2 Variable Environment
   3. 3.3 Environment Lookup
4. 4 Syntax
5. 5 Annotations
   1. 5.1 Parameter Type Annotations
   2. 5.2 Return Type Annotations
   3. 5.3 Function Type Annotations
   4. 5.4 Variable Type Annotations
   5. 5.5 Global Variable Type Annotations
   6. 5.6 Function Table Types
6. 6 Validation Rules
   1. 6.1 Modules
   2. 6.2 Export Declarations
   3. 6.3 Function Declarations
   4. 6.4 Statements
      1. 6.4.1 Block
      2. 6.4.2 ExpressionStatement
      3. 6.4.3 EmptyStatement
      4. 6.4.4 IfStatement
      5. 6.4.5 ReturnStatement
      6. 6.4.6 IterationStatement
      7. 6.4.7 BreakStatement
      8. 6.4.8 ContinueStatement
      9. 6.4.9 LabelledStatement
      10. 6.4.10 SwitchStatement
   5. 6.5 Switch Cases
      1. 6.5.1 CaseClause
      2. 6.5.2 DefaultClause
   6. 6.6 Expressions
      1. 6.6.1 Expression
      2. 6.6.2 NumericLiteral
      3. 6.6.3 Identifier
      4. 6.6.4 MemberExpression
      5. 6.6.5 AssignmentExpression
      6. 6.6.6 CallExpression
      7. 6.6.7 UnaryExpression
      8. 6.6.8 MultiplicativeExpression
      9. 6.6.9 AdditiveExpression
      10. 6.6.10 ShiftExpression
      11. 6.6.11 RelationalExpression
      12. 6.6.12 EqualityExpression
      13. 6.6.13 BitwiseANDExpression
      14. 6.6.14 BitwiseXORExpression
      15. 6.6.15 BitwiseORExpression
      16. 6.6.16 ConditionalExpression
      17. 6.6.17 Parenthesized Expression
7. 7 Linking
8. 8 Operators
   1. 8.1 Unary Operators
   2. 8.2 Binary Operators
9. 9 Standard Library
10. 10 Heap View Types
11. Acknowledgements

1 Introduction

This specification defines asm.js, a strict subset of JavaScript that can be used as a low-level, efficient target language for compilers. The asm.js language provides an abstraction similar to the C/C++ virtual machine: a large binary heap with efficient loads and stores, integer and floating-point arithmetic, first-order function definitions, and function pointers.

Programming Model

The asm.js programming model is built around integer and floating-point arithmetic and a virtual heap represented as a typed array. While JavaScript does not directly provide constructs for dealing with integers, they can be emulated using two tricks:

• integer loads and stores can be performed using the typed arrays API; and
• integer arithmetic is equivalent to the composition of JavaScript's floating-point arithmetic operators with the integer coercions performed by the bitwise operators.

As an example of the former, if we have an Int32Array view of the heap called HEAP32, then we can load the 32-bit integer at byte offset p:

HEAP32[p >> 2]|0

The shift converts the byte offset to a 32-bit element offset, and the bitwise coercion ensures that an out-of-bounds access is coerced from undefined back to an integer.

As an example of integer arithmetic, addition can be performed by taking two integer values, adding them with the built-in addition operator, and coercing the result back to an integer via the bitwise or operator:

(x+y)|0

This programming model is directly inspired by the techniques pioneered by the Emscripten and Mandreel compilers.

Validation

The asm.js sub-language is defined by a static type system that can be checked at JavaScript parse time. Validation of asm.js code is designed to be "pay-as-you-go" in that it is never performed on code that does not request it. An asm.js module requests validation by means of a special prologue directive, similar to that of ECMAScript Edition 5's strict mode:

function MyAsmModule() {
    "use asm";
    // module body
}

This explicit directive allows JavaScript engines to avoid performing pointless and potentially costly validation on other JavaScript code, and to report validation errors in developer consoles only where relevant.

Ahead-Of-Time Compilation

Because asm.js is a strict subset of JavaScript, this specification only defines the validation logic—the execution semantics is simply that of JavaScript. However, validated asm.js is amenable to ahead-of-time (AOT) compilation. Moreover, the code generated by an AOT compiler can be quite efficient, featuring:

• unboxed representations of integers and floating-point numbers;
• absence of runtime type checks;
• absence of garbage collection; and
• efficient heap loads and stores (with implementation strategies varying by platform).

Code that fails to validate must fall back to execution by traditional means, e.g., interpretation and/or just-in-time (JIT) compilation.

Linking

Using an asm.js module requires calling its function to obtain an object containing the module's exports; this is known as linking. An asm.js module can also be given access to standard libraries and custom JavaScript functions through linking. An AOT implementation must perform certain dynamic checks to check compile-time assumptions about the linked libraries in order to make use of the compiled code.

This figure depicts a simple architecture of an AOT implementation that otherwise employs a simple interpreter. If either dynamic or static validation fails, the implementation must fall back to the interpreter. But if both validations succeed, calling the module exports executes the binary executable code generated by AOT compilation.

External Code and Data

Within an asm.js module, all code is fully statically typed and limited to the very restrictive asm.js dialect. However, it is possible to interact with recognized standard JavaScript libraries and even custom dynamic JavaScript functions.

An asm.js module can take up to three optional parameters, providing access to external JavaScript code and data:

• a standard library object, providing access to a limited subset of the JavaScript standard libraries;
• a foreign function interface (FFI), providing access to custom external JavaScript functions; and
• a heap buffer, providing a single ArrayBuffer to act as the asm.js heap.

These objects allow asm.js to call into external JavaScript (and to share its heap buffer with external JavaScript). Conversely, the exports object returned from the module allows external JavaScript to call into asm.js.

So in the general case, an asm.js module declaration looks like:

function MyAsmModule(stdlib, foreign, heap) {
    "use asm";

    // module body...

    return {
        export1: f1,
        export2: f2,
        // ...
    };
}

Function parameters in asm.js are provided a type annotation by means of an explicit coercion on function entry:

function diag(x, y) {
    x = +x; // x has type double
    y = +y; // y has type double
    return +sqrt(square(x) + square(y));
}

These annotations serve two purposes: first, to provide the function's type signature so that the validator can enforce that all calls to the function are well-typed; second, to ensure that even if the function is exported and called by external JavaScript, its arguments are dynamically coerced to the expected type. This ensures that an AOT implementation can use unboxed value representations, knowing that once the dynamic coercions have completed, the function body never needs any runtime type checks.

Putting It All Together

The following is a simple but complete example of an asm.js module.

function DiagModule(stdlib) {
    "use asm";

    var sqrt = stdlib.Math.sqrt;

    function square(x) {
        x = +x;
        return +(x*x);
    }

    function diag(x, y) {
        x = +x;
        y = +y;
        return +sqrt(square(x) + square(y));
    }

    return { diag: diag };
}

In a JavaScript engine that supports AOT compilation of asm.js, calling the module on a true global object would produce a fully compiled exports object:

var fast = DiagModule(window);     // produces AOT-compiled version
console.log(fast.diag(3, 4));      // 5

By contrast, calling the module on a standard library object containing something other than the true Math.sqrt would fail to produce compiled code:

var bogusGlobal = {
    Math: {
        sqrt: function(x) { return x * 2; }
    }
};

var slow = DiagModule(bogusGlobal); // produces purely-interpreted version
console.log(slow.diag(3, 4));       // 50

2 Types

Validation of an asm.js module relies on a static type system that classifies and constrains the syntax. This section defines the types used by the validation logic.

2.1 Value Types

Validation in asm.js limits JavaScript programs to only use operations that can be mapped closely to efficient data representations and machine operations of modern architectures, such as 32-bit integers and integer arithmetic.

The types of asm.js values are inter-related by a subtyping relation, which can be represented pictorially:

The light boxes represent arbitrary JavaScript values that may flow freely between asm.js code and external JavaScript code.

The dark boxes represent types that are disallowed from escaping into external (i.e., non-asm.js) JavaScript code. (These values can be given efficient, unboxed representations in optimized asm.js implementations that would be unsound if they were allowed to escape.)

The meta-variables σ and τ are used to stand for value types.

2.1.1 void

The void type is the type of functions that are not supposed to return any useful value. As JavaScript functions, they produce the undefined value, but asm.js code is not allowed to make use of this value; functions with return type void can only be called for effect.

2.1.2 double

The double type is the type of ordinary JavaScript double-precision floating-point numbers.

2.1.3 signed

The signed type is the type of signed 32-bit integers. While there is no direct concept of integers in JavaScript, 32-bit integers can be represented as doubles, and integer operations can be performed with JavaScript arithmetic, relational, and bitwise operators.

2.1.4 unsigned

The unsigned type is the type of unsigned 32-bit integers. Again, these are not a first-class concept in JavaScript, but can be represented as floating-point numbers.

2.1.5 int

The int type is the type of 32-bit integers where the signedness is not known. In asm.js, the type of a variable never has a known signedness. This allows them to be compiled as 32-bit integer registers and memory words. However, this representation creates an overlap between signed and unsigned numbers that causes an ambiguity in determining which JavaScript number they represent. For example, the bit pattern 0xffffffff could represent 4294967295 or -1, depending on the signedness. For this reason, values of the int type are disallowed from escaping into external (non-asm.js) JavaScript code.

2.1.6 fixnum

The fixnum type is the type of integers in the range [0, 2³¹)—that is, the range of integers such that an unboxed 32-bit representation has the same value whether it is interpreted as signed or unsigned.

2.1.7 intish

Even though JavaScript only supports floating-point arithmetic, most operations can simulate integer arithmetic by coercing their result to an integer. For example, adding two integers may overflow beyond the 32-bit range, but coercing the result back to an integer produces the same 32-bit integer as integer addition in, say, C.

The intish type represents the result of a JavaScript integer operation that must be coerced back to an integer with an explicit coercion (ToInt32 for signed integers and ToUint32 for unsigned integers). Validation requires all intish values to be immediately passed to an operator or standard library that performs the appropriate coercion or else dropped via an expression statement. This way, each integer operation can be compiled directly to machine operations.

The one operator that does not support this approach is multiplication. (Multiplying two large integers can result in a large enough double that some lower bits of precision are lost.) So asm.js does not support applying the multiplication operator to integer operands. Instead, the proposed Math.imul function is recommended as the proper means of implementing integer multiplication.

2.1.8 doublish

2.1.9 unknown

2.1.10 extern

2.2 Global Types

Variables and functions defined at the top-level scope of an asm.js module can have additional types beyond the value types. These include:

• value types τ;
• ArrayBufferView types IntnArray, UintnArray, and FloatnArray;
• function types ((σ, …) → τ) ∧ … ∧ ((σ′, …) → τ′);
• function table types ((σ, …) → τ)[n]; and
• the FFI function type Function.

The "∧" notation for function types serves to represent overloaded functions and operators. For example, the Math.abs function is overloaded to accept either integers or floating-point numbers, and returns a different type in each case. Similarly, many of the operators have overloaded types.

The meta-variable γ is used to stand for global types.

3 Environments

Validating an asm.js module depends on tracking contextual information about the set of definitions and variables in scope. This section defines the environments used by the validation logic.

3.1 Global Environment

An asm.js module is validated in the context of a global environment. The global environment maps each global variable to its type as well as indicating whether the variable is mutable:

The meta-variable Δ is used to stand for a global environment.

3.2 Variable Environment

In addition to the global environment, each function body in an asm.js module is validated in the context of a variable environment. The variable environment maps each function parameter and local variable to its value type:

{ x : τ, … }

The meta-variable Γ is used to stand for a variable environment.

3.3 Environment Lookup

Looking up a variable's type

is defined by:

• τ if x : τ occurs in Γ;
• γ if x does not occur in Γ and x : mut γ or x : imm γ occurs in Δ

If x does not occur in either environment then the Lookup function has no result.

4 Syntax

Validation of an asm.js module is specified by reference to the ECMAScript grammar, but conceptually operates at the level of abstract syntax. In particular, an asm.js validator must obey the following rules:

• Empty statements (;) are always ignored, whether in the top level of a module or inside an asm.js function body.
• No variables bound anywhere in an asm.js module (whether in the module function parameter list, global variable declarations, asm.js function names, asm.js function parameters, or local variable declarations) may have the name eval or arguments.

These rules are otherwise left implicit in the rest of the specification.

5 Annotations

All variables in asm.js are explicitly annotated with type information so that their type can be statically enforced by validation.

5.1 Parameter Type Annotations

Every parameter in an asm.js function is provided with an explicit type annotation in the form of a coercion. This coercion serves two purposes: the first is to make the parameter type statically apparent for validation; the second is to ensure that if the function is exported, the arguments dynamically provided by external JavaScript callers are coerced to the expected type. For example, a bitwise OR coercion annotates a parameter as having type int:

function add1(x) {
    x = x|0; // x : int
    return (x+1)|0;
}

In an AOT implementation, the body of the function can be implemented fully optimized, and the function can be given two entry points: an internal entry point for asm.js callers, which are statically known to provide the proper type, and an external dynamic entry point for JavaScript callers, which must perform the full coercions (which might involve arbitrary JavaScript computation, e.g., via implicit calls to valueOf).

There are two recognized parameter type annotations:

The first form annotates a parameter as type int, and the second as type double.

5.2 Return Type Annotations

An asm.js function's return type is determined by the last statement in the function body, which for non-void functions is required to be a ReturnStatement. This distinguished return statement may take one of four forms:

The first form has return type double. The second has type signed. The third has return type double if n is a floating-point literal, i.e., a numeric literal with the character . in its source; alternatively, if n is an integer literal in the range [-2³¹, 2³¹), the return statement has return type signed. The fourth form has return type void.

If the last statement in the function body is not a ReturnStatement, or if the function body has no non-empty statements (other than the initial declarations and coercions—see Function Declarations), the function's return type is void.

5.3 Function Type Annotations

The type of a function declaration

is (σ,…) → τ where σ,… are the types of the parameters, as provided by the parameter type annotations, and τ is the return type, as provided by the return type annotation. The variable f is stored in the global environment with type imm (σ,…) → τ.

5.4 Variable Type Annotations

The types of variable declarations are determined by their initializer. A variable initializer may be a floating-point literal, which is any numeric literal with the character . in their source, and has type double. Alternatively, an initializer may be an integer literal in the range [-2³¹, 2³²), which has type int.

5.5 Global Variable Type Annotations

A global variable declaration is a VariableStatement node in one of several allowed forms.

A global program variable is initialized to a literal:

The global variable x is stored in the global environment with type mut τ, where τ is determined in the same way as local variable type annotations.

A standard library import is of one of the following two forms:

The variable stdlib must match the first parameter of the module declaration. The global variable x is stored in the global environment with type imm γ, where γ is the type of library y or Math.y as specified by the standard library types.

A foreign import is of one of the following three forms:

The variable foreign must match the second parameter of the module declaration. The global variable x is stored in the global environment with type imm Function for the first form, imm int for the second, and imm double for the third.

A global heap view is of the following form:

The variable stdlib must match the first parameter of the module declaration and the variable heap must match the third. The identifier view must be one of the standard ArrayBufferView type names. The global variable x is stored in the global environment with type imm view.

5.6 Function Table Types

A function table is a VariableStatement of the form:

The length of the array literal must be a power of two and all the identifiers f must map to the same type imm (σ,…) → τ in the global environment. The function table x is stored in the global environment with type imm ((σ,…) → τ)[n] where n is the length of the array literal.

6 Validation Rules

To ensure that a JavaScript function is a proper asm.js module, it must first be statically validated. This section specifies the validation rules. The rules operate on JavaScript abstract syntax, i.e., the output of a JavaScript parser. The non-terminals refer to parse nodes defined by productions in the ECMAScript grammar, but note that the asm.js validator only accepts a subset of legal JavaScript programs.

6.1 Modules

An asm.js module is a FunctionDeclaration or FunctionExpression node with the following form:

A module is valid if:

• f, stdlib, foreign, heap, and the var, fun, and table variables are all mutually distinct;
• the global environment Δ is constructed in two stages:
  1. the types from the global variable type annotations in the var declarations and the function type annotations in the fun declarations are the initial contents of Δ;
  2. the types of the function tables in the table declarations are extracted using the initial contents of Δ, and their types are added to Δ.
• each fun declaration is valid in Δ;
• each table declaration is valid in Δ;
• and exports is valid in Δ.

6.2 Export Declarations

An asm.js module's export declaration is a ReturnStatement returning either a single asm.js function or an object literal exporting multiple asm.js functions.

An export declaration node

is valid if for each f, Δ(f) = imm γ where γ is a function type (σ,…) → τ.

An export declaration node

is valid if Δ(f) = imm γ where γ is a function type (σ,…) → τ.

6.3 Function Declarations

An asm.js function declaration is a FunctionDeclaration node

A function declaration is valid if:

• Δ(f) = imm (σ,…) → τ;
• the x and y variables are all mutually distinct;
• the variable environment Γ is constructed by mapping each parameter x to its parameter type annotation and each local variable y to its variable type annotation;
• each body statement is valid in Δ and Γ with expected return type τ.

6.4 Statements

Each statement is validated in the context of a global environment Δ, a variable environment Γ, and an expected return type τ. Unless otherwise explicitly stated, a recursive validation of a subterm uses the same context as its containing term.

6.4.1 Block

A Block statement node

is valid if each stmt is valid.

6.4.2 ExpressionStatement

An ExpressionStatement node

is valid if expr is valid.

6.4.3 EmptyStatement

An EmptyStatement node is always valid.

6.4.4 IfStatement

An IfStatement node

is valid if expr validates as a subtype of int and stmt1 and stmt2 are both valid.

An IfStatement node

is valid if expr validates as a subtype of int and stmt is valid.

6.4.5 ReturnStatement

A ReturnStatement node

is valid if expr validates as a subtype of the expected return type τ.

A ReturnStatement node

is valid if the expected return type τ is void.

6.4.6 IterationStatement

An IterationStatement node

is valid if expr validates as a subtype of int and stmt is valid.

An IterationStatement node

is valid if stmt is valid and expr validates as a subtype of int.

An IterationStatement node

is valid if init validates (if present), test validates as a subtype of int (if present), update validates (if present), and body is valid.

6.4.7 BreakStatement

A BreakStatement node

is always valid.

6.4.8 ContinueStatement

A ContinueStatement node

is always valid.

6.4.9 LabelledStatement

A LabelledStatement node

is valid if body is valid.

6.4.10 SwitchStatement

A SwitchStatement node

is valid if

• test validates as a subtype of signed;
• each case validates with expected case type signed;
• each case value is distinct;
• the difference between the maximum and minimum case values is less than 2³¹;
• default is valid.

6.5 Switch Cases

Cases in a switch block are validated in the context of a global environment Δ, a variable environment Γ, an expected return type τ, and an expected case type σ. Unless otherwise explicitly stated, a recursive validation of a subterm uses the same context as its containing term.

6.5.1 CaseClause

A CaseClause node

is valid if

• the source of n does not contain a . character;
• n is in the range [-2³¹, 2³¹);
• each stmt is valid.

6.5.2 DefaultClause

A DefaultClause node

is valid if each stmt is valid.

6.6 Expressions

Each expression is validated in the context of a global environment Δ and a variable environment Γ, and validation determines the type of the expression. Unless otherwise explicitly stated, a recursive validation of a subterm uses the same context as its containing term.

6.6.1 Expression

An Expression node:

validates at type τ if expr1 validates at some type σ and expr2 validates at type τ.

6.6.2 NumericLiteral

For a NumericLiteral node:

• if the source contains a . character, the expression validates as type double;
• if the source does not contain a . character and its numeric value is in the range [-2³¹, 0), the expression validates as type signed;
• if the source does not contain a . character and its numeric value is in the range [0, 2³¹), the expression validates as type fixnum;
• if the source does not contain a . character and its numeric value is in the range [2³¹, 2³²), the expression validates as type unsigned.

Note that integer literals outside the range [-2³¹, 2³²) are invalid, i.e., fail to validate.

6.6.3 Identifier

An Identifier node

validates as Lookup(Δ, Γ, x).

6.6.4 MemberExpression

A MemberExpression node

validates at type τ if:

• Lookup(Δ, Γ, x) = view where view is an ArrayBufferView type;
• the element type of view is τ;
• the source of n does not contain a . character;
• 0 ≤ n < 2³².

A MemberExpression node

validates at type intish if:

• Lookup(Δ, Γ, x) = view where view is an ArrayBufferView type;
• the element size of view is 1;
• the element type of view is intish;
• expr validates as type int.

A MemberExpression node

validates at type τ if:

• Lookup(Δ, Γ, x) = view where view is an ArrayBufferView type;
• the element size of view is bytes;
• the element type of view is τ;
• expr validates as type intish;
• the source of n does not contain a . character;
• n = log₂(bytes).

6.6.5 AssignmentExpression

An AssignmentExpression node

validates as type τ if the nested AssignmentExpression validates as type τ and one of the following two conditions holds:

• x is bound in Γ as a supertype of τ; or
• x is not bound in Γ and is bound to a mutable supertype of τ in Δ.

An AssignmentExpression node

validates as type τ if lhs validates as type τ, rhs validates as type σ, and σ is a subtype of τ.

6.6.6 CallExpression

A CallExpression node

validates as type τ if Lookup(Δ, Γ, f) = … ∧ (σ,…) → τ ∧ … and each arg validates as a subtype of its corresponding σ.

Alternatively, the CallExpression node validates as type unknown if Lookup(Δ, Γ, f) = Function and each arg validates as a subtype of extern.

A CallExpression node

validates as type τ if:

• the source of n does not contain a . character;
• Lookup(Δ, Γ, x) = ((σ,…) → τ)[n+1], index validates as a subtype of intish;
• each arg validates as a subtype of its corresponding σ.

6.6.7 UnaryExpression

A UnaryExpression node

validates as type τ if the type of op is … ∧ (σ) → τ ∧ … and arg validates as a subtype of σ.

A UnaryExpression node of the form

validates as type signed if arg validates as a subtype of double.

6.6.8 MultiplicativeExpression

A MultiplicativeExpression node

validates as type τ if the type of op is … ∧ (σ₁, σ₂) → τ ∧ … and lhs validates as a subtype of σ₁ and rhs validates as a subtype of σ₂.

A MultiplicativeExpression node

validates as type intish if the source of n does not contain a . character and -2²⁰ < n < 2²⁰ and expr validates as a subtype of int.

6.6.9 AdditiveExpression

An AdditiveExpression node

validates as type intish if:

• each expr_i validates as type int;
• n ≤ 2²⁰.

Otherwise, an AdditiveExpression node

validates as type double if the type of op is (σ₁, σ₂) → double and lhs validates as a subtype of σ₁ and rhs validates as a subtype of σ₂.

6.6.10 ShiftExpression

A ShiftExpression node

validates as type τ if the type of op is … ∧ (σ₁, σ₂) → τ ∧ … and lhs validates as a subtype of σ₁ and rhs validates as a subtype of σ₂.

6.6.11 RelationalExpression

A RelationalExpression node

validates as type τ if the type of op is … ∧ (σ₁, σ₂) → τ ∧ … and lhs validates as a subtype of σ₁ and rhs validates as a subtype of σ₂.

6.6.12 EqualityExpression

An EqualityExpression node

validates as type τ if the type of op is … ∧ (σ₁, σ₂) → τ ∧ … and lhs validates as a subtype of σ₁ and rhs validates as a subtype of σ₂.

6.6.13 BitwiseANDExpression

A BitwiseANDExpression node

validates as type signed if lhs and rhs validate as type intish.

6.6.14 BitwiseXORExpression

A BitwiseXORExpression node

validates as type signed if lhs and rhs validate as type intish.

6.6.15 BitwiseORExpression

A BitwiseORExpression node

validates as type signed if lhs and rhs validate as type intish.

6.6.16 ConditionalExpression

A ConditionalExpression node

validates as type τ if:

• τ = int or τ = double;
• test validates as type int;
• cons and alt validate as subtypes of τ.

6.6.17 Parenthesized Expression

A parenthesized expression node

validates as type τ if expr validates as type τ.

7 Linking

An AOT implementation of asm.js must perform some internal dynamic checks at link time to be able to safely generate AOT-compiled exports. If any of the dynamic checks fails, the result of linking cannot be an AOT-compiled module. The dynamically checked invariants are:

• control must reach the module's return statement without throwing;
• the heap object (if provided) must be an instance of ArrayBuffer;
• the heap object's byteLength must be a multiple of 4096;
• the heap object's byteLength must be a power of 2;
• the heap object's byteLength must be no greater than 2³¹ (assuming the engine even allows ArrayBuffers that large);
• all view objects must be true instances of their respective typed array types;
• all globals taken from the stdlib object must implement the semantics of the corresponding standard library of the same name (in practice, they must be the SameValue as the specified library function or value).

If any of these conditions is not met, it is generally unsafe to produce an AOT-compiled module object, and the engine should fall back to an interpreted or JIT-compiled implementation.

8 Operators

8.1 Unary Operators

8.2 Binary Operators

9 Standard Library

10 Heap View Types

Acknowledgements

Thanks to Martin Best, Brendan Eich, Andrew McCreight, and Vlad Vukićević for feedback and encouragement.

Thanks to Michael Bebenita for improved diagrams.