GCC Optimierung, unterschiedliche Codelänge

[Thomas E. (thomase)]

Mit ein und demselben Sourcecode wird je nach Controller unterschiedlich 
langer Binärcode generiert.

AVR-Studio 4.18, Build 716, Optimierung -0s

Atmega 168p 1022 Bytes
Atmega 644p 1006 Bytes

Anders herum wäre es das erwartete Ergebnis, da der 644 mehr Interrupts 
hat.

Aber so?

Ohne Optimierung betragen die Codelängen (168:644)
4938 : 4940
Was zwar tendenziell besser passt, aber der 644 hat 5 Interrupts mehr 
als der 168, sodaß die Interruptvektortabelle 20 Bytes länger ist.

Warum entsteht bei im Grunde gleichen Controllern unterschiedlicher 
Code?

Hierbei handelt es sich um einen Bootloader bei dem der Uart gepollt 
wird und die Bootloaderfunktionen aus der <avr/boot.h> verwendet werden. 
Ist zwar nicht dramatisch, da der Code in den 168er gerade noch 
reinpasst, aber doch etwas verblüffend.


mfg.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas Eckmann schrieb:
> Warum entsteht bei im Grunde gleichen Controllern unterschiedlicher
> Code?
Wo kannst du im Assemblerlisting Unterschiede erkennen?

[Thomas E. (thomase)]

Lothar Miller schrieb:
> Wo kannst du im Assemblerlisting Unterschiede erkennen?

Einige. Aber warum.
Die Controller sind, bis auf daß der 644 ein paar mehr Register für die 
Peripherie hat, gleich.

mfg.

[Peter D. (peda)]

Beim 644 ist eine Page 256 Bytes, das macht die Adreßberechnung 
einfacher.


Peter

[Thomas E. (thomase)]

Peter Dannegger schrieb:
> Beim 644 ist eine Page 256 Bytes, das macht die Adreßberechnung
> einfacher.

Ja klar.

Danke, jetzt kann ich wieder ruhig schlafen.

mfg.

[Peter II (Gast)]

eigentlich müsste nach den 1.code vergleich das 644 file größer sein. 
Weil er mehr flash hat, muss er mit mehr als 8bit rechnen.

Atmel 644:
    fcea:  4e 5f         subi  r20, 0xFE  ; 254
    fcec:  5f 4f         sbci  r21, 0xFF  ; 255
    fcee:  f1 e0         ldi  r31, 0x01  ; 1
    fcf0:  40 30         cpi  r20, 0x00  ; 0
    fcf2:  5f 07         cpc  r21, r31
    fcf4:  41 f7         brne  .-48       ; 0xfcc6

Atmel 186:
    3cd6:  4e 5f         subi  r20, 0xFE  ; 254
    3cd8:  5f 4f         sbci  r21, 0xFF  ; 255
    3cda:  40 38         cpi  r20, 0x80  ; 128
    3cdc:  51 05         cpc  r21, r1
    3cde:  49 f7         brne  .-46       ; 0x3cb2


Bei der nächsten stelle, scheint der optimierer bei 16bit besser 
zurechtzukommen, da ist auf einmal das 644 file kleiner:

644:

If(PGM_READ_BYTE((nPage * (UINT)SPM_PAGESIZE) + nInd) != 
nPageBuffer[nInd]) return 0x21;
    fd1c:  58 2f         mov  r21, r24
    fd1e:  40 e0         ldi  r20, 0x00  ; 0
    fd20:  20 e0         ldi  r18, 0x00  ; 0
    fd22:  30 e0         ldi  r19, 0x00  ; 0
    fd24:  f9 01         movw  r30, r18
    fd26:  e4 0f         add  r30, r20
    fd28:  f5 1f         adc  r31, r21
    fd2a:  e4 91         lpm  r30, Z+
    fd2c:  d9 01         movw  r26, r18
    fd2e:  a4 5f         subi  r26, 0xF4  ; 244
    fd30:  be 4f         sbci  r27, 0xFE  ; 254
    fd32:  8c 91         ld  r24, X
    fd34:  e8 17         cp  r30, r24
    fd36:  11 f0         breq  .+4        ; 0xfd3c <VerifyPage+0x20>
    fd38:  81 e2         ldi  r24, 0x21  ; 33
    fd3a:  08 95         ret

186:
    if(PGM_READ_BYTE((nPage * (UINT)SPM_PAGESIZE) + nInd) != 
nPageBuffer[nInd]) return 0x21;
    3d06:  ac 01         movw  r20, r24
    3d08:  56 95         lsr  r21
    3d0a:  54 2f         mov  r21, r20
    3d0c:  44 27         eor  r20, r20
    3d0e:  57 95         ror  r21
    3d10:  47 95         ror  r20
    3d12:  20 e0         ldi  r18, 0x00  ; 0
    3d14:  30 e0         ldi  r19, 0x00  ; 0
    3d16:  f9 01         movw  r30, r18
    3d18:  e4 0f         add  r30, r20
    3d1a:  f5 1f         adc  r31, r21
    3d1c:  e4 91         lpm  r30, Z+
    3d1e:  d9 01         movw  r26, r18
    3d20:  a4 5f         subi  r26, 0xF4  ; 244
    3d22:  be 4f         sbci  r27, 0xFE  ; 254
    3d24:  8c 91         ld  r24, X
    3d26:  e8 17         cp  r30, r24
    3d28:  11 f0         breq  .+4        ; 0x3d2e <VerifyPage+0x28>
    3d2a:  81 e2         ldi  r24, 0x21  ; 33
    3d2c:  08 95         ret



so wie es scheint, kommt den unterschiende weil die beiden µC 
unterschiedlich viel Flash haben.

[Thomas E. (thomase)]

Peter II schrieb:
> so wie es scheint, kommt den unterschiende weil die beiden µC
> unterschiedlich viel Flash haben.

Dir auch danke für die Mühe. Es ist, wie Peter schrieb, die 
Adressberechnung für die Pagesize. Was natürlich mit der Flashgröße zu 
tun hat.

Da sind sie eben doch nicht gleich.

mfg.