schlechte Optimierung (GCC io.h) ATxmega

[Julius F. (xeno)]

Hallo,

ich beschäftige mich gerade mit den ATxmegas dabei ist mir bei der neuen 
API der AVRLibC eine schlechte Optimierung aufgefallen.

Beispiel:

SPIE.DATA = 0xAA;

Wird zu:

LDI R24,0xAA    Load immediate 
LDI R30,0xC0    Load immediate 
LDI R31,0x0A    Load immediate 
STD Z+3,R24    Store indirect with displacement

Aber warum?
Viel Sinnvoller wäre doch:

LDI R24,0xAA    Load immediate 
STS 0x0AC3,R24    Store direct to data space

Die AVRLibC iox128a1.h sieht so aus:

#define SPIE    (*(SPI_t *) 0x0AC0)  /* Serial Peripheral Interface E */

typedef volatile uint8_t register8_t;

/* Serial Peripheral Interface */
typedef struct SPI_struct
{
    register8_t CTRL;  /* Control Register */
    register8_t INTCTRL;  /* Interrupt Control Register */
    register8_t STATUS;  /* Status Register */
    register8_t DATA;  /* Data Register */
} SPI_t;

Ich verstehe nicht warum der GCC nicht auf eine statische Adresse 
Optimiert. Denn die Adresse ändert sich ja nicht sondern nur der Inhalt.

z.B. bei:

SPIE.CTRL = 0xBB;

Macht der GCC es richtig und setzt dafür eine statische Adresse ein.

LDI R25,0xBB    Load immediate 
STS 0x0AC0,R25    Store direct to data space

Aber bei SPI.INTCTRL, SPI:STATUS ... nicht mehr.


Um das Problem zu lösen muss ich nun immer auf die "alte" API 
zurückgreifen. Sprich: SPIE_DATA = 0xAA;

Ich verwende:

Atmel AVR Studio 5
Atmel AVR Toolchain 3.2.3.314
Windows

AVR 8-bits GNU Binutils 2.20.1
AVR 8-bits GNU Compiler Collection (avr-gcc) 4.5.1
AVRLibC 1.7.1
AVR 8-bits GNU Debugger (avr-gdb) 6.7.1



Gibt es dazu einen Patch o.ä.?

[(prx) A. K. (prx)]

Zeig mal die gesamte Funktion und den erzeugten Code davon.

[(prx) A. K. (prx)]

Julius F. schrieb:

> Um das Problem zu lösen muss ich nun immer auf die "alte" API
> zurückgreifen. Sprich: SPIE_DATA = 0xAA;

Bist du beim Speicher tatsächlich so knapp dran, dass diese 2 Bytes zum 
echten "Problem" werden?

Ein Motiv für solche Adressierung ist, dass die Basisadresse ggf. 
mehrfach verwendet werden kann, wenn auf benachbarte Register ebenfalls 
zugegriffen wird. Das ist freilich bei AVRs aufgrund deren Knappheit an 
Adressregistern seltener möglich als bei anderen Architekturen.

[Julius F. (xeno)]

Hier:

#include <avr/io.h>

int main(void)
{
  SPIE.DATA = 0xAA;
  
  while(!(SPIE.STATUS & SPI_IF_bm)){}
  
  SPIE.DATA = 0xBB;
  
   while(!(SPIE.STATUS & SPI_IF_bm)){}
  
  
    while(1)
    {

    }
}

wird zu:

  SPIE.DATA = 0xAA;
0000010C 8a ea                LDI R24,0xAA    Load immediate 
0000010D e0 ec                LDI R30,0xC0    Load immediate 
0000010E fa e0                LDI R31,0x0A    Load immediate 
0000010F 83 83                STD Z+3,R24    Store indirect with displacement 
  while(!(SPIE.STATUS & SPI_IF_bm)){}
00000110 80 91 c2 0a          LDS R24,0x0AC2    Load direct from data space 
00000112 87 ff                SBRS R24,7    Skip if bit in register set 
00000113 fc cf                RJMP PC-0x0003    Relative jump 
  SPIE.DATA = 0xBB;
00000114 8b eb                LDI R24,0xBB    Load immediate 
00000115 e0 ec                LDI R30,0xC0    Load immediate 
00000116 fa e0                LDI R31,0x0A    Load immediate 
00000117 83 83                STD Z+3,R24    Store indirect with displacement 
   while(!(SPIE.STATUS & SPI_IF_bm)){}
00000118 80 91 c2 0a          LDS R24,0x0AC2    Load direct from data space 
0000011A 87 ff                SBRS R24,7    Skip if bit in register set 
0000011B fc cf                RJMP PC-0x0003    Relative jump 
0000011C ff cf                RJMP PC-0x0000    Relative jump

Und dagegen die "alte" API:

int main(void)
{
  SPIE_DATA = 0xAA;
  
  while(!(SPIE_STATUS & SPI_IF_bm)){}
    
  SPIE_DATA = 0xBB;
  
  while(!(SPIE_STATUS & SPI_IF_bm)){}
  
    while(1)
    {

    }
}

SPIE_DATA = 0xAA;
0000010C 8a ea                LDI R24,0xAA    Load immediate 
0000010D 80 93 c3 0a          STS 0x0AC3,R24    Store direct to data space 
  while(!(SPIE_STATUS & SPI_IF_bm)){}
0000010F 80 91 c2 0a          LDS R24,0x0AC2    Load direct from data space 
00000111 87 ff                SBRS R24,7    Skip if bit in register set 
00000112 fc cf                RJMP PC-0x0003    Relative jump 
  SPIE_DATA = 0xBB;
00000113 8b eb                LDI R24,0xBB    Load immediate 
00000114 80 93 c3 0a          STS 0x0AC3,R24    Store direct to data space 
  while(!(SPIE_STATUS & SPI_IF_bm)){}
00000116 80 91 c2 0a          LDS R24,0x0AC2    Load direct from data space 
00000118 87 ff                SBRS R24,7    Skip if bit in register set 
00000119 fc cf                RJMP PC-0x0003    Relative jump 
0000011A ff cf                RJMP PC-0x0000    Relative jump

[Julius F. (xeno)]

>Bist du beim Speicher tatsächlich so knapp dran, dass diese 2 Bytes zum
>echten "Problem" werden?

Es geht mir nicht um die 2Byte Codegröße sondern um die Geschwindigkeit.
Immerhin sind es 2Takte mehr pro aufruf. Und das ganze beschränkt sich 
ja nicht nur auf die SPI Struct sondern auf alle Bereiche.

Es macht einen unterschied ob ich einen Pin in 2Takten oder in 4Takten 
Toggeln kann.

[(prx) A. K. (prx)]

Yep, unschön, insbesondere weil die relative Adressierung an Stelle des 
STS hier tatsächlich sinnvoll wäre, wenn Z für alle 4 
Lade/Speicher-Operationen nur einmal geladen würde.

Rechne aber lieber nicht damit, dass sich das in absehbarer Zeit ändert, 
denn fehlende Optimierung auf AVR in einem minder schweren Fall hat 
vmtl. nicht grad hohe Priorität bei den Entwicklern.

[Stefan E. (sternst)]

Und wo hast du den Assembler-Code her? Vielleicht irgendwo aus dem 
AVR-Studio-5-Debugger? Ist dir klar, dass das Studio5 den Debug-Build 
mit -O0 übersetzt?

[(prx) A. K. (prx)]

-O0 sieht anders aus. Nö, das ist reproduzierbar.

Was ich mit der Z-Optimierung meinte zeigt sich bei:

#define SPIE    (*(SPI_t *) 0x0AC0)  /* Serial Peripheral Interface E */

typedef volatile unsigned char register8_t;

/* Serial Peripheral Interface */
typedef struct SPI_struct
{
    register8_t CTRL;  /* Control Register */
    register8_t INTCTRL;  /* Interrupt Control Register */
    register8_t STATUS;  /* Status Register */
    register8_t DATA;  /* Data Register */
} SPI_t;

SPI_t *p = &SPIE;

int main(void)
{
  p->DATA = 0xAA;
  
  while(!(p->STATUS & 1)){}
  
  p->DATA = 0xBB;
  
   while(!(p->STATUS & 1)){}
  
  
    while(1)
    {

    }
}

denn das wird zu:

        lds r30,p
        lds r31,(p)+1
        ldi r24,lo8(-86)
        std Z+3,r24
.L2:
        ldd r24,Z+2
        sbrs r24,0
        rjmp .L2
        ldi r24,lo8(-69)
        std Z+3,r24
.L3:
        ldd r24,Z+2
        sbrs r24,0
        rjmp .L3
.L8:
        rjmp .L8

[Julius F. (xeno)]

> Und wo hast du den Assembler-Code her? Vielleicht irgendwo aus dem
> AVR-Studio-5-Debugger? Ist dir klar, dass das Studio5 den Debug-Build
> mit -O0 übersetzt?

Ja aus dem AVR-Studio 5 Disassembler bzw. der *.lss Datei aber ich glaub 
nicht der er mir -O0 Code anzeigt denn wenn ich den Code mit -Os oder 
-O3 übersetzte kommt auch ein anderer ASM Code dabei raus.

habe nun meine #define geändert:

#define SPI_SEND(modul, data)  while(!(modul.STATUS & SPI_IF_bm)){}; modul.DATA = data

in

#define SPI_SEND(modul, data)  while(!(modul##_STATUS & SPI_IF_bm)){}; modul##_DATA = data

Aufruf

int main(void)
{
    SPI_SEND(SPIE, 0xAA);
}

[Johann L. (gjlayde)]

Diese 4.5.1 ist eine von Atmel gepatchte Version des Compilers, d.h. der 
entsprechende Bug-Report gehört nach atmel.com.

Auf einem "suberen" avr-gcc lässt sich dies nicht übersetzten und damit 
auch nicht nachvollziehen.

[Johann L. (gjlayde)]

Mit einer angepassten Quelle sehe ich das auch mit 4.3, 4.5 und 4.6.

typedef struct
{
    volatile unsigned char a,b,c,d;
} SPI_t;

#define SPIE (*(SPI_t*) 0x0AC0)

void foo (void)
{
    SPIE.d = 0xAA;
    while (!(SPIE.c & 0x80));

    SPIE.d = 0xBB;
    while (!(SPIE.c & 0x80));
}

Wenn du magst, kannst du einen Bug-Report bei GCC machen. Da es nur ein 
Optimierungsproblem ist, wird das frühestens in 4.7 behoben — zumindest 
im GCC und falls es in 4.7 noch besteht. Oder du musst eben selber 
Patches machen, besorgen oder zurückportieren, sobald es in 4.7/4.8 
behoben ist.

Mit 4.7 habe ich es noch nicht getestet, und ich kann auch (noch) nicht 
sagen, ob es am AVR-Teil hängt oder nicht.

[Johann L. (gjlayde)]

Eigentlich gehört das ins GCC-Forum.

Das Problem entsteht beim tree→RTL Lowering.

[Julius F. (xeno)]

> Diese 4.5.1 ist eine von Atmel gepatchte Version des Compilers, d.h. der
> entsprechende Bug-Report gehört nach atmel.com.

> Auf einem "suberen" avr-gcc lässt sich dies nicht übersetzten und damit
> auch nicht nachvollziehen.

Mit WinAVR 20100110 besteht das Problem auch.
Werde gleich mal aufm Linux System einen "sauberen" avr-gcc compilieren 
mal gucken wie es dort aussieht.

> Wenn du magst, kannst du einen Bug-Report bei GCC machen.

Mein Schrift-Englisch ist jetzt nicht so gut das ich es machen würde.
Ich würde mich freuen wenn einer von euch es dort Posten könnte.

> Eigentlich gehört das ins GCC-Forum.

Ja, richtig. Hab es leider aus Reflex / Gewohnheit hier gepostet. Ein 
Mod könnte es ja verschieben.

[Johann L. (gjlayde)]

Julius F. schrieb:

>> Wenn du magst, kannst du einen Bug-Report bei GCC machen.
>
> Mein Schrift-Englisch ist jetzt nicht so gut das ich es machen würde.
> Ich würde mich freuen wenn einer von euch es dort Posten könnte.

Ist PR50448.

[Julius F. (xeno)]

Danke dir.

Ich werde es weiterverfolgen.