Skip to content

Latest commit

 

History

History
70 lines (54 loc) · 3.49 KB

PostMVP.md

File metadata and controls

70 lines (54 loc) · 3.49 KB
Raw

Essential Post-MVP Features

Some features are know to be essential and needed as soon as possible but aren't in the Minimum Viable Product (MVP) because there isn't yet a portably-efficient polyfill via JavaScript. There is a much bigger list of features that will be added after these essential features.

Post-MVP features will be available under feature tests.

Threads

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.

Fixed-width SIMD

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.

Zero-cost Exception Handling

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.
  • 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 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 (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 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.