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 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 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