Rouven Raudzus (Jul 26 2026 at 01:41): Rouven Raudzus (Jul 26 2026 at 01:41):Topic: Metal: freestanding WAMR host with async imports, AOT and per-CPU runners
I’m embedding WAMR into an experimental UEFI/BIOS freestanding host. WAMR is the engine for signed Wasm/AOT modules, while MicroPython runs as a separate native persistent core runtime.
They are distinct execution layers, but intentionally interoperable: signed Wasm/AOT modules can self-register functionality into the native Python side, so Python can load and use module-provided capabilities through the Metal binding layer. MicroPython itself is not executed by WAMR.
I would value feedback on the WAMR-specific boundary: which assumptions should a host preserve around exec_env ownership, reentrancy, native-call suspension/resume, AOT lifecycle, and execution across CPU runners?
Today I ship matching AOT where available and fall back to the interpreter. Long term I’m also interested in the realistic path to Fast JIT on a freestanding x86-64 target.
Repo: https://github.com/pymergetic/metal
Rouven Raudzus (Jul 26 2026 at 01:44):A small concrete proof that this is already running, not just a design idea:
Metal boots into the persistent native MicroPython REPL. The screenshot shows the boot/device tree, the host/Python boundary, and a deliberately boring but live pmcmd.ping("127.0.0.1") call through the Metal network stack.
The important bit for the WAMR side is the line about signed Wasm/AOT natives self-registering into Python: WAMR modules are still separate guests, but they can intentionally expose capabilities into the persistent native Python layer through Metal’s binding mechanism.
Still experimental and definitely not claiming this is production-ready — I’m sharing it because I’d rather find the bad assumptions early.
Last updated: Jul 29 2026 at 05:03 UTC