From 2c447e38e70a4d3ad21792f42acab309cd36a0b1 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Wed, 10 Jun 2015 13:48:02 +0200 Subject: Use cases. WebAssembly: what is it good for? Unordered and incomplete list of use cases for WebAssembly. --- UseCases.md | 51 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 UseCases.md diff --git a/UseCases.md b/UseCases.md new file mode 100644 index 0000000..23fa652 --- /dev/null +++ b/UseCases.md @@ -0,0 +1,51 @@ +# Use Cases + +WebAssembly's [high-level goals](HighLevelGoals.md) define *what* WebAssembly +aims to achieve, and in *which order*. *How* WebAssembly achieves its goals is +documented for [Web](Web.md) and [non-Web](NonWeb.md) platforms. The following +list of use cases is an unordered and incomplete list of what WebAssembly's +designers think WebAssembly will *enable*. + +## Inside the browser + +* Common NPAPI users, within the web’s security model. +* Better execution for languages that are currently cross-compiled (GWT, Dart, + C/C++). +* Image / video editing. +* Games: + - Casual games that need to start quickly. + - AAA games that have heavy assets. + - Game portals (mixed-party/origin content). +* Peer-to-peer applications (games, collaborative editing, decentralized and + centralized). +* Music applications (streaming, caching). +* Image recognition. +* Live video augmentation (e.g. putting hats on people's heads). +* VR and augmented reality (very low latency). +* CAD applications. +* Scientific visualization and simulation. +* Interactive educational software, and news articles. +* Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, …). +* Language interpreters. +* Language virtual machines. +* Entire UNIX user-space environment, with existing UNIX applications. +* Developer tooling (editors, compilers, debuggers, …). +* Remote desktop. +* VPN. +* Encryption. +* Local web server. +* Fat client for enterprise applications (e.g. databases). + +# Outside the browser + +* Game distribution service (portable and secure). +* Server-side compute of untrusted code. +* Server-side application. +* Hybrid native apps on mobile devices. + +# How WebAssembly can be used + +* Entire code base in Web Assembly. +* Main frame in Web Assembly, but the UI is in JavaScript / HTML. +* Re-use existing code by targeting Web Assembly, embedded in a larger + JavaScript / HTML application. -- cgit v1.2.3 From 8efa809874ec4edb7b47683f73931578056f38f1 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Wed, 10 Jun 2015 16:52:02 +0200 Subject: Intrp & VM. --- UseCases.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/UseCases.md b/UseCases.md index 23fa652..f742665 100644 --- a/UseCases.md +++ b/UseCases.md @@ -26,8 +26,7 @@ designers think WebAssembly will *enable*. * Scientific visualization and simulation. * Interactive educational software, and news articles. * Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, …). -* Language interpreters. -* Language virtual machines. +* Language interpreters and virtual machines. * Entire UNIX user-space environment, with existing UNIX applications. * Developer tooling (editors, compilers, debuggers, …). * Remote desktop. -- cgit v1.2.3 From 1b9845738c87e9ff74126c5396326520ef5c492d Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Wed, 10 Jun 2015 16:53:30 +0200 Subject: NPAPI: only for web APIs. --- UseCases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UseCases.md b/UseCases.md index f742665..215bfab 100644 --- a/UseCases.md +++ b/UseCases.md @@ -8,7 +8,7 @@ designers think WebAssembly will *enable*. ## Inside the browser -* Common NPAPI users, within the web’s security model. +* Common NPAPI users, within the web's security model and APIs. * Better execution for languages that are currently cross-compiled (GWT, Dart, C/C++). * Image / video editing. @@ -26,7 +26,7 @@ designers think WebAssembly will *enable*. * Scientific visualization and simulation. * Interactive educational software, and news articles. * Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, …). -* Language interpreters and virtual machines. +* Language interpreters virtual machines. * Entire UNIX user-space environment, with existing UNIX applications. * Developer tooling (editors, compilers, debuggers, …). * Remote desktop. -- cgit v1.2.3 From 15b3a944bbb85119d62feac5482bca1f0779757d Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Wed, 10 Jun 2015 17:18:28 +0200 Subject: Move NPAPI. --- UseCases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UseCases.md b/UseCases.md index 215bfab..04a04b0 100644 --- a/UseCases.md +++ b/UseCases.md @@ -8,7 +8,6 @@ designers think WebAssembly will *enable*. ## Inside the browser -* Common NPAPI users, within the web's security model and APIs. * Better execution for languages that are currently cross-compiled (GWT, Dart, C/C++). * Image / video editing. @@ -33,6 +32,7 @@ designers think WebAssembly will *enable*. * VPN. * Encryption. * Local web server. +* Common NPAPI users, within the web's security model and APIs. * Fat client for enterprise applications (e.g. databases). # Outside the browser -- cgit v1.2.3 From 95d112a39d392596cecfe841f05ab8ed96554058 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 10 Jun 2015 16:59:11 -0500 Subject: Change 'incompletely specified behavior' phrasing to 'limited local nondeterminism' --- IncompletelySpecifiedBehavior.md | 36 ------------------------------ Nondeterminism.md | 47 ++++++++++++++++++++++++++++++++++++++++ Portability.md | 2 +- 3 files changed, 48 insertions(+), 37 deletions(-) delete mode 100644 IncompletelySpecifiedBehavior.md create mode 100644 Nondeterminism.md diff --git a/IncompletelySpecifiedBehavior.md b/IncompletelySpecifiedBehavior.md deleted file mode 100644 index d525051..0000000 --- a/IncompletelySpecifiedBehavior.md +++ /dev/null @@ -1,36 +0,0 @@ -# Incompletely Specified Behavior - -WebAssembly is a [portable](Portability.md) sandboxed platform. Applications -can't access data outside the sandbox without going through appropriate APIs, or -otherwise escape the sandbox, even if the behavior inside the sandbox should -ever be unspecified in any way. - -WebAssembly always maintains valid callstacks. Return addresses are stored on the trusted stack and can't be clobbered by the application. And, WebAssembly ensures that calls and branches always have valid destinations. - -Beyond that, WebAssembly minimizes observable differences between implementations, to reduce the risk of applications becoming dependent on any particular implementation's behavior. However, occasionally compromises are made due to performance concerns, listed below. - -In particular, WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons), since they are an extreme on the spectrum of observable differences, and since they make it difficult to reason about what state an application might be in. WebAssembly prefers to [trap](AstSemantics.md) when feasible, and otherwise it permits a specific set of possible conforming behaviors. - -The following is a list of the places where the WebAssembly specification currently admits or is expected to admit multiple possible behaviors. - - - [Out of bounds heap accesses](AstSemantics.md#accessing-the-heap) - - - [Environment-dependent resource limits may be exhausted](AstSemantics.md) - - - [NaN bit patterns](AstSemantics.md#floating-point-operations) - - - [Races between threads](EssentialPostMVPFeatures.md#threads) - - - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd) - - 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. - -## 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. - -On WebAssembly, the primary invariants are always maintained. Demons can't actually fly out your nose, as that would constitute an escape from the sandbox. And, callstacks can't become corrupted. - -Other than that, programs which invoke undefined behavior at the source language level may be compiled into WebAssembly programs which do anything else, including corrupting the contents of the application heap, calling APIs with arbitrary parameters, hanging, trapping, or consuming arbitrary amounts of resources (within the limits). - -[Tools are being developed and ported](Tooling.md) to help developers find and fix bugs in their code. diff --git a/Nondeterminism.md b/Nondeterminism.md new file mode 100644 index 0000000..2dac091 --- /dev/null +++ b/Nondeterminism.md @@ -0,0 +1,47 @@ +# Nondeterminism in WebAssembly + +WebAssembly is a [portable](Portability.md) sandboxed platform with limited, +local, nondeterminism. + * *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, + there is no "spooky action at a distance". + +The limited, local, non-deterministic model implies: + * Applications can't access data outside the sandbox without going through + appropriate APIs, or otherwise escape the sandbox. + * WebAssembly always maintains valid, trusted callstacks; stray pointer writes + cannot corrupt return addresses or spilled variables on the stack. + * Calls and branches always have valid destinations ensuring + [Control Flow Integrity](http://research.microsoft.com/apps/pubs/default.aspx?id=64250). + * WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons). + +Ideally, WebAssembly would be fully deterministic. Nondeterminism is only +specified as a compromise when there is no other practical way to achieve +[portable](Portability.md), near-native performance. + +The following is a list of the places where the WebAssembly specification +currently admits nondeterminism: + + - [Races between threads](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) + + - [NaN bit patterns](AstSemantics.md#floating-point-operations) + + - [Fixed-width SIMD may want some flexibility](EssentialPostMVPFeatures.md#fixed-width-simd) + - 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. + +## 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. + +On WebAssembly, the primary invariants are always maintained. Demons can't actually fly out your nose, as that would constitute an escape from the sandbox. And, callstacks can't become corrupted. + +Other than that, programs which invoke undefined behavior at the source language level may be compiled into WebAssembly programs which do anything else, including corrupting the contents of the application heap, calling APIs with arbitrary parameters, hanging, trapping, or consuming arbitrary amounts of resources (within the limits). + +[Tools are being developed and ported](Tooling.md) to help developers find and fix bugs in their code. diff --git a/Portability.md b/Portability.md index 365e070..b47f2df 100644 --- a/Portability.md +++ b/Portability.md @@ -5,7 +5,7 @@ efficiently on a variety of operating systems and instruction set architectures, [on the Web](Web.md) and [off the Web](NonWeb.md). Execution environments which, despite -[allowed implementation variants](IncompletelySpecifiedBehavior.md), don't offer +[limited, local, non-determinism](Nondeterminism.md), don't offer the following characteristics may be able to execute WebAssembly modules nonetheless. In some cases they may have to emulate behavior that the host hardware or operating system don't offer so that WebAssembly modules execute -- cgit v1.2.3 From e5496a88eb64a64f8dceffa0e221fdc63c82c766 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 10 Jun 2015 17:05:18 -0500 Subject: Remove spaces --- Nondeterminism.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index 2dac091..a797f2e 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: -- cgit v1.2.3 From 5a7008cb8b145d0944edcb196f663ab51e888d92 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Wed, 10 Jun 2015 17:09:54 -0500 Subject: Well, not *fully* deterministic --- Nondeterminism.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index a797f2e..f93e807 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -17,7 +17,8 @@ The limited, local, non-deterministic model implies: [Control Flow Integrity](http://research.microsoft.com/apps/pubs/default.aspx?id=64250). * WebAssembly has no [nasal demons](https://en.wikipedia.org/w/index.php?title=Nasal_demons). -Ideally, WebAssembly would be fully deterministic. Nondeterminism is only +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. -- cgit v1.2.3 From b21682d6b49c4866010ccb5d3b01bbec8aef6425 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 09:36:57 +0200 Subject: C/C++ first. Drop Dart. Ellipsis. --- UseCases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UseCases.md b/UseCases.md index 04a04b0..18bad7e 100644 --- a/UseCases.md +++ b/UseCases.md @@ -8,8 +8,8 @@ designers think WebAssembly will *enable*. ## Inside the browser -* Better execution for languages that are currently cross-compiled (GWT, Dart, - C/C++). +* Better execution for languages that are currently cross-compiled to the Web + (C/C++, GWT, …). * Image / video editing. * Games: - Casual games that need to start quickly. -- cgit v1.2.3 From 9d8df3fd18bc68db8aad6f4bf3e24ebc772a01f9 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 09:43:42 +0200 Subject: Clarify code reuse. --- UseCases.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/UseCases.md b/UseCases.md index 18bad7e..5689f7d 100644 --- a/UseCases.md +++ b/UseCases.md @@ -47,4 +47,5 @@ designers think WebAssembly will *enable*. * Entire code base in Web Assembly. * Main frame in Web Assembly, but the UI is in JavaScript / HTML. * Re-use existing code by targeting Web Assembly, embedded in a larger - JavaScript / HTML application. + JavaScript / HTML application. This could be anything from simple helper + libraries, to compute-oriented task offload. -- cgit v1.2.3 From b7d0b716fb29d8694303f96e9a48a64c51eb14cc Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 11:25:55 +0200 Subject: Refactor essential post-MVP features * Format similar to other documents. * Clarify threads. * Move some details of threads on the Web to Web.md. * Move some details of SIMD for the Web to Web.md. * Expand on zero-cost EH. * Move discussion of coroutines to FutureFeatures.md. --- EssentialPostMVPFeatures.md | 96 +++++++++++++++++++++++++++------------------ FutureFeatures.md | 7 ++++ Web.md | 21 ++++++++-- 3 files changed, 81 insertions(+), 43 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index aea0a35..9204ad9 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -1,47 +1,65 @@ # Essential Post-MVP Features -This is a list of essential features that are known to be needed ASAP, but were -removed from [the MVP](MVP.md) since there was not (yet) a portably-efficient -polyfill via JavaScript. There is a much bigger -[list of features](FutureFeatures.md) that will be added after this list, -prioritized by feedback and experience. These features will be available under -[feature tests](FeatureTest.md). +Some features are know to be essential and needed as soon as possible but aren't +in the [Minimum Viable Product (MVP)](MVP.md) because there isn't yet a +portably-efficient [polyfill](Polyfill.md) via JavaScript. There is a much +bigger [list of features](FutureFeatures.md) that will be added after these +essential features. + +Post-MVP features will be available under [feature tests](FeatureTest.md). ## Threads -* Provide low-level buildings blocks for pthreads-style shared memory: shared memory, - atomics + futexes (or [synchronics](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4195.pdf)). -* Import [SharedArrayBuffer proposal](https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk). - * The goal is to reuse the specification of memory model, happens-before, etc (with TC39) and backend implementation - (same IR nodes and semantic invariants preserved). -* Modules can have global variables that are either shared or thread-local. - * While the heap could be used for shared global variables, global variables are not aliasable - and thus allow more aggressive optimization. -* Initially, a WebAssembly module is distributed between workers via `postMessage()`. - * This also has the effect of explicitly sharing code so that engines don't - perform N fetches and compile N copies. - * May later standardize a more direct way to create a thread from WebAssembly. + +Provide low-level buildings blocks for pthreads-style shared memory: shared +memory between threads, atomics and futexes (or [synchronic][]). WebAssembly's +approach would be similar to the [original PNaCl atomic support][] and +[SharedArrayBuffer][] proposal: reuse the specification of memory model, +happens-before relationship, and synchronize-with edges as defined in other +languages. + +Modules can have global variables that are either shared or thread-local. While +the heap could be used for shared global variables, global variables are not +aliasable and thus allow more aggressive optimization. + + [synchronic]: http://wg21.link/n4195 + [original PNaCl atomic support]: https://developer.chrome.com/native-client/reference/pnacl-c-cpp-language-support#memory-model-and-atomics + [SharedArrayBuffer]: https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk ## Fixed-width SIMD -* Essentially, import [SIMD.js](https://github.com/johnmccutchan/ecmascript_simd). - * Would be statically typed analogous to [SIMD.js-in-asm.js](http://discourse.specifiction.org/t/request-for-comments-simd-js-in-asm-js). - * The goal is to both reuse specification of op semantics (with TC39) and backend implementation (same IR nodes) - * Track SIMD.js after the MVP. -* SIMD adds new primitive variable/expression types (e.g., `float32x4`) so it has to be part of - the core semantics. -* SIMD operations (e.g., `float32x4.add`) could be either builtin ops (no different than int32 add) or - exports of a builtin SIMD module. - -## 64-bit integers -* Provide access to efficient 64-bit arithmetic. -* Some code will want to only use 64-bit integers when running on a 64-bit system (for performance - reasons) so provide a "has native 64-bit integer" query. + +Support fixed-width SIMD vectors, initially only for 128-bit wide vectors as +demonstrated in [PNaCl's SIMD][] and [SIMD.js][]. + +SIMD adds new primitive variable and expression types (e.g., `float32x4`) so it +has to be part of the core semantics. SIMD operations (e.g., `float32x4.add`) +could be either builtin operations (no different from `int32.add`) or exports of +a builtin SIMD module. + + [PNaCl's SIMD]: https://developer.chrome.com/native-client/reference/pnacl-c-cpp-language-support#portable-simd-vectors + [SIMD.js]: https://github.com/johnmccutchan/ecmascript_simd ## Zero-cost Exception Handling -* Developer access to stack unwinding and inspection. -* This may be used to implement `setjmp`/`longjmp` (instead of the usual - opposite approach). This can enable all of the defined behavior of - `setjmp`/`longjmp`, namely unwinding the stack, but does not allow - the undefined behavior case of jumping forward to a stack that - was already unwound (which is sometimes used to implement coroutines; - however, explicit coroutine support is being considered separately - anyhow). + +The initial release of WebAssembly will support two no-exception modes for C++: +* Compiler transforms `throw` to `abort()`. +* Compiler-enforced `-fno-exceptions` mode (note [caveats][]). + +These modes are very unfortunate for code bases which rely on C++ exception +handling, but are perfectly acceptable for C code, or for C++ code which avoids +exceptions. This doesn't prevent developers from using the STL… as long as their +code doesn't encounter exceptional cases! + +Post-MVP, WebAssembly will gain support for developer access to stack unwinding, +inspection, and limited manipulation. These are critical to supporting zero-cost +exception handling by exposing [low-level capabilities][]. + +In turn, stack unwinding, inspection, and limited manipulation will be used to +implement `setjmp`/`longjmp`. This can enable all of the defined behavior of +`setjmp`/`longjmp`, namely unwinding the stack without calling C++ +destructors. It does not, however, allow the undefined behavior case of jumping +forward to a stack that was already unwound which is sometimes used to implement +coroutines. Coroutine support is being +[considered separately](FutureFeatures.md#Coroutines). + + [caveats]: https://blog.mozilla.org/nnethercote/2011/01/18/the-dangers-of-fno-exceptions + [low-level capabilities]: https://extensiblewebmanifesto.org diff --git a/FutureFeatures.md b/FutureFeatures.md index 7021668..dbadd13 100644 --- a/FutureFeatures.md +++ b/FutureFeatures.md @@ -89,6 +89,13 @@ implementation running on such a platform may restrict allocations to the lower * Text source maps become intractably large for even moderate-sized compiled codes, so probably need to define new binary format for source maps. +## Coroutines + +Coroutines will [eventually be part of C++][] and is already popular in other +programming languages that WebAssembly will support. + + [eventually be part of C++]: http://wg21.link/n4499 + ## Signature-restricted Proper Tail Calls See the [asm.js RFC][] for a full description of signature-restricted Proper diff --git a/Web.md b/Web.md index ac24b21..e1f2513 100644 --- a/Web.md +++ b/Web.md @@ -20,20 +20,33 @@ that the design, especially that of the [MVP](MVP.md), are sensible: * A [module](MVP.md#Modules) can be loaded in the same way as an ES6 module (`import` statements, `Reflect` API, `Worker` constructor, etc) and the result is reflected to JS as an ES6 module object. - * Exports are the ES6 module object exports. - * An import first passes the module name to the [module loader pipeline][] and + - Exports are the ES6 module object exports. + - An import first passes the module name to the [module loader pipeline][] and resulting ES6 module (which could be implemented in JS or WebAssembly) is queried for the export name. - * There is no special case for when one WebAssembly module imports another: + - There is no special case for when one WebAssembly module imports another: they have separate [heaps](MVP.md#heap) and pointers cannot be passed between the two. Module imports encapsulate the importer and importee. [Dynamic linking](FutureFeatures.md#dynamic-linking) should be used to share heaps and pointers across modules. - * To synchronously call into JavaScript from C++, the C++ code would declare + - To synchronously call into JavaScript from C++, the C++ code would declare and call an undefined `extern` function and the target JavaScript function would be given the (mangled) name of the `extern` and put inside the imported ES6 module. +* Once [threads are supported](EssentialPostMVPFeatures.md#Threads), a + WebAssembly module would initially be distributed between workers via + `postMessage()`. + - This also has the effect of explicitly sharing code so that engines don't + perform N fetches and compile N copies. + - May later standardize a more direct way to create a thread from WebAssembly. +* Once [SIMD is supported](EssentialPostMVPFeatures.md#Fixed-width-SIMD), a Web + implementation of WebAssembly would: + - Be statically typed analogous to [SIMD.js-in-asm.js][]; + - Reuse specification of operation semantics (with TC39); + - Reuse backend implementation (same IR nodes). [CORS]: http://www.w3.org/TR/cors/ [subresource integrity]: http://www.w3.org/TR/SRI/ [module loader pipeline]: http://whatwg.github.io/loader + [SIMD.js-in-asm.js]: http://discourse.specifiction.org/t/request-for-comments-simd-js-in-asm-js + -- cgit v1.2.3 From d6845563e73f6e6eccf3398d5fc38a56ad4dbf67 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:17:09 +0200 Subject: s/initial release of WebAssembly/WebAssembly MVP/ --- EssentialPostMVPFeatures.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index 9204ad9..c2439a9 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -40,7 +40,7 @@ a builtin SIMD module. ## Zero-cost Exception Handling -The initial release of WebAssembly will support two no-exception modes for C++: +The WebAssembly MVP will support two no-exception modes for C++: * Compiler transforms `throw` to `abort()`. * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). -- cgit v1.2.3 From 83bbf1108534eb8ea8e6fa66122d5cad616b9c38 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:20:31 +0200 Subject: Be more formal. --- EssentialPostMVPFeatures.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index c2439a9..2727f92 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -46,8 +46,8 @@ The WebAssembly MVP will support two no-exception modes for C++: These modes are very unfortunate for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids -exceptions. This doesn't prevent developers from using the STL… as long as their -code doesn't encounter exceptional cases! +exceptions. This doesn't prevent developers from using the STL: their code will +function correctly as long as it doesn't encounter exceptional cases. Post-MVP, WebAssembly will gain support for developer access to stack unwinding, inspection, and limited manipulation. These are critical to supporting zero-cost -- cgit v1.2.3 From 9d4c71886ff6946be202e17873329aca1e62e6b5 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:24:15 +0200 Subject: Drop enable. --- UseCases.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/UseCases.md b/UseCases.md index 5689f7d..58a13de 100644 --- a/UseCases.md +++ b/UseCases.md @@ -3,8 +3,9 @@ WebAssembly's [high-level goals](HighLevelGoals.md) define *what* WebAssembly aims to achieve, and in *which order*. *How* WebAssembly achieves its goals is documented for [Web](Web.md) and [non-Web](NonWeb.md) platforms. The following -list of use cases is an unordered and incomplete list of what WebAssembly's -designers think WebAssembly will *enable*. +is an unordered and incomplete list of applications/domains/computations that +would benefit from WebAssembly and are being considered as use cases during the +design of WebAssembly. ## Inside the browser -- cgit v1.2.3 From 34318807a17cb43d79e8cf5939319e5b4909dc6d Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:25:20 +0200 Subject: Toolkits. --- UseCases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/UseCases.md b/UseCases.md index 58a13de..eb8d34e 100644 --- a/UseCases.md +++ b/UseCases.md @@ -9,8 +9,8 @@ design of WebAssembly. ## Inside the browser -* Better execution for languages that are currently cross-compiled to the Web - (C/C++, GWT, …). +* Better execution for languages and toolkits that are currently cross-compiled + to the Web (C/C++, GWT, …). * Image / video editing. * Games: - Casual games that need to start quickly. -- cgit v1.2.3 From abe174981643df3b0f37d625425e5706e6302708 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:26:19 +0200 Subject: Missing 'and.' --- UseCases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UseCases.md b/UseCases.md index eb8d34e..e657403 100644 --- a/UseCases.md +++ b/UseCases.md @@ -26,7 +26,7 @@ design of WebAssembly. * Scientific visualization and simulation. * Interactive educational software, and news articles. * Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, …). -* Language interpreters virtual machines. +* Language interpreters and virtual machines. * Entire UNIX user-space environment, with existing UNIX applications. * Developer tooling (editors, compilers, debuggers, …). * Remote desktop. -- cgit v1.2.3 From 36b59085649bf01b071064c977fc1a552f9149de Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 17:27:11 +0200 Subject: UNIX -> POSIX. --- UseCases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UseCases.md b/UseCases.md index e657403..405cafa 100644 --- a/UseCases.md +++ b/UseCases.md @@ -27,7 +27,7 @@ design of WebAssembly. * Interactive educational software, and news articles. * Platform simulation / emulation (ARC, DOSBox, QEMU, MAME, …). * Language interpreters and virtual machines. -* Entire UNIX user-space environment, with existing UNIX applications. +* POSIX user-space environment, allowing porting of existing POSIX applications. * Developer tooling (editors, compilers, debuggers, …). * Remote desktop. * VPN. -- cgit v1.2.3 From c6b5be06dd2f505e5a669e0c5bf3fb7f25c98677 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Jun 2015 10:37:44 -0500 Subject: Update for comments --- Nondeterminism.md | 18 +++++++++--------- 1 file 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. -- cgit v1.2.3 From b1b824b45111d4f5f4aa7e95d2d7b128c4ad8431 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Jun 2015 10:43:10 -0500 Subject: Add period. --- Nondeterminism.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index aa6bb66..ec7a3dc 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -35,7 +35,7 @@ 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 + - Environment-dependent resource limits may be exhausted. ## Note for users of C, C++, and similar languages -- cgit v1.2.3 From 40a6bf5e08479803b9e595bd2ac9f666af09800a Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Jun 2015 10:53:32 -0500 Subject: Refine description of thread nondeterminism --- Nondeterminism.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index ec7a3dc..252dc73 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -25,9 +25,14 @@ 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: - - [No sequential consistency guarantee for programs which contain races](EssentialPostMVPFeatures.md#threads) - - - [Out of bounds heap accesses may want some flexibility](AstSemantics.md#out-of-bounds) + - [When threads are added as a feature](EssentialPostMVPFeatures.md#threads), + even without shared memory, nondeterminism will be visible through the + ordering of API calls. Shared memory will allow further nondeterminism via + load/store operations which, + [following the C++ definition](http://www.hboehm.info/c++mm/sc_proof.html), + only provide sequentially consistent views of memory in the absence of races. + + - [Out of bounds heap accesses *may* want some flexibility](AstSemantics.md#out-of-bounds) - [NaN bit patterns](AstSemantics.md#floating-point-operations) -- cgit v1.2.3 From a5fa6585f2d0a952fca085e1557bbce93e46997b Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 20:22:25 +0200 Subject: Branching EH. --- EssentialPostMVPFeatures.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index 2727f92..dcbaafb 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -40,9 +40,10 @@ a builtin SIMD module. ## Zero-cost Exception Handling -The WebAssembly MVP will support two no-exception modes for C++: +The WebAssembly MVP will support three no-exception modes for C++: * Compiler transforms `throw` to `abort()`. * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). +* Compiler conversion of exceptions to branching at all callsites. These modes are very unfortunate for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids -- cgit v1.2.3 From 6ec45bfca37b09c5b499e4b057a4f2757546b8e0 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 20:24:38 +0200 Subject: Drop 'very'. --- EssentialPostMVPFeatures.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index dcbaafb..e8ad032 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -45,8 +45,8 @@ The WebAssembly MVP will support three no-exception modes for C++: * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). * Compiler conversion of exceptions to branching at all callsites. -These modes are very unfortunate for code bases which rely on C++ exception -handling, but are perfectly acceptable for C code, or for C++ code which avoids +These modes are unfortunate for code bases which rely on C++ exception handling, +but are perfectly acceptable for C code, or for C++ code which avoids exceptions. This doesn't prevent developers from using the STL: their code will function correctly as long as it doesn't encounter exceptional cases. -- cgit v1.2.3 From e53990a8cdc6239050290c340454e0ded08c4246 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 20:25:26 +0200 Subject: Clarify STL. --- EssentialPostMVPFeatures.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index e8ad032..753ac54 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -47,8 +47,9 @@ The WebAssembly MVP will support three no-exception modes for C++: These modes are unfortunate for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids -exceptions. This doesn't prevent developers from using the STL: their code will -function correctly as long as it doesn't encounter exceptional cases. +exceptions. This doesn't prevent developers from using the C++ standard library: +their code will function correctly as long as it doesn't encounter exceptional +cases. Post-MVP, WebAssembly will gain support for developer access to stack unwinding, inspection, and limited manipulation. These are critical to supporting zero-cost -- cgit v1.2.3 From 71f0b245cb57e7027df94707a78d656983a99020 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 20:55:44 +0200 Subject: SJ EH. --- EssentialPostMVPFeatures.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index 753ac54..a504233 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -44,6 +44,8 @@ The WebAssembly MVP will support three no-exception modes for C++: * Compiler transforms `throw` to `abort()`. * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). * Compiler conversion of exceptions to branching at all callsites. +* In a Web environment, exception handling can be emulated using JavaScript + exception handling. These modes are unfortunate for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids -- cgit v1.2.3 From 7ee73d80f22f3694f499023cd5d0d64f95cc8a13 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 20:58:45 +0200 Subject: FAQ: use cases. --- FAQ.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/FAQ.md b/FAQ.md index 4b1fba0..adbeadf 100644 --- a/FAQ.md +++ b/FAQ.md @@ -1,5 +1,9 @@ # FAQ +## Who was WebAssembly designed for? + +WebAssembly was designed with [a variety of use cases in mind](UseCases.md). + ## Can the polyfill really be efficient? Yes, this is a [high-level goal](HighLevelGoals.md) and there is a -- cgit v1.2.3 From d4b10d2fb103ab377efbba770eafc183db745a64 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 21:02:18 +0200 Subject: May support, in compilers and polyfill. --- EssentialPostMVPFeatures.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index a504233..08010e9 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -40,7 +40,8 @@ a builtin SIMD module. ## Zero-cost Exception Handling -The WebAssembly MVP will support three no-exception modes for C++: +The WebAssembly MVP (compilers and polyfills) may support four no-exception +modes for C++: * Compiler transforms `throw` to `abort()`. * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). * Compiler conversion of exceptions to branching at all callsites. -- cgit v1.2.3 From 26dfab5dcf0aa38c7d214cd2fd1f8fb2265882f7 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 21:12:13 +0200 Subject: JS == not fast. --- EssentialPostMVPFeatures.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index 08010e9..3cc06de 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -45,8 +45,8 @@ modes for C++: * Compiler transforms `throw` to `abort()`. * Compiler-enforced `-fno-exceptions` mode (note [caveats][]). * Compiler conversion of exceptions to branching at all callsites. -* In a Web environment, exception handling can be emulated using JavaScript - exception handling. +* In a Web environment exception handling can be emulated using JavaScript + exception handling, which can provide correct semantics but isn't fast. These modes are unfortunate for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids -- cgit v1.2.3 From 2b32b3ca9b5b0008d3f007686f64b1944fa96986 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Thu, 11 Jun 2015 21:13:37 +0200 Subject: Suboptimal; albeit slower. --- EssentialPostMVPFeatures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EssentialPostMVPFeatures.md b/EssentialPostMVPFeatures.md index 3cc06de..9d4347f 100644 --- a/EssentialPostMVPFeatures.md +++ b/EssentialPostMVPFeatures.md @@ -48,11 +48,11 @@ modes for C++: * In a Web environment exception handling can be emulated using JavaScript exception handling, which can provide correct semantics but isn't fast. -These modes are unfortunate for code bases which rely on C++ exception handling, +These modes are suboptimal for code bases which rely on C++ exception handling, but are perfectly acceptable for C code, or for C++ code which avoids exceptions. This doesn't prevent developers from using the C++ standard library: -their code will function correctly as long as it doesn't encounter exceptional -cases. +their code will function correctly (albeit slower at times) as long as it +doesn't encounter exceptional cases. Post-MVP, WebAssembly will gain support for developer access to stack unwinding, inspection, and limited manipulation. These are critical to supporting zero-cost -- cgit v1.2.3 From 2546267273a7a18b6cb052ff59e7a18e41b29f12 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Jun 2015 14:26:57 -0500 Subject: Tweak to remove seq-cst mention (irrelevant to goal of doc) and mention nondeterminism of load --- Nondeterminism.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index 252dc73..585dd6b 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -27,10 +27,8 @@ currently admits nondeterminism: - [When threads are added as a feature](EssentialPostMVPFeatures.md#threads), even without shared memory, nondeterminism will be visible through the - ordering of API calls. Shared memory will allow further nondeterminism via - load/store operations which, - [following the C++ definition](http://www.hboehm.info/c++mm/sc_proof.html), - only provide sequentially consistent views of memory in the absence of races. + global ordering of API calls. With shared memory, the result of load + operations is nondeterministic. - [Out of bounds heap accesses *may* want some flexibility](AstSemantics.md#out-of-bounds) -- cgit v1.2.3 From 225ce8b501b41c67a306973f623873661c5bf323 Mon Sep 17 00:00:00 2001 From: Luke Wagner Date: Thu, 11 Jun 2015 15:12:01 -0500 Subject: order -> sequence --- Nondeterminism.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Nondeterminism.md b/Nondeterminism.md index 585dd6b..308861d 100644 --- a/Nondeterminism.md +++ b/Nondeterminism.md @@ -27,7 +27,7 @@ currently admits nondeterminism: - [When threads are added as a feature](EssentialPostMVPFeatures.md#threads), even without shared memory, nondeterminism will be visible through the - global ordering of API calls. With shared memory, the result of load + global sequence of API calls. With shared memory, the result of load operations is nondeterministic. - [Out of bounds heap accesses *may* want some flexibility](AstSemantics.md#out-of-bounds) -- cgit v1.2.3 From 582c28f34419662594d1ff40f0d72091c097393d Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Thu, 11 Jun 2015 16:52:23 -0700 Subject: Fix broken link. --- TextFormat.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/TextFormat.md b/TextFormat.md index 0a64157..bebd120 100644 --- a/TextFormat.md +++ b/TextFormat.md @@ -17,7 +17,7 @@ The text format will be standardized, but only for tooling purposes: implement WebAssembly semantics. Given that the code representation is actually an -[Abstract Syntax Tree](ASTSemantics.md), the syntax would contain nested +[Abstract Syntax Tree](AstSemantics.md), the syntax would contain nested statements and expressions (instead of the linear list of instructions most assembly languages have). -- cgit v1.2.3 From 6b703e430cb847b34b94961fd5913a7e8529c283 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Fri, 12 Jun 2015 11:52:15 +0200 Subject: What are WebAssembly's use cases? --- FAQ.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/FAQ.md b/FAQ.md index adbeadf..d2be3a3 100644 --- a/FAQ.md +++ b/FAQ.md @@ -1,6 +1,6 @@ # FAQ -## Who was WebAssembly designed for? +## What are WebAssembly's use cases? WebAssembly was designed with [a variety of use cases in mind](UseCases.md). -- cgit v1.2.3