Which WASM runtime(s) will K/W support?
# webassemblyn
napperley
12/17/2021, 11:44 PMWhich WASM runtime(s) will K/W support?
s
Svyatoslav Kuzmich [JB]
12/18/2021, 7:08 PMJS embedding initially. WASI probably later.
Wasm runtime would have to support exception handling and GC proposals. If not, we would need to additionally transpile “Wasm+GC” to “Wasm w/o GC”.
Our standard library doesn’t import many things from the host, so it should be easy to port it to different hosts. Currently, besides JS interop, we have just two imports:
println👍 1
n
napperley
12/19/2021, 12:27 AMThere are some key WASM runtimes to keep an eye on:
• WASM3 - supports many platforms incl uC based ones, many programming languages are supported ( https://github.com/wasm3/wasm3 )
• WasmEdge - optimized for server side applications, supports some programming languages ( https://github.com/WasmEdge/WasmEdge )
• Wasmer - a WASI based WASM runtime, many programming languages are supported ( https://github.com/wasmerio/wasmer )
• WAMR - standalone WASM runtime with small footprint, supports some platforms incl RTOS ones ( https://github.com/bytecodealliance/wasm-micro-runtime )
A list of known WASM runtimes can be found here: https://github.com/appcypher/awesome-wasm-runtimes
napperley
12/19/2021, 12:28 AMNote that there are a few WASM runtimes that specialise in running on many different embedded devices; especially uC's. Hypothetically if Kotlin were to run on uC's then the strategy would be to use K/W, and pick a WASM runtime that supports as many uC's as possible. Once that is done a pathway is provided to Kotliners to do uC development with Kotlin via K/W. Part of that would involve having a dedicated Micro Controller Development section on the Kotlin website, and possibly some Kotlin Koans containing some uC development exercises that can be run in Kotlin Playground ( https://play.kotlinlang.org/ ).
s
Svyatoslav Kuzmich [JB]
12/19/2021, 9:36 AMGood thing that most of the non-JS runtimes support standards like WASI. Ideally we wouldn’t need to cater to a specific runtime, but target standards like Wasm+WASI instead. Non-standard runtime features could, perhaps, be provided as a third-party library.
I’m not an expert in micro controllers, do you think it would be preferable to use Wasm instead of native code there?
n
napperley
12/19/2021, 9:56 PMI'm not an expert in Embedded development (especially with uC's) by any means. From what I do know it would be preferable to go the bare metal ( https://en.wikipedia.org/wiki/Bare_machine ) route, rather than heading down a route where a VM is used or something similar to a VM like WASM. Most high level programming languages fail to take off on uC's although there are two main exceptions, MicroPython ( https://micropython.org/ ) and TinyGo ( https://tinygo.org/ ).
napperley
12/20/2021, 12:07 AMWith that said there have already been some successful attempts to get WASM programs running on various uC's including the Raspberry Pi Pico ( https://www.raspberrypi.com/products/raspberry-pi-pico/ ), and some Arduino based uC's. I found a very interesting presentation covering Wasm3 with uC's ( ). Unfortunately the presenter is speaking Russian (YouTube doesn't do a good job of translating Russian to English), however all the slides/demos are in English which is very weird.
s
Svyatoslav Kuzmich [JB]
12/20/2021, 12:08 AMYea, I’m not sure why people would want to run Wasm on microcontrollers. Wasm shines in cases where you need sandboxing and portability. But are these features commonly needed in embedded development, especially when you have to trade performance and memory usage to achieve them? Wouldn’t some stripped down version of K/Native be a better fit?
Svyatoslav Kuzmich [JB]
12/20/2021, 12:12 AMWasm3 video is in Ukrainian, btw 🙂
n
napperley
12/20/2021, 12:20 AMPortability would definitely be needed considering that there are a colossal number of different uC chip/board combos. Imagine trying to port something to that many combinations. It would involve a massive amount of work/maintenance, and there would be tons of code duplication 😦. Some projects exist to address the code portability issue ( https://platformio.org/ ) with uC's. No single uC dominates the uC market. Micro controllers are a bit like the PC market in the 70s; very little in the way of hardware standards and no code portability.
s
Svyatoslav Kuzmich [JB]
12/20/2021, 12:31 AMThere wouldn't be any code duplication if it was written in some high-level language, would it? I could be wrong, but it feels like embedded developers know the hardware they are developing for, and it it would change, it wouldn't be very hard for them to recompile the project for this different uC.
n
napperley
12/20/2021, 12:38 AMEven if a high level language can be used many of them require an OS in order to function. With a uC there is no OS which means that some of the OS functionality would need to be covered using one of the following options:
1. Do it all in the program running on the uC
2. Use a programming language runtime containing the functionality
3. Run an RTOS (similar to an OS) on the uC
4. Use a lightweight VM/WASM runtime containing the functionality
napperley
12/20/2021, 12:44 AMSome high level libraries would be required in order to have portable code, which cover some areas like GPIO ( https://en.wikipedia.org/wiki/General-purpose_input/output ), SPI ( https://en.wikipedia.org/wiki/Serial_Peripheral_Interface ), Serial ( https://en.wikipedia.org/wiki/Serial_communication ), I2C ( https://en.wikipedia.org/wiki/I%C2%B2C ) etc.
s
Svyatoslav Kuzmich [JB]
12/20/2021, 12:45 AMLooks like 2. and 3. are just like 4. but without penalizing efficiency of user-level code. Wasm VM would still have to compile or interpret code compared to just running native code.
n
napperley
12/20/2021, 12:48 AMIf one were to go with #4 then AOT would be the way to go for performance reasons.
s
Svyatoslav Kuzmich [JB]
12/20/2021, 12:48 AMI'm not sure that Wasm would make it any easier to abstract IO libraries, compared to using C API.
Svyatoslav Kuzmich [JB]
12/20/2021, 12:52 AMIf you mean AOT before sending to device - then you are just sending native code, which you could have gotten by using Native toolchain.
If you mean AOT on device - the you would need to store compiler and both Wasm and native code on device, which looks suboptimal.
n
napperley
12/20/2021, 1:00 AMI meant AOT before sending to device (similar to what happens with building K/N programs).
s
Svyatoslav Kuzmich [JB]
12/20/2021, 1:04 AMEven in this case Wasm has more overhead. It would have to perform address range checks on memory accesses. These checks are almost free on regular CPUs because of virtual memory protection trick, but I guess they wouldn't be free on some uCs.
n
napperley
12/20/2021, 1:24 AMThis video covers lightweight abstractions for embedded WASM:
One of the key things used to reduce WASM overhead is using CPU interrupts (an alternative form of events) instead of C libraries for some key functionality. Would an ARM M series CPU containing a MPU ( https://en.wikipedia.org/wiki/Memory_protection_unit ) be sufficient performance wise?
s
Svyatoslav Kuzmich [JB]
12/20/2021, 1:52 AMWould an ARM M series CPU containing a MPU ( https://en.wikipedia.org/wiki/Memory_protection_unit ) be sufficient performance wise?I’m not familiar with these CPUs, but usually it works by protecting 8Gb of virtual memory, so that every out-of-bounds i32 address + i32 offset would hit protected page.
It is a bit of a mystery how WASM modules can be used like software libraries ( ). Isn’t a WASM module similar to an ELF file?Wasm modules can be used as libraries, they can export functions, globals, and other things. They can be linked dynamically.
👍 1
7 Views