As best I can tell, the problem seems to be the way that SDCC allocates internal/intermediate working variables for functions.

I'm not talking about variables I define in a function, such as "int x". I'm talking about intermediate working variables that are used when it compiles something like "x = a - 25". Sometimes intermediate working variables seem to be needed when there doesn't seem to be any logical reason why they should be necessary.

Memory for the intermediate steps is apparently allocated by the compiler and it seems that that memory must be in the lower 128 bytes of internal RAM. It doesn't use that space dynamically so if one function needs 4 bytes of intermediate variable space, those 4 bytes will never be used by anything else.

The problem arises when you have a sufficient number of functions with a sufficient number of internal intermediate variables that use up all of the available 128 lower bytes of internal RAM. At that point, apparently, SDCC isn't able to use the indirect internal RAM for its working variables so you get a link error about the linker not being able to allocate XX bytes to DSEG.

So far the only work-around I've found is to declare a function as "reentrant". This causes SDCC to use the stack space for the internal working variables of that function rather than fixed addresses in the lower half of internal RAM. Interestingly, the stack is in upper internal RAM so clearly SDCC is capable of using indirect access to access working variables. Why SDCC can't automatically allocate its intermediate variables to high internal RAM is beyond me and I haven't been able to get a solution at the SDCC forum.

If I'm doing something wrong I'd very much like to know it so I can get rid of my cludges. On the other hand, my stack is big enough that having SDCC put intermediate variables on the stack dynamically rather than permanently reserving an internal RAM address probably is a better use of memory.

Regards,
Craig Steiner