Moving the string buffers to the start of free memory.

I am interested to move the string buffers to the start of the free memory space. These buffers use EOM to align themselfs to the end of the memory space. Is this as simple as setting EOM to 1536 + size of eval buffer + size of temporary strings? Are there other things to consider when moving these areas and having Heap grow above them?

Assigned to
5 months ago
2 days ago
RFC discussion

~crc_ 5 months ago

The biggest downside to doing this is the loss of flexibility. A few bits that would probably need to be considered:

  • adjust retro.muri to set the inital Heap to the desired starting point for compiled code
  • ensuring enough space reserved for the largest temporary strings you anticipate needing
  • with a long enough string, you could overwrite actual code compiled beyond the strings area
  • you would need to document the environmental limits on TempStringMax and TempStrings
  • this will increase the image size by the size of the string buffers

You could try this with a couple of small patches:

The main reason I have for keeping buffers at EOM is flexibility; it lets me easily increase the size of the string pool as needed for larger applications or decrease it if running Retro on a system with very constrained RAM.

~scott91e1 4 months ago

Thanks for confirming that this change should not have any additional consequences, aside from changing how the memory is used. The memory model I am working on is dict based and assumes 0 values. This lets me have much larger buffers, lower in memory without overhead if they are not used.

I am also moving to a memory based i/o system where 0-4999 represents a 50x100 screen and 5000-9999 is the color/background for the screen area. The VM also supports access controls on memory locations. This will let me mark 10000 as halt-on-access so run away writing to the screen does not override the code area. I am actually thinking of making the screen 49x99 and marking the memory locations as no-access to catch run-away code even earlier.

To make this more efficient retro-embedimage.py is being enhanced with run length encoding so runs of zero bytes can be represented as [10000] to represent the 10000 0 cells at the start of memory. The Retro class can then look at these blocks of zeros and decide how they should be handled, in the case of the assume 0 dict system is simply do nothing.

Using this model there is no real upper limit so will probably set the Heap to 100000 and grow from there. The memory object then cares how many non-zero values have been set, rather than limiting memory to a fixed range. To support this I think muri will be have 2 new operators to allocate n cells of 0 and allocate 0 cells until a specific address is reached.

~crc_ 4 months ago

These sound interesting; I'm looking forward to seeing how your branch evolves.

Have you implemented the RLE in retro-embedimage.py yet? I'm very interested in supporting that in my branch.

~crc_ referenced this from #44 4 months ago

~crc_ REPORTED BY_DESIGN 2 days ago

Register here or Log in to comment, or comment via email.