seltsamer code assembler code.

[mitleser (Gast)]

Hallo zusammen

Ich arbeite z.Zt. mit einem AtMega664P unter AVR Studio 4.18.
Optimierungsstufe -Os

Es geht um folgenden code. Eingedampft auf das nötigste, aber 
compilierbar und lauffähig.

#define    F_CPU     20000000UL

#include  <inttypes.h>
#include  <avr/io.h>
#include   <stdlib.h> 

#define FTDI_TXE        (PINA &   0b00010000)
#define FTDI_WR_1       PORTA |=  0b01000000
#define FTDI_WR_TOGGLE  PINA  =   0b01000000
#define FPGA_DATA_AV    (PINA &   0b00000100)

//******************************************************
//    function prototypes
//******************************************************

int16_t    main(void);

//******************************************************
//  main
//******************************************************
  
int16_t main(void)
{
  uint16_t    u16_C1, u16_C2;

  DDRA = 0b11100000;            // IN=0; OUT=1
  FTDI_WR_1;

  for(u16_C1 = 0; u16_C1 < 43; u16_C1++)
  {
    u16_C2 = 39;
    do
    {
      while(FPGA_DATA_AV != 0);  // Warten bis Daten vom FPGA kommen

      while(FTDI_TXE != 0);    // Warten bis USB-Bus frei ist

      FTDI_WR_TOGGLE;        // FTDI_WR_0
      FTDI_WR_TOGGLE;        // FTDI_WR_1

    }while(--u16_C2 != 0);
  }

  return 0;
}

Nach dem compilieren zeigt das Disaembler Window folgendes:
(nur ein Ausschnitt)

40:       {
+0000004A:   EE80        LDI       R24,0xE0       Load immediate
+0000004B:   B981        OUT       0x01,R24       Out to I/O location
45:         FTDI_WR_1; 
+0000004C:   9A16        SBI       0x02,6         Set bit in I/O register
+0000004D:   E020        LDI       R18,0x00       Load immediate
+0000004E:   E030        LDI       R19,0x00       Load immediate
59:             FTDI_WR_TOGGLE;        // FTDI_WR_0  <---- ????????????
+0000004F:   E440        LDI       R20,0x40       Load immediate
45:         FTDI_WR_1;
+00000050:   E287        LDI       R24,0x27       Load immediate
+00000051:   E090        LDI       R25,0x00       Load immediate
55:             while(FPGA_DATA_AV != 0);  // Warten bis Daten vom FPGA kommen
+00000052:   9902        SBIC      0x00,2         Skip if bit in I/O register cleared
+00000053:   CFFE        RJMP      PC-0x0001      Relative jump
57:             while(FTDI_TXE != 0);    // Warten bis USB-Bus frei ist
+00000054:   9904        SBIC      0x00,4         Skip if bit in I/O register cleared
+00000055:   CFFE        RJMP      PC-0x0001      Relative jump
59:             FTDI_WR_TOGGLE;        // FTDI_WR_0
+00000056:   B940        OUT       0x00,R20       Out to I/O location
60:             FTDI_WR_TOGGLE;        // FTDI_WR_1
+00000057:   B940        OUT       0x00,R20       Out to I/O location
63:           }while(--u16_C2 != 0);
+00000058:   9701        SBIW      R24,0x01       Subtract immediate from word
+00000059:   F7C1        BRNE      PC-0x07        Branch if not equal
47:         for(u16_C1 = 0; u16_C1 < 43; u16_C1++)
+0000005A:   5F2F        SUBI      R18,0xFF       Subtract immediate
+0000005B:   4F3F        SBCI      R19,0xFF       Subtract immediate with carry
+0000005C:   322B        CPI       R18,0x2B       Compare with immediate
+0000005D:   0531        CPC       R19,R1         Compare with carry
+0000005E:   F789        BRNE      PC-0x0E        Branch if not equal
67:       }

Was ich gar nicht verstehe, ist der C Kommentar über Adresse 4F:
FTDI_WR_TOGGLE;        // FTDI_WR_0

Warum steht er da? Der passt doch gar nicht zur Anweisung?

Dieses Verhalten ist reproduzierbar!

[900ss (900ss)]

Wenn du den Code mit irgendeiner Optimierung übersetzt, dann optimiert 
der Compiler die Anweisungen. Dadurch passen die dann nicht mehr zu den 
'C'-Zeilennummern.
Schalte die Optimierung ab, dann sollte es passen.

[mitleser (Gast)]

>Dadurch passen die dann nicht mehr zu den
>'C'-Zeilennummern.

Ja, das ist mir klar.
Ich will aber wissen, warum an dieser Stelle ein komplett falscher 
C-Kommentar steht, der nichts mit der folgenden Anweisung zu tun hat.

P.S.
Das Prg wird übrigends korrekt auisgeführt.

[Justus S. (jussa)]

da wird R20 einfach mit dem Bitmuster 0100 0000, welches FTDI_WR_TOGGLE 
belegt, vorbelegt, und später dann einfach benutzt...siehst du ja 
später, da wird bei jedem Aufruf von FTDI_WR_TOGGLE R20 benutzt

[mitleser (Gast)]

Bingo :-)

Danke Justus. So einfach ist das ...

[900ss (900ss)]

mitleser schrieb:
> Ja, das ist mir klar.

Ist es scheinbar nicht. Sonst würdest du nicht fragen.
Du kannst nicht mehr davon ausgehen, dass die 'C'-Zeilen zu dem 
Assembler passen. Darum(!) steht dort eine 'C'-Zeile, die dort evtl. 
nicht paßt. Übersetze mal mit -O2, dann sieht es wahrscheinlich 
nochmerkwürdiger aus.

[900ss (900ss)]

Justus Skorps schrieb:
> da wird R20 einfach mit dem Bitmuster 0100 0000, welches FTDI_WR_TOGGLE
> belegt, vorbelegt, und später dann einfach benutzt...siehst du ja
> später, da wird bei jedem Aufruf von FTDI_WR_TOGGLE R20 benutzt

Das ist reiner Zufall, dass das in dem Zusammnhang paßt. Bei anderen 
Optimierungsstufen stehen dann 'C'-Zeilen scheinbar zu völlig 
unpassendem Assemblercode im Listing.

Andere Optimierungsstufe und schon sieht es anders und vielleicht 
garnicht mehr passend aus.

[mitleser (Gast)]

>Das ist reiner Zufall, dass das in dem Zusammnhang paßt. Bei anderen

Was ist denn noch?
Die Sache ist doch geklärt. Der Kommentar passt entgegen meiner ersten 
Annahme doch zum Assembler-code, ich habs nur nicht gesehen.
Das hat nix mit Zufall zu tun.

[900ss (900ss)]

mitleser schrieb:
> Was ist denn noch?

Das hier ist geklärt und sieht hier "einigermaßen" gut aus. Aber ich 
weiß halt, dass das auch so aussehen kann, dass die C-Sourcezeilen im 
Assemblerlisting an eine ganz unpassenden Stelle stehen können. Will nur 
den Hinweis geben, nur weil es hier einigermaßen paßt, muß das nicht 
immer so sein.
Ich habe gerade kein Beispiel zur Hand, sonst würde ich es zeigen.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

900ss D. schrieb:
> Ich habe gerade kein Beispiel zur Hand, sonst würde ich es zeigen.

Gerade switch/case-Strukturen sehen im Assembler- bzw. Maschinencode oft 
komplett anders aus, da sie gerade bei einer großen Zahl von 
case-Anweisungen nicht als lineare Liste von Abfragen übersetzt werden, 
sondern zunächst als Binärbaum sortiert.

Deutliche Verschiebungen von Zeilennummern findet man insbesondere dann, 
wenn die Quelltexte keine einheitlichen Zeilenenden haben, d.h. eine 
Mischung aus CR, LF, CR/LF vorliegt. Viele Compiler orientieren sich am 
Umbruch der ersten Quelltextzeile.

[Johann L. (gjlayde)]

Siehe auch "Debugging Optimized Code"

http://sourceware.org/gdb/current/onlinedocs/gdb/Optimized-Code.html#Optimized-Code