[1] https://johnysswlab.com/the-price-of-dynamic-memory-allocati...
If your use case is plugging a keyboard into your MCU or connecting a terminal prompt on the UART, then the MCU needs to be running a parser, yes. But there may be many real-world use cases where your "scripts" will be going through some kind of deployment and release process, and adding a step to compile them to bytecode is easy. But YMMV depending on what you need.
> not using malloc/free is actually a feature, not a bug
Microvium maintains its own managed heap which uses a compacting garabage collector, so that heap allocations there are fast O(1) and have no fragmentation. But it needs to occassionally get chunks of memory from the host/OS to expand its managed heap, which is where it uses malloc.
I agree that there are better and worse ways to use dynamic memory. I have more thoughts here: https://coder-mike.com/blog/2022/05/27/single-threading-is-m...
So I think excluding that use case is a bit odd.
Maybe you could have two configurations - one with a parser and one without. Most microcontrollers are not restricted to 16kB of RAM these days.
You’d be compiling the majority of other options too for embedded, so that’s not really a drawback.
Architecturally speaking, it makes almost no sense to have dynamic memory allocation in Microvium. You could theoretically even do static analysis on whatever chunk of code you're about to run and figure out exactly what your upper bound for memory usage would be. (Remember, we don't have an interactive runtime.)
So now that I actually think about it more, not pre-allocating in this particular case is actually an antipattern.
> In typical firmware, idle memory is much more important than peak memory, as I explained in my last post.
https://coder-mike.com/blog/2022/05/27/single-threading-is-m...