Compiling Rust, GoLang, Zig, WebAssembly to MicroPython modules

[vshymanskyy]

Back in 2021, I experimented with the concept of embedded-wasm-apps.
This allowed to run any of the WebAssembly supported languages on microcontrollers:

Recently, I discovered that MicroPython has the ability to compile plain C code into a dynamically loadable .mpy file. This revelation immediately sparked an idea:

So, here is how to convert a WASM file into a MPY module and run it dynamically on different MCUs:
https://github.com/vshymanskyy/wasm2mpy

Compile

$ make
W2C test.wasm
GEN build/test.config.h
CC runtime.c
CC wasm.c
CC wasm2c/wasm-rt-mem-impl.c
CC wasm2c/wasm-rt-impl.c
AS thumb_case.S
LINK build/runtime.o
arch:         EM_ARM
text size:    1388
bss size:     108
GOT entries:  5
GEN test.mpy

Upload to the board

mpremote cp test.mpy :lib/

Run

MicroPython v1.24.0-preview.224.g6c3dc0c0b on 2024-08-22; Raspberry Pi Pico W with RP2040
Type "help()" for more information.
>>> import test
>>> test.add(3, 4)
7
>>> test.add(10, 6)
16

Potential benefits of this approach are already described in embedded-wasm-apps.
Also, it will play nicely with VfsMap

Further reading:

• https://github.com/wasm3/embedded-wasm-apps
• https://github.com/WebAssembly/wabt/blob/main/wasm2c/README.md
• https://docs.micropython.org/en/latest/develop/natmod.html
• natmod: Allow linking with static libraries #15838
• Include a WASM interpreter as part of micropython or its standard library? #15270 (comment)

[jonnor]

Very cool work! I believe that building on, and expanding the usage of, .mpy native modules has a lot of potential for MicroPython. It enables creating modules with near-native performance (the bindings boundary does have a slight overhead), while preserving the "just mip install it" developer experience. Which is what people expect from Python on desktop, but is quite unique on embedded/microcontrollers.

Having WASM also as an option here, allows code in more languages to be used. And over time we will likely see more and more libraries built in a WASM-first manner, which can then be utilized on MicroPython. Often this comes from "web land" (with very different constraints) but there are some areas where I think code reuse might be realistic - for example compression algorithms, hashing, file formats, digital signal processing, algorithms, numeric computing, machine learning, et.c.

[jonnor]

It seems that in your approach, WASM is ahead-of-time compiled? That is excellent, because one avoids the FLASH/RAM footprint of an interpreter/runtime, and the difficulty of making two different runtimes interoperate.

Also: Congratulations on Independence Day of Ukraine! А завзяття, праця щира свого ще докаже, Ще ся волі в Україні піснь гучна розляже.

[vshymanskyy]

Thank you for the warm wishes and for quoting such a powerful line!
Indeed, Ukraine's spirit of independence resonates deeply 💙 💛

As for the approach - you guessed it right. The wasm module is compiled AOT to the native target architecture. It will still impose some overhead, but it can be negligible in many cases.

Deploying such modules via mip or OTA updates will also require taking into account the target architecture. I'm not sure if mip currently does this.

[jonnor]

Indeed, it does. I am happy to know many from Ukraine, and hope to go there soon.

As far as I know, mip does currently not understand native modules and the target architecture / .mpy binary version. This is something I would like to see addressed (I use dynamic modules extensively in https://github.com/emlearn/emlearn-micropython/). But that is a bit wider scope - so ideally we would have a separate discussion thread for that.

Btw, there is currently a blocker issue with non-trivial .mpy native modules (those that have BSS data) - #6769 - hopefully it can be resolved soon.

[agatti]

Sorry for derailing the discussion but, @jonnor do you reckon that it's the same issue I see in #15603?

[vshymanskyy]

I have also updated https://github.com/wasm3/embedded-wasm-apps

Since 2021, many dependencies had breaking changes.. some significant efforts were required to get everything working again.
Now we have a set of 8 sample wasm apps written in different languages and with different complexity, that can be used to evaluate the wasm -> mpy conversion process.

[vshymanskyy]

small update... 😁

======================================
    Building assemblyscript.mpy ...
======================================

🚀 AssemblyScript is running!

======================================
    Building cpp.mpy ...
======================================

🤩 C++ is running!

======================================
    Building rust.mpy ...
======================================

🦀 Rust is running!

======================================
    Building tinygo.mpy ...
======================================

🤖 TinyGo is running!

======================================
    Building virgil.mpy ...
======================================

✨ Virgil is running

======================================
    Building wat.mpy ...
======================================

⚙ WAT is running!

======================================
    Building zig.mpy ...
======================================

⚡ Zig is running!

[jonnor]

Yeah, that is a known issue/limitation at this moment. Discussion, including some fixes/workaround at #5629

[vshymanskyy]

Yes, thanks. I already got my first impressions from this process 😁
I was able to progress a little bit with xtensawin.

Looks like mpy_ld.py just links everything you throw at it, so providing a generic set of .o files from libgcc is not the best approach - it will just inflate every single .mpy file with unnecessary code.

Also, as already discussed in other threads, it requires some automation.
I can't imagine going through this every time I'm building another module or apply changes to existing code.

I was struggling to apply the same process to armv6m, will try again later.

Also, I figured out that XIP (executing from flash directly) of native modules is still not happening even if modules are frozen.

[vshymanskyy]

On the positive note, here are the current results on ESP32:

ARCH=xtensawin ./run-all.sh
🚀 AssemblyScript is running!
🦀 Rust is running!
🤩 C++ is running!
🤖 TinyGo is running!
⚙ WAT is running!
⚡ Zig is running!
Running CoreMark 1.0...

These are real WebAssembly apps built with different languages and running on ESP32-S3 as MicroPython .mpy files, i.e:

import zig
zig.run()

[Josverl]

Very Nice progress.
is there any interaction sync or dare I ask , async possible between these different modules ?

[vshymanskyy]

The progress stands on the shoulders of embedded-wasm-apps and mpy_ld :)

These are just normal MicroPython modules, so they can interact as usual. I don't think "deep" async is possible, but "shallow" async should be possible.
@Josverl we may also get possibility of deep async when WebAssembly Stack Switching paves its way to the toolchains

[vshymanskyy]

I was finally able to run something more complicated...
Namely Coremark compiled to .mpy via WebAssembly.

MicroPython v1.24.0-preview.193.gba49efe6b on 2024-08-20; Generic ESP32S3 module with ESP32S3
Type "help()" for more information.
>>> import machine
>>> machine.freq(240000000)
>>> import coremark
>>> coremark.setup()
Running CoreMark 1.0...
Result: 135.796

The declared CoreMark for ESP32-S3 is 613.86.

[vshymanskyy]

With some small optimizations, I'm getting 250.517 now.
There's still room for improvement

[vshymanskyy]

UPD: 271.573

[vshymanskyy]

You can now access and modify the wasm module memory:

>>> import cpp
>>> cpp.setup()
🤩 C++ is running!
>>> cpp._memory[4096:4096+32]
bytearray(b' Blink\x00\xf0\x9f\xa4\xa9 C++ is running!\x00\n\x00\x00\x00')
>>> new_data = b"Hello C++ world"
>>> cpp._memory[4108:4108+len(new_data)] = new_data
>>> cpp.setup()
🤩 Hello C++ world

[vshymanskyy]

🚀🚀🚀 wasm2mpy is now on the HN Front Page: https://news.ycombinator.com/item?id=41599579

[rkompass]

While I think this is a very cool project, I'm wondering what the limitations of the combined toolchains are.

More specifically: Python is an object oriented language and has nice predefined types like: list, tuple, dictionary, ...
Also functions are complemented by generators, iterators, ....
You may define objects with certain interfaces like the ability to indexing (let the object behave like an array).

Also the source languages you mention like Rust, Go, Zig are object oriented, aren't they?

I don't know webassembly. But I know that C is not an object oriented language.
Therefore I don't expect that any object oriented features of the source code can be translated to python.

Can you confirm this?
On the other hand if object features could be translated I would be interesed in an example of this.

[vshymanskyy]

Yes, I think this is what you're looking for: https://component-model.bytecodealliance.org/design/why-component-model.html
Basically, some form of bindgen will have to be run (this is not done in wasm2mpy right now)