........Fehler ist bisher immer viel Handarbeit nach dem Decompile notwendig......
Davon kann ich ein Lied singen. Den ganzen Tag, bis spät in die Nacht war ich auf Bug Hunt. Auch habe ich zahlreich Bugs erlegt, und es hat sich auch gelohnt, um die v1.9 zu erstellen.
Achja, wenn man den Decompilierungbug aus Datei-X entfernt hat, bekommt man in vorher fehlerfrei decompilierter Datei-Y eine Decompilierungbug zu sehen.
Die Spaces , die du entdeckt hast, dienen der übersichtlichkeit, wenn ich das Basic-Programm mit Notepad++ bearbeiten möchte.
Würdest Du eventuell das UDL File von Notepad für den C64 zur Verfügung stellen ?
Dankeschön
Dankeschön... das schaue ich mir mal an.
Kann man damit auch den Blitz-Compiler selber decompilieren? Bekomme ich nämlich nicht hin, er bricht immer in Zeile 1860 ab...
Plum's Blitz lässt sich z.B. mit den Decompiler 3.1 / 3.2 von Hokuto Force decompilieren. Aber auch andere, ältere Versionen können das.
Ich meine ich hätte das mit einer älteren Version von Stephans Decompiler auch problemlos geschafft.
Welche Blitz Compiler Version nutzt du denn ? Skyles Blitz oder Plum's oder was anderes ?
Skyles Blitz!
Die Version v2.0 ist fertig. Hinzugekommen ist der Autoerkennungsmodus. Diesen Bitte nur nutzen, wenn das Compilat ML-Code enthält oder man zu faul ist, den manuellen Modus zu nutzen.
Der Automodus benötigt im Pass 1 bedeutend mehr Zeit für das Scannen, um festzustellen um welchen Compiler es sich handelt und ob ML-Code vorhanden ist. Es wird auch die erste und die
letzte Zeile weggelassen, die immer CLR und END beinhalten, weil diese vom Compiler erstellt werden.
Achja, wenn im ML-Code ein $4F-Byte vorkommt, funktioniert der Scanner nicht. Es funktioniert dann kein Decompiler, der ML-Code extrahieren kann. Um das zu realisieren muss ich eine aufwendige
Prüfroutine, die testet ob ML-Code oder P-Code vorhanden ist, einbauen. Das aber in einer späteren Version.
Wird der ML-Code vom Compiler nicht immer zwischen P-Code und den Variablen gespeichert ?
Wenn doch, dann steht die Adresse ab wo die Variablen beginnen, doch vorne im File bzw. hinter dem Runtime Code.
Dann brauchst Du doch eigentlich nur von Ende P-Code bis Anfang Variablen den Bereich auslesen, merken, speichern.
Oder vertue ich mich da jetzt ?
Ja, da schätzt du falsch. Der Scanner sucht nach dem letzten $4F. Wenn nun im ML-Code ein $4F vorkommt, interpretiert der Decompiler das als P-Code-Ende.
Es ist fast unmöglich bei soetwas zwischen P-Code und ML-Code zu unterscheiden. Du kannst es selbst testen, indem du z.B. den Austrospeed Compiler nutzt. Füge mitten im ML-Code ein $4F ein
und speichere das dann ab. Nun decompiliere das mit dem Decompiler 3.1 / 3.2 von Hokuto Force.
Es stehen am Anfang die Vektoren, wo die Variablen beginnen, aber nicht wo der P-Code aufhört.
Was ist denn das für ML-Code, der da so rumhangt? Die Runtime ja nicht, oder? Sonst müsste das ja immer ein Problem sein.
Du kannst den BASIC Code mit einer anhängenden ML Datei durch den Compiler verwursten lassen. D.h. BASIC File und ML File werden vor dem Compile Vorgang miteinander verlinkt in eine neue Datei (manuell natürlich...).
Du kannst den BASIC Code mit einer anhängenden ML Datei durch den Compiler verwursten lassen. D.h. BASIC File und ML File werden vor dem Compile Vorgang miteinander verlinkt in eine neue Datei (manuell natürlich...).
Sorry, wenn ich blöd frage...aber wo ist da der Nutzen? Dann landet das doch an ganz anderen Adressen als zuvor!?
Sorry, wenn ich blöd frage...aber wo ist da der Nutzen? Dann landet das doch an ganz anderen Adressen als zuvor!?
Maschinencode kann man auch ganz relokatibel schreiben.
Man darf halt nur relative Sprünge benutzen.
Sorry, wenn ich blöd frage...aber wo ist da der Nutzen? Dann landet das doch an ganz anderen Adressen als zuvor!?
Schau mal hier Post 196: Heute so compiliert
Maschinencode kann man auch ganz relokatibel schreiben.
Man darf halt nur relative Sprünge benutzen.
Ja, schon klar. Aber das will man doch nicht...
Ja, schon klar. Aber das will man doch nicht...
Naja, ob man es will oder nicht entscheidet die Situation.
Relokatible Programmierung hat Vor- und Nachteile.
Je nach dem was man gerade benötigt, überwiegt halt das eine oder andere.
Wenn ich genau weiß wie der Compiler arbeitet, kann ich ja den M-Code danach noch einfügen/modifizieren.
Wenn nicht, dann muss er zur Compile Zeit schon passen.
Und zwar für jede Adresse wo er dann läuft ...
