I'm not sure if here is good place or github issue is better place. I've noticed there is beginning of JIT feature merged in this commit
There is also old closed issue here https://github.com/espruino/Espruino/issues/73 describing some pluses/minuses.
There is also the inline C and JS compiler https://github.com/gfwilliams/EspruinoCompiler described here https://www.espruino.com/InlineC and https://www.espruino.com/Compilation
When I saw the JIT is a Kickstarter goal I was curious how this could fit together.
Looks like current implementation starts from scratch with doing the JIT directly on the device.
I just wonder is it really needed to have this on the device? What is target device regarding available flash/ram/cpu speed for this? I'd guess even bangle 2 could be too slow and small for this to be an improvement - I fear the compiler would always be too simple and possibly slow.
Couldn't the inline server based compiler be improved so that it would run as part of some minification phase? If we are talking only Bangle apps stored in repo maybe this could be done on the server somehow automatically so the loader would load already compiled bits to the device?
I know it is not exactly JIT in the traditional sense but maybe it could offer very similar JIT like flexibility without bloating the device firmware and burning CPU time?
I think there are a few big drawbacks with server-based stuff:
As you've noticed I've been trying multiple options, but so far none of them have been that great, and it's always felt like a bit of a hack. I've got a company using the Espruino firmware in some custom watches of theirs, and they're actually avoiding the JIT even though maybe they could do it because it's just an extra layer of difficulty. However the JIT compiler in the firmware seems promising to me... So far it only uses 4kB Flash and even now there's a 2x speed improvement.
Normally Espruino is pretty slow, but there's no one big time hog. I guess roughly (this is just a guess) time is spent:
Even if we use GCC and some optimisation, we're still going to have the Variable Lookups and MathsOp in a lot of cases, so it may not actually be that fast.
By contrast, if we use JIT on the device, we can actually get the address of built-in functions and can call them direct, so in many cases we can skip the expensive variable lookups. The JS compiler on the server does this in one or two small cases where the JS function is be exposed (eg digitalWrite) but it doesn't do it for many at all.
The reality is that most of the code is just stringing together calls to built-in functions (jsvUnLock,jsvMathsOp,jspGetVariable...,etc) so actually simple JIT on the device can do that pretty well. Obviously if we're at the point where we're really compiling the JS into C that's dealing with ints and doubles directly then GCC will be a lot faster, but I don't think in a lot of cases we're really going to be doing that.
Thanks for answer, looks like it might be still worth it then even if being simple. The variable/function address lookup and possibly other stuff known only at runtime cannot be done on server indeed.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem