Inkonsistente Codegenerierung bei avr-gcc?

[Florian (Gast)]

Hi,
mir ist bei der Suche nach einem anderem Fehler ggf. ein Problem mit dem 
Compiler aufgefallen:
Im folgendem der Ausschnitt aus dem C code und darauf folgend der 
assembler code:

uint8_t spi_exchangebyte( uint8_t data )
{
  SPDR = data;
  while( ! (  SPSR & ( 1 << SPIF ) ) );
  return SPDR;
}

00000026 <spi_exchangebyte>:
  26:   8e bd           out     0x2e, r24       ; 46
  28:   0d b4           in      r0, 0x2d        ; 45
  2a:   07 fe           sbrs    r0, 7
  2c:   00 c0           rjmp    .+0             ; 0x2e <spi_exchangebyte+0x8>
  2e:   8e b5           in      r24, 0x2e       ; 46
  30:   08 95           ret

Zum ersten würde ich wissen wollen was ".+0" bedeutet? Derzeit gehe ich 
davon aus, dass "." die aktuelle Adresse ist.

Zum zweiten scheint die while Schleife nicht zu funktionieren, da es 
egal ist ob ich "rjmp" überspringe oder nicht, weil der Sprung auch bei 
0x2e endet?(Unter Annahme meiner Vermutung zu ".")

GCC 4.8.2, OPT=s

Danke im Voraus!
Gruß
Florian

[Peter D. (peda)]

Beim 4.3.3 sieht der Code o.k. aus (ATmega16):

uint8_t spi_exchangebyte( uint8_t data )
{
  SPDR = data;
  6c:  8f b9         out  0x0f, r24  ; 15
  while( ! (  SPSR & ( 1 << SPIF ) ) );
  6e:  77 9b         sbis  0x0e, 7  ; 14
  70:  fe cf         rjmp  .-4        ; 0x6e <spi_exchangebyte+0x2>
  return SPDR;
  72:  8f b1         in  r24, 0x0f  ; 15
}
  74:  08 95         ret

[Mike (Gast)]

Peter Dannegger schrieb:
> Beim 4.3.3 sieht der Code o.k. aus (ATmega16):
>

> uint8_t spi_exchangebyte( uint8_t data )
> {
>   SPDR = data;
>   6c:  8f b9         out  0x0f, r24  ; 15
>   while( ! (  SPSR & ( 1 << SPIF ) ) );
>   6e:  77 9b         sbis  0x0e, 7  ; 14
>   70:  fe cf         rjmp  .-4        ; 0x6e <spi_exchangebyte+0x2>
>   return SPDR;
>   72:  8f b1         in  r24, 0x0f  ; 15
> }
>   74:  08 95         ret
>

4.8.1 liefert den gleichen Code (Mega8).

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

Verlass dich nicht auf den Disassembler.

Assembler-Code (atmega88):

spi_exchangebyte:
  out 0x2e,r24
.L2:
  in _tmp_reg_,0x2d
  sbrs _tmp_reg_,7
  rjmp .L2
  in r24,0x2e
  ret
avr-gcc (GCC) 4.7.2

Disassembly:

00000000 <spi_exchangebyte>:
   0:  8e bd         out  0x2e, r24  ; 46
   2:  0d b4         in  r0, 0x2d  ; 45
   4:  07 fe         sbrs  r0, 7
   6:  00 c0         rjmp  .+0        ; 0x8 <spi_exchangebyte+0x8>
   8:  8e b5         in  r24, 0x2e  ; 46
   a:  08 95         ret
GNU objdump (GNU Binutils) 2.20.1.20100303

[Johann L. (gjlayde)]

Das sieht aus wie der Dump eines Objects, also .o das noch nicht 
lokatiert ist, was zu verwirrenden Dumps führen kann.  Mit -r bei 
objdump wirds dann etwas klarer, denn es wird Info zu den RELOCs 
(Platzhalter für Symbole) ausgegeben.

Beispiel:

#include <avr/io.h>

uint8_t spi_exchangebyte (uint8_t data)
{
  SPDR = data;
  while (!(SPSR & (1 << SPIF)))
    ;
  return SPDR;
}

int main;

übersetzt mit

$ avr-gcc foo.c -mmcu=atmega8 -Os -save-temps -c
$ avr-gcc -mmcu=atmega8 foo.o -o foo.elf
$ avr-objdump -x -d -r foo.o > foo.lss
$ avr-objdump  -d -j .text -j .data -j .rodata foo.elf > foo.lst

== foo.s ==

Sieht gut aus, der RJMP geht zu einem lokalen Label (.L3) wie erwartet:

spi_exchangebyte:
  out 0xf,r24
.L3:
  sbis 0xe,7
  rjmp .L3
  in r24,0xf
  ret

== foo.lss ==

Das "RJMP .+0" ist verwirred, der Kommentar danach auch (auch wenn er 
konsistent mit dem .+0 ist).  Was wirklich geschieht zeigt der RELOC in 
der nächsten Zeile: Der Sprung geht zum SBIS, also entsprechend dem .L3 
wie oben auch.

Disassembly of section .text:

00000000 <spi_exchangebyte>:
   0:  8f b9         out  0x0f, r24  ; 15
   2:  77 9b         sbis  0x0e, 7  ; 14
   4:  00 c0         rjmp  .+0        ; 0x6 <spi_exchangebyte+0x6>
      4: R_AVR_13_PCREL  .text+0x2
   6:  8f b1         in  r24, 0x0f  ; 15
   8:  08 95         ret

== foo.lst ==

Das Zeug ist lokatiert (und gelinkt) und der Sprung wird wieder wie 
erwartet dargestellt:

00000048 <spi_exchangebyte>:
  48:  8f b9         out  0x0f, r24  ; 15
  4a:  77 9b         sbis  0x0e, 7  ; 14
  4c:  fe cf         rjmp  .-4        ; 0x4a <spi_exchangebyte+0x2>
  4e:  8f b1         in  r24, 0x0f  ; 15
  50:  08 95         ret

Also alles im grünen Bereich! Das ".-4" bedeutet: Spring zu PC -4 Bytes; 
hier gezählt ab dem Byte, das auf den Sprung folgt (also ab 4e 
rückwärts).  Eine Endlosschleife ist also "RJMP .-2" oder "JMP .-4".