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

According to clang, all common 64-bit CPUs, x86-64, arm64, mips64,
ppc64, sparcv9, and systemz (and bpf, if that counts) support a 64-bit
integer type as "lock free". In the spirit of #327, this is a
significant agreement among 64-bit architectures, but not 32-bit
architectures.

I propose we think about the >4GiB linear memory feature as belonging to
a distinct "architecture" called *wasm64*, when we need to distinguish
it from *wasm32*. This will allow us to say that wasm64 has up to 64-bit
lock-free integers, while wasm32 only has up to 32-bit lock-free
integers. If we add signal handling it could also let us say that wasm64
has up to 64-bit signal-atomic integers (sig_atomic_t). It would also
make it obvious what types to use around page_size and resize_memory.

Except where it makes sense to make them different, wasm32 and wasm64
would otherwise be kept identical. In particular, wasm32 would still have
64-bit integers.

The main negative consequence of this distinction is that wasm64 code
would not be supported on many popular 32-bit CPUs. This is unfortunate,
but it would already be the case that code using 64-bit pointers
wouldn't run as efficiently as code using 32-bit pointers on 32-bit
platforms.

There's a desire to leave open the possibility of having both 32-bit and
64-bit linear memory addressing within a single instance. wasm64 could
still be made to support mixing 64-bit indices and 32-bit indices if we
choose, for example. We could potentially even permit wasm32 libraries
to be linked into wasm64 applications (though there would of course be
ABI complications at the C/C++ level, non-C/C++ code might be able to
take advantage of this).

1 files changed, 9 insertions, 9 deletions

diff --git a/CAndC++.md b/CAndC++.md
index 15e066e..9429f05 100644
--- a/CAndC++.md
+++ b/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