Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 9 additions & 8 deletions AstSemantics.md
Original file line number Diff line number Diff line change
Expand Up @@ -524,14 +524,15 @@ When the result of any arithmetic operation other than `neg`, `abs`, or
the implicit leading digit of the significand) of the NaN are computed as
follows:

- If the operation has any NaN input values, implementations may select any of
them to be the result value, but with the most significant bit of the
fraction field overwritten to be 1.

- If the implementation does not choose to use an input NaN as a result value,
or if there are no input NaNs, the result value has a nondeterministic sign
bit, a fraction field with 1 in the most significant bit and 0 in the
remaining bits.
- If the fraction fields of all NaN inputs to the instruction all consist
of 1 in the most significant bit and 0 in the remaining bits, or if there are
no NaN inputs, the result is a NaN with a nondeterministic sign bit, 1 in the
most significant bit of the fraction field, and all zeros in the remaining
bits of the fraction field.

- Otherwise the result is a NaN with a nondeterministic sign bit, 1 in the most
significant bit of the fraction field, and nondeterminsitic values in the
remaining bits of the fraction field.

32-bit floating point operations are as follows:

Expand Down
27 changes: 12 additions & 15 deletions Rationale.md
Original file line number Diff line number Diff line change
Expand Up @@ -340,23 +340,20 @@ architectures there may be a need to revisit some of the decisions:
## NaN bit pattern propagation

In general, WebAssembly's floating point operations provide the guarantee that
a NaN returned from an operation won't have new bits set in its fractional
field, except the most significant bit.
if all NaNs passed to an operation are "canonical", the result is "canonical",
where canonical means the most significant bit of the fraction field is 1, and
the trailing bits are all 0.

This is intended to support interpreters running on WebAssembly that use
NaN-boxing, because they can rely on the property that if an arithmetic
operation has no non-canonical NaNs as input, its output is also canonical.

The specific bit-pattern rules are modeled after what numerous popular
hardware architectures do. Note that IEEE 754-1985 had looser rules for NaN
bit pattern encodings than IEEE 754-2008, and some hardware architectures,
notably MIPS, historically behaved differently than other architectures.
However, since the publication of IEEE 754-2008, MIPS has added a configuration
mode (NAN2008) which enables support for the new rules.

In particular, the sign bit of generated NaNs is nondeterministic since x86
generates NaNs with it set to 1 while other architectures generate NaNs with it
set to 0.
NaN-boxing, because they don't have to canonicalize the output of an arithmetic
instruction if they know the inputs are canonical.

When the inputs are non-canonical, the resulting NaN is nondeterministic, to
accomodate a variety of known hardware behaviors: returning one of the input
NaNs, returning a canonical NaN, or bitwise-or'ing the input NaNs together.

The sign bit of generated NaNs is always nondeterministic since x86 generates
NaNs with it set to 1 while other architectures generate NaNs with it set to 0.


## Integer operations
Expand Down