Wasm2Mpy: Compiling WASM to MicroPython so it can run on Raspberrys

Post by 01HNNWZ0MV43FF » Tue, Sep 24, 2024, 10:47 PM UTC

jononor wrote: post #10

kristianp wrote: post #8

Earlier quoted context omitted.

> i do think it would be clearer, though, to explain up front that the module being built is not made of python code, but rather callable from python code I know nothing about micropython. Do the modules contain bytecode?

.mpy modules can contain MicroPython bytecode and/or native machine code. In this case, WASM is compiled (via C) to native code. So the performance is very good, much better than interpreting either MicroPython bytecode or WASM bytecode. The conventional way of creating native modules for MicroPython is to write them in C. This work allows to use any language that supports WASM output target.

Post by dbcurtis » Wed, Sep 25, 2024, 12:32 AM UTC

01HNNWZ0MV43FF wrote: post #12

jononor wrote: post #10

Earlier quoted context omitted.

.mpy modules can contain MicroPython bytecode and/or native machine code. In this case, WASM is compiled (via C) to native code. So the performance is very good, much better than interpreting either MicroPython bytecode or WASM bytecode. The conventional way of creating native modules for MicroPython is to write them in C. This work allows to use any language that supports WASM output target.

Oh, I didn't know MicroPython was fully AOT. I'm surprised, since vanilla Python is typically interpreted with maybe a bytecode cache, right?

Post by 15155 » Wed, Sep 25, 2024, 4:02 AM UTC

kragen wrote: post #7

bragr wrote: post #2

I feel like this project is a classic example of the README missing a "Why?" section. Not to justify the project, it just makes it hard to evaluate without understanding why they choose implementing a transpiler rather than an embedded WASM VM. Or why not transpile to native assembly? I'm sure they have good reasons but they aren't listed here.

i think your questions are implicitly answered in the top page of the readme, but by showing rather than telling esp32 and stm32 run three different native assembly instruction sets (though this only supports two of them, the others listed in the first line of the readme are all arm) the coremark results seem like an adequate answer to why you'd use a compiler rather than an interpreter i do think it would be clearer…

Post by zorgmonkey » Wed, Sep 25, 2024, 5:35 AM UTC

jononor wrote: post #10

kristianp wrote: post #8

Earlier quoted context omitted.

> i do think it would be clearer, though, to explain up front that the module being built is not made of python code, but rather callable from python code I know nothing about micropython. Do the modules contain bytecode?

.mpy modules can contain MicroPython bytecode and/or native machine code. In this case, WASM is compiled (via C) to native code. So the performance is very good, much better than interpreting either MicroPython bytecode or WASM bytecode. The conventional way of creating native modules for MicroPython is to write them in C. This work allows to use any language that supports WASM output target.

Post by vshymanskyy » Wed, Sep 25, 2024, 6:00 AM UTC

bragr wrote: post #2

I feel like this project is a classic example of the README missing a "Why?" section. Not to justify the project, it just makes it hard to evaluate without understanding why they choose implementing a transpiler rather than an embedded WASM VM. Or why not transpile to native assembly? I'm sure they have good reasons but they aren't listed here.