-
I think this should represent a good improvement.
Please let me know how you get on!Wow, looks interesting. Could be useful to force old 16 byte way via some define in board file to compare otherwise same build version on two identical devices with same js code.
So there are more variables but smaller. Can it take more memory in some cases? Like something fitting two 16byte variables before (=32 bytes) that would need three variables now (=39 bytes)? Or even needing two now (=26) that would fit one variable before? That something being e.g array with one or two values, some typical string or byte array length, simple number variable with some typical variable name length ... just guessing, have no idea.
Also slightly related idea, can we have one or two more bits for array size so typed arrays over 64k are possible on 52840 (with 256k of ram)?
Hi,
For year or two now there's been an
experimental_compact_vars
branch. This branch re-organises the contents of the 'JsVar' inside the interpreter to save a few bits that were otherwise not usable. If you have 1000 variables for instance you can use 10 bit addresses, rather than 16 bit - and this saving really adds up.In Bangle.js, JsVars can use only 13 bytes, not 16, which gives you over 20% more variables available.
As far as I know, the only person that's actually used this is @MaBe, but given the issues people seem to be having with Bangle.js memory it seemed worth merging this in now, as I don't actually see any regressions from using it (apart from maybe a minor slowdown).
I have just merged the branch into
master
so you should see new builds appearing in https://www.espruino.com/binaries/travis/master/ that you can try out. Builds for one or two devices are not appearing yet as it seems I need to do some work on reducing code size where it's a big tight, but otherwise I think this should represent a good improvement.Please let me know how you get on!