Disassembler Listing falsch ?

Beim Testen eines neuen PICs Typ 16F688 habe ich arge Probleme.
Dann habe ich die Software abgespeckt und habe den erzeugten Assembler Code mir angesehen
und ehrlich gesagt überhaupt nicht verstanden, obwohl ich quasi mit dem aufgewachsen bin....;)

Anhang 34041

Code:

---

!void Delay_ms(U16 ms)
!{
!  GIE = 0;
0x60: BCF INTCON, 0x7
!  TimeOut = ms;
0x61: BCF STATUS, 0x5
0x62: BCF STATUS, 0x6
0x63: MOVF 0x2F, W
0x64: MOVWF 0x78
0x65: MOVF __pcstackBANK0, W
0x66: MOVWF TimeOut
!  while(TimeOut)
0x67: MOVF TimeOut, W
0x68: IORWF 0x78, W
0x69: BTFSC STATUS, 0x2
0x6A: GOTO 0x6E
0x6D: GOTO 0x67
!  {
!    GIE = 1;
0x6B: BSF INTCON, 0x7
!//  NOP();   
!    GIE = 0;
0x6C: BCF INTCON, 0x7
!  }
!  GIE = 1;
0x6E: BSF INTCON, 0x7
!}
0x6F: RETURN

---

Zuerst dachte ich der C-Compiler erzeugt falschen Code,
nach einigem rumprobieren und schließlich durch Simulation mit dem
integrierten Simulator der IDE ging mir mehr und mehr ein Licht auf.

Der angezeigte ASM Code stimmt nicht:

Dreh und Angelpunkt ist die Abfrage
0x69: BTFSC STATUS, 0x2
0x6A: GOTO 0x6E
0x6D: GOTO 0x67 // Dieser Goto ist "hier" an falscher Stelle, es fehlen die Adresszeilen 0x6B und 0x6C

Die kommen dann erst viel später im Listing
Hier ist also etwas durcheinander geraten.

Normalerweise springt der BTFSC entweder in die nächste oder übernächste Zeile vom Code.
Da die Abfrage an der Adresse 0x69 im Speicher steht
muss er entweder auf die nächste Adresse0x6A oder auf die übernächste Adresse 0x6B springen.
Die übernächste Zeile ist aber 0x6D ?????
Die Adresse 0x6B steht aber erst viel weiter hinten im Listing.

Witzigerweise macht der Simulator das sogar richtig.
Er überspringt tatsächlich mehrere Zeilen um an die richtige Adresse 0x6B zu gelangen.

MPLAB-X 5.15
XC8 V2.05


Mein eigentliches Problem konnte ich nun auch lösen,
und ist auch interessant, daher rührt nämlich der obige Code.

Bei einer direkten Folge von
GIE=1;
GIE=0;
wenn voher die Interrupts schon gesperrt waren, werden keine neuen anstehenden Interrupts ausgelöst.
Es ist zwingend erforderlich zumindest ein NOP dazwischen zu setzen, also
GIE=1;
NOP(); // Zeit schaffen um Interrupt auszulösen
GIE=0;

Siro

Ich habe es eben nochmal probiert um es noch einfacher darzustellen bzw. dass ihr es evtl. auch mal nachvollziehen könnt:
Der angezeigte ASM Code sieht hier wieder falsch aus,
Die Zeilen stimmen nicht in der Reihenfolge:

Code:

---

volatile char value;

void Test(void)
{
  while(value)
  {
    RC2 = 1;
    RC2 = 0;
  }
}

---

Der erzeugt Assembler Code bzw. das Listing:

Code:

---

176:          volatile char value;
177:          void Test(void)
178:          {
179:            while(value)
008A  0876    MOVF value, W
008B  1903    BTFSC STATUS, 0x2
008C  0008    RETURN
0091  288A    GOTO 0x8A    // diese zeile gehört hier nicht hin
180:            {
181:              RC2 = 1;
008D  1283    BCF STATUS, 0x5
008E  1303    BCF STATUS, 0x6
008F  1507    BSF PORTC, 0x2
182:              RC2 = 0;
0090  1107    BCF PORTC, 0x2
0091  288A    GOTO 0x8A
183:            }
184:          }

---

wenn man sich nur den Assemblercode anschaut, die linke Adresspalte also wegdenkt,
würde er niemals das RC2 Bit anfassen.

Bei genauerer Betrachtung ist da eigentlich nur eine Zeile zu viel drin nach dem Return
Irgendwie taucht die Zeile doppelt auf:
0091 288A GOTO 0x8A

Das scheint meiner Meinung nach ein Bug zu sein, oder wie seht Ihr das ?

Siro

Zitat:

---

Zitat von Siro

Das scheint meiner Meinung nach ein Bug zu sein, oder wie seht Ihr das ?

---

Ist das Ergebnis deines C-Codes falsch? Entspricht es nicht dem C-Standard? Wenn ja, ist es ein Bug.

Vergiss, daß es Assembler überhaupt gibt. Wenn du eine Formel, eine Anweisung formulierst, ob in C, in Python oder in Excel, kannst du erwarten, daß sie richtig ausgerechnet bzw. ausgeführt wird, nicht mehr und nicht weniger. Wenn das Ergebnis nach den Regeln der jeweiligen Sprache falsch ist, ist das ein Bug, sonst nicht.

Die Aufgabe eines Compilers ist, funktionierenden Code zu erzeugen. Der muß unter allen Bedingungen funktionieren, egal was vorher oder nachher passiert. So wie ein Pilot vor jedem Start das Flugzeug inspizieren muß, selbst wenn er das eine Stunde zuvor schon mal gemacht hat. Dabei entstehen schon mal Doppelbearbeitungen. Und bevor ich nicht selbst einen Compiler gebaut habe, der alle Tests besteht, wäre ich mit der Beurteilung des erzeugten Codes eines Compilers sehr vorsichtig.

MfG Klebwax

Hallo!

Zitat:

---

Zitat von Klebwax

Wenn das Ergebnis nach den Regeln der jeweiligen Sprache falsch ist, ist das ein Bug, sonst nicht.

---

Ich kann das nur bestätigen und aus eigener langjähriger Erfahrung dazu sagen, daß wenn die beide Programme (s.g. Dis- und Assembler) von diversen Autoren stammten, war die "Rückübersetzung" nie richtig. Das gleiche Problem gibt es bei jedem Wörterbuch für "normale" Sprachen. Ich denke, daß du die Richtigkeit der Rückübersetzung gar nicht selber bewerten könntest. :(

Moin Klebwax,

Zitat:

---

Vergiss, daß es Assembler überhaupt gibt.

---

Kein Kommentar...;)

Nur so (mit dem Disassembler Listing) kann ich oftmals Probleme überhaupt finden, die mir z.B. der Compiler verbockt hat.
Oh Oh, klingt jetzt negativ, ist aber nicht neagtiv gemeint....

Zitat:

---

Die Aufgabe eines Compilers ist, funktionierenden Code zu erzeugen. Der muß unter allen Bedingungen funktionieren, egal was vorher oder nachher passiert.

---

Du weist aber schon, das z.B. es im C99 Standard 190 Fälle gibt, wo nicht eindeutig festgelegt ist wie der Compiler eine C-Anweisung zu übersetzen hat.
Wobei generell solcher Code möglicht vermieden werden sollte.
Ich würd schon gerne wissen was er daraus macht und das steht nunmal im Assembler Listing.

Stell Dir vor, dein Code funktioniert einwandfrei in der Optimierunsgsstufe O-0 also ohne Optimierungen
nun stellst Du eine andere Optimierungsstufe ein und plötzlich geht der Code nicht mehr.
Was macht Du dann ? Festlegen dass man keine Optimierung verwenden darf ?
Das wäre in meinen Augen grob fahrlässig,
also bleibt einem kaum etwas anderes übrig als im Assemblerocde zu wühlen.
Mal abgesehn davon, dass es mir Spass macht, ist hier fast immer die Ursache zu finden, da der C Code ja nicht verändert wurde.
Das heisst jetzt nicht dass der C Compiler Mist gebaut hat, sondern dass ich ihm anscheinend nicht richtig klar gemacht habe was er zu tun sollte....

Es gibt auch Prozessor Probleme die je nach Code Implementierung auftreten können oder auch nicht,
also abhängig davon was der Compiler für Code erzeugt. (Egal was für ein Compiler oder Programmiersprache das ist)
Auch hier gibt NUR der Blick in den ASM Code Aufschluss darüber.

Viel mehr möcht ich jetzt dazu garnicht dazu sagen, das artet sonst wieder in wilde Diskussionen aus, das war aber nicht Sinn des Threads.

Eigentlich wollte ich nur darauf aufmerksam machen, dass der angezeigte Dissambler Code nicht korrekt ist
und ich dadurch unnötig Zeit investieren muste um mein eigentliches Problem zu finden.


@PicTure:
Ja, ich habe Ähnliches früher auch schon erlebt, dass die Rücküberstzungen von Disassemblern verschiedener Hersteller anders aussahen.
Das waren noch zu Zeiten des 8086.
Problematisch ist das natürlich wenn der Source Code nicht zur Verfügung steht, denn dann weis er nicht ob es sich um
Daten oder evtl. Tabellen handelt oder ob es Code sein soll.
.

Siro

Zitat:

---

Zitat von Siro

Moin Klebwax,

Zitat:

---

Vergiss, daß es Assembler überhaupt gibt.

---

Kein Kommentar...;)

Nur so (mit dem Disassembler Listing) kann ich oftmals Probleme überhaupt finden, die mir z.B. der Compiler verbockt hat.
Oh Oh, klingt jetzt negativ, ist aber nicht neagtiv gemeint....


Du weist aber schon, das z.B. es im C99 Standard 190 Fälle gibt, wo nicht eindeutig festgelegt ist wie der Compiler eine C-Anweisung zu übersetzen hat.
Wobei generell solcher Code möglicht vermieden werden sollte.

---

Nicht sollte, sie sind verboten, genauso wie die Division durch Null. In vernünftig geschriebenem und strukturiertem Code kommen diese Fälle aber nicht vor oder sie lassen sich ohne Not vermeiden.

Zitat:

---

Ich würd schon gerne wissen was er daraus macht und das steht nunmal im Assembler Listing.

---

Da kann man natürlich neugierig sein, aber die Erkenntnis hilft auch nicht weiter. Undefiniert heißt undefiniert. Beim nächsten Compilerlauf mit etwas geändertem Code oder bei der nächsten Compilerversion kann das Ergebnis komplett anders sein. Auch ein Absturz gehört zu den Dingen, die passieren können. Genau das gleiche was passiert, wenn man versucht durch Null zu teilen.

Zitat:

---

Stell Dir vor, dein Code funktioniert einwandfrei in der Optimierunsgsstufe O-0 also ohne Optimierungen
nun stellst Du eine andere Optimierungsstufe ein und plötzlich geht der Code nicht mehr.
Was macht Du dann ?

---

Dann habe ich einen oder mehrere Fehler im Code und muß diese beseitigen. Eine der ersten Sachen, die ein fremder Tester mit dem Code macht, ist die Optimierungsstufe ändern. Wenn er nicht in jeder Stufe geht, ist er kaputt und muß korrigiert werden. Und den Fehler findet man, ohne in das Assemblerlisting zu schauen.

Zitat:

---

Das heisst jetzt nicht dass der C Compiler Mist gebaut hat, sondern dass ich ihm anscheinend nicht richtig klar gemacht habe was er zu tun sollte....

---

Das gerade ist die Herausforderung.

Alle Programmierer, die ich kenne und die ihr Geld mit Programmieren verdienen, können kein Assembler und haben ein Listing höchstens mal aus Zufall gesehen. Dafür läuft ihr Code aber auf jedem Prozessor, für den es einen C-Compiler gibt. Ich benutze auch den gleichen C-Code für PIC16 und PIC24. Und wenn ich mal einen Algorithmus schneller und komfortabler testen will, teste ich ihn auf dem PC mit nem x86 oder dem Raspberry mit einem ARM.

MfG Klebwax

Vorurteil: Assembler?

http://www.bixoft.nl/deutsch/why.htm

Gruß

Zitat:

---

Alle Programmierer, die ich kenne und die ihr Geld mit Programmieren verdienen, können kein Assembler und haben ein Listing höchstens mal aus Zufall gesehen. Dafür läuft ihr Code aber auf jedem Prozessor, für den es einen C-Compiler gibt. Ich benutze auch den gleichen C-Code für PIC16 und PIC24. Und wenn ich mal einen Algorithmus schneller und komfortabler testen will, teste ich ihn auf dem PC mit nem x86 oder dem Raspberry mit einem ARM.

---

Ich muss zugeben, dass mir Assembler die Denkerfalten auf die Stirn massiv zusammenschiebt und ein Programm (komplett) in Assembler oder Basic zu verfassen tatsächlich nicht mehr in meinen Fähigkeitsspektrum liegt.

Aber Hochsprachen sollen die Programme ja (Sourcemäßig) weit strukturierter gestalten als man es mit Assembler jemals könnte. Der Apollo Computer hatte nicht mehr Leistung als mein alter Casio 9850 Grafik Taschenrechner und die Entwicklung der Software entstammt einem ziemlich großem Entwicklerteam dass Jahre daran Entwickelt hat. Heutzutage darf die Software in einer Entwicklung bis zur ersten Produktreife doch nicht mehr als 1 Jahr betragen oder Projekte werden zusammengestrichen (ist zumindest mein Eindruck den ich durch Erfahrungen bisher so gesammelt habe) ... und obendrauf kommt, dass man meist nur noch als Einzel-Entwickler an Software arbeitet oder nur in sehr kleinen Teams.

Außerdem kann ich mir kaum vorstellen, dass sich HEUTE oder auch schon direkt nach dem Ausscheiden der betreffenden Entwickler aus dem Apollo Programm irgend jemand in absehbarer Zeit hätte in das Programm alleine einarbeiten können. (Ja mir ist schon klar dass der Kram heute schon von 3ten komplett zerlegt worden ist, aber mit welcher Manpower? Im industriellen Umfeld wäre sowas für einzelne sicherlich eine Monsteraufgabe ein Assembler Programm zu verstehen auch wenn es noch so gut dokumentiert wird ... Ausnahme sind Programme die durch die Doku schon implizit in Hochsprache geschrieben sind)

Aber wenn man nur ein halbes Jahr hat ein Produkt zu Entwickeln und dann auch noch ständig kleine Patches und Erweiterungen hinzufügt, wird die lesbarkeit der Doku auch nicht besser. Ich habe schon Code von Vorgängern lesen und verstehen müssen (ohne viel Doku, nur mit Protokollspezifikationen) um Probleme zu beheben oder neue Funktionen nachzupflegen. In einer Hochsprache geht sowas meist schnell von der Hand auch wenn der Code fast undokumentiert ist. In Assembler muss man ja erstmal erkennen dass man da eine Schleife vor sich hat (einfach) ... und dann die ganzen Abbruchbedingungen und Verzweigungen erfassen (mäßig leicht und viel zu notieren und zu verfolgen) ... aber wenn dann noch lustige Aktionen hinzukommen, die gewisse Seiteneffekte ausnutzen um effizienter zu sein wirds kompliziert und zeitaufwendig.


..... So ... sorry fürs Off-Topic gehen aber back to Topic


Vielleicht interpretiert er in Verbindung mit dem Code die Reihenfolge etwas anders!
Wenn ich z.B. eine kopfgesteuerte Schleife ala "while(<condition>)" schreibe, wird im Assembler daraus meist semantisch gesagt eine Fußgesteuerte Schleife, bei der die eigentliche Prüfbedingung als Branch nach dem zu schleifendem Code ausgeführt und vorher nur mit einem goto geskippt. In deinem Fall könnte das schlicht eine "Variante" sein in der der Compiler deine While Schleife konstruiert und der Disassembler versucht den Source halt den Assembler Befehlen, die in einer anderen Reihenfolge im Code stehen, anzupassen. Da aber die Adresse der Instruktion gegeben ist würde ich sagen dass es nicht unbedingt ein Fehler, sondern eher eine Umständliche Darstellung ist, wenn man gerade versucht das Programm sequentiell zu verstehen und dabei nicht jede Adresse von jeder Instruktion immer kontrollieren möchte.

Gibt es bei dem Tool vielleicht eine Option die es erlaubt die Interpretation des Disassembly zu konfigurieren?



-------------

Edit zu Aretobor:

Die Seite ist aber auch sehr pro-assembler geschrieben. Da werden für andere Sprachen auch viele Teufel an die Wand gemalt wie man es für Assembler auf der anderen Seite tut ... man sollte auch so etwas immer mit einer Prise Salz lesen.

Edit 2 als Kompromiss: Wenn man Assembler lange genug benutzt und gewisse Strukturen schon aus dem FF kennt (genau so in den ach so komplizierten Hochsprachen) fällt einem das Argumentieren für die jeweilige Seite auch immer recht einfach. aber ich würde zumindest imm Kompromiss sagen, dass der C Schreiber ein undokumentiertes C Programm mindestens genau so schnell versteht wie ein Assembler Schreiber ein undokumnetiertes Assembly :) Alles ein Frage der Übung und Erfahrung.

Vorurteil!!

Zitat:

---

Vorurteil!!

---

Könnte ich genauso zu deinem Link schreiben

ich haeb ein paar Edits reingemacht weil wir zeitgleich am Tippen waren ... ich bitte um Korrektur

Die Gedanken sind frei, und wir sind Gefangene unserer Erfahrungen!

Gruß
ARetobor