Wasmtime GitHub notifications bot (Dec 27 2025 at 18:22): Wasmtime GitHub notifications bot (Dec 27 2025 at 18:22):the-ssd opened PR #12222 from the-ssd:cranelift-nostd to bytecodealliance:main:
Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.
There is already #9007, which stalled.
And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).
What is left to do:
- [ ] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [ ] separete PRs for: cranelift_assembler_x86, moving large parts to core and alloc, and isle
For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of
///!doc comments. Should I redo it, and move them to the top, or avoid prelude fully?
Wasmtime GitHub notifications bot (Dec 27 2025 at 18:50):the-ssd updated PR #12222.
Wasmtime GitHub notifications bot (Dec 27 2025 at 19:00):the-ssd updated PR #12222.
Wasmtime GitHub notifications bot (Dec 27 2025 at 19:11):the-ssd edited PR #12222:
Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.
There is already #9007, which stalled.
And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).
What is left to do:
- [ ] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [ ] separate PRs for: cranelift_assembler_x86, moving large parts to core and alloc, and isle
For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of
///!doc comments. Should I redo it, and move them to the top, or avoid prelude fully?Edit: prelude can be added by replacing first use of
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
Wasmtime GitHub notifications bot (Dec 27 2025 at 19:16):the-ssd edited PR #12222:
Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.
There is already #9007, which stalled.
And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).
What is left to do:
- [ ] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [ ] separate PRs for: cranelift_assembler_x86, moving large parts to core and alloc, and isle
- [ ] floating point issues
For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of
///!doc comments. Should I redo it, and move them to the top, or avoid prelude fully?Edit: prelude can be added by replacing first use of
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
Wasmtime GitHub notifications bot (Dec 27 2025 at 19:26):the-ssd updated PR #12222.
Last updated: Jan 09 2026 at 13:15 UTC