OUT OF FROM question

[benoitstjean]

Compiler: 5.116
Device: PIC24EP512GP806

Hi guys,

I know this is a recurring question but I just want clarifications because I never really delved down into this.

So I get the infamous "Out of ROM" error like this:

*** Error 71 "C:\MainFile.c" Line 234(1,2): Out of ROM, A segment or the program is too large SYSTEM_ProcessModemFramedMessage

Seg 30000-3FFFE, 32CA left, need 0DB40
Seg 40000-4FFFE, 4A0E left, need 0DB40
Seg 50000-557FE, 5800 left, need 0DB40
Seg 00000-00002, 0000 left, need 0DB40 Reserved
Seg 00004-001FE, 0000 left, need 0DB40 Reserved
Seg 00200-0FFFE, 0004 left, need 0DB40
Seg 10000-1FFFE, 0000 left, need 0DB40
Seg 20000-2FFFE, 000E left, need 0DB40

In 5.026, this compile just fine with the exception that I am at 93% ROM usage.

Now with 5.116, I get the error. I do have a LOT of fprintf statements to print on a console with all with different messages and variables. I also have message queues to process realtime UART data. I also have an SD card stack that uses a crap-load of space.

But I do have one huge function where I added #separate back years ago under 5.026 and that solved my problem because there too I was getting the error. But now with the new compiler I'm getting it again. It'll be difficult to break this function in smaller functions but I could attempt it.

I tried adding the #separate to another big function but doesn't seem to help.

So.... DB40 is 56,128 bytes. What does it mean when I see all those Seg xxxxx-yyyyy, zzzz left, need 0DB40?

Does it mean that it attempted to store my problematic function in one of those ROM segments and it's telling me it needs 56,128 bytes but there's only, let's say, 32CA (13,002) left in 30000-3FFFE, then it tried the next bank and there's only 4A0E (18,958) left in 40000-4FFFE and so on but that function requires 56,128 bytes therefore does not fit anywhere?

Thanks,

Ben

[temtronic]

my gut says yes....
take that BIG function and recode into 2-3- 4 smaller 'pieces'.

hmm..might have to make the variable 'global' though....
other who code every day will KNOW.....

[Ttelmah]

You have pretty much summarized what it means.
The key point is you have a single large entity that won't fit anywhere.

First thing to try is

#OPT COMPRESS

There was a major change in the optimisation at about version 5.09x.
The compiler from this point switched to optimising for speed, rather than size.
COMPRESS switches it to optimise for size instead. It now tends to put much
more stuff 'inline', which reduces stack usage, and improves speed, but
leads to problems like you are seeing.
Also try with

#OPT 0

This will probably give results closer to the old compiler.

[benoitstjean]

Hi,

Do I put both #OPT COMPRESS and #OPT 0? My wild guess is 'no' but I've never used this.

I tried with '0' then 'COMPRESS' and it doesn't change anything.

Not sure where to put it but it's at the top of my main header file. It's not complaining at compile time therefore I assume that's where it goes.

So my next question is is there a way to know what code is compiled in which bank? So like if 40000-4FFFE is the one with the most memory available but not enough for my code, is there a way to know what code is stored in that block of memory?

Benoit

[temtronic]

if you dump the listing, it'll show 'memory location...code that's there'
BTW the listing is NOT in sequential order !
In the early dayze, I'd copy th elisting then use the MSDOS program 'sort' to put it in address order....


sigh, I miss the good old dayze...

still impressed you've got ONE function larger than any entire program I've ever coded.....

[Ttelmah]

Looking at it, if you add up the available spaces, it would almost fit
Suggests that with some splitting and care it may be possible to get
it in..
However first comment is there ought to be a lot of space you can save
with a bit of care.
As Jay has said, the listing from the version that compiles is the first place
to look. Honestly almost any code unless it has been very carefully optimised,
will be able to be reduced by at least 25% by applying a bit of thought to
saving space. Look at disabling automatic inlining where possible. Use
separate subroutines, and explicitly declare them as separate. Particularly
things like printouts. Then look at the order variables are declared.
Grouping everything used in a function together increases the probability
it'll all be in the same bank. Using smaller types reduces the code to access
them, as well as the RAM usage.

[benoitstjean]

Ok, fair enough. FOR SURE I need to do code optimization but it's not my strength! I'll see though if I can cut-down that big function.

Alrighty thanks for your help!

Ben