wasm64, >4 GiB indexing, and a 64-bit lock-free guarantee

AstSemantics.md

@@ -146,11 +146,12 @@ address for an access is out-of-bounds, the effective address will always also
 be out-of-bounds. This is intended to simplify folding of offsets into complex
 address modes in hardware, and to simplify bounds checking optimizations.
 
-In the MVP, address operands and offset attributes have type `int32`, and linear
+In wasm32, address operands and offset attributes have type `int32`, and linear
 memory sizes are limited to 4 GiB (of course, actual sizes are further limited
-by [available resources](Nondeterminism.md)). In the future, to support
-[>4GiB linear memory](FutureFeatures.md#heaps-bigger-than-4gib), support for
-indices with type `int64` will be added.
+by [available resources](Nondeterminism.md)). In wasm64, address operands and
+offsets have type `int64`. The MVP only includes wasm32; subsequent versions
+will add support for wasm64 and thus
+[>4 GiB linear memory](FutureFeatures.md#linear-memory-bigger-than-4-gib).
 
 ### Alignment
 

CAndC++.md

@@ -12,15 +12,15 @@ WebAssembly has a pretty conventional ISA: 8-bit bytes, two's complement
 integers, little-endian, and a lot of other normal properties. Reasonably
 portable C/C++ code should port to WebAssembly without difficultly.
 
-In [the MVP](MVP.md), WebAssembly will have an ILP32 data model, meaning
-that `int`, `long`, and pointer types are all 32-bit. The `long long`
-type is 64-bit.
-
-In the future, WebAssembly will be extended to support
-[64-bit address spaces](FutureFeatures.md#linear-memory-bigger-than-4gib). This
-will enable an LP64 data model as well, meaning that `long` and pointer
-types will be 64-bit, while `int` is 32-bit. From a C/C++ perspective,
-this will be a separate mode from ILP32, with a separate ABI.
+WebAssembly has 32-bit and 64-bit architecture variants, called wasm32 and
+wasm64. wasm32 has an ILP32 data model, meaning that `int`, `long`, and
+pointer types are all 32-bit, while the `long long` type is 64-bit. wasm64
+has an LP64 data model, meaning that `long` and pointer types will be
+64-bit, while `int` is 32-bit.
+
+[The MVP](MVP.md) will support only wasm32; support for wasm64 will be
+added in the future to support
+[64-bit address spaces](FutureFeatures.md#linear-memory-bigger-than-4-gib).
 
 ### Language Support
 

FAQ.md

@@ -259,3 +259,44 @@ omission is:
   * This interleaving would require making allocation nondeterministic and
     nondeterminism is something that WebAssembly generally
     [tries to avoid](Nondeterminism.md).
+
+## Why have wasm32 and wasm64, instead of just an abstract `size_t`?
+
+The amount of linear memory needed to hold an abstract `size_t` would then also
+need to be determined by an abstraction, and then partitioning the linear memory
+address space into segments for different purposes would be more complex. The
+size of each segment would depend on how many `size_t`-sized objects are stored
+in it. This is theoretically doable, but it would add complexity and there would
+be more work to do at application startup time.
+
+Also, allowing applications to statically know the pointer size can allow them
+to be optimized more aggressively. Optimizers can better fold and simplify
+integer expressions when they have full knowledge of the bitwidth. And, knowing
+memory sizes and layouts for various types allows one to know how many trailing
+zeros there are in various pointer types.
+
+Also, C and C++ deeply conflict with the concept of an abstract `size_t`.
+Constructs like `sizeof` are required to be fully evaluated in the front-end
+of the compiler because they can participate in type checking. And even before
+that, it's common to have predefined macros which indicate pointer sizes,
+allowing code to be specialized for pointer sizes at the very earliest stages of
+compilation. Once specializations are made, information is lost, scuttling
+attempts to introduce abstractions.
+
+And finally, it's still possible to add an abstract `size_t` in the future if
+the need arises and practicalities permit it.
+
+## Why have wasm32 and wasm64, instead of just using 8 bytes for storing pointers?
+
+A great number of applications don't ever need as much as 4 GiB of memory.
+Forcing all these applications to use 8 bytes for every pointer they store would
+significantly increase the amount of memory they require, and decrease their
+effective utilization of important hardware resources such as cache and memory
+bandwidth.
+
+The motivations and performance effects here should be essentially the same as
+those that motivated the development of the
+[x32 ABI](https://en.wikipedia.org/wiki/X32_ABI) for Linux.
+
+Even Knuth found it worthwhile to give us his opinion on this issue at point,
+[a flame about 64-bit pointers](http://www-cs-faculty.stanford.edu/~uno/news08.html).

FutureFeatures.md

@@ -65,20 +65,26 @@ Options under consideration:
 
 See [GC.md](GC.md).
 
-## Linear memory bigger than 4GiB
+## Linear memory bigger than 4 GiB
 
-WebAssembly will eventually allow a module to have a linear memory size greater
-than 4GiB by providing load/store/etc. operations that take 64-bit index
-operands.
+The WebAssembly MVP will support the wasm32 mode of WebAssembly, with linear
+memory sizes up to 4 GiB using 32-bit linear memory indices. To support larger
+sizes, the wasm64 mode of WebAssembly will be added in the future, supporting
+much greater linear memory sizes using 64-bit linear memory indices. wasm32
+and wasm64 are both just modes of WebAssembly, to be selected by a flag in
+a module header, and don't imply any semantics differences outside of how
+linear memory is handled. Platforms will also have APIs for querying which of
+wasm32 and wasm64 are supported.
 
 Of course, the ability to actually allocate this much memory will always be
 subject to dynamic resource availability.
 
-Initially, it will likely be required that a program use all 32-bit indices or
-all 64-bit indices, and not a mix of both, so that implementations don't have
-to support both in the same program. However, operators with 32-bit indices and
-operations with 64-bit indices will be given separate names to leave open the
-possibility of supporting both in the same program in the future.
+It is likely that wasm64 will initially support only 64-bit linear memory
+indices, and wasm32 will leave 64-bit linear memory indices unsupported, so
+that implementations don't have to support multiple index sizes in the same
+instance. However, operators with 32-bit indices and operations with 64-bit
+indices will be given separate names to leave open the possibility of
+supporting both in the same instance in the future.
 
 ## Source maps integration
 

Portability.md

@@ -31,17 +31,17 @@ characteristics:
 * Little-endian byte ordering.
 * Memory regions which can be efficiently addressed with 32-bit
   pointers or indices.
-* Linear memory bigger than 4GiB with 64-bit addressing
-  [may be added later](FutureFeatures.md#linear-memory-bigger-than-4gib), though it will
-  be done under a [feature test](FeatureTest.md) so it won't be required for all
-  WebAssembly implementations.
+* wasm64 additionally supports linear memory bigger than
+  [4 GiB with 64-bit pointers or indices](FutureFeatures.md#linear-memory-bigger-than-4-gib).
 * Enforce secure isolation between WebAssembly modules and other modules or
   processes executing on the same machine.
 * An execution environment which offers forward progress guarantees to all
   threads of execution (even when executing in a non-parallel manner).
 * Availability of lock-free atomic memory operations, when naturally aligned, for
   8- 16- and 32-bit accesses. At a minimum this must include an atomic
   compare-and-exchange operation (or equivalent load-linked/store-conditional).
+* wasm64 additionally requires lock-free atomic memory operations, when naturally
+  aligned, for 64-bit accesses.
 
 ## API