1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
# Browser Embedding
Unsurprisingly, one of WebAssembly's primary purposes is to run on the Web,
embedded in Web browsers (though this is [not its only purpose](NonWeb.md)).
This means integrating with the Web ecosystem, leveraging Web APIs, supporting
the Web's security model, preserving the Web's portability, and designing in
room for evolutionary development. Many of these goals are clearly
reflected in WebAssembly's [high-level goals](HighLevelGoals.md).
# Implementation Details
We've identified interesting implementation approaches which help convince us
that the design, especially that of the [MVP](MVP.md), are sensible:
* WebAssembly's security model should depend on [CORS][] and
[subresource integrity][] to enable distribution, especially through content
distribution networks and to implement
[dynamic linking](FutureFeatures.md#dynamic-linking).
* 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
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:
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
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](PostMVP.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](PostMVP.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
|
