AVR_GCC: "lpm __temp_reg__, Z" wird durch "lpm __temp_reg__, Z+" ersetzt

[Leo B. (luigi)]

Hey Leute,

[background]
ich möchte eine look-up-Table im Programmspeicher unterbringen. Nichts
besonderes. Jetzt möchte ich aber in einer Schleife mehrere Werte suchen.
Da das ganze schnell gehen muss (sind etwas über 4000 Werte und Zeit knapp) 
und der Compiler immer recht amüsant movw-Befehle eingefügt hat habe ich 
nun probiert den Code mit inline-Assembler etwas zu beschleunigen.
[/background]

Dabei habe ich nun aber festgestellt (und darum soll es eigentlich in 
diesem Thread gehen), dass der Compiler aus folgenden Quellcode-Zeilen

// äquivalent nur langsamer wegen sporadisch generierter, unnötiger mov-befehle:
// b0 = pgm_read_byte( &sBox[ b0 ] );
asm
(
  "ldi  %A[ptr], lo8(%[sBox])  \n\t"
  "ldi  %B[ptr], hi8(%[sBox])  \n\t"
  "add  %A[ptr], %[b0]         \n\t"
  "adc  %B[ptr], __zero_reg__  \n\t"
  "lpm %[b0], Z                \n\t"
  : [b0] "+r" (b)
  , [ptr] "=z" (b)  // b ist an dieser Stelle zwar falsch aber hat
                    // auch keine Auswirkung. Was hier korrekt wäre
                    // ist mir leider nicht klar.
  : [sBox] "i" (sBox)
);

folgenden code erzeugt:

 158:  e4 e3         ldi  r30, 0x34  ; 52
 15a:  f0 e0         ldi  r31, 0x00  ; 0
 15c:  e8 0f         add  r30, r24
 15e:  f1 1d         adc  r31, r1
 160:  84 91         lpm  r24, Z+

Nicht, dass das jetzt in diesem Falle stören würde, aber allgemein macht 
er aus dem "Z" (ohne post-increment) ein "Z+". Das ist mir auch schon an 
Stellen aufgefallen, wo es mich gestört hat und ich dann ein workaround 
finden musste.

Was ich mich nun Frage ist, ob das irgendwie mein Fehler oder ein Fehler 
des Compilers ist?

Danke schonmal fürs lesen
Liebe Grüße
Leo

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

84 91 ist LPM R24,Z
Riecht also nach einem Fehler im Disassembler.

[Johann L. (gjlayde)]

Leo B. schrieb:

> Nicht, dass das jetzt in diesem Falle stören würde, aber allgemein macht
> er aus dem "Z" (ohne post-increment) ein "Z+".

Kein Fehler von dem ich je gehört hätte.  Lies mal den Assemblercode im 
mit -save-temps erzeugten s-File.

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

http://sourceware.org/bugzilla/show_bug.cgi?id=10964

[Leo B. (luigi)]

also im s-File steht noch

  ldi  r30, lo8(sBox)  
  ldi  r31, hi8(sBox)  
  add  r30, r24      
  adc  r31, __zero_reg__  
  lpm r24, Z

im hex-file an entsprechender Adresse steht dann

:1001600084918E2F880F10F43BE18327E4B984B982
         ^^^^

das enspricht der binären Folge

1000 0100 1001 0001

und im AVR "Instruction Set Nomenclature" steht, dass "LPM" wie folgt 
übersetzt wird:

(i)   LPM None, R0 implied PC ← PC + 1
(ii)  LPM Rd, Z 0 ≤ d ≤ 31 PC ← PC + 1
(iii) LPM Rd, Z+ 0 ≤ d ≤ 31 PC ← PC + 1

(i)   1001 0101 1100 1000
(ii)  1001 000d dddd 0100
(iii) 1001 000d dddd 0101

einzig sinnvolle Übersetzung ergibt sich, wenn man zuvor die Bytes 
tauscht. Das hat sicher was mit Big- und Little-Endian zu tun, aber 
damit halte ich mich jetzt mal nicht auf...

Ich vergleiche dann also:

     1001 0001 1000 0100
(ii) 1001 000d dddd 0100

=> d = 0b11000 = 24 (= r24, passt)
(ii) ist ohne "Post increment". Also scheints wirklich ein Fehler im 
Disassembler zu sein.

Danke
Gruß Leo

[Johann L. (gjlayde)]

Ist aber nicht nur in Debian, sondern auch in "neueren" Versionen von 
WinAVR.

[Leo B. (luigi)]

A. K. schrieb:
> http://sourceware.org/bugzilla/show_bug.cgi?id=10964

Jo da stehts dann wohl auch. so ähnlich.

Danke nochmal