You are reading a single comment by @tve 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.
@tve
[I'm assuming this is an esp8266 focused discussion]
From a performance point of view, you have to decide whether by "flash" you mean memory-mapped flash, i.e. 1MB, or all flash, i.e. up to 4MB. I have not made any performance benchmarks. I believe that the routine that reads from any flash has to jump through a bunch of hoops to disable the cache and such in order to gain control of the SPI interface. Getting a good grasp on that might be one place to start looking.
Some numbers: the current build uses 445780 of 483328 bytes of flash reserved for the firmware (472KB). (See flash map in the esp8266 reference page). The remainder of the first 512KB on a 512KB system has the bootloader (4KB) , the SDK save area (16KB), the Espruino save area (16KB) and the EEPROM emulation area (4KB). If you want to put JSvars into flash on such a system you have to take away from one of these.
On a 4MB flash system, the first 1MB has a total of 56KB of unused flash in 2 blocks. If you eliminate the ability to flash an update over the air then you have a bit over 512KB of free flash.
If you're willing to use rboot (open source bootloader), I believe you can change the cache mapping so you could have an upgrade partition and ~512KB of free flash.
The loading of a block is trivial, either using memory mapped flash accesses or the read-flash function. I think writing is more fun. If the bytes you're writing are erased there's a straight-forward function. The fun part is the garbage collection, you probably want to always have at least one block you can allocate into and ensure that by compacting blocks at idle time?
How would GC work with all this? Would you modify the GC so it could access flash directly, or would it basically wipe out the cache?
Personally, I believe that with 1400-1500 JSvars things are going to be OK and the next step I would go is to be able to preload modules where the code is stored in flash using native strings.