Stream: git-wasmtime

Topic: wasmtime / Issue #572 wasm64 support

Wasmtime GitHub notifications bot (Mar 21 2020 at 04:20):

sunfishcode commented on Issue #572:

There is now an official spec proposal repo, memory64.

Wasmtime GitHub notifications bot (Sep 11 2020 at 03:42):

lygstate commented on Issue #572:

When this going to happen?

Wasmtime GitHub notifications bot (Sep 11 2020 at 03:46):

aardappel commented on Issue #572:

I've implemented wasm64 support in LLVM, LLD, WABT, now working on Binaryen..

Wasmtime GitHub notifications bot (Sep 11 2020 at 03:56):

lygstate commented on Issue #572:

Wonderfull work, support in wasmtime would be relative harder?

Wasmtime GitHub notifications bot (Sep 11 2020 at 10:22):

tschneidereit commented on Issue #572:

Indeed, that's excellent progress, @aardappel!

Wonderfull work, support in wasmtime would be relative harder?

My understanding — which might be wrong — is that it's probably not a huge amount of work, but also non-trivial. @alexcrichton and @sunfishcode, ISTM we talked about this a while ago, do you happen to have an idea of the work involved to make this happen?

Wasmtime GitHub notifications bot (Sep 11 2020 at 11:31):

lygstate commented on Issue #572:

Indeed, that's excellent progress, @aardappel!

Wonderfull work, support in wasmtime would be relative harder?

My understanding — which might be wrong — is that it's probably not a huge amount of work, but also non-trivial. @alexcrichton and @sunfishcode, ISTM we talked about this a while ago, do you happen to have an idea of the work involved to make this happen?

does the wasm64 and wasm32 have different abi？

Wasmtime GitHub notifications bot (Sep 11 2020 at 11:38):

bjorn3 commented on Issue #572:

They would need to have different abi's. Pointer size is part of the abi and they use different pointer sizes.

Wasmtime GitHub notifications bot (Sep 11 2020 at 18:22):

alexcrichton commented on Issue #572:

I suspect this would be relatively simple to implement nowadays. The memory64 proposal is quite small, basically just changing memory-operating instructions to work with either 32 or 64-bit indices. The work in wasmparser is already done to implement the memory64 proposal, so all that's needed to be done is to thread it all through cranelift.

At this time this probably won't be as well optimized as memory32 since we can't naively do the exact same guard page trick we do there (reserving a 32-bit region of the address space). That being said cranelift has all the internal machinery to insert manual checks on each load/store, so we'd just need to hook that up. Overall this is likely a simple-ish refactoring of the code translator to conditionally use 64 or 32-bit indices everywhere, depending on what type each memory has.

The wasmtime API itself may not even have to change at all for something like this. We might add a flag to Memory as to whether it's 64-bit or not, but otherwise everything is pretty much the same. Although ABIs are different that's only really an artifact of compilation toolchains, once you get to the runtime it's all basically just a wasm blob.

Last updated: Dec 23 2024 at 13:07 UTC