'Spill loactions' is mentioned one time in the manual:
"3.2.8 Optimization Options
--nogcse Will not do global subexpression elimination, this option may
be used when the compiler creates
undesirably large stack/data spaces to store compiler temporaries (spill
locations, sloc). A warning
message will be generated when this happens and the compiler will
indicate the number of extra bytes
it allocated. It is recommended that this option NOT be used, #pragma
nogcse can be used to turn off
global subexpression elimination for a given function only."
Would it help to use this option, maybe as a test?
Bobby
Mark Swayne wrote:
You probably have a build up of spill locations. Look in the .map file
for your project for any variables with 'sloc' in the name.
You will get spill locations any time you have too many active variables
in a routine. In my experience, the best way to deal with them is to
make simpler subroutines. Strictly scoping all your variables seems to
help make more of the spill locations overlayable, which helps as well.
You can also move some values into globals, which helps a little--but
this way leads to danger from too many globals. If you are working with
pointers a bunch, it helps to specify what type of memory a pointer is
pointing to, instead of using generic pointers. If you are doing a lot
of manipulation of long ints or other 3 or 4 byte types, and you can't
reduce your variable usage, your last hope is to port the routine to
assembly.
Fortunately, there is no need to remove all the spill locations, you
just need to keep the number small enough that your code builds and runs.
--Mark Swayne
Jesse Lackey wrote:
Hi - I'm using the large data model, and as I understand it all globals
are in external RAM. And isn't idata the precious first 256 bytes, why
would I want to put an array there?
I must be missing something.
Since I'm using the large data model, the unsigned 32-bit divide routine
should be using xdata as well, right?
J
Message: 6
Date: Tue, 9 Sep 2008 13:12:51 +0300
From: "Ori Idan" <[EMAIL PROTECTED]>
Subject: Re: [Sdcc-user] Emergency help... linker memory error with
DSEG
To: sdcc-user@lists.sourceforge.net
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset="utf-8"
Try to move some global variables to external RAM if possible.
Or maybe locating few arrays in idata.
-- Ori Idan
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
