[SDCC] weird memory problem

[ervin]

Hi folks.

I'm wondering if anyone knowledgable with SDCC can help me with a strange problem.
While writing my game for cpcretrodev2017, I ran into a problem I've never seen before.

I've got a lot of arrays set up at the top of my main.c file.
They are followed by the function main().
This is how I've always done SDCC dev.

Now, the weird thing is that I seem to have hit a wall, despite my program only compiling to around 4K.
When I add one more variable, and try to reference that new variable in code, I get weird crashes.

I've tried a lot of different things, and the only thing that fixed it was to either remove one of the arrays, or move an array to my asm.s file, and define it in z80. The compiler then seemed to put the array definition into a different part of memory, thereby fixing the crash I was getting.

It seems that too many variables/arrays defined in C confuses the compiler. It looks very much like the compiler placed data into the code area at compile time, overwriting some code.

Has anyone ever seen anything like this before?

[ervin]

Interesting...

I've got 2 buffers (1024 bytes each) that I use to determine which tiles have changed from frame-to-frame.
I've put them into fixed locations in RAM, and the crashes are gone.
(This is in cpctelera, by the way).

Code Select Expand


__at(0x1000) u8 buffer0[1024];
__at(0x1400) u8 buffer1[1024];


This is perfectly fine (as far as data organisation in the program goes), as those buffers will always be there, so they may as well be fixed in place!

[Docent]

Can you post some example c source and object code that crashes?

[rpalmer]

Are you indexing beyond the arrays?

This will corrupt anything after them which may be code.

[ervin]

Can you post some example c source and object code that crashes?

If I have time I'll try to put together a small example program that behaves the same way.

[ervin]

Are you indexing beyond the arrays?

This will corrupt anything after them which may be code.

I don't think I am, but I'll double check.
I've got tables being referenced by fields in other tables, so... maybe?

[ervin]

Interesting... I *must* have been using an out-of-bounds index, because now I can't reproduce the problem.
Even when I take out the fixed location definitions for buffer0 and buffer1, the program runs correctly.
Nonetheless, it makes sense for them to stay at their fixed locations.