how does wasmtime implement abi for wasm64-wasi?

[trcrsired]

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

I am proposing to duplicate all existing APIs for 64 bit wasi interface to be with a _wasm64 suffix.

Benefit

TODO: I have a working wasm64 libc and a correct implementation with 64 bit wasi interface WAVM. This prevents plugins to break

Implementation

TODO: Duplicate all existing 32 bit apis with a _wasm64 suffix. The pointer and size type being i64 with 64 bit apis.
https://github.com/trcrsired/WAVM/blob/fb912a528cb64291034fbdfa2367c727f6ea9eb7/Lib/WASI/WASIFile.cpp#L238

it also prevents breaking exist tools that assume address being 32 bit and prevent breaking of function validations or other changes.

Alternatives

Using existing APIs without a different name creates headache.

https://github.com/trcrsired/wasi-libc
https://github.com/trcrsired/wasi-libc/blob/main/libc-bottom-half/headers/public/wasi/api.h
https://github.com/trcrsired/wasi-libc/blob/b40e9997393fad87a98554230b50417aae62ec5b/libc-bottom-half/sources/__wasilibc_real.c#L16

[alexcrichton]

Thanks for the report, but at this time there's no such thing as 64-bit support for the wasi_snapshot_preview1 version of WASI. I believe as you've seen on WebAssembly/WASI#566 this doesn't exist at the standards layer, and as a result Wasmtime doesn't implement this. Additionally I'm not aware of any wasm64-wasi target officially supported by C, Rust, or other compiler. For example wasi-libc doesn't support wasm64-wasi (as I'm sure you're aware of). In that sense, the answer to this issue is "Wasmtime doesn't support this".

Now all that being said it's not like wasm64 and memory64 and all that has never been considered before. Rust for example has support for wasm64-unknown-unknown and I'd like to support wasm64-wasi once it's defined. Additionally an important point to note is that WASI is no longer defined as wasi_snapshot_preview1 and it's now defined in terms of the component model. In the component model the size of memory is an implementation detail that does not show up in WIT interfaces. Wasmtime's implementation of the component model does not currently support 64-bit memories and additionally there is no defined interaction between the component model and the memory64 proposal. (It's also important to note that the memory64 proposal is currently at stage 3 and thus not generally considered stable at this time)

Given all that I'm going to close this. For Wasmtime we'll follow the WASI standard for wasi_snapshot_preview1. Whether or not changes are made to that definition of WASI is up to the WASI subgroup, not us. Additionally we'll follow the component model standard for how to interact with the memory64 proposal.

My personal recommendation, if you're interested in 64-bit WASI, is to follow these steps:

• Help out with the definition of component model + memory64 support.
• Help implement memory64 + component model support in Wasmtime (as defined by the prior issue)
• Help update bindings generators to support 64-bit targets
• Help add 64-bit targets to wasi-libc and other compilers like Rust.

That all starts with upstream standards work as opposed to runtimes, however, and it's additionally a nontrivial amount of work. I understand it's more work than "just merge this PR please" but 64-bit support is a pretty major and foundational feature which has quite a large impact on the ecosystem.

[trcrsired]

what about preview2?

[bjorn3]

The component model doesn't have memory64 support yet either. See WebAssembly/component-model#22 Once the component model has memory64 support, preview2 should automatically get support if I understand correctly.