Microvium closures are tiny!
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 closures can use less RAM than C
Closures are a good way to represent callbacks for non-blocking code. Although C doesn’t support closures, you can achieve something similar using structs on the heap, but you can get even better memory efficiency by using JavaScript running on Microvium.
FFI with no glue code!
Microvium’s snapshotting paradigm allows a library to generate the FFI glue code, so you don’t have to.
Microvium has Classes!
Microvium now has support for classes. Here are some details for the curious.
Inside Microvium Closures
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 has try-catch!
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
Snapshotting is like compiling but better
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.
Microvium is very small
The Microvium JavaScript engine for microcontrollers takes less than 16 kB of ROM and 64 bytes of RAM per VM while idle, making it possibly the smallest JavaScript engine to date with more language features than engines 4x its size
Single-threading is more memory-efficient
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.
Short-lived memory is cheaper
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 …