Platform Support - Wasmtime

# Platform Support

This page is intended to give a high-level overview of Wasmtime's platform support along with some aspirations of Wasmtime. For more details see the documentation on tiers of stability which has specific information about what's supported in Wasmtime on a per-matrix-combination basis.

Wasmtime strives to support hardware that anyone wants to run WebAssembly on. Maintainers of Wasmtime support a number of "major" platforms themselves but porting work may be required to support platforms that maintainers are not themselves familiar with. Out-of-the box Wasmtime supports:

- Linux x86_64, aarch64, s390x, and riscv64
- macOS x86_64, aarch64
- Windows x86_64

Other platforms such as Android, iOS, and the BSD family of OSes are not built-in yet. PRs for porting are welcome and maintainers are happy to add more entries to the CI matrix for these platforms.

## Compiler Support

Cranelift supports x86_64, aarch64, s390x, and riscv64. No 32-bit platform is currently supported. Building a new backend for Cranelift is a relatively large undertaking which maintainers are willing to help with but it's recommended to reach out to Cranelift maintainers first to discuss this.

Winch supports x86_64. The aarch64 backend is in development. Winch is built on Cranelift's support for emitting instructions so Winch's possible backend list is currently limited to what Cranelift supports.

Usage of the Cranelift or Winch requires a host operating system which supports creating executable memory pages on-the-fly. Support for statically linking in a single precompiled module is not supported at this time.

Both Cranelift and Winch can be used either in AOT or JIT mode. In AOT mode one process precompiles a module/component and then loads it into another process. In JIT mode this is all done within the same process.

Neither Cranelift nor Winch support tiering at this time in the sense of having a WebAssembly module start from a Winch compilation and automatically switch to a Cranelift compilation. Modules are either entirely compiled with Winch or Cranelift.

## Interpreter support

At this time `wasmtime` does not have a mode in which it simply interprets WebAssembly code. It is desired 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.

## Support for `#![no_std]`

The `wasmtime` crate supports being build on no_std platforms in Rust, but only for a subset of its compile-time Cargo features. Currently supported Cargo features are:

- `runtime`
- `gc`
- `component-model`

This notably does not include the `default` feature which means that when depending on Wasmtime you'll need to specify `default-features = false`. This also notably does not include Cranelift or Winch at this time meaning that no_std platforms must be used in AOT mode where the module is precompiled elsewhere.

Wasmtime's support for no_std requires the embedder to implement the equivalent of a C header file to indicate how to perform basic OS operations such as allocating virtual memory. This API can be found as `wasmtime-platform.h` in Wasmtime's release artifacts or at `examples/min-platform/embedding/wasmtime-platform.h` in the source tree. Note that this API is not guaranteed to be stable at this time, it'll need to be updated when Wasmtime is updated.

Wasmtime's runtime will use the symbols defined in this file meaning that if they're not defined then a link-time error will be generated. Embedders are required to implement these functions in accordance with their documentation to enable Wasmtime to run on custom platforms.