I'm having some trouble understanding how SDCC allocates memory on MCS51. I am using the large memory model. No variables should be placed on internal memory, except for spilled locations. Everything ok here. The troube is that sometimes I get the error "Could not get xx consecutive bytes in internal RAM for area DSEG". This should indicate that I run out of internal memory (bit surprising since I am using the large memory model, but ok). If I check the memory report I get something like this:
From the SDCC user manual: "By default the 8051 linker will place the stack after the last byte of (i)data variables". So if I understood correctly, in this case SDCC has enough internal memory to allocate those 37 bytes, it just needs to reduce the stack (which is 157 bytes size, so plenty of space). Why is SDCC not doing that? Am I missing something?
Thanks in advance.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The linker needs 37 bytes between 0x63 and 0x7F (the last possible DATA address) and that obviously doesn't fit. The stack is allocated afterwards in the remaining DATA+IDATA space and thus uses the thereby unused space from 0x63 up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the clarification. I have just read somewhere that spilled locations cannot be allocated in IDATA, that is the part I was missing. Just out of curiosity, is it an SDCC restriction or a limitation of the 8051 architecture? How could I reduce the number of spilled locations?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Switch to small memory model? Or maybe medium? Or use stack-auto which places them on stack and thus can use all of IDATA.
Since large model uses XDATA and thus always needs the one and only DPTR to access everything, SDCC likes to spill a lot to improve the code.
The best code is usually generated when only large arrays and structures are placed in xdata explicitly and rest is automatically placed in data by using the small model.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I'm having some trouble understanding how SDCC allocates memory on MCS51. I am using the large memory model. No variables should be placed on internal memory, except for spilled locations. Everything ok here. The troube is that sometimes I get the error "Could not get xx consecutive bytes in internal RAM for area DSEG". This should indicate that I run out of internal memory (bit surprising since I am using the large memory model, but ok). If I check the memory report I get something like this:
From the SDCC user manual: "By default the 8051 linker will place the stack after the last byte of (i)data variables". So if I understood correctly, in this case SDCC has enough internal memory to allocate those 37 bytes, it just needs to reduce the stack (which is 157 bytes size, so plenty of space). Why is SDCC not doing that? Am I missing something?
Thanks in advance.
The linker needs 37 bytes between 0x63 and 0x7F (the last possible DATA address) and that obviously doesn't fit. The stack is allocated afterwards in the remaining DATA+IDATA space and thus uses the thereby unused space from 0x63 up.
Hello Maarten,
Thanks for the clarification. I have just read somewhere that spilled locations cannot be allocated in IDATA, that is the part I was missing. Just out of curiosity, is it an SDCC restriction or a limitation of the 8051 architecture? How could I reduce the number of spilled locations?
Switch to small memory model? Or maybe medium? Or use stack-auto which places them on stack and thus can use all of IDATA.
Since large model uses XDATA and thus always needs the one and only DPTR to access everything, SDCC likes to spill a lot to improve the code.
The best code is usually generated when only large arrays and structures are placed in xdata explicitly and rest is automatically placed in data by using the small model.