![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
arocholl
Joined: 14 Dec 2008 Posts: 21
|
#ORG and Unused code |
Posted: Mon Nov 22, 2010 11:35 am |
|
|
Context: PCD v4.110-4.112
Problem: Unused code gets compiled (and takes ROM space) when it goes within an #ORG section.
Does anybody know a workaround?
If you include a large file with lots of common utility functions, all them will be compiled (think on stdlib.h for instance) regardless you using them or not. This is a killer, apparently only way to resolve is to manually get rid of unused functions one by one, thus you cannot longer share files among projects. Worse: if you forget to get rid of one single unused function it will use ROM forever for no reason.
Demo code:
Code: |
#include <24fj64GA004.h>
//Comment out next two ORG lines and UnusedFunction() wont be compiled, whereas with them UnusedFunction() takes ROM space
#org default
#org 0x2000, 0x4000 default
void UnusedFunction()
{
int nTest=0;
nTest++;
}
void main()
{
int nInd=0;
while(1)
{
nInd++;
}
} |
See result with exact above code (i.e. #ORG in place)
Code: |
6: void UnusedFunction()
7: {
2000 EF2804 clr.w 0x0804
8: int nTest=0;
9: nTest++;
2002 EC2804 inc.w 0x0804
10: }
|
With no #ORG in place, the function gets ignored and wont take any ROM. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9176 Location: Greensville,Ontario
|
|
Posted: Mon Nov 22, 2010 10:14 pm |
|
|
Welcome to the new 'real' world ! If you think this is bad, don't ever look at what's in DLLs on PCs but if you do, you'll see why today's computers need gigabytes of RAM and terrabytes of storage for 'bloatware'.
The good news is you've already discovered the 'trick' to tight code. ONLY compile the functions YOU require for YOUR program.
Generic libraries (like math ones) are generic and NOT necessarily efficient code! Good for overall, general purpose programs cut by regular programmers using chips with a large amount of ROM and RAM.
In the 'good old days' we could get a complete BASIC interpretor with a LOT of functionality in just 4,096 BYTES of ROM.
sigh...I miss the old dayze... |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19375
|
|
Posted: Tue Nov 23, 2010 2:56 am |
|
|
The definition of what 'org' does, says:
"This directive will fix the following function or constant declaration into a specific ROM area. End may be omitted if a segment was previously defined if you only want to add another function to the segment."
The whole 'point' of ORG, is to allow _you_ to take over function placement. If you have taken this over, why be surprised if the compiler does not then remove unused functions....
Now of course, what would be 'nice' would be to have an extra directive for the ORG statement, that told it to still remove functions if unused. However this would not be what is wanted in a lot of situations, where ORG is used to deliberately place functions at a location, so that they can be accessed by other routines that are not 'known' to the compiler. Hence the default behaviour.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
arocholl
Joined: 14 Dec 2008 Posts: 21
|
|
Posted: Tue Nov 23, 2010 7:31 am |
|
|
Ttelmah wrote: | The whole 'point' of ORG, is to allow _you_ to take over function placement. If you have taken this over, why be surprised if the compiler does not then remove unused functions.... |
I partially agree with that. Note "#ORG + range + default" makes the compiler/linker to place any subsequent function or constant definition in that ROM area, so how is that incompatible with unused code removal anyway?. I am of course surprised that means every function in that range will be compiled no matter being used or not. I would agree, perhaps, if you specify ORG for a single function (i.e. with no "default"), but what you are doing with ORG default is to change the equivalent implicit "#ORG 0 default" every program has.
In any case, apparently no one has a workaround to offer so it means we have to live with that. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|