Verfasst am: Sa März 27, 2010 4:33 pm Titel: Problem der CCASM "Debug-Option" in der Workbench
Hallo Dierk und Tappi,
vor einiger Zeit hatten ich und Homelink vorgeschlagen, dass es doch besser wäre, wenn der "Zielcode" einer CCASM-Kompilation in dem Map-Reiter dargestellt wird, damit der Benutzer, wenn er eine ASM-Datei in eine BIN-Datei kompiliert, gleich sieht, was der Compiler mit seinem Code wirklich anstellt und die Sprungadressen in den Pages kennt.
Unsere Idee war: Warum nicht automatisch den Debug-Code bereitstellen, der mit der -Debug-Option in einem DAT-File erzeugt wird? Dierk hat hier schnell unseren Wunsch entsprochen und hat versucht diese Infos einzubauen.
Mit neuster Version 2.4. Beta 4 habe ich festgestellt, dass der Debug-Code nicht für alle 256 Bytes dargestellt wird, denn die Debugging-Liste hört bei Zeile 23 auf. Etwas unschön, wenn man eine höhere Einsprungadresse ermitteln möchte.
@Dierk: ist es möglich, das Listing zu komplettieren? Danke im Voraus!
Mit der Implementierung ist allerdings nun die Compile-Option für ASM-Files nicht mehr funktional. Werden ASM-Dateien geöffnet und mit dem Compile-Button CCASM aufgerufen, wird nicht mehr der Code compiliert und in BIN umgewandelt.
Das gleiche Problem hat man übrigens auch, wenn man CCASM in einer Kommandozeile alleine ohne Workbench ausführt.
Ich vermute, dass Dierk den Compiler-Aufruf in der Workbench schlicht um die Option
"-debug" erweitert hat, denn eine Option ist normalerweise "optional" zu verstehen.
@Tappi und Dierk: Hier wäre meine Bitte an Stefan, die CCASM Option -Debug doch auch optional im wahrsten Sinne des Wortes zu behandeln und mit Debug-Option gleichzeitig zu BIN zu kompilieren. Was nützt einem ein korrektes Debug-Listing, wenn ein altes nicht korrektes BIN-File irrtümlich in ein bpp eingebunden wird.
@Tappi und Dierk: Wenn Stefan dies nicht ändern würde/kann, so muss Dierk 2x compilieren, einmal ohne und einmal mit Debug-Option, damit das Debuglisting im Map-Datei-Reiter zum BIN-Code und dem Compilierergebnis passt und korrekt eingebunden werden kann. Und natürlich im Falle eines CCASM-Updates bitte die Dokumentation entsprechend anpassen - eh klar
Ich bitte um Rückmeldung, wenn es Unklarheiten geben sollte oder ein Update vorliegt.
Danke euch schon mal im Voraus!
Mit neuster Version 2.4. Beta 4 habe ich festgestellt, dass der Debug-Code nicht für alle 256 Bytes dargestellt wird, denn die Debugging-Liste hört bei Zeile 23 auf.
Seltsam, dass das so ist. Wie ich gerade gesehen habe, stehen in Spalte "Bin" die Zeichen in binärer Schreibform, eventuell liegt es daran. Mein Vorschlag wäre, dass Stefan beim Schreiben dieser Spalte eine Abfrage macht, ob das Zeichen > 31 und <127 ist.
Zitat:
Ich vermute, dass Dierk den Compiler-Aufruf in der Workbench schlicht um die Option
"-debug" erweitert hat, denn eine Option ist normalerweise "optional" zu verstehen.
Oh, ja das ist natürlich blöd, das wußte ich nicht. _________________
„Das, wobei unsere Berechnungen versagen, nennen wir Zufall.”
nach dem Beitrag von toolchecker habe ich versucht das Problem (mit Workbench++ 2.3) nachzuvollziehen.
Das heißt, wenn ich eine "Debug-Datei" erzeugen will muss ich CCASM aus dem DOS-Fenster aufrufen. Dabei gibt es die Alternative mit und ohne "-debug" und es werden unterschiedliche Files erzeugt: ohne Debug .log, .map, .inc.bas und .bin, mit Debug nur .log und .dat.
Vorschlag um die Handhabung wesentlich zu vereinfachen: die "Option" -debug kann grundsätzlich entfallen und die Datei *.DAT (Debug) wird immer erzeugt, parallel zu den Datein *.BIN, *.map und *.inc-bas.
Danke für Dein Feedback. Was den Debugging-List-Abbruch in "Zeile 23", betrifft so ist das wohl rein zufällig, weil mein Debug-Code in Zeile 23 eine "0"-Byte ausgibt. Evtl. liegt es daran, dass Du nach einer EOF-Signatur suchst und daher die Ausgabe abgeschnitten wird? (Listing siehe unten)
Ich bin wie Homelink der Meinung, dass die "Debug"-Option eigentlich keine Option ist, sondern in der Welt der verschlüsselten BIN-Dateien und autorisierten Maschinencodes nebst lückenhafter CCASM-Dokumentation "mandatory" ist, um zu erkennen, was der Compiler überhaupt ausgibt, denn der versierte Assembler-Nutzer kennt mehr als nur die erste Standard-Einsprung-Adresse.
Mein Bugfix-Vorschlag würde daher lauten:
EOF-Signature Bug-Fix in Map-Listing @ Dierk
CCASM Debug-Option-Output als Standard auch ohne "-debug" @ Tappi
Danke für Eure konstruktive Unterstützung!
Grüße vom Toolchecker
Sie können keine Beiträge in dieses Forum schreiben. Sie können auf Beiträge in diesem Forum nicht antworten. Sie können Ihre Beiträge in diesem Forum nicht bearbeiten. Sie können Ihre Beiträge in diesem Forum nicht löschen. Sie können an Umfragen in diesem Forum nicht mitmachen.