9 ms·
WebAssembly Micro Runtime
- janekm 7y agoI was wondering if it would be suitable for micro controllers (with let's say a few hundred kB of memory, not MB). I can't immediately find the answer but there appears to be a port to Zephyr OS in the repo so that is promising. There's also the beginnings of a sensor manager and API so clearly small embedded use cases are intended. It's still a very small project (looks like one contributor so far), but that's no bad thing...
- justinclift 7y agoTinyGo (Go for embedded devices - AVR, Cortex, Bluepill, STM32F4, etc) compiles to Wasm as well: https://github.com/tinygo-org/tinygo/ https://github.com/tinygo-org/tinygo/ No garbage collector yet, but it's on the ToDo list and probably not too far off. :)
- snarfy 7y agoDo you really want garbage collection when your device has 2KB of ram?
- justinclift 7y agoIt depends. There's no one-size-fits-everything approach for this stuff. :)
- kbumsik 7y agoNo, you can't run GC at all. The minimum size of WASM heap is 64KiB by its spec. Otherwise it should run in stack-only mode. So running GC for microcontroller with less than that size doesn't make much sense.
- zaarn 7y agoI would imagine a scaled down and cut version of WASM could be viable on MCU's as a form of interpreted program to be loaded from an external memory device, the WASM compiler/interpreter would likely already take much of a small MCU's memory.
- i4t 7y agoYes, definitely aimed at embedded devices.
- baybal2 7y agoIt will be much more ahead of interpreters running on MCUs (overhead of parsing alone is enough to disqualify them for production use,) but still hopelessly far behind native code. WASM was made with running on regular desktop CPUs in mind. Wasm is not a truly a state machine, nor stack machine, but a horrible hybrid in between them thanks to design by committee. Changeable locals, accessible undefineds, use of stack pointer protection technique that kills both pipelining and speculative execution. Yes, that's combined downsides of both stack and register VMs. There were MCU that were naively running Java long time ago, but all failed on the market. The idea proved non feasible
- Zardoz84 7y agoSo BASIC Stamp, was a dream... I know that was popular to do some automatization on industrial machines.
- boomlinde 7y ago> It will be much more ahead of interpreters running on MCUs (overhead of parsing alone is enough to disqualify them for production use,) but still hopelessly far behind native code. To be clear, this is also interpreted, so it doesn't have an advantage there.
- rjsw 7y ago> There were MCU that were naively running Java long time ago, but all failed on the market. The idea proved non feasible Not sure they failed for technical reasons, embedded CPUs just got fast enough and typical memory big enough to run a JIT.
- sitkack 7y agoWe already have Lua [1] and MicroPython [2] as well as a myriad of Forths, Scheme, etc running on MCUs. So arguably Wasm would be a better fit for an MCU over these two as it doesn't need to be parsed and the interpreter doesn't need to handle dynamic types. [1] http://www.eluaproject.net/ http://www.eluaproject.net/ [2] https://micropython.org/ https://micropython.org/
- deleted 7y ago[deleted]
- radarsat1 7y agoWhat would be the advantage of running WASM on a microcontroller instead of compiling the code directly for the microcontroller's architecture?
- yorwba 7y agoI assume this is meant for cases where there's no LLVM backend for the target architecture and you're forced to use the vendor's proprietary C compiler. Then you can use that to compile this runtime and run any program written in a WASM-targeting language on top of it.
- janekm 7y agoI'm assuming safer loadable modules (there's no memory protection on most mcus) and choice of languages that have wasm backends. In some circumstances being able to run the same code in a browser in a test environment as on the device could also be great (for education for example).
- jononor 7y agoI'm interested in WASM for microcontrollers to have the application guaranteed free of side-effects (due to the sandboxing). This allows to be test the logic thoroughly in isolation, and have reasonably high certainty that it does not do anything funky - like write to some hardware register in some edge-case. Such code would not be able to do I/O directly, but must receive it from outside the sandbox. It could be a pure function implementing a state machine on form `state, outputs = next(state, inputs)`, where state,inputs and outputs are plain data. This structure is amendable to generating testcases, be it via property testing or fuzzing. Or regression tests by capturing a stream of state transitions in serialized form. There are languages which makes this possible, like Haskell, or maybe even Rust or Ada. However in the embedded world, C is what everyone knows and uses, so there would be a benefit to staying within that ecosystem.
- unwind 7y agoCool, but aren't side-effects just what you want when using a microcontroller to, you know, control things? I work in embedded development and the amount of pure logic is really small in our software but I guess that varies with the niche you're in.
- grenoire 7y agoGosh, somebody should be proofreading that README. It seems a little unprofessional of Intel when I cannot understand what's meant in certain sentences...
- jeswin 7y agoIt was quite readable for me, although there were some sentences which stood out. How I see it is: A developer whose first language is not English (or even any of the Western Languages which share similarities) made a fairly good README - which could be improved further by native speakers. If you ask me to write a similar README in Japanese/Chinese/Thai, I wouldn't even know where to start.
- imtringued 7y agoI envy people who suck at grammar but are still capable of expressing their ideas because they know their vocabulary. They somehow managed to succeed at the hard parts before mastering the easy parts of a language.
- deleted 7y ago[deleted]
- andai 7y agoArguably, vocabulary is the easy part.
- sanxiyn 7y agoNo, vocabulary is the hard part. It's where you spend most of learning time.
- andai 7y agoIf you define vocabulary to include not just the words, but the appropriate usage-in-context, then sure. Arguably that's not a short formal list of rules you memorize, but an intuitive understanding of thousands of specific cases that can only be acquired through massive exposure to the language. I'm not sure what the word for that is, it's neither vocabulary nor grammar, and yet more important than either of them -- actually even more important than both vocabulary and grammar put together (lists of words and lists of rules).
- cabalamat 7y agoBig companies like Intel should be able to afford to pay technical writers whose native language is English. Consider: > WASM is already the LLVM official backend target This implies that the only thing LLVM compiles to is WASM. Better would be something like "WASM is already an official LLVM backend target" or "LLVM already compiles to WASM".
- no_identd 7y agoThey don't seem to require a CLA right now, so, how about you send a pull request?
- thrower123 7y agoThe "submit a pull request" method of responding to problems, especially for a project supported by billion dollar companies, needs to die in a fire. I really prefer to have documentation written by people who understand how things actually work on the inside.
- oblio 7y ago> Big companies like Intel should be able to afford to pay technical writers whose native language is English. Do they actually need native English speakers? I'd assume they'd just need people proficient in English :)
- int_19h 7y agoI doubt this was written by a technical writer. Most likely, it's maintained by the developers who work on the project.
- ngcc_hk 7y agoSeems quite interesting and hope to have more info about actual device.
- pepijndevos 7y agoHold on... so if I implement a wasm runtime somewhere, I can compile random things for it. brb, writing wasm runtime for avr and z80
- acqq 7y agoNote: “Features WASM interpreter (AOT is planned)” You’ll compile a program to have it interpreted at the end. Does anybody know some specific case where this direction is advantageous?
- q3k 7y agoThis is how a lot of interpreters work - they compile source code to some intermediary bytecode (usually an imaginary stack or register machine) and then interpret that. It's usually faster than executing directly over some sort of AST, and also fast when you re-execute the same script over again (that's why Python creates .pyc files for modules).
- boomlinde 7y agoIn this instance I think that by AOT they mean that at some point the runtime will be able to compile WASM into machine code ahead of time and execute that instead of interpreting it during run-time. WASM already is the intermediate format and VM that you describe.
- baybal2 7y ago> Does anybody know some specific case where this direction is advantageous? Very slow memory. Decades ago, a lot of interpreters did the same trick internally: 1. tokenise code, 2. convert to some compact binary serialisation format used internally by the rest of interpreter. The trick was to make interpreter code to remain in CPU cache as long as possible while the code being interpreted did not require fetching from RAM
- sanxiyn 7y agoInterpreters save space. That's why Apple II used interpretation extensively.
- no_identd 7y agoEvery time someone submits wasm related content, I feel obliged to link this classic talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Bernhardt, Gary – The Birth & Death of JavaScript (PyCon 2014)
- afiori 7y agoHonest question, why is this talk so relevant? I agree it had a good foresight, but I watched it and am a bit surprised by how much it is mentioned.
- shurcooL 7y agoMy guess as to why it’s mentioned so much is that the general expectation is that many people haven’t seen it yet. When people do watch it, they’re surprised by how much good foresight there was, and so they repeat the cycle.
- oblio 7y agoThe presentation style is quite funny. It was even funnier at the time, when such a thing was considered almost inconceivable. Now, it seems prescient.
- Jyaif 7y agoThis talk is (thankfully) obsolete now. We don't need to write (or even to compile to) JS to have multi platform, we just need to write/generate wasm :-)
- NonEUCitizen 7y agoThe README says "small footprint" but does not seem to mention what this is numerically?
- snarfy 7y agoHow does this compare to Mozilla's wasi? [1] [1] - https://wasi.dev/ https://wasi.dev/
- ColinEberhardt 7y agoWASI is a system interface for WebAssembly modules, it is not an implementation. Therefore, these are quite different. However, they could have decided to use WASI as the interface for their wasm runtime, but it looks like they didn't
- oblio 7y agoIt's likely this project was started before WASI was announced.
- gouh 7y agoa bit off topic, but I was wondering, can WASI API be used directly from c/c++ without compiling to wasm ? Basically to have native perf but still benefit from the crossplatform APIs that WASI will expose
- Rusky 7y agoThat depends entirely on the implementation (and leaves open the question of ABI and binary file format).
- kibwen 7y agoInteresting, apparently WebAssembly is a relatively small spec to implement; someone at our local Rust usergroup has also shown off a WASM runtime that runs on microcontrollers.
- nicolashahn 7y agoArduino-compatible?
- kbumsik 7y agoI'm always interested in running WASM in microcontrollers, but AFAIK there is a severe limitation of WASM spec: the minimum size of heap (WASM memory page) is 64KiB, which is too big for many of microcontrollers. Otherwise a WASM module must run in stack-only mode. Unless this problem is resolved I don't think WASM can be adopt widely in the world of microcontrollers.
- BubRoss 7y agoWhy is it a problem to not have the wasm heap with less than 64KB of memory? At that level you could deal with all your memory explicitly, by creating fixed size arrays.
- kbumsik 7y agoWe could and it is always better to have fixed sized arrays, but having no choices is totally different situation than doing something preferable. It will make your life much harder in some operations such as string manipulation. Having minimum 64KB of WASM memory is still a huge cost for mainstream microcontrollers. Most of dynamic memory stuff in embedded system requires at most ~10KB (and often less than 1KB) of memory. We are just throwing away the rest of the precious memory.
- jononor 7y agoOn a microcontroller one probably controls both the runtime and the application. Is there something that prevents configuring the run-time to have only 1kB memory (stack and heap)?
- sound_and_form 7y agoI'm working on a Wasm interpreter. Yes, Wasm ideally needs a smaller page size for embedded applications. But, the 64kB page size is more of an interoperability specification. If you own the environment and you're already doing bounds checking on memory accesses, you can treat the memory size as virtual and dynamically allocate only what is used.
- deleted 7y ago[deleted]
- chubot 7y agoCool. The whole repo is about 24K lines, and the vmcore_wasm dir is ~8300 lines. ~/git/languages/wasm-micro-runtime$ find . -name '*.[ch]' |xargs wc -l |sort -n ... 472 ./core/iwasm/runtime/vmcore_wasm/wasm-opcode.h 478 ./core/shared-lib/utils/runtime_timer.c 537 ./core/shared-lib/platform/zephyr/bh_thread.c 581 ./core/iwasm/runtime/platform/zephyr/wasm_math.c 590 ./core/shared-lib/mem-alloc/ems/ems_alloc.c 841 ./core/iwasm/lib/native-interface/attr-container.c 893 ./core/iwasm/lib/native/libc/libc_wrapper.c 1220 ./core/iwasm/runtime/vmcore_wasm/wasm-runtime.c 2160 ./core/iwasm/runtime/vmcore_wasm/wasm-interp.c 2874 ./core/iwasm/runtime/vmcore_wasm/wasm-loader.c 24534 total There is also a C++ VM here that’s ~7700 lines. I haven’t tried either one but it would be interesting to see how they compare! https://github.com/WebAssembly/wabt/tree/master/src/interp https://github.com/WebAssembly/wabt/tree/master/src/interp ~/git/languages/wabt/src/interp$ wc -l *.cc *.h 1863 binary-reader-interp.cc 3585 interp.cc 642 interp-disassemble.cc 740 interp-trace.cc 43 binary-reader-interp.h 735 interp.h 94 interp-internal.h 7702 total