diff --git a/AstSemantics.md b/AstSemantics.md index 59eac0f3..f16cc23a 100644 --- a/AstSemantics.md +++ b/AstSemantics.md @@ -71,9 +71,8 @@ extending for `memory_size` bytes which can be dynamically adjusted by be an untyped array of bytes, and it is unspecified how embedders map this array into their process' own [virtual memory][]. The linear memory is sandboxed; it does not alias the execution engine's internal data structures, the execution -stack, local variables, global variables, or other process memory. The initial -state of linear memory is specified by the -[module](Modules.md#initial-state-of-linear-memory). +stack, local variables, or other process memory. The initial state of linear +memory is specified by the [module](Modules.md#initial-state-of-linear-memory). [virtual memory]: https://en.wikipedia.org/wiki/Virtual_memory @@ -235,7 +234,7 @@ contiguous linear memory. Each function has a fixed, pre-declared number of local variables which occupy a single index space local to the function. Parameters are addressed as local variables. Local -variables do not have addresses and are not aliased in the globals or memory. Local +variables do not have addresses and are not aliased by linear memory. Local variables have local types and are initialized to the appropriate zero value for their type at the beginning of the function, except parameters which are initialized to the values of the arguments passed to the function. @@ -247,18 +246,6 @@ The details of index space for local variables and their types will be further c e.g. whether locals with type `i32` and `i64` must be contiguous and separate from others, etc. -## Global variables - -Global variables are storage locations outside the linear memory. -Every global has exactly one memory type. -Accesses to global variables specify the index as an integer literal. - - * `load_global`: load the value of a given global variable - * `store_global`: store a given value to a given global variable - -The specification will add atomicity annotations in the future. Currently -all global accesses can be considered "non-atomic". - ## Control flow structures WebAssembly offers basic structured control flow. All control flow structures diff --git a/DynamicLinking.md b/DynamicLinking.md index 675471fd..f110d8fd 100644 --- a/DynamicLinking.md +++ b/DynamicLinking.md @@ -10,6 +10,17 @@ dynamic libraries. WebAssembly will support both load-time and run-time (`dlopen`) dynamic linking of libraries. +One important requirement of dynamic linking is to allow the linked module +to have its own position-independent global data segment. This could be achieved +by specifying a new kind of link-time-initialized immutable global variable +which would be initialized with the address (in linear memory) of the modules' +global data segment. These immutable globals could also be used to provide +a linked module with the offsets of its function pointers in the instance's +function pointer tables. An important aspect of immutable globals is that they +could either be patched directly as constant values or implemented through a +[Global Offset Table](https://en.wikipedia.org/wiki/Position-independent_code) +in position-independent code. + Dynamic linking is especially useful when combined with a Content Distribution Network (CDN) such as [hosted libraries][] because the library is only ever downloaded and compiled once per user device. It can also allow for smaller diff --git a/FutureFeatures.md b/FutureFeatures.md index fb3d328e..35a71cc8 100644 --- a/FutureFeatures.md +++ b/FutureFeatures.md @@ -376,3 +376,18 @@ is to allow a WebAssembly decoder to decode "through" an AST node that it knows nothing about. There are a number of ways to achieve this and more concrete experience with the realities of polyfilling is necessary to suggest the right design. + +## Mutable global variables + +In the MVP, there are no global variables; C/C++ global variables are stored in +linear memory and thus accessed through normal +[linear memory operations](AstSemantics.md#linear-memory-operations). +[Dynamic linking](DynamicLinking.md) will add some form of immutable global +variable analogous to "symbols" in native binaries. In some cases, though, +it may be useful to have a fully mutable global variable which lives outside +linear memory. This would allow more aggressive compiler optimizations (due to +better alias information). If globals are additionally allowed array types, +significant portions of memory could be moved out of linear memory which could +reduce fragmentation issues. Languages like Fortran which limit aliasing would be +one use case. C/C++ compilers could also determine that some global variables never +have their address taken. diff --git a/Modules.md b/Modules.md index e4eaa7a0..40697348 100644 --- a/Modules.md +++ b/Modules.md @@ -19,7 +19,6 @@ silently ignored. An instance contains: * the code of the module from which the instance was loaded; * a [linear memory](AstSemantics.md#linear-memory); -* [global variable](AstSemantics.md#global-variables) state; * fully resolved imports; * host-specific state (for example, the JS function objects that reflect exported functions to JS); @@ -105,7 +104,7 @@ place of executing the ES6 module top-level script. By default, multiple loads of the same module URL (in the same realm) reuse the same instance. It may be worthwhile in the future to consider extensions to allow applications to load/compile/link a module once and instantiate multiple times (each with a -separate heap and global state). +separate linear memory). This integration strategy should allow WebAssembly modules to be fairly interchangeable with ES6 modules (ignoring diff --git a/PostMVP.md b/PostMVP.md index 4a417030..8c7a4107 100644 --- a/PostMVP.md +++ b/PostMVP.md @@ -24,9 +24,8 @@ executes as if it were sequentially consistent. Even when there are data races, WebAssembly will ensure that the [nondeterminism](Nondeterminism.md) remains limited and local. -Modules can have global variables that are either shared or thread-local. While -the linear memory could be used to store shared global variables, global -variables are not aliasable and thus allow more aggressive optimization. +Modules can have thread-local variables that are disjoint from linear memory +and can thus be represented efficiently by the engine. [synchronic]: http://wg21.link/n4195 [C++11 memory model]: http://www.hboehm.info/c++mm/ diff --git a/TextFormat.md b/TextFormat.md index 6619f6f3..316b0651 100644 --- a/TextFormat.md +++ b/TextFormat.md @@ -33,3 +33,12 @@ binary format are considered invalid text. Floating-point numbers are therefore represented as hexadecimal floating-point as specified by the C99 standard, which IEEE-754-2008 section 5.12.3 also specifies. The textual format may be improved to also support more human-readable representations, but never at the cost of accurate representation. + +## Debug symbol integration + +The binary format inherently strips names from functions, locals, globals, etc, +reducing each of these to dense indices. Without help, the text format must +therefore synthesize new names. However, as part of the [tooling](Tooling.md) +story, a lightweight, optional "debug symbol" global section may be defined +which associates names with each indexed entity and, when present, these names +will be used in the text format projected from a binary WebAssembly module.