lcc: malloc, 64K support and memory control

[kervinck]

At some point we like to add 64K support, and before that already malloc/free.

This leads to options on how to use the upper 32K. The most significant change is that data can become larger than 256 bytes, and this is a very desirable feature. But then segments start to work different for code and data: data can seamlessly cross page boundaries and code needs special treatment. Segmentation at page boundaries must still happen for the .gt1 file format. Under 32K, we could just ignore these differences between code and data.

Also the programmer will want to control the use of memory locations. Specifically those shared with screen memory.

Another idea is to have the heap already available at link time, and let the linker get its memory from there. At the end of the link process, the remainder of this heap can be placed in the GT1 file as static initialisation for the runtime malloc heap.

Many ideas...

[kervinck]

Low priority

[jurkstas]

Is this what is necessary to store larger lookup tables as global constants?

[kervinck]

Indeed, it needs a new way to deal with segmentation.

[lb3361]

Suggesting to close this issue since glcc does this already.