Merge pull request #344 from WebAssembly/rm-globals

Move globals out of the MVP

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

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

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.

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 

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/

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.