You are reading a single comment by @Gordon and its replies.
Click here to read the full conversation.
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.
@Gordon
@Wilberforce the idea is to avoid any pre-computation of what is constant and what isn't - it would 'just happen'.
@tve great - thanks for taking a look at it!
What you're suggesting sounds like what I had in mind - so you leave each JSVar's address in flash as 0xFFFF, and then overwrite it with the address of the new var if the var gets replaced?
For testing, what I had in mind was to make the Linux versions of jshFlashRead/Write/Erase/etc work on a file (or even just RAM) and behave like proper flash memory would. You can then develop + debug it on linux with a proper debugger :)
The free list is tricky - for simple stuff it could definitely just pick something from the variables in the cache, and then maybe just do a linear search for a free variable if it missed the cache (keeping unused entries at 0xFF) - but as you say, for starters it's best to leave what's there and see how it performs. As you say it probably wont be that bad because the free list will tend to use stuff that was in the cache anyway.
For GC - I guess the bit set/reset code could just call a function, and in the variable cache case that function could do something different. I think it might even be able to store the GC bit in flash, because basically the bit is just reset (flash erase) and then set when the var is referenced (but never cleared again). You could then use a huge amount of flash.
But RAM would be faster (and much easier for now :). The page erase is going to be slow - on most ARM you can do it non-blocking I think (but it's sometimes not exposed via the API). I think it's probably something that (at least for now) people will have to deal with. Another option is to do the erase on idle when the interpreter knows it's got some free time before the next setInterval - it's not perfect but it'd help in a lot of cases.
When I did some tests, I found that even with relatively few variables in RAM (256?) there was virtually no cache eviction during normal execution, so I think the interpreter will stop pretty rarely.