Microvium closures are now as small as 6 bytes on the heap, down from 12 bytes previously and compared to over 100 B in some other engines.
Microvium’s snapshotting paradigm allows a library to generate the FFI glue code, so you don’t have to.
Microvium now has support for classes. Here are some details for the curious.
Support for closures in Microvium sets it apart from other JS engines of a similar size. Closures simplify state machines and enable functional-style code. Closures in snapshots are a new way of sharing compile-time state with the runtime program. This post goes through some examples and design details.
Microvium now has exception handling, with just 4 bytes of overhead per active try block. This post covers some of the details of the design, for those who are interested
The final output of a traditional compiler like GCC bears a family resemblance to a Microvium snapshot, but the snapshotting paradigm is both easier to use and more powerful because it allows real application code to run at build time and its state to persist until runtime.
Single-threading with super-loops or job queues may make more efficient use of a microcontroller’s memory over time, and Microvium’s closures make single-threading easier with callback-style async code.
TL;DR: RAM on a microcontroller should not just be thought of as space but as space-time: a task that occupies the same memory but for a longer time is more expensive. MCU memory is expensive If you’re reading this, I probably don’t need to tell you: RAM on a microcontroller is typically very constrained. A …