Chris Fallin

@bahbah94 you'll want to look at the codegen from the ISLE-to-Rust compiler in [this](https://github.com/bytecodealliance/wasmtime/blob/main/cranelift/isle/isle/src/codegen.rs) file. That generates Rust source code that is then compiled as part of the main Cranelift...

As noted above this is officially an unsupported platform, but we're happy to merge contributions on a best-effort basis. It looks like it's probably a handful-of-lines addition for the FreeBSD/aarch64...

> How about scheduling a call when y'all are ready with the 3 of us? That'd probably be best to draw attention to any various areas and for me to...

> There seems to be an issue with getting the correct return addresses when walking the stack on x64 Linux. > > From what I gather, it's because Rust and/or...

No, Wasmtime's unwinder has nothing to do with native stack frames; it is specific to Wasmtime's metadata format. You'll probably want to do similar to Wasmtime (and Cranelift's `clif-util` test...

Would it make sense to fit the notion of asynchronous/background compilation into this design? Engines today often have mechanisms to kick off a compilation, and allow the background thread to...

> so that makes me wonder if engines could copy+validate the bytecode synchronously and provide a valid funcref as a return value, but then block if the function is invoked...

Indeed, and to state it explicitly, before the function is ready, calling the funcref could still have the blocking semantics you describe. That behavior actually makes it possible to do...

> Perhaps it would be viable to simply rely on engines' ability to compile/optimize lazily? An uncompiled funcref that will be lazily compiled on its first call is very quick...

The `func.ready` approach could *kind of* work for that, too; though there is a distinction between "pause because compiler is churning on a background thread" and "pause until you return...