Obscure behaviour of GCC 4.1.2 (WinAVR-20070525)

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm compiling a project with avr-gcc 3.4.6 and tried it with 4.1.2 of the newest WinAVR. The project consists of a bootoloader + extension and the application. The following codesizes are the results of identical sources:

Bootloader
3.4.6: 1262 (dec)
4.1.2: 1514 (Change of short jumps into normal jumps necessary)

Trying to compare both lss-files with a diff does not lead to any result, because the file format has changed. Did anyone have identical findings? (and a solution?)

Additionally there seems to be a major change in handling of user named segments. If you had (3.4.6) a user named program code-segment distributed to several object files all of them were covered by name of the __attribute__. Now they exist with extensions.

Example:
foo.c 
void foo (void) __attribute__ ((section (".mysec")));
void foo (void) {...}

bar.c 
void bar (void) __attribute__ ((section (".mysec")));
void bar (void) {...}

In the 3.4.6-map file only the section name .mysec appears. In 4.1.2 there are ".mysec" and ".mysec.1" based on the sequence of appearing of both object-files in the linker command. I don't understand if this is only cosmetic or serious.

What astonishes me is the start address of the .mysec-segment is not used in the map-file. I use a ",--section-start=.mysec=0x4711" in 3.4.6 an saw that address in the map-file. In 4.1.2 the linker takes the command without comment and finds an overlap of the .data-segment with one of the named (e.g. ".myseg.1") segments which does not lead to an elf-file.

Any suggestions are welcome.

Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is difficult to compare the compilation results of the two different compilers because there is a major version change between them. Yes, there are some programs that will increase in size. We (the AVR toolchain developers) would like to continue to improve the tools. If you can reduce your code to simple test cases, showing where optimization has become worse, we would appreciate it if you could fill out bug reports with the GCC project. (Let me know what the bug numbers are so I can track them). This will help to (eventually) improve the compiler, though it may take some time.

As to the linker issue, with enumerated sections, I agree that this is really annoying. The only solution that I am aware of is to start off with the default linker script and customize it by combining those sections to a single output section that is then relocated to the address of your choice.

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kschwiRG wrote:
Did anyone have identical findings?

My application compiles to slightly smaller code using the new release across several AVR models. The reduction is about 1%.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Eric,

EW wrote:
It is difficult to compare the compilation results of the two different compilers because there is a major version change between them. Yes, there are some programs that will increase in size. We (the AVR toolchain developers) would like to continue to improve the tools.

Fully agreed.

I tried to figure out an example. This is the initalisation code of an rc4 encryption. Comparing the lss files show a serious increase in the use of uint8_t variables! It looks as if they were handled as uint16!

typedef struct rc4_state
{
 uint8_t x, y;
 uint8_t m[256];
} trc4_state;                                                                           


void rc4_init(uint8_t *key,  uint8_t length, trc4_state *s)
{
 uint8_t i, j, k, a;
 uint8_t * m;
 s->x = 0;
 s->y = 0;
 m = s->m;
 i=0;
 do {        
    *m = i;   
     m++;      
     i++;      
 } while (i);
 j = k = 0; 
 m = s->m;
 i=0;       
 do {        
   a = m[i];
   j = (uint8_t) ( j + a + key[k] );
   m[i] = m[j]; m[j] = a;
   if (++k >= length)
      {
      k = 0;
      }
   i++;   
  }while (i);    
}

As far as I've seen around the "while()" are the biggest differencies. More registers are pushed onto the stack...

The size difference for this routine is 78 Bytes 3.4.6 to 106 Bytes 4.1.2 which is an increase by 36%!

HTH

Knut