trcrsired opened issue #7864:
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#L238it 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 commented on issue #7864:
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 https://github.com/WebAssembly/WASI/issues/566 this doesn't exist at the standards layer, and as a result Wasmtime doesn't implement this. Additionally I'm not aware of anywasm64-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 supportwasm64-wasi
once it's defined. Additionally an important point to note is that WASI is no longer defined aswasi_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.
alexcrichton closed issue #7864:
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#L238it 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
trcrsired commented on issue #7864:
what about preview2?
bjorn3 commented on issue #7864:
The component model doesn't have memory64 support yet either. See https://github.com/WebAssembly/component-model/issues/22 Once the component model has memory64 support, preview2 should automatically get support if I understand correctly.
Last updated: Dec 23 2024 at 12:05 UTC