This specification defines asm.js, a strict subset of JavaScript that can be used as a lowlevel, efficient target language for compilers. This sublanguage effectively describes a sandboxed virtual machine for memoryunsafe languages like C or C++. A combination of static and dynamic validation allows JavaScript engines to employ an aheadoftime (AOT) optimizing compilation strategy for valid asm.js code.
This specification is working towards a candidate draft for asm.js version 1. Mozilla's SpiderMonkey JavaScript engine provides an optimizing implementation of this draft.
case
and default
validation rules
mut
doublish
to double?
for symmetry with float?
Math.fround
and singleton fround
type
float
support for operators and Math
functions
float
to legal result types for ConditionalExpression
Math.min
and Math.max
Math.abs
is signed
unsigned
is not an extern
type
!
operator to UnaryExpression operators
~~
to Unary Operators section
NumericLiteral
cases everywhere
unknown
, which is no longer needed
%
is intish
This specification defines asm.js, a strict subset of JavaScript that can be used as a lowlevel, 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 floatingpoint arithmetic, firstorder function definitions, and function pointers.
The asm.js programming model is built around integer and floatingpoint 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:
As an example of the former, if we have
an Int32Array
view of the heap called HEAP32
, then we can load the
32bit integer at byte offset p
:
HEAP32[p >> 2]0
The shift converts the byte offset to a 32bit element offset, and
the bitwise coercion ensures that an outofbounds 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 builtin 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.
The asm.js sublanguage is defined by a static type system that can be checked at JavaScript parse time. Validation of asm.js code is designed to be "payasyougo" 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.
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 aheadoftime (AOT) compilation. Moreover, the code generated by an AOT compiler can be quite efficient, featuring:
Code that fails to validate must fall back to execution by traditional means, e.g., interpretation and/or justintime (JIT) compilation.
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 compiletime 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.
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:
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 geometricMean(start, end) { start = start0; // start has type int end = end0; // end has type int return +exp(+logSum(start, end) / +((end  start)0)); }
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 welltyped; 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.
The following is a small but complete example of an asm.js module.
function GeometricMean(stdlib, foreign, buffer) { "use asm"; var exp = stdlib.Math.exp; var log = stdlib.Math.log; var values = new stdlib.Float64Array(buffer); function logSum(start, end) { start = start0; end = end0; var sum = 0.0, p = 0, q = 0; // asm.js forces byte addressing of the heap by requiring shifting by 3 for (p = start << 3, q = end << 3; (p0) < (q0); p = (p + 8)0) { sum = sum + +log(values[p>>3]); } return +sum; } function geometricMean(start, end) { start = start0; end = end0; return +exp(+logSum(start, end) / +((end  start)0)); } return { geometricMean: geometricMean }; }
In a JavaScript engine that supports AOT compilation of asm.js, calling the module on a proper global object and heap buffer would link the exports object to use the statically compiled functions.
var heap = new ArrayBuffer(0x10000); // 64k heap init(heap, START, END); // fill a region with input values var fast = GeometricMean(window, null, heap); // produce exports object linked to AOTcompiled code fast.geometricMean(START, END); // computes geometric mean of input values
By contrast, calling the module on a standard library object
containing something other than the true Math.exp
or
Math.log
would fail to produce AOTcompiled code:
var bogusGlobal = { Math: { exp: function(x) { return x; }, log: function(x) { return x; } }, Float64Array: Float64Array }; var slow = GeometricMean(bogusGlobal, null, heap); // produces purelyinterpreted/JITted version console.log(slow.geometricMean(START, END)); // computes bizarrogeometric mean thanks to bogusGlobal
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.
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 32bit integers and integer arithmetic.
The types of asm.js values are interrelated 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., nonasm.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 metavariables σ and τ are used to stand for value types.
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.
The double
type is the type of ordinary
JavaScript doubleprecision floatingpoint numbers.
The signed
type is the type of signed
32bit integers. While there is no direct concept of integers in
JavaScript, 32bit integers can be represented as doubles, and integer
operations can be performed with JavaScript arithmetic, relational,
and bitwise operators.
The unsigned
type is the type of unsigned
32bit integers. Again, these are not a firstclass concept in
JavaScript, but can be represented as floatingpoint numbers.
The int
type is the type of 32bit 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
32bit 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 (nonasm.js) JavaScript code.
The fixnum
type is the type of integers in the
range [0, 2^{31})—that is, the range of integers such
that an unboxed 32bit representation has the same value whether it is
interpreted as signed or unsigned.
Even though JavaScript only supports floatingpoint arithmetic, most operations can simulate integer arithmetic by coercing their result to an integer. For example, adding two integers may overflow beyond the 32bit range, but coercing the result back to an integer produces the same 32bit 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.
The double?
type represents operations that
are expected to produce a double
but may also produce
undefined
, and so must be coerced back to a number
via ToNumber.
Specifically, reading out of bounds from a typed array
produces undefined
.
The float
type is the type of 32bit
floatingpoint numbers.
The float?
type represents operations that
are expected to produce a float
but, similar
to double?
, may also produce undefined
and
so must be coerced back to a 32bit floating point number
via fround.
Specifically, reading out of bounds from a typed array
produces undefined
.
Similar to integers, JavaScript can almost support 32bit floatingpoint arithmetic, but requires extra coercions to properly emulate the 32bit semantics. As proved in When is double rounding innocuous? (Figueroa 1995), both the 32 and 64bit versions of standard arithmetic operations produce equivalent results when given 32bit inputs and coerced to 32bit outputs.
The floatish
type,
like intish
, represents the result of a JavaScript 32bit
floatingpoint operations that must be coerced back to a 32bit
floatingpoint value with an
explicit fround
coercion. Validation requires all floatish
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 32bit floatingpoint operation can be
compiled
directly to machine operations.
extern
type represents the root
of all types that can escape back into external JavaScript—in
other words, the light boxes in the above diagram.
Variables and functions defined at the toplevel scope of an asm.js module can have additional types beyond the value types. These include:
ArrayBufferView
types IntnArray
, UintnArray
, and FloatnArray
;
…
) → τ) ∧ … ∧ ((σ′, σ′…
) → τ′);
fround
of Math.fround
; and
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 floatingpoint numbers, and
returns a different type in each case. Similarly, many of
the operators have overloaded types.
The metavariable γ is used to stand for global types.
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.
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 metavariable Δ is used to stand for a global 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 metavariable Γ is used to stand for a variable environment.
Looking up a variable's type
is defined by:
mut
γ or x : imm
γ
occurs in Δ
If x does not occur in either environment then the Lookup function has no result.
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:
;
) are always ignored, whether in
the top level of a module or inside an asm.js function body.
eval
or arguments
.
These rules are otherwise left implicit in the rest of the specification.
All variables in asm.js are explicitly annotated with type information so that their type can be statically enforced by validation.
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 = x0; // 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 three recognized parameter type annotations:
=
x:Identifier0;
=
+
x:Identifier;
=
f:Identifier(
x:Identifier);
The first form annotates a parameter as type int
, the
second as type double
, and the third as
type float
. In the latter case,
Lookup(Δ, Γ, f) must
be fround
.
An asm.js function's formal return type is determined by
the last statement in the function body, which for
nonvoid
functions is required to be
a ReturnStatement. This distinguished return statement may
take one of five forms:
return +
e:Expression;
return
e:Expression0;
return
n:
NumericLiteral;
return
f:Identifier(
arg:Expression);
return;
The first form has return type double
. The second has
type signed
. The third has return
type double
if n is composed of a floatingpoint
literal, i.e., a numeric literal with the character .
in
its source; alternatively, if n is composed of an integer
literal and has its value in the range [2^{31},
2^{31}), the return statement has return
type signed
. The fourth form has return
type float
, and the fifth has return
type void
.
If the last statement in the function body is not
a ReturnStatement, or if the function body has no nonempty
statements (other than the initial declarations and
coercions—see Function
Declarations), the function's return type is void
.
The type of a function declaration
function
f:Identifier(
x:Identifier…) {
x:Identifier =
AssignmentExpression;
…
var
y:Identifier =

NumericLiteral Identifier(

NumericLiteral)
,
… …
body:Statement…}
is (σ,…) → τ where σ,… are the
types of the parameters, as provided by
the parameter type
annotations, and τ is the formal return type, as provided by
the return type annotation. The
variable f is stored in
the global environment with
type imm
(σ,…) → τ.
The types of variable declarations are determined by their initializer, which may take one of two forms:

NumericLiteral(
n:
NumericLiteral)
In the first case, the variable type is double
if n's source contains the character .
;
otherwise n may be an integer literal in the range
[2^{31}, 2^{32}), in which case the variable type
is int
.
In the second case, the variable type
is float
. Lookup(Δ, Γ, f)
must be fround
and n must be a floatingpoint
literal with the character .
in its source.
A global variable declaration is a VariableStatement node in one of several allowed forms. Validating global variable annotations takes a Δ as input and produces as output a new Δ′ by adding the variable binding to Δ.
A global program variable is initialized to a literal:
var
x:Identifier =
n:
NumericLiteral;
var
x:Identifier =
f:Identifier(
n:
NumericLiteral);
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:
var
x:Identifier =
stdlib:Identifier.
y:Identifier;
var
x:Identifier =
stdlib:Identifier.Math.
y:Identifier;
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:
var
x:Identifier =
foreign:Identifier.
y:Identifier;
var
x:Identifier =
foreign:Identifier.
y:Identifier0;
var
x:Identifier =
+
foreign:Identifier.
y:Identifier;
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, mut
int
for the second, and mut double
for the third.
A global heap view is of the following form:
var
x:Identifier = new
stdlib:Identifier.
view:Identifier(
heap:Identifier);
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.
A function table is a VariableStatement of the form:
var
x:Identifier = [
f_{0}:Identifier,
f:Identifier,
…];
The function table x is stored in
the global environment with
type imm
((σ,…) → τ)[n]
where (σ,…) → τ is the type of f in the
global environment and n is the length of the array literal.
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 nonterminals 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.
The result of a validation operation is either a success, indicating that a parse node is statically valid asm.js, or a failure, indicating that the parse node is statically invalid asm.js.
The ValidateModule rule validates an asm.js module, which is either a FunctionDeclaration or FunctionExpression node.
Validating a module of the form
function
f:Identifier_{opt}(
stdlib:Identifier
foreign:Identifier ,,
heap:Identifier _{opt} _{opt} _{opt}) {
"use asm";
var:VariableStatement…
fun:FunctionDeclaration…
table:VariableStatement…
exports:ReturnStatement}
succeeds if:
The ValidateExport rule validates an asm.js module's export declaration. An export declaration is a ReturnStatement returning either a single asm.js function or an object literal exporting multiple asm.js functions.
Validating an export declaration node
return
{
x:Identifier :
f:Identifier,
… };
succeeds if for each f, Δ(f) = imm
γ where γ is a function type (σ,…) →
τ.
Validating an export declaration node
return
f:Identifier;
succeeds if Δ(f) = imm
γ where
γ is a function type (σ,…) → τ.
The ValidateFunctionTable rule validates an asm.js module's function table declaration. A function table declaration is a VariableStatement binding an identifier to an array literal.
Validating a function table of the form
var
x:Identifier = [
f:Identifier,
…];
succeeds if:
imm
((σ,…) → τ)[n]; and
The ValidateFunction rule validates an asm.js function declaration, which is a FunctionDeclaration node.
Validating a function declaration of the form
function
f:Identifier(
x:Identifier,
…) {
x:Identifier =
AssignmentExpression;
…
var
y:Identifier =

NumericLiteral Identifier(

NumericLiteral)
,
… …
body:Statement…}
succeeds if:
imm
(σ,…) → τ;
The ValidateStatement rule validates an asm.js statement. 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.
Validating a Block statement node
{
stmt:Statement… }
succeeds if ValidateStatement succeeds for each stmt.
Validating an ExpressionStatement node
;
succeeds if ValidateCall
succeeds for cexpr with actual return type void
.
Validating an ExpressionStatement node
;
succeeds if ValidateExpression succeeds for expr with some type σ.
Validating an EmptyStatement node always succeeds.
Validating an IfStatement node
if (
expr:Expression )
stmt_{1}:Statement else
stmt_{2}:Statement
succeeds
if ValidateExpression
succeeds for expr with a subtype of int
and ValidateStatement
succeeds for stmt_{1} and stmt_{2}.
Validating an IfStatement node
if (
expr:Expression )
stmt:Statement
succeeds
if ValidateExpression
succeeds for expr with a subtype of int
and ValidateStatement
succeeds for stmt.
Validating a ReturnStatement node
return
expr:Expression ;
succeeds if ValidateExpression succeeds for expr with a subtype of the expected return type τ.
Validating a ReturnStatement node
return ;
succeeds if the expected return type τ is void
.
Validating an IterationStatement node
while (
expr:Expression )
stmt:Statement
succeeds
if ValidateExpression
succeeds for expr with a subtype of int
and ValidateStatement
succeeds for stmt.
Validating an IterationStatement node
do
stmt:Statement while (
expr:Expression ) ;
succeeds
if ValidateStatement
succeeds for stmt
and ValidateExpression
succeeds for expr with a subtype of int
.
Validate an IterationStatement node
for (
init:ExpressionNoIn_{opt} ;
test:Expression_{opt} ;
update:Expression_{opt} )
body:Statement
succeeds if:
int
(if
present);
Validating a BreakStatement node
break
Identifier_{opt} ;
always succeeds.
Validating a ContinueStatement node
continue
Identifier_{opt} ;
always succeeds.
Validating a LabelledStatement node
:
body:Statement
succeeds if ValidateStatement succeeds for body.
Validating a SwitchStatement node
switch (
test:Expression )
{
case:CaseClause… default:DefaultClause_{opt} }
succeeds if
signed
;
Cases in a switch
block are 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.
Validating a CaseClause node
case
n:
NumericLiteral :
stmt:Statement…
succeeds if
.
character;
The default case in a switch
block 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.
Validating a DefaultClause node
default :
stmt:Statement…
succeeds if ValidateStatement succeeds for each stmt.
Each expression is validated in the context of a global environment Δ and a variable environment Γ, and validation produces the type of the expression as a result. Unless otherwise explicitly stated, a recursive validation of a subterm uses the same context as its containing term.
Validating an Expression node
,
… ,
expr_{n}:AssignmentExpression
succeeds with type τ if for every i < n, one of the following conditions holds:
void
; or
and ValidateExpression succeeds for expr_{n} with type τ.
Validating a NumericLiteral node
double
if the source contains a .
character; or
validates as type double
;
fixnum
if the source does not contain a .
character and its numeric value is in the range [0, 2^{31}); or
unsigned
if the source does not contain a .
character and its numeric value is in the range [2^{31}, 2^{32}).
Note that the case of negative integer constants is handled under UnaryExpression.
Note that integer literals outside the range [0, 2^{32}) are invalid, i.e., fail to validate.
Validating an Identifier node
succeeds with type τ if Lookup(Δ, Γ, x) = τ.
Validating a CallExpression node succeeds with
type float
if ValidateFloatCoercion
succeeds.
Validating a MemberExpression node succeeds with type τ if ValidateHeapAccess succeeds with load type τ.
Validating an AssignmentExpression node
=
expr:AssignmentExpression
succeeds with type τ if ValidateExpression succeeds for the nested AssignmentExpression with type τ and one of the following two conditions holds:
Validating an AssignmentExpression node
=
rhs:AssignmentExpression
succeeds with type τ if ValidateExpression succeeds for rhs with type τ and ValidateHeapAccess succeeds for lhs with τ as one of its legal store types.
Validating a UnaryExpression node of the form

NumericLiteral
succeeds with type signed
if
the NumericLiteral source does not contain a .
character and the numeric value of the expression is in the range
[2^{31}, 0).
Validating a UnaryExpression node of the form
+
cexpr:CallExpression
succeeds with type double
if ValidateCall succeeds
for cexpr with actual return type double
.
Validating a UnaryExpression node of the form
+

~
!
arg:UnaryExpression
succeeds with type τ if the type of op is … ∧ (σ) → τ ∧ … and ValidateExpression succeeds with a subtype of σ.
Validating a UnaryExpression node of the form
~~
arg:UnaryExpression
succeeds with type signed
if ValidateExpression
succeeds for arg with a subtype of either double
or float?
.
Validating a MultiplicativeExpression node
*
/
%
rhs:UnaryExpression
succeeds with type τ if:
Validating a MultiplicativeExpression node
*
n:
NumericLiteral
NumericLiteral *
expr:UnaryExpression
succeeds with type intish
if the source of n
does not contain a .
character and 2^{20}
< n < 2^{20}
and ValidateExpressionexpr with a subtype of int
.
Validating an AdditiveExpression node
+

… +

expr_{n}
succeeds with type intish
if:
int
;
Otherwise, validating an AdditiveExpression node
+

rhs:MultiplicativeExpression
succeeds with type double
if:
double
;
Validating a ShiftExpression node
<<
>>
>>>
rhs:AdditiveExpression
succeeds with type τ if
Validating a RelationalExpression node
<
>
<=
>=
rhs:ShiftExpression
succeeds with type τ if
Validating an EqualityExpression node
==
!=
rhs:RelationalExpression
succeeds with type τ if
Validating a BitwiseANDExpression node
&
rhs:EqualityExpressionsucceeds with type signed
if ValidateExpression
succeeds for lhs and rhs with
a subtype of intish
.
Validating a BitwiseXORExpression node
^
rhs:BitwiseANDExpressionsucceeds with type signed
if ValidateExpression
succeeds for lhs and rhs with
a subtype of intish
.
Validating a BitwiseORExpression node
0
succeeds with type signed
if ValidateCall succeeds
for cexpr with actual return type signed
.
Validating a BitwiseORExpression node

rhs:BitwiseXORExpressionsucceeds with type signed
if ValidateExpression
succeeds for lhs and rhs with
a subtype of intish
.
Validating a ConditionalExpression node
?
cons:AssignmentExpression :
alt:AssignmentExpression
succeeds with type τ if:
int
, double
, or float
;
int
;
Validating a parenthesized expression node
(
expr:Expression )
succeeds with type τ if ValidateExpression succeeds for expr with type τ.
Each function call expression is validated in the context of a global environment Δ and a variable environment Γ, and validates against an actual return type τ, which was provided from the context in which the function call appears. A recursive validation of a subterm uses the same context as its containing term.
Validating a CallExpression node
(
arg:Expression,
…)
with actual return type τ succeeds if one of the following conditions holds:
…
)
→ τ ∧ …
and ValidateExpression
succeeds for the first n arg_{i} expressions
with subtypes of their corresponding σ_{i} and
the remaining arg expressions with subtypes of σ.
Alternatively, validating the CallExpression succeeds with
any actual return type τ other than float
if Lookup(Δ, Γ, f)
= Function
and ValidateExpression
succeeds for each arg with a subtype of extern
.
Validating a CallExpression node
[
index:Expression &
n:
NumericLiteral](
arg:Expression,
…)
succeeds with actual return type τ if:
.
character;
intish
; and
Each heap access expression is validated in the context of a global
environment Δ and a variable environment Γ, and validation
produces a load type as well as a set of legal store
types as a result. These types are determined by
the heap view types corresponding to
each ArrayBufferView
type.
Validating a MemberExpression node
[
n:
NumericLiteral]
succeeds with load type σ and store types { τ, … } if:
ArrayBufferView
type;
.
character;
Validating a MemberExpression node
[
expr:Expression >>
n:
NumericLiteral]
succeeds with load type σ and store types { τ, … } if:
ArrayBufferView
type;
intish
;
.
character;
A call to the fround
coercion is validated in the
context of a global environment Δ and a variable environment
Γ and validates as the type float
.
Validating a CallExpression node
(
cexpr:CallExpression)
succeeds with type float
if Lookup(Δ,
Γ, f) = fround
and ValidateCall succeeds for
cexpr with actual return type float
.
Alternatively, validating a CallExpression node
(
arg:Expression)
succeeds with type float
if Lookup(Δ,
Γ, f) = fround
and ValidateExpression
succeeds for arg with type τ, where τ is a subtype
of floatish
, double?
, signed
,
or unsigned
.
An AOT implementation of asm.js must perform some internal dynamic checks at link time to be able to safely generate AOTcompiled exports. If any of the dynamic checks fails, the result of linking cannot be an AOTcompiled module. The dynamically checked invariants are:
return
statement without throwing;
ArrayBuffer
;
byteLength
must be either 2^{n} for n in [12, 24) or 2^{24} · n for n ≥ 1;
If any of these conditions is not met, AOT compilation may produce invalid results so the engine should fall back to an interpreted or JITcompiled implementation.
Unary Operator  Type 

+ 
(signed ) → double ∧( unsigned ) → double ∧( double? ) → double ∧( float? ) → double

 
(int ) → intish ∧( double? ) → double ∧( float? ) → floatish

~ 
(intish ) → signed 
! 
(int ) → int 
Note that the special combined operator ~~
may be used
as a coercion from double
or float?
to signed
; see Unary
Expressions.
Binary Operator  Type 

+ 
(double , double ) → double ∧( float? , float? ) → floatish

 
(double? , double? ) → double ∧( float? , float? ) → floatish

* 
(double? , double? ) → double ∧( float? , float? ) → floatish

/ 
(signed , signed ) → intish ∧( unsigned , unsigned ) → intish ∧( double? , double? ) → double ∧( float? , float? ) → floatish

% 
(signed , signed ) → intish ∧( unsigned , unsigned ) → intish ∧( double? , double? ) → double

 , & , ^ , << , >> 
(intish , intish ) → signed 
>>> 
(intish , intish ) → unsigned 
< , <= , > , >= , == , != 
(signed , signed ) → int ∧( unsigned , unsigned ) → int ∧( double , double ) → int ∧( float , float ) → int

Standard Library  Type 

Infinity NaN

double 
Math.acos Math.asin Math.atan Math.cos Math.sin Math.tan Math.exp Math.log

(double? ) → double 
Math.ceil Math.floor Math.sqrt

(double? ) → double ∧( float? ) → float

Math.abs 
(signed ) → signed ∧( double? ) → double ∧( float? ) → float

Math.min Math.max

(int , int … ) → signed ∧( double , double … ) → double

Math.atan2 Math.pow

(double? , double? ) → double 
Math.imul 
(int , int ) → signed 
Math.fround 
fround 
Math.E Math.LN10 Math.LN2 Math.LOG2E Math.LOG10E Math.PI Math.SQRT1_2 Math.SQRT2 
double 
View Type  Element Size (Bytes)  Load Type  Store Types 

Uint8Array 
1  intish 
intish 
Int8Array 
1  intish 
intish 
Uint16Array 
2  intish 
intish 
Int16Array 
2  intish 
intish 
Uint32Array 
4  intish 
intish 
Int32Array 
4  intish 
intish 
Float32Array 
4  float? 
floatish , double? 
Float64Array 
8  double? 
float? , double? 
Thanks to Martin Best, Brendan Eich, Andrew McCreight, and Vlad Vukićević for feedback and encouragement.
Thanks to Benjamin Bouvier, Douglas Crosher, and Dan Gohman for
contributions to the design and implementation, particularly for
float
.
Thanks to Jesse Ruderman and C. Scott Ananian for bug reports.
Thanks to Michael Bebenita for diagrams.