Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Understanding memory layout
Hi everyone,

I am seeing some strange memory problems when compiling a reasonably large program, which probably means I don't understand how the compiler organises memory.

Specifically, I have a program that is around 28kb in size, including a 1kb heap. Depending on the origin value I use, the program will either work or crash, but not as you might expect.

Initially, I set the origin of the code to 26000 (that is, "--org 26000") and this worked fine for a time. However, when my program reached a certain length (from memory, around 25kb), I started to see odd behaviour (corrupted strings and Out Of Memory errors). I tried increasing the heap size (to 2kb, 3kb, 4kb, 5kb, 6kb), though this didn't help. I then tried changing the origin to 28000 and then everything was fine again.

A little later on, with some more code added, I started to see problems again, so I again tried increasing the origin address--now to 29000 and again all is fine.

I'm confused because:

  1. the program isn't that big, fitting in between address 29000 and 57,353 (right now), so well clear of user-defined graphics and any Sinclair BASIC workspaces
  2. I would have expected that lowering the origin address would be more likely to help, if there was a lack of memory, rather than increasing it.

I checked the memory map (produced with '--mmap') and, indeed, symbols are defined for addresses between 29,000 and 57,247, so that all looks correct.

Can anyone suggest what is going on here? Thanks in advance,
Interested in this too.

I've made some progress with this by looking at the memory map (produced when you specify --mmap filename as part of the compile command).  By comparing the output from the same compile command with only the heap size changed, I can see that the heap is at the beginning of the program code. E.g., this is the memory map for a 1024-byte heap:

7561: ._CR
7563: ._FU
---and here is the corresponding excerpt of the map for a 2048-byte heap:

7961: ._CR
7963: ._FU

(Note that CR and FU are variables).

So, if the heap grows down from the ZXBASIC_MEM_HEAP address and I don't have a big enough heap, then the program will grow below the origin address (above it is 0x7148) and start to impinge on Sinclair BASIC memory. I've been able to fortuitously work around the issue by moving the origin: the heap can spill over more before I see the problem. I think the issue is that I haven't made the heap big enough, so when my program overflows the heap it starts to impact on Sinclair BASIC stuff like the loader program and system variables.

Surprisingly, though, the --debug-memory option didn't produce an Out of memory error, when the program was running. Perhaps it isn't possible to catch all of the memory-overflow problems.

Hope that makes sense,

Darn. Sadly that's not the whole story. Returning the origin address is 26000 and increasing the heap size does not solve the problem. I should have remembered I tried experimenting with the heap size earlier on. Back to the memory map ...

Forum Jump:

Users browsing this thread: 1 Guest(s)