39e57e3e9a
* Migrate back to `std::` stylistically This commit moves away from idioms such as `alloc::` and `core::` as imports of standard data structures and types. Instead it migrates all crates to uniformly use `std::` for importing standard data structures and types. This also removes the `std` and `core` features from all crates to and removes any conditional checking for `feature = "std"` All of this support was previously added in #407 in an effort to make wasmtime/cranelift "`no_std` compatible". Unfortunately though this change comes at a cost: * The usage of `alloc` and `core` isn't idiomatic. Especially trying to dual between types like `HashMap` from `std` as well as from `hashbrown` causes imports to be surprising in some cases. * Unfortunately there was no CI check that crates were `no_std`, so none of them actually were. Many crates still imported from `std` or depended on crates that used `std`. It's important to note, however, that **this does not mean that wasmtime will not run in embedded environments**. The style of the code today and idioms aren't ready in Rust to support this degree of multiplexing and makes it somewhat difficult to keep up with the style of `wasmtime`. Instead it's intended that embedded runtime support will be added as necessary. Currently only `std` is necessary to build `wasmtime`, and platforms that natively need to execute `wasmtime` will need to use a Rust target that supports `std`. Note though that not all of `std` needs to be supported, but instead much of it could be configured off to return errors, and `wasmtime` would be configured to gracefully handle errors. The goal of this PR is to move `wasmtime` back to idiomatic usage of features/`std`/imports/etc and help development in the short-term. Long-term when platform concerns arise (if any) they can be addressed by moving back to `no_std` crates (but fixing the issues mentioned above) or ensuring that the target in Rust has `std` available. * Start filling out platform support doc
44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# Platform Support
|
|
|
|
The `wasmtime` project is a configurable and lightweight runtime for WebAssembly
|
|
which has a number of ways it can be configured. Not all features are supported
|
|
on all platforms, but it is intended that `wasmtime` can run in some capacity on
|
|
almost all platforms! The matrix of what's being tested, what works, and what's
|
|
supported where is evolving over time, and this document hopes to capture a
|
|
snapshot of what the current state of the world looks like.
|
|
|
|
All features of `wasmtime` should work on the following platforms:
|
|
|
|
* Linux x86\_64
|
|
* macOS x86\_64
|
|
* Windows x86\_64
|
|
|
|
For more detailed information about supported platforms, please check out the
|
|
sections below!
|
|
|
|
## JIT compiler support
|
|
|
|
The JIT compiler, backed by either `lightbeam` or `cranelift` supports only the
|
|
x86\_64 architecture at this time. Support for at least ARM, AArch64, and x86 is
|
|
planned at this time.
|
|
|
|
Usage of the JIT compiler will require a host operating system which supports
|
|
creating executable memory pages on-the-fly. In Rust terms this generally means
|
|
that `std` needs to be supported on this platform.
|
|
|
|
## Interpreter support
|
|
|
|
At this time `wasmtime` does not have a mode in which it simply interprets
|
|
WebAssembly code. It is planned to add support for an interpreter, however, and
|
|
this will have minimal system dependencies. It is planned that the system will
|
|
need to support some form of dynamic memory allocation, but other than that not
|
|
much else will be needed.
|
|
|
|
## What about `#[no_std]`?
|
|
|
|
The `wasmtime` project does not currently use `#[no_std]` for its crates, but
|
|
this is not because it won't support it! At this time we're still gathering use
|
|
cases for for what `#[no_std]` might entail, so if you're interested in this
|
|
we'd love to hear about your use case! Feel free to open an issue on the
|
|
`wasmtime` repository to discuss this.
|