And yes - the 'compile' option only works for ARM-based micros, and I don't think it works on nRF51(perhaps not even nRF52) because of the way functions are linked in at the moment.
To be honest it uses significantly more memory compiling. I did some tests, and minified JS code is actually significantly more efficient than almost everything else, including Mozilla's bytecode.
As an aside, one interesting option is actually to ban the use of character codes 128 and up in normal (non-string) code (which I don't think is even an issue) and to then use those in a similar way to your JS packer to pre-tokenise reserved words. It could allow Espruino to store code in an amazingly compact way, while increasing execution speed quite a lot.
Of course it'd then blow away comments, formatting, etc - but on some platforms I guess that wouldn't be a problem.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
And yes - the 'compile' option only works for ARM-based micros, and I don't think it works on nRF51(perhaps not even nRF52) because of the way functions are linked in at the moment.
To be honest it uses significantly more memory compiling. I did some tests, and minified JS code is actually significantly more efficient than almost everything else, including Mozilla's bytecode.
As an aside, one interesting option is actually to ban the use of character codes 128 and up in normal (non-string) code (which I don't think is even an issue) and to then use those in a similar way to your JS packer to pre-tokenise reserved words. It could allow Espruino to store code in an amazingly compact way, while increasing execution speed quite a lot.
Of course it'd then blow away comments, formatting, etc - but on some platforms I guess that wouldn't be a problem.