How do you control the top of the heap?

ZX80, ZX 81, ZX Spectrum, TS2068 and other clones
Post Reply
thricenightly
Member
Posts: 28
Joined: Thu Jun 01, 2017 5:46 pm

How do you control the top of the heap?

Post by thricenightly »

Further to pull request #626, there's a comment there which says "...if the heap is used, you have to tell it what the last byte in memory is or it will continue to assume it can use up to the bottom of the stack...". I was aware of that issue and specifically looked for a way of controlling where the heap stops, but the only thing I could find was the heap size, which is of limited use because you'd have to know the size of the compiled code and data.

So, OK, I'll bite. :) What's the way of controlling where the heap goes up to?
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

The pragma "CLIB_MALLOC_HEAP_SIZE " can do it:

https://www.z88dk.org/wiki/doku.php?id= ... figuration
The size of malloc's heap. < -1 has the crt place the heap between the end of the bss section and the absolute value taken as address, -1 has the crt automatically place the heap between the end of the bss section and the bottom of the stack. 0 means no heap will be created. More than 14 creates a heap of the indicated size in the bss section. If < 0 and the crt computes a negative heap size, the program will immediately exit.
So if you want the last byte of the heap to be some address x, you would set "CLIB_MALLOC_HEAP_SIZE = -x"
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

There's another popular location for the isr btw (but maybe less suitable for basic) and that's underneath the program at 0x8000. Then the im2 table occupies 0x8000-0x8100 and the jp to the usr is at address 0x8181. This works if the program org is moved to 0x8184.

You have to be careful where I is due to hw bugs in the spectrum. If I points into contended ram then you see snow. If I points to contended ram in 128k machines except the +3 and you execute code in contended ram, the computer can crash. Putting I in the 0xc000 16k block also means it's in the space the bankswitching occurs too. People often run into the 128ks crashing because they often have I pointing into the 0xc000+ area, field and interrupt and jump to and isr < 0xc000. Then the isr pages in contended ram containing music in 0xc000+ and code there executes. Now you have I pointing into contended ram (the top 16k) and contended code is executing and just like that the computer crashes.
Post Reply