Yes - on normal 512k parts it wouldn't be useful at all, but on the 1MB parts I imagine most people would be interested in using the extra 512k even if that meant they couldn't use the bootloader (and that 512 is memory mapped?).
Usage won't be 100%, but suddenly having ~200kB of program memory available would be hugely exciting to a lot of people I imagine.
With the modules, I'm still not sure it will save you much - I guess it might be possible to do some hack that allowed function code to stay in flash memory, but right now just parsing the module from a string in flash wouldn't make any difference to the final result at all (since the string is thrown away after parsing in Espruino).
As you say, 1400 vars is good though, and will probably mean this isn't that urgent.
Still, I think this could be pretty cool - and is something totally different that none of the other language interpreters for the ESP8266 can manage (as far as I know).
I think GC could possibly be split into two passes - one that worked quickly on just what was in the cache, and one that ran on what was in flash, but only when there was a real problem with memory.
Having had a play with the branch, it seems like there's actually very little thrashing involved in most things - generally code just stays in RAM and you don't see much performance drop-off.
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.
Yes - on normal 512k parts it wouldn't be useful at all, but on the 1MB parts I imagine most people would be interested in using the extra 512k even if that meant they couldn't use the bootloader (and that 512 is memory mapped?).
Usage won't be 100%, but suddenly having ~200kB of program memory available would be hugely exciting to a lot of people I imagine.
With the modules, I'm still not sure it will save you much - I guess it might be possible to do some hack that allowed function code to stay in flash memory, but right now just parsing the module from a string in flash wouldn't make any difference to the final result at all (since the string is thrown away after parsing in Espruino).
As you say, 1400 vars is good though, and will probably mean this isn't that urgent.
Still, I think this could be pretty cool - and is something totally different that none of the other language interpreters for the ESP8266 can manage (as far as I know).
I think GC could possibly be split into two passes - one that worked quickly on just what was in the cache, and one that ran on what was in flash, but only when there was a real problem with memory.
Having had a play with the branch, it seems like there's actually very little thrashing involved in most things - generally code just stays in RAM and you don't see much performance drop-off.