Skip to content

Add a FutureFeatures.md section discussing full IEEE-754 conformance. #171

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 16, 2015
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
2 changes: 2 additions & 0 deletions AstSemantics.md
Original file line number Diff line number Diff line change
Expand Up @@ -368,6 +368,8 @@ Floating point arithmetic follows the IEEE-754 standard, except that:
- Not all operations required by IEEE-754 are provided directly. However,
WebAssembly includes enough functionality to support reasonable library
implementations of the remaining required operations.
- The strategy for gradual underflow (subnormals) is
[under discussion](https://github.com/WebAssembly/design/issues/148).

* `float32.add`: addition
* `float32.sub`: subtraction
Expand Down
32 changes: 32 additions & 0 deletions FutureFeatures.md
Original file line number Diff line number Diff line change
Expand Up @@ -301,3 +301,35 @@ tradeoffs.
* `float32.pow`: exponentiate

The rounding behavior of these operations would need clarification.

## Full IEEE-754 conformance

WebAssembly floating point conforms IEEE-754 in most respects, but there are a
few areas that are [not yet covered](AstSemantics.md#floating-point-operations).

IEEE-754 NaN bit pattern propagation is presently permitted but not required.
It would be possible for WebAssembly to require it in the future.

To support exceptions and alternate rounding modes, one option is to define an
alternate form for each of `add`, `sub`, `mul`, `div`, `sqrt`, and `fma`. These
alternate forms would have extra operands for rounding mode, masked traps, and
old flags, and an extra result for a new flags value. These operations would be
fairly verbose, but it's expected that their use cases will specialized. This
approach has the advantage of exposing no global (even if only per-thread)
control and status registers to applications, and to avoid giving the common
operations the possibility of having side effects.

Debugging techniques are also important, but they don't necessarily need to be
in the spec itself. Implementations are welcome (and encouraged) to support
non-standard execution modes, enabled only from developer tools, such as modes
with alternate rounding, or evaluation of floating point expressions at greater
precision, to support [techniques for detecting numerical instability]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is too new, but Herbie sounds interesting too!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These paragraphs are addressing important use cases on popular hardware platforms that typically involve global (per-thread) floating point control/status registers, which is something that we may wish to avoid. The previous paragraph covers local override use cases, which covers most of the use cases I'm aware of. This paragraph explains how we can address the main use case that actually wants a global mode, by observing that debug techniques don't necessarily need to be specified in the spec. And I tossed in the idea of greater precision evaluation because it's another technique mentioned in the same paper which doesn't end up being completely futile and which would be straight-forward to implement.

Herbie looks neat, and correct me if I'm wrong, but it doesn't appear to require any special platform support, so there'd be no reason why users can't use it on WebAssembly implementations.

(http://www.cs.berkeley.edu/~wkahan/Mindless.pdf).

To help developers find the sources of floating point exceptions,
implementations may wish to provide a mode where NaN values are produced with
payloads containing identifiers helping programmers locate where the NaNs first
appeared. Another option would be to offer another non-standard execution mode,
enabled only from developer tools, that would enable traps on selected floating
point exceptions, however care should be taken, since not all floating point
exceptions indicate bugs.