Move globals out of the MVP

5 files changed, 32 insertions, 21 deletions

diff --git a/AstSemantics.md b/AstSemantics.md
index f735b8a..bd27f6e 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
 
@@ -233,7 +232,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.
@@ -245,18 +244,6 @@ The details of index space for local variables and their types will be further c
 e.g. whether locals with type `int32` and `int64` 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 675471f..f110d8f 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 d0f13ec..0feaf50 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. Langauges 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 e4eaa7a..4069734 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 e431c0f..59b4de4 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/