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).

0 files changed, 0 insertions, 0 deletions