From c455c03a6aeac6b2300c928a0d5adf0d86b2bb5b Mon Sep 17 00:00:00 2001 From: Dan Gohman Date: Sat, 5 Sep 2015 11:29:49 -0700 Subject: 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). --- CAndC++.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'CAndC++.md') 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 -- cgit v1.2.3