On 2007-03-28, Grant Edwards <[email protected]> wrote:
> On 2007-03-28, Grant Edwards <[email protected]> wrote:
>
>> 2) Currently, variables are placed in RAM in the order they
>> happen to occur in the source file. This means that there
>> can be a significan number of wasted bytes do to alignment
>> requirements. When you've only got 256 bytes of RAM, you
>> can't really afford to waste any of them. ;)
>>
>> I seem to recall that there's something you can do in the
>> linker script to fix that: you can tell the linker to sort
>> objects by size in order to minimize padding wastage. But I
>> can't quite remember now to do that. I'll try to find a
>> example of that tomorrow...
>
> It would appear that --sort-common should solve this problem,
> but it appears to do nothing (either with or without
> -fdatasections). Does it work for anybody else?
After further testing, it's apparent that it will "do nothing"
only after my changes. Without my changes, it generates
warnings like this:
main.c:158: warning: internal error: unsupported relocation error
main.c:199: warning: internal error: unsupported relocation error
I was afraid that I had broken the --sort-common option with my
changes, but apparently "do nothing" is an improvement. ;)
With my current changes, uninitialized variables are compiled
into the .bss section instead of the .comm section. I had
thought that perhaps if they were in the .comm section, then
the --sort-common linker option might do something useful. But,
it doesn't. So I'm planning on leaving them in .bss.
Does anybody know of any reason why uninitialized variables
shouldn't be compiled into .bss instead of .comm?
--
Grant Edwards grante Yow! What's the MATTER
at Sid?... Is your BEVERAGE
visi.com unsatisfactory?
