Disassembler Listing falsch ?

**Siro** · 10.03.2019, 07:57

Moin Klebwax,

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....

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

**Klebwax** · 11.03.2019, 06:57

Zitat von Siro

Moin Klebwax,

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.

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.

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.

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

**ARetobor** · 11.03.2019, 08:41

Vorurteil: Assembler?

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

Gruß

**Ceos** · 11.03.2019, 08:47

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.