Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Petr Hnizdil <petr.hnizdil@se...> - 2003-10-22 13:13:54
im trying port big project in AT89C51ED2. I'm using sdcc from Apr 28
2003 and my own header file for AT89C51ED2 (I created it from keil
header file from vendor).
I'm using complicated data structures, malloc, and pointers on functions.
After compilation I get
sdcc --model-large -V --code-loc 0x00 --idata-loc 0x80 main.rel uart.rel
device.rel serial.rel linklay.rel netlay.rel timer.rel
+ "aslink" -nf "main"
?ASlink-Error-Insufficient DRAM memory. 200 bytes short.
?ASlink-Error-Stack overlaps area 'DATA'
make: *** [main.ihx] Error 1
Compilator creates about 100 of sloc variables in DSEG which then
Exist some compilator option which move this variables into XDATA?
Or exist any other technique solve this problem?
In archive on
http://www.geocrawler.com/archives/3/3278/2000/5/0/3815036/ i find
information that problem is going to be solved. What situation is now?
From: Erik Petrich <epetrich@iv...> - 2003-10-30 14:37:24
On Wed, 22 Oct 2003, Petr Hnizdil wrote:
> im trying port big project in AT89C51ED2. I'm using sdcc from Apr 28
> 2003 and my own header file for AT89C51ED2 (I created it from keil
> header file from vendor).
> Compilator creates about 100 of sloc variables in DSEG which then
> overflows DATA.
> Exist some compilator option which move this variables into XDATA?
> Or exist any other technique solve this problem?
> In archive on
> http://www.geocrawler.com/archives/3/3278/2000/5/0/3815036/ i find
> information that problem is going to be solved. What situation is now?
As far as I know (there is still a lot of SDCC source code I haven't
looked at yet), the mcs51 port does not have an option to move slocs into
XDATA. This would also be rather hard to implement since it is for a basic
8051 architecture with a single DPTR; the code generator really only
supports one operand to be in XDATA per operation.
I looked at the archived message and suspect that, if actually
implemented, it would be in the ds390 port. It's architecture is much more
In my projects, I deal with sloc overflow by:
1. Using the reentrant keyword in the function declaration to keep the
slocs on the stack. This also puts local variables on the stack; if there
are many of them I given them an xdata storage class.
2. Disable optimizations that increase storage requirements, such as gcse,
induction, and loop invariance. These optimizations usually increase code
speed and decrease code size; however, if the compiler runs out of
registers and has to use slocs they can become counterproductive. Rather
than globally disable these optimizations on the command line, I use the
#pragma directives to turn them on or off on a function by function basis.
Hope this helps,