Problem mit Inline Assembler Routine (es wird zu viel optimiert)

[Der T. (Gast)]

Hallo,

IDE: AtmelStudio 7.0.1931 (Optimierung steht auf -Os)
MCU: ATXMega128A1U mit ext. SDRAM

Ich habe mir ein paar Routinen (Write/Read Byte/Word/DWord/Block, Copy 
Block, ...) in Inline Assembler geschrieben, um auf den externen 
Speicher zugreifen zu können. Eine dieser Funktionen macht allerdings 
Probleme.

Funktion:

static inline bool himem_fill_block(uint8_t seg, uint16_t off, uint8_t val, uint16_t len)
{
  __asm__ __volatile__
  (
    "in __tmp_reg__,%4"  "\n\t"
    "out %4,%1"          "\n\t"
    "cp  %A3,r1"         "\n\t"
    "cpc %B3,r1"         "\n\t"
    "breq END%="         "\n\t"
    "LOOP%=:"            "\n\t"
    "st %a2+,%0"         "\n\t"
    "subi %A3,0x01"      "\n\t"
    "sbci %B3,0x00"      "\n\t"
    "brne LOOP%="        "\n\t"
    "END%=:"             "\n\t"
    "out %4,__tmp_reg__" "\n\t"
    :
    :  "r"  (val),
      "r"  (seg),
      "z"  (off),
      "d"  (len),
      "I"  (_SFR_IO_ADDR(RAMPZ))
  );
  return TRUE;
}

Mit dieser Funktion kann ich einen Speicherbereich initialisieren. An 
sich läuft die Funktion. Wenn allerdings der Offset zufällig die gleiche 
Größe wie die Länge hat, optimiert der Compiler etwas zu viel - trotz 
dem volatile.


Beispiel-Listing OK:  (seg=0x80, off=0x0010, val=0x11, len=0x000f)

LDI R18,0x0F    Load immediate
LDI R19,0x00    Load immediate
LDI R30,0x10    Load immediate
LDI R31,0x00    Load immediate
LDI R25,0x80    Load immediate
LDI R24,0x11    Load immediate
IN R0,0x3B    In from I/O location
OUT 0x3B,R25    Out to I/O location
CP R18,R1    Compare
CPC R19,R1    Compare with carry
BREQ PC+0x05    Branch if equal
ST Z+,R24    Store indirect and postincrement
SUBI R18,0x01    Subtract immediate
SBCI R19,0x00    Subtract immediate with carry
BRNE PC-0x03    Branch if not equal
OUT 0x3B,R0    Out to I/O location

Beispiel-Listing FAIL:  (seg=0x80, off=0x0010, val=0x11, len=0x0010)

LDI R30,0x10    Load immediate
LDI R31,0x00    Load immediate
LDI R25,0x80    Load immediate
LDI R24,0x11    Load immediate
IN R0,0x3B    In from I/O location
OUT 0x3B,R25    Out to I/O location
CP R30,R1    Compare
CPC R31,R1    Compare with carry
BREQ PC+0x05    Branch if equal
ST Z+,R24    Store indirect and postincrement
SUBI R30,0x01    Subtract immediate
SBCI R31,0x00    Subtract immediate with carry
BRNE PC-0x03    Branch if not equal
OUT 0x3B,R0    Out to I/O location

Wie kann ich den Compiler zwingen hier gefälligst nicht zu optimieren? 
;-)

Danke!

[Kaj (Gast)]

Der T. schrieb:
> Wie kann ich den Compiler zwingen hier gefälligst nicht zu optimieren?

#pragma GCC push_options
#pragma GCC optimize ("O0")

your code

#pragma GCC pop_options

oder

void __attribute__((optimize("O0"))) foo(unsigned char data) {
    // unmodifiable compiler code
}

[Stefan F. (Gast)]

Ich hätte nicht gedacht, dass der Compiler den Assembler Code verändert.

[Falk B. (falk)]

Komplette Funktionen schreibt man besser in echtem Assembler. Das ist 
DEUTLICH einfacher, angenehmer und der kein C-Compiler der Welt pfuscht 
rein. Es gibt da eine sehr einfache, über sichtloiche App-Note zum 
Thema.

doc42055

[Jörg W. (dl8dtl) (Moderator)]

Der T. schrieb:

> IDE: AtmelStudio 7.0.1931 (Optimierung steht auf -Os)

Interessiert nicht. :)  Wenn schon, würde die Compilerversion 
interessieren.

> Speicher zugreifen zu können. Eine dieser Funktionen macht allerdings
> Probleme.

Mit anderen Worten: dein Inline-Assembler-Code ist nicht korrekt 
constrained.

> Wie kann ich den Compiler zwingen hier gefälligst nicht zu optimieren?

Es ist die Aufgabe des Compilers, Code zu optimieren. Deinen 
Inline-Assembler-Code selbst kann er natürlich dabei nicht anfassen, nur 
die Vor- und Nachbereitung. Die constraints dienen dazu, dass du ihm 
mitteilst, an welchen Stellen er was wie hinterlegen muss.

Soviel zur Vorrede. :-)  Jetzt muss ich aber auch erstmal gucken, was du 
da genau vergessen haben könntest …

Probier doch mal, die Länge als "+d" zu constrainen.

Korrekterweise müsstest du wohl auch den Offset als "+z" deklarieren, 
denn durch das Z+ änderst du ja den Z-Pointer innerhalb des Codes.

Ich bin übrigens nicht wirklich davon überzeugt, dass man das nicht auch 
gleich in C schreiben könnte.

[Der T. (Gast)]

Danke Kaj! :-)

So läuft es:

static inline bool __attribute__((optimize("O0"))) himem_fill_block(uint8_t seg, uint16_t off, uint8_t val, uint16_t len)
{
....
}

[Der T. (Gast)]

Jörg W. schrieb:

> Probier doch mal, die Länge als "+d" zu constrainen.
>
> Korrekterweise müsstest du wohl auch den Offset als "+z" deklarieren,
> denn durch das Z+ änderst du ja den Z-Pointer innerhalb des Codes.

Der Compiler mag das "+" nicht..?

    :  "r"  (val),
      "r"  (seg),
      "z"  (off),
      "+d"  (len),
      "I"  (_SFR_IO_ADDR(RAMPZ))

Dieser meckert dann mit dem Fehler: "input operand constraint contains 
'+'"

[Jörg W. (dl8dtl) (Moderator)]

Dann musst du ihn wohl bei den output operands angeben (also nach dem 
ersten Doppelpunkt).

Allerdings ändert sich dann leider die Nummerierung. Nummerierte 
Operanden sind aber eh bäh, besser sind benannte Operanden.  Also ein 
[foo] for das Constraint, und du kannst statt %0 %[foo] schreiben.

[Der T. (Gast)]

Jörg W. schrieb:
> Dann musst du ihn wohl bei den output operands angeben (also nach dem
> ersten Doppelpunkt).
>
> Allerdings ändert sich dann leider die Nummerierung. Nummerierte
> Operanden sind aber eh bäh, besser sind benannte Operanden.  Also ein
> [foo] for das Constraint, und du kannst statt %0 %[foo] schreiben.


Das habe ich auch gerade ausprobiert - Pustekuchen!
Der Compiler optimiert hier ebenfalls.. :-(

Das Listing sieht fast genauso wie der FAIL oben aus.

[Jörg W. (dl8dtl) (Moderator)]

Ist mir jetzt gerade zu spät. Schau ich mir morgen nochmal an.

[Johann L. (gjlayde)]

Der T. schrieb:

> Wie kann ich den Compiler zwingen hier gefälligst nicht zu optimieren?

Das ist nicht der richtige Ansatz.  Der richtige Ansatz ist, korrekten 
Code zu schreiben, z.B. so:

static inline bool himem_fill_block (uint8_t seg, uint16_t off, uint8_t val, uint16_t len)
{
    if (len)
    {
      __asm__ __volatile__
      (
        "out __RAMPZ__, %[seg]"       "\n"
        "LOOP%=:"                     "\n\t"
        "st %a[off]+, %[val]"         "\n\t"
        "sbiw %[len], 1"              "\n\t"
        "brne LOOP%="                 "\n\t"
        "out __RAMPZ__, __zero_reg__"
        : [off] "+z" (off),
          [len] "+w" (len)
        : [val] "r" (val),
          [seg] "r" (seg)
        : "memory");
    }

  return true;
}

off und len werden verändert -> Müssen also zu den Outputs wie Jörg 
bereits schrieb.

Speicher wird verändert -> "memory" muss zu den Clobbers.

avr-gcc geht davon aus, dass in RAMP* immer 0 steht -> Der Inhalt von 
RAMPZ braucht nicht gemerkt zu werden, und am Ende kann RAMPZ auf 0 
gesetzt werden -> Kürzerer Code.

Am Anfang des s-Files wird __RAMPZ__ zur I/O-Adresse von RAMPZ definiert 
-> Weniger Operanden.

Die 16-Bit Operationen können in einem 16-Bit Befehl abgehandelt werden 
-> Kürzerer Code.

Der zu wartende asm-Code kann weiter verkürzt werden, indem der 
Vergleich von len aus dem asm herausgezogen wird.  Falls len zur 
Compilezeit bekannt ist, entfällt der Vergleich komplett.

stdbool.h (C99) definiert true und false.

[Der T. (Gast)]

Danke Johann für deinen Betrag.

Assembler nutze ich zu wenig, so dass ich zu wenig in der Materie drin 
stecke. Ich programmiere fast ausschließlich in Hochsprache.

Ich werde mir dies näher ansehen und auch meine älteren Routinen ggf. 
Überarbeiten. Vielen Dank für deine Unterstützung. :-)