I just had a look at the code and it is indeed very compact. I haven't compiled or used it.
Looks like RISC-V 32-bit integer and multiply and atomic instr extension. Floating point supported when compiling via gcc or similar the example apps (not by the emulator itself but by the compiler emiting the required software functions to emulate the floating point operations instead).
I think it is very clever. Very compact instruction set, with the advantage of being supported by several compilers.
I suppose this is in the same realm as what some people are trying to do with WASM, creating a common execution environment? This is built on RISC-V instead though. I wish I knew more about the limitations/capabilities of each approach, but in any case a future where applications are built for a common VM seems like something we've been building to for a while, the modern web being the closest we've come.
I did a brief comparison a while back, specifically WASM vs libriscv for. I decided to go with WASM, primarily because it was much more closely designed for this sort of thing, and it works in browsers. libriscv is really cool and impressive though.
libriscv looks amazing but its's much larger. It says "Less than 40kB total memory usage".
My first version (unpublished) of uvm32 was called uvm80 and emulated a Zilog Z80 CPU. My aim is to have a safe, embeddable sandbox for any device, rather than the best performance.
This looks like it has a smaller code footprint at least. I'm not sure RISC-V is a very good target for this sort of thing. E.g. decoding the immediates in software is going to be very slow, whereas in hardware it's fast.
But on the other hand it is a stable target and can be configured to be a lot simpler than WASM.
I like the single C file, but Docker if you want all the examples approach, that's really convenient for embedded.
Test coverage looks good as well, be interesting to see the metrics.
This would be quite cool for adding scripting to medical devices, avoiding the need to revalidate the "core" each time you change a feature.
An interesting comparison would be against an embedded WASM bytecode interpreter like https://github.com/bytecodealliance/wasm-micro-runtime, which is still much larger at 56.3K on a Cortex M4F.
Maybe WASM is just a more complicated instruction set than the smallest RISCV profile?
Wasm-mvp is very simple, especially if you drop the floating point instructions. But WAMR supports a lot of extensions - https://github.com/bytecodealliance/wasm-micro-runtime?tab=r.... There is a garbage collector, jit, WASI, threads, debugger support etc.
Interesting timing - been looking for exactly this for embedded firmware testing. Most alternatives are either too heavy (full emulation) or too fragile (custom interpreters).
Have you considered adding support for memory-mapped IO simulation? That would make it useful for testing IoT/microcontroller drivers without the actual hardware.
I just had a look at the code and it is indeed very compact. I haven't compiled or used it.
Looks like RISC-V 32-bit integer and multiply and atomic instr extension. Floating point supported when compiling via gcc or similar the example apps (not by the emulator itself but by the compiler emiting the required software functions to emulate the floating point operations instead).
I think it is very clever. Very compact instruction set, with the advantage of being supported by several compilers.
Wrapper over this other project which is the one implementing the instruction set itself: https://github.com/cnlohr/mini-rv32ima
Kudos to both projects.
I suppose this is in the same realm as what some people are trying to do with WASM, creating a common execution environment? This is built on RISC-V instead though. I wish I knew more about the limitations/capabilities of each approach, but in any case a future where applications are built for a common VM seems like something we've been building to for a while, the modern web being the closest we've come.
I did a brief comparison a while back, specifically WASM vs libriscv for. I decided to go with WASM, primarily because it was much more closely designed for this sort of thing, and it works in browsers. libriscv is really cool and impressive though.
EDIT: Found this link in my notes as well: https://news.ycombinator.com/item?id=24900376
libriscv looks amazing but its's much larger. It says "Less than 40kB total memory usage". My first version (unpublished) of uvm32 was called uvm80 and emulated a Zilog Z80 CPU. My aim is to have a safe, embeddable sandbox for any device, rather than the best performance.
See https://opensource.googleblog.com/2025/11/secure-by-design-f...
This looks like it has a smaller code footprint at least. I'm not sure RISC-V is a very good target for this sort of thing. E.g. decoding the immediates in software is going to be very slow, whereas in hardware it's fast.
But on the other hand it is a stable target and can be configured to be a lot simpler than WASM.
Thanks for the link, Wasefire looks interesting. I suspect that their design goals are very different to mine. https://github.com/ringtailsoftware/uvm32?tab=readme-ov-file...
Really neat clean code!
I like the single C file, but Docker if you want all the examples approach, that's really convenient for embedded.
Test coverage looks good as well, be interesting to see the metrics.
This would be quite cool for adding scripting to medical devices, avoiding the need to revalidate the "core" each time you change a feature.
An interesting comparison would be against an embedded WASM bytecode interpreter like https://github.com/bytecodealliance/wasm-micro-runtime, which is still much larger at 56.3K on a Cortex M4F. Maybe WASM is just a more complicated instruction set than the smallest RISCV profile?
Wasm-mvp is very simple, especially if you drop the floating point instructions. But WAMR supports a lot of extensions - https://github.com/bytecodealliance/wasm-micro-runtime?tab=r.... There is a garbage collector, jit, WASI, threads, debugger support etc.
Interesting timing - been looking for exactly this for embedded firmware testing. Most alternatives are either too heavy (full emulation) or too fragile (custom interpreters).
Have you considered adding support for memory-mapped IO simulation? That would make it useful for testing IoT/microcontroller drivers without the actual hardware.
This could be easily done. The emulator core supports memory mapped IO, but uvm32 only uses this to map an extra block of RAM from the host (for a framebuffer, or a separare memory heap). You can trap the writes here: https://github.com/ringtailsoftware/uvm32/blob/main/uvm32/uv... and the reads here https://github.com/ringtailsoftware/uvm32/blob/main/uvm32/uv...
"Just add rats" https://github.com/ringtailsoftware/uvm32/tree/main/apps/zig...