[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 ins

From: Bernard Fouché
Subject: Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 instead of GCC 3.4.3
Date: Wed, 27 Apr 2005 16:36:22 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Bingo! I'm back to my usual .data size when I compile with -mno-tablejump.

Should I fill a bug report? Is this a bug anyway? I think so since I do not see why the array is built in ram, it should be in flash since all addresses are constants..

Now the win between gcc3.4.3 and gcc4.0.0 is much more smaller. Here are the application text sizes compiled with gcc-3.4.3 and gcc-4.0.0 (ntj=compilation with -mno-tablejump)

gcc-3.4.3 ntj  |  gcc-3.4.3 | gcc-4.0.0 ntj | gcc-4.0.0
51364          |  50874     | 50588         | 49782(*)

(*) table jump uses 218 bytes of RAM.

Now 49782+218=50000, so the best would be with table jump in flash.

BTW I'm very far from the 8% I mentionned in a previous mail, I also had problems with an included lib (but on gcc3.4.3), now everything is clean and I'm sure of the values. So if ever gcc4.0.0 can make an application 50000 bytes in size, compared to 50874, I would have win about 1% of code size. Which is still a win..


Thanks Dave for your help.

Dave Hylands wrote:

On 4/27/05, Bernard Fouché <address@hidden> wrote:

Good hint Dave: of the 90 objects making the application, I find 2
objects having a big increase in .data . The 2 C files corresponding to
these objects both have a big switch/case and it seems that the compiler
is making some kind of 'jump table' to each 'case', probably to optimize
the speed of processing the switch/case.

Try using the -mno-tablejump option to see if that helps.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]