4 ms·

Calling Microvium an "engine" without a runtime parser is a bit inaccurate imo. The entire purpose of Javascript is that it's a "scripting" language, so having

by dvt 4y ago

Calling Microvium an "engine" without a runtime parser is a bit inaccurate imo. The entire purpose of Javascript is that it's a "scripting" language, so having an interactive runtime is kind of the point. And as @dmitrygr already pointed out, not using malloc/free is actually a feature, not a bug[1]. [1] https://johnysswlab.com/the-price-of-dynamic-memory-allocation/ https://johnysswlab.com/the-price-of-dynamic-memory-allocati...

ricardobeat 4y ago
The main concern seems to be memory usage. Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory. You’d be compiling the majority of other options too for embedded, so that’s not really a drawback.
- dvt 4y ago
  > Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory. 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.
  - ricardobeat 4y ago
    The author has a different perspective on that. From the article: > 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-more-memory-efficient/ https://coder-mike.com/blog/2022/05/27/single-threading-is-m...
  - codermike 4y ago
    The static analysis in Microvium does do this for the stack variables, but the heap is not bounded. It's trivial to write a for-loop or something that creates N new objects.
codermike 4y ago
> The entire purpose of Javascript is that it's a "scripting" language, so having an interactive runtime is kind of the point. 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-more-memory-efficient/ https://coder-mike.com/blog/2022/05/27/single-threading-is-m...
- IshKebab 4y ago
  A UART REPL is always the use case that advocates of Python and JS on microcontrollers bring up as one of the main reasons to use it. I haven't tried it myself but it does sound compelling. 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.

by dvt 4y ago

ricardobeat 4y ago

The main concern seems to be memory usage. Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory. You’d be compiling the majority of other options too for embedded, so that’s not really a drawback.

dvt 4y ago
> Dynamic allocation reduces the memory footprint, the author compares it to the best alternative which requires pre-allocation of a large chunk of memory. 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.
- ricardobeat 4y ago
  The author has a different perspective on that. From the article: > 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-more-memory-efficient/ https://coder-mike.com/blog/2022/05/27/single-threading-is-m...
- codermike 4y ago
  The static analysis in Microvium does do this for the stack variables, but the heap is not bounded. It's trivial to write a for-loop or something that creates N new objects.

codermike 4y ago

> The entire purpose of Javascript is that it's a "scripting" language, so having an interactive runtime is kind of the point. 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-more-memory-efficient/ https://coder-mike.com/blog/2022/05/27/single-threading-is-m...

IshKebab 4y ago
A UART REPL is always the use case that advocates of Python and JS on microcontrollers bring up as one of the main reasons to use it. I haven't tried it myself but it does sound compelling. 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.