aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Wagner <mail@lukewagner.name>2015-06-11 10:37:44 -0500
committerLuke Wagner <mail@lukewagner.name>2015-06-11 10:37:44 -0500
commitc6b5be06dd2f505e5a669e0c5bf3fb7f25c98677 (patch)
tree11490576bb3cca243f070a1c1b01ff97e60ababd
parent5a7008cb8b145d0944edcb196f663ab51e888d92 (diff)
downloadnanowasm-design-c6b5be06dd2f505e5a669e0c5bf3fb7f25c98677.tar.gz
Update for comments
-rw-r--r--Nondeterminism.md18
1 files changed, 9 insertions, 9 deletions
diff --git a/Nondeterminism.md b/Nondeterminism.md
index f93e807..aa6bb66 100644
--- a/Nondeterminism.md
+++ b/Nondeterminism.md
@@ -2,10 +2,10 @@
WebAssembly is a [portable](Portability.md) sandboxed platform with limited,
local, nondeterminism.
- * *limited*: non-deterministic execution can only occur in a small number of
+ * *Limited*: non-deterministic execution can only occur in a small number of
well-defined cases (described below) and, in those cases, the implementation
may select from a limited set of possible behaviors.
- * *local*: when non-deterministic execution occurs, the effect is local,
+ * *Local*: when non-deterministic execution occurs, the effect is local,
there is no "spooky action at a distance".
The limited, local, non-deterministic model implies:
@@ -18,18 +18,16 @@ The limited, local, non-deterministic model implies:
* WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons).
Ideally, WebAssembly would be fully deterministic (except where nondeterminism
-was introduced by the API, like `random` or input events). Nondeterminism is only
-specified as a compromise when there is no other practical way to achieve
-[portable](Portability.md), near-native performance.
+was essential to the API, like random number generators, date/time functions or
+input events). Nondeterminism is only specified as a compromise when there is no
+other practical way to achieve [portable](Portability.md) native performance.
The following is a list of the places where the WebAssembly specification
currently admits nondeterminism:
- - [Races between threads](EssentialPostMVPFeatures.md#threads)
+ - [No sequential consistency guarantee for programs which contain races](EssentialPostMVPFeatures.md#threads)
- - [Out of bounds heap accesses may want some flexibility](AstSemantics.md#accessing-the-heap)
-
- - [Environment-dependent resource limits may be exhausted](AstSemantics.md)
+ - [Out of bounds heap accesses may want some flexibility](AstSemantics.md#out-of-bounds)
- [NaN bit patterns](AstSemantics.md#floating-point-operations)
@@ -37,6 +35,8 @@ currently admits nondeterminism:
- In SIMD.js, floating point values may or may not have subnormals flushed to zero.
- In SIMD.js, operations ending in "Approximation" return approximations that may vary between platforms.
+ - Environment-dependent resource limits may be exhausted
+
## Note for users of C, C++, and similar languages
Some operations which have fully defined behavior in WebAssembly itself may nonetheless have undefined behavior at the source code level. For example, while unaligned memory access is fully defined in WebAssembly, C and C++ compilers make no guarantee that a (non-packed) unaligned memory access at the source level is harmlessly translated into an unaligned memory access in WebAssembly. And in practice, popular C and C++ compilers do optimize on the assumption that alignment rules are followed, meaning that they don't always preserve program behavior otherwise.