Maarten,
Thank you so much for your help.
>
> The large memory model indeed puts all variables in
> xdata. But this memory is only indirectly addressable
> and always needs both dptr and acc to do that. In order
> to get anything done the compiler needs to copy its
> contents to registers and if it runs out of them to data
> memory. This is called spilling. If your program is
> large and complex enough you can still run out of data
> memory.
How does the compiler determine when this will happen? Is there any
compile-time warning?
And just to be clear, sdcc by default (the "small memory model") creates
space for the function-local variables (i.e. not global or static) in
data memory, and leaves them there. This means that functions are never
reenterant. This is different from the more traditional GCC way of
having all function-local non-static variables allocated on the stack.
Is this correct?
> I recommend to switch to a smaller memory model and move
> large variables to xdata by hand.
I've tried that, and as far as I can see, inside of each function (which
should have a pretty small call depth while running) there are only
~20-30 bytes worth of variables, max.
> An alternative might
> be to switch to stack-auto which tries to put all local
> variables on the stack. But check that you do not
> overflow your stack, because the compiler can not do
> that.
Everything builds (yay!) when I use stack-auto. My code even runs. But
when I then try and create a large global buffer (say, to store a single
sector) things build just fine, but the program itself doesn't run.
When I look at my .map I see:
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
DSEG 0000 006F = 111. bytes (REL,CON)
Value Global
-------- --------------------------------
0008 _bp
Hexadecimal
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
SSEG 0021 00DF = 223. bytes (REL,OVR)
Value Global
-------- --------------------------------
0021 __start__stack
Hexadecimal
Area Addr Size Decimal Bytes (Attributes)
-------------------------------- ---- ---- ------- ----- ------------
XSEG 0100 022B = 555. bytes (REL,CON,XDATA)
Value Global
-------- --------------------------------
0D:0100 _buffer
0D:0305 __gptrput_PARM_2
0D:0306 __mulint_PARM_2
0D:0308 _memcmp_PARM_2
0D:030B _memcmp_PARM_3
0D:0310 __divulong_PARM_2
0D:031C _memset_PARM_2
0D:031D _memset_PARM_3
0D:031F _memcpy_PARM_2
0D:0322 _memcpy_PARM_3
0D:0327 __mullong_PARM_2
How can my dseg and my sseg add up to more than 256 bytes?
Thanks again for the help,
...Eric
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Sdcc-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sdcc-user
