It is more a memory manager with garbage collect for storing/retrieving/updating strings... it could certainly be tuned to the needs of a page oriented thing. I was thinking of it when reading @tve's post. The issue though is that the way it is built, a flash would wear out quickly. It has a pointer system for free space and freed space management that is updated on most of the writes... too much of updates for a flash. I had started it for MRAM/FRAM where no page limitations are and no real wear out. For a flash, it gets a bit more complicated, because the free space would have to be managed with bit lists (ribs - 1 bit per n bytes block)... reference to mm.html in conversation about New EEPROM module names/AT EEPROMS with an emulation / cross-implementation for developing the logic... some more explanation and rational in the conversation about Running code off of an EEPROM - includes screen shots of usage example and explananation what's goin on in the memory (all in the cross-context / browser), where visualization is easy to show what is going on.
To apply the memory manager for flash would require:
convert pointer/chained blocks system to bitlist for free space
take page constraints into account (only update 'in one direction' (go for a new page or rease it before rewrite...)
Not that simple... may become slow, and is still not holding up for frequent use.
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.
It is more a memory manager with garbage collect for storing/retrieving/updating strings... it could certainly be tuned to the needs of a page oriented thing. I was thinking of it when reading @tve's post. The issue though is that the way it is built, a flash would wear out quickly. It has a pointer system for free space and freed space management that is updated on most of the writes... too much of updates for a flash. I had started it for MRAM/FRAM where no page limitations are and no real wear out. For a flash, it gets a bit more complicated, because the free space would have to be managed with bit lists (ribs - 1 bit per n bytes block)... reference to mm.html in conversation about New EEPROM module names/AT EEPROMS with an emulation / cross-implementation for developing the logic... some more explanation and rational in the conversation about Running code off of an EEPROM - includes screen shots of usage example and explananation what's goin on in the memory (all in the cross-context / browser), where visualization is easy to show what is going on.
To apply the memory manager for flash would require:
Not that simple... may become slow, and is still not holding up for frequent use.