coder-mike
commented
7 months ago Yeah. The size increase you're referring to is due to the inclusion of async-await, which is one of the biggest and most challenging changes I've made to the engine since the beginning and was part of a parallel branch for over a year. I think this kind of big change won't be a common thing.
I haven't formalized the growth strategy, but roughly these are my thoughts:
-
On the main readme, I've said Microvium is "less than 16kB". It's currently about 12kB on the platform I'm using to measure it, so I see that as giving me another 33% or so space for growth. But now that I think about it, I should more explicitly say that users should expect it to grow by about 33% from its current size, since of course their compile size may not be the same as mine, depending on the platform and compiler.
-
I don't intend to keep up with all the latest ECMAScript spec advances. At some point, hopefully soon, I'm going to consider the engine "sufficient" and mostly only include bug fixes or minor tweaks. I believe that engines like mJS have taken this approach, and basically just stop adding new features after a point.
-
If I get time to work on it again, my intention is to introduce a data type I call "virtual" (there is a type code reserved for it) which will be like a Proxy in that its implementation can be defined in user code, but more powerful than a proxy. The intention is that with this type, user-level code can extend Microvium's type system with things like BigInt, Regexp, Proxy, or anything else. This is possibly the last invasive thing I hope to add to Microvium, but it would open the door for opt-in libraries that provide much more functionality. So much of the expansion of Microvium from that point could be in the form of opt-in libraries rather than the core itself. At least that is the dream, but I'm not getting much time these days to work on Microvium.
-
Up until recently, I've basically been treating Microvium as a pre-release version, so I've been pretty aggressive with things like instruction set refactoring, which causes incompatibility between versions. I believe it's transitioned now to a more stable state, where I'm not likely to make changes of that nature, but I may still need to add new op-codes to access new engine capability, which necessarily break compatibility. I don't think Microvium has yet reached a point where I can guarantee that there won't be new instructions. Certainly, things like the "virtual" type will require corresponding engine support. I can't see a way around requiring that users update their runtime engine when they update their compiler, at least for the moment.
Something that might help a little is that I'm hoping to improve the support for compile-time code generation, and in particular the ability for compile-time JavaScript code to emit the microvium.c and microvium.h files which would match the current compiler version. Depending on your project structure, this would automatical update the host firmware project when you build the JavaScript project, which makes migration easier. But it doesn't solve the case where you have existing firmware running in the field and want to use a newer compiler version on the back-end.
What are your thoughts on the matter?
davidchisnall
Upgrading from a version from March to today makes the code size of the microvium library jump from just under 14 KiB to just under 17.5 KiB.
It's not clear to me what the correct model is for long-term deployments. Picking up bug fixes may require moving to a newer version. Even without that, the fact that the new version of the host part can't generate bytecode for an older version means that things like Node.js support lifetimes may require upgrading to be able to still produce working bytecode.
I presume the code won't continue to grow at a rate of 25% every six months, but it would be nice to understand what strategy people should use for devices with a long support life (even if it's 'buy a support contract').