libfirm VS wasmtime

An alternative: LibFirm but it's much simpler and feature-poor.

libFirm.

A full debugging session is also possible after LLDB >= 13 and Wasmtime are installed.

The only runtime that at least partially implements component model is wasmtime. But, as everything with component model, it is still WIP.

//Original Code from https://github.com/bytecodealliance/wasmtime/blob/main/examples/hello.rs //Adapted for brevity use anyhow::Result; use wasmtime::*; fn main() -> Result<()> { println!("Compiling module..."); let engine = Engine::default(); let module = Module::from_file(&engine, "hello.wat")?; //(1) println!("Initializing..."); let mut store = Store::new( &engine, () ); //(2) println!("Creating callback..."); let hello_func = Func::wrap(&mut store, |_caller: Caller<'_, ()>| { println!("Calling back..."); }); //(3) println!("Instantiating module..."); let imports = [hello_func.into()]; let instance = Instance::new(&mut store, &module, &imports)?; println!("Extracting export..."); let run = instance.get_typed_func::<(), ()>(&mut store, "run")?; //(4) println!("Calling export..."); run.call(&mut store, ())?; //(5) println!("Done."); Ok(()) }

Running a Wasm application outside the browser requires an appropriate runtime that implements the WebAssembly VM and provides interfaces to the underlying system. There are a few competing solutions in this field, the most popular being wasmtime, wasmer, and WAMR.

In 2022, we merged a project that has a huge impact on compile times in the right scenarios: incremental compilation. The basic idea is to cache the result of compiling individual functions, keyed on a hash of the IR. This way, when the compiler input only changes slightly – which is a common occurrence when developing or debugging a program – most of the compilation can reuse cached results. The actual design is much more subtle and interesting: we split the IR into two parts, a “stencil” and “parameters”, such that compilation only depends on the stencil (and this is enforced at the type level in the compiler). The cache records the stencil-to-machine-code compilation. The parameters can be applied to the machine code as “fixups”, and if they change, they do not spoil the cache. We put things like function-reference relocations and debug source locations in the parameters, because these frequently change in a global but superficial way (i.e., a mass renumbering) when modifying a compiler input. We devised a way to fuzz this framework for correctness by mutating a function and comparing incremental to from-scratch compilation, and so far have not found any miscompilation bugs.

If you've got more thoughts on this, filing an issue is always a good way to either start a discussion or at least put the information in a permanent place we can find later! It looks like we don't have any issues related to this in our tracker at the moment.

This actually seems to be experimentally supported by some runtimes, like wasmtime[0].

[0]: https://github.com/bytecodealliance/wasmtime/pull/3153

So, does someone know how to allocate memory on the heap using Cranelift? I've seen instructions like heap_addr, heap_load and heap_store so there should be some way (altrough I don't understand why we can't use the normal load and store here..). create_heap would be my best guess, but it takes a HeapData which confuses me. Dafuq is an index_type, HeapStyle and offset_guard_size? How do I get a GlobalValue for it? How do I free it? Or maybe I should just use C's malloc/free instead... On the other hand direct support for heaps seems to be removed? Sigh. I'm confused.

The only path forward here would be to bend rustc/MIR for streaming codegen (and then bolt it to something like lightbeam).

But, am I mistaken in thinking that it isn't available for armv6 (based on the releases seen here)