I see the new native strings coming up in 1v85 with great interest. On the esp8266 I see the following two options coming up:
increase JSvars from 1023 to ~1280, using 8KB more heap, reducing heap to ~5-8KB, which is going to cause problems on systems that have several network connections or that are receiving "large" amounts of data (large being >3-4KB). The gain would be ~256 more JSvars plus flat strings using fewer JSvars, so it's a bit more than a 25% increase in effective JSvars.
add a feature to write code into the upcoming native strings, which would be malloc'd. This could perhaps be used in specific cases, such as when requiring a module, i.e., only module code might be put there. Also, the network code could be tweaked to put network buffers into native strings. This doesn't increase the total number of JSvars, but it should free up a lot of them. The fact that it uses malloc means that it shares the memory available to the networking stack, so more code means fewer concurrent connections, less code means more connections.
Thoughts?
NB: using native strings to access flash is more difficult, I believe, because flash requires 32-bit accesses and there's the issue of managing the writes and erasures of 4KB blocks.
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.
I see the new native strings coming up in 1v85 with great interest. On the esp8266 I see the following two options coming up:
increase JSvars from 1023 to ~1280, using 8KB more heap, reducing heap to ~5-8KB, which is going to cause problems on systems that have several network connections or that are receiving "large" amounts of data (large being >3-4KB). The gain would be ~256 more JSvars plus flat strings using fewer JSvars, so it's a bit more than a 25% increase in effective JSvars.
add a feature to write code into the upcoming native strings, which would be malloc'd. This could perhaps be used in specific cases, such as when requiring a module, i.e., only module code might be put there. Also, the network code could be tweaked to put network buffers into native strings. This doesn't increase the total number of JSvars, but it should free up a lot of them. The fact that it uses malloc means that it shares the memory available to the networking stack, so more code means fewer concurrent connections, less code means more connections.
Thoughts?
NB: using native strings to access flash is more difficult, I believe, because flash requires 32-bit accesses and there's the issue of managing the writes and erasures of 4KB blocks.