avr-gcc-list
[Top][All Lists]
Advanced

[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: Thu, 28 Apr 2005 10:33:49 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

E. Weddington wrote:

Dave Hylands wrote:

It's really an issue of whether the tables are stored in flash or in
RAM. Actually, because they're in RAM, they take up space twice, once
in flash (used to initialize the RAM) and once in RAM, where they're
actually used.

Sure. I don't know for sure, though, but I would guess that that section of the port hasn't really changed, so in essence it's not a bug. It's a mis-feature, so technically it would be an enhancement request. Somebody who is more familiar with the AVR port (see new additions to CC list) can perhaps comment.

Eric

There are also table jumps in gcc-3.4.3, and we don't see RAM used for the table itself. Here is my switch/case compiled with gcc-3.4.3:

160:../gsm8.c     ****   switch(etape_telit){
456                     .LM29:
457 02f2 8091 0000         lds r24,etape_telit
458 02f6 9927              clr r25
459 02f8 AA27              clr r26
460 02fa BB27              clr r27
461 02fc FC01              movw r30,r24
462 02fe 4A97              sbiw r24,26
463 0300 08F0              brlo .+2
464 0302 3EC3              rjmp .L1
465 0304 E050              subi r30,lo8(-(pm(.L65)))
466 0306 F040              sbci r31,hi8(-(pm(.L65)))
467 0308 EE0F              lsl r30
468 030a FF1F              rol r31
469 030c 0590              lpm __tmp_reg__,Z+
470 030e F491              lpm r31,Z
471 0310 E02D              mov r30,__tmp_reg__
472 0312 0994              ijmp
473                           .data
474 .section .progmem.gcc_sw_table, "a", @progbits
475                           .p2align 1
476                     .L65:
477 0000 0000              .word pm(.L13)
478 0002 0000              .word pm(.L15)
479 0004 0000              .word pm(.L16)
480 0006 0000              .word pm(.L17)
481 0008 0000              .word pm(.L20)
482 000a 0000              .word pm(.L22)
483 000c 0000              .word pm(.L23)
484 000e 0000              .word pm(.L26)
485 0010 0000              .word pm(.L28)
486 0012 0000              .word pm(.L31)
487 0014 0000              .word pm(.L34)
488 0016 0000              .word pm(.L37)
489 0018 0000              .word pm(.L40)
490 001a 0000              .word pm(.L43)
491 001c 0000              .word pm(.L44)
492 001e 0000              .word pm(.L46)
493 0020 0000              .word pm(.L49)
494 0022 0000              .word pm(.L51)
495 0024 0000              .word pm(.L47)
496 0026 0000              .word pm(.L53)
497 0028 0000              .word pm(.L54)
498 002a 0000              .word pm(.L55)
499 002c 0000              .word pm(.L56)
500 002e 0000              .word pm(.L57)
501 0030 0000              .word pm(.L60)
502 0032 0000              .word pm(.L63)
503                           .text
504                     .L13:
161:../gsm8.c **** 162:../gsm8.c **** case GSM_STEP_NOTHING_TO_DO:


Here it is with gcc-4:

160:../gsm8.c     ****   switch(etape_telit){
428                     .LM27:
429 02bc 8091 0000         lds r24,etape_telit
430 02c0 E82F              mov r30,r24
431 02c2 FF27              clr r31
432 02c4 EA31              cpi r30,26
433 02c6 F105              cpc r31,__zero_reg__
434 02c8 08F0              brlo .+2
435 02ca 3AC3              rjmp .L95
436 02cc E050              subi r30,lo8(-(pm(.L60)))
437 02ce F040              sbci r31,hi8(-(pm(.L60)))
438 02d0 EE0F              lsl r30
439 02d2 FF1F              rol r31
440 02d4 0590              lpm __tmp_reg__,Z+
441 02d6 F491              lpm r31,Z
442 02d8 E02D              mov r30,__tmp_reg__
443 02da 0994              ijmp
444                           .data
445 .section .progmem.gcc_sw_table, "a", @progbits
446                           .p2align 1
447                     .L60:
448                           .data
449 0019 0000              .word pm(.L34)
450 001b 0000              .word pm(.L35)
451 001d 0000              .word pm(.L36)
452 001f 0000              .word pm(.L37)
453 0021 0000              .word pm(.L38)
454 0023 0000              .word pm(.L39)
455 0025 0000              .word pm(.L40)
456 0027 0000              .word pm(.L41)
457 0029 0000              .word pm(.L42)
458 002b 0000              .word pm(.L43)
459 002d 0000              .word pm(.L44)
460 002f 0000              .word pm(.L45)
461 0031 0000              .word pm(.L46)
462 0033 0000              .word pm(.L47)
463 0035 0000              .word pm(.L48)
464 0037 0000              .word pm(.L49)
465 0039 0000              .word pm(.L50)
466 003b 0000              .word pm(.L51)
467 003d 0000              .word pm(.L52)
468 003f 0000              .word pm(.L53)
469 0041 0000              .word pm(.L54)
470 0043 0000              .word pm(.L55)
471 0045 0000              .word pm(.L56)
472 0047 0000              .word pm(.L57)
473 0049 0000              .word pm(.L58)
474 004b 0000              .word pm(.L59)
475                           .text
476                     .L34:
161:../gsm8.c **** 162:../gsm8.c **** case GSM_STEP_NOTHING_TO_DO:


So in both case the table should go in flash, if ever '.word pm(...)' means 'word in program memory'. Now in the gcc-4.0 version, there is a '.data' line just at the beginning at the table (line 448) that is not in the gcc3.4.3 version. Both switch code use lpm. I don't know yet if the gcc-4.0 version is functionnal since the increase of RAM forbids me to try it without slicing data somewhere else. If it works, then the ram spent is totally useless.

Now is there someone else having the same problem? That would be nice to confirm this.





reply via email to

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