Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05): Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05):stevefan1999-personal opened PR #13607 from stevefan1999-personal:feat/cranelift-no-std to bytecodealliance:main:
This PR is the part 1 of the 2 to convert wasmtime into no-std build capable runtime, that makes Cranelift crates to be able to build in fully no-std mode with hopefully minimal code changes, which is needed because https://github.com/wasmi-labs/wasmi lacked so many features I needed.
The first step is to enable Cranelift and its satellite crates to be no-std capable, and since a platform is no longer a guarantee, which means that only Pulley interpreter is available for no-std mode, and thus no need for virtual memory support, so I added a Vec arena backed memory allocator for the "JIT" (but which honestly should be a no-op).
This is also needed because I'm also writing a C compiler, and I don't really want each unit tests to invoke the codegen which sometimes exhitbits strange memory protection error during normal
cargo test. My educated guess for that is because of the allocated JIT memory map is so frequent, but the memory protection region has overlapped with ongoing page fault, so the internal virtual memory allocator can't keep up, causing general memory protection error. Although I can sidestep it withcargo nextestwhich runs each test as an independent process for now, but I'm also curious why that would happen.
Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05):stevefan1999-personal requested alexcrichton for a review on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05):stevefan1999-personal requested wasmtime-compiler-reviewers for a review on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05):stevefan1999-personal requested wasmtime-core-reviewers for a review on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 08:05):stevefan1999-personal requested wasmtime-default-reviewers for a review on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 08:09):stevefan1999-personal edited PR #13607:
This PR is the part 1 of the 2 to convert wasmtime into no-std build capable runtime, that makes Cranelift crates to be able to build in fully no-std mode with hopefully minimal code changes, which is needed because https://github.com/wasmi-labs/wasmi lacked so many features I needed.
The first step is to enable Cranelift and its satellite crates to be no-std capable, and since a platform is no longer a guarantee, which means that only Pulley interpreter is available for no-std mode, and thus no need for virtual memory support, so I added a Vec arena backed memory allocator for the "JIT" (but which honestly should be a no-op).
This is also needed because I'm also writing a C compiler, and I don't really want each unit tests to invoke the codegen which sometimes exhitbits strange memory protection error during normal
cargo test. My educated guess for that is because of the allocated JIT memory map is so frequent, but the memory protection region has overlapped with ongoing page fault, so the internal virtual memory allocator can't keep up, causing general memory protection error. Although I can sidestep it withcargo nextestwhich runs each test as an independent process for now, but I'm also curious why that would happen.I also opted for using libm entirely for the Cranelift interpreter (what's the difference between this and Pulley by the way?), that a deeper research revealed that the fundamental reason for the seemingly faulty fma behavior is due to different ISA platforms implementations, a close analogy for that is the different implementation of
long doublein x87 and in ARM NEON, which I hope could make things easy to explain. As such, I would suggest just normalize it by using libm anyway.
Wasmtime GitHub notifications bot (Jun 10 2026 at 11:50):github-actions[bot] added the label cranelift:module on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 11:50):github-actions[bot] added the label cranelift on PR #13607.
Wasmtime GitHub notifications bot (Jun 10 2026 at 15:44)::memo: bjorn3 submitted PR review.
Wasmtime GitHub notifications bot (Jun 10 2026 at 15:44)::speech_balloon: bjorn3 created PR review comment:
I feel like if you want a no_std JIT, you should make your own cranelift_module::Module implementation tailored to the constraints of your OS.
Wasmtime GitHub notifications bot (Jun 10 2026 at 15:45)::speech_balloon: bjorn3 edited PR review comment.
Wasmtime GitHub notifications bot (Jun 10 2026 at 20:25):alexcrichton commented on PR #13607:
Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a
no_stdenvironment? Or are you looking to get the entire suite of Cranelift crates separately running in ano_stdenvironment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.
Wasmtime GitHub notifications bot (Jun 10 2026 at 23:37):stevefan1999-personal commented on PR #13607:
Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a
no_stdenvironment? Or are you looking to get the entire suite of Cranelift crates separately running in ano_stdenvironment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.Okay so it is two fold:
- Use Cranelift for the C compiler, which is written in no_std
- Having a wasmtime build that I can run WASI universally, such that Cranelift may or may not have JIT over that platform. The most important one is i386 support (or technically i686)
But I agree that it is okay to downsize the scope of the PR to break it down one by one, its just a little bit entangled.
Wasmtime GitHub notifications bot (Jun 10 2026 at 23:38):stevefan1999-personal edited a comment on PR #13607:
Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a
no_stdenvironment? Or are you looking to get the entire suite of Cranelift crates separately running in ano_stdenvironment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.Okay so it is two fold:
- Use Cranelift for the C compiler, which is written in no_std
- Having a wasmtime build that I can run WASI universally, such that Cranelift may or may not have JIT over that platform. The most important one is i386 support (or technically i686)
The reason I have to do 1. is that the C compiler should run in wasm and i686, basically any platforms that Rust could technically support. With enough hacks, maybe even on powerful ESP32s in the future
But I agree that it is okay to downsize the scope of the PR to break it down one by one, its just a little bit entangled.
Wasmtime GitHub notifications bot (Jun 10 2026 at 23:40):stevefan1999-personal edited a comment on PR #13607:
Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a
no_stdenvironment? Or are you looking to get the entire suite of Cranelift crates separately running in ano_stdenvironment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.Okay so it is two fold:
- Use Cranelift for the C compiler, which is written in no_std
- Having a wasmtime build that I can run WASI universally, such that Cranelift may or may not have JIT over that platform. The most important one is i386 support (or technically i686)
The reason I have to do 1. is that the C compiler should run in wasm and i686, basically any platforms that Rust could technically support. With enough hacks, maybe even on powerful ESP32s in the future. In fact, 2. is also part of the reason because I need a virtual file system if I compile it to wasm for browser access.
But I agree that it is okay to downsize the scope of the PR to break it down one by one, its just a little bit entangled.
Wasmtime GitHub notifications bot (Jun 10 2026 at 23:43):stevefan1999-personal edited a comment on PR #13607:
Is your motivation here @stevefan1999-personal tied to using Wasmtime-with-Cranelift-enabled in a
no_stdenvironment? Or are you looking to get the entire suite of Cranelift crates separately running in ano_stdenvironment? If the former then many of the changes here won't be necessary, although if the latter then many of these changes will be required. Before going too much further into review though I'd want to confirm this high-level bit.Okay so it is two fold:
- Use Cranelift for the C compiler, which is written in no_std
- Having a wasmtime build that I can run universally (and better if it comes with WASI support), such that Cranelift may or may not have JIT over that platform. The most important one is i386 support (or technically i686)
The reason I have to do 1. is that the C compiler should run in wasm and i686, basically any platforms that Rust could technically support. With enough hacks, maybe even on powerful ESP32s in the future. In fact, 2. is also part of the reason because I need a virtual file system if I compile it to wasm for browser access, may or may not be using WASI as a middle layer. I'm aware of that Rust's std do support WASI to some extent, but I prefer not to because that means I have to choose for using the legacy proposal or the component model.
But I agree that it is okay to downsize the scope of the PR to break it down one by one, its just a little bit entangled.
Wasmtime GitHub notifications bot (Jun 11 2026 at 14:39):alexcrichton commented on PR #13607:
Ok sounds reasonable. I'd recommend, yes, splitting this PR up as it's a bit too sprawling to review at this point. What I'd reccommend is going crate-by-crate to get things
no_stdcompatible. Since this is your first contribution I'd recommend doing something on the small-to-mid size first to learn how CI/review/style will work here, and then it should be easy to scale up to other crates after that.
Last updated: Jul 29 2026 at 05:03 UTC