20. August 2004
Autor: Dietmar Harlos
Der Decompiler kann DAT-Dateien vom C-Control/BASIC-Compiler für DOS oder vom C-Control/PLUS-Compiler temporär angelegte CODE.TXT-Dateien lesen oder eine direkte Verbindung zur C-Control aufnehmen und das im Speicher der C-Control stehende Programm über die RS232-Schnittstelle einlesen und verarbeiten. Letzteres sollte sowohl unter reinem DOS, als auch in der DOS-Box und im MS-DOS-Modus aller Windows-Versionen funktionieren.
Unterstützt werden die C-Control-Mikrokontroller der Version 1.1 in allen Varianten (M-Unit, Main-Unit und Station). Der vom Decompiler erstellte Quellcode ist zur Version 1.7 des C-Control/BASIC-Compilers kompatibel. Unter Windows wird die Version 1.33 der C-Control/BASIC-Entwicklungsumgebung benötigt.
Übersetzt werden die Demo-Programme folgendermaßen. Unter Windows wird in das Verzeichnis des Decompilers gewechselt und das beiliegende DEMO.PIF gestartet. Eventuell wird die Endung "PIF" nicht angezeigt, sondern nur "DEMO". Nach dem Starten öffnet sich ein Fenster mit MS-DOS-Logo und einigen Meldungen des Decompilers. Der Dekompiliervorgang ist bereits abgeschlossen und im Verzeichnis wurde eine neue Datei namens DEMO1.BAX erstellt. Diese enthält den aus der DEMO1.DAT-Datei erstellten Quellcode und kann nun in der C-Control/BASIC-Entwicklungsumgebung geladen, untersucht und kompiliert werden.
Um weitere C-Control-Programme zu übersetzen kann die DEMO.PIF-Datei editiert werden. Fortgeschrittene Anwender werden den Decompiler sicher lieber am sogenannten DOS-Prompt bedienen wollen. Um die PIF-Datei zu editieren, wird die rechte Maustaste gedrückt, während die Datei markiert ist. Im nun erscheinenden Kontextmenü wählt man 'Eigenschaften' und es sollte sich ein neues Fenster mit den Reitern 'Allgemein', 'Programm', 'Schriftart', usw. öffnen. Je nach Windows-Version sieht dieses Fenster etwas anders aus. Auf dem Reiter 'Programm' befindet sich die entscheidende 'Befehlszeile'. Hier ist der DOS-Befehl eingetragen, der beim Starten der PIF-Datei ausgeführt wird. Er kann beispielsweise in "CCTOKBAS.EXE demo2.dat" geändert und das Fenster mit 'Ok' geschlossen werden. Beim nächsten Starten der PIF-Datei wird nun das zweite Beispiel übersetzt.
Die vom Decompiler erstellte Ausgabedatei hat die Endung "BAX", um Verwechslungen mit einer eventuell vorhandenen BASIC-Datei aus dem Wege zu gehen. Im Bedarfsfall kann der Anwender diese Endung später in "BAS" umbenennen. Zusätzlich legt der Decompiler eine Datei namens CCTOKBAS.BIN an. Diese enthält das zu übersetzende Programm im Binärcode, also aufgebaut aus den verschiedenen C-Control-Tokenbefehlen wie sie der Decompiler als Eingabe erhält, und kann vom fortgeschrittenen Anwender mit einem Hexeditor untersucht werden.
Wenn man eine vom C-Control/BASIC-Compiler erstellte DAT-Datei übersetzen möchte, muß als Befehlszeile "CCTOKBAS.EXE datei.dat" übergeben werden. Wenn man dagegen das Programm, das sich augenblicklich im Speicher der C-Control befindet, übersetzen möchte, gibt man "CCTOKBAS.EXE 2" ein, wenn die C-Control über die serielle Schnittstelle COM2 mit dem PC verbunden ist. Falls es sich bei dem Programm in der C-Control um ein CCPLUS-Programm handelt, muß unbedingt der Parameter "-autoccplus" angehängt werden. In diesem Fall also "CCTOKBAS.EXE 2 -autoccplus".
Wird der Decompiler unter neueren Windows-Versionen (XP, 2000) eingesetzt, können auf einigen Computern Probleme bei der Übertragung über die serielle Schnittstelle auftreten. Um auch in diesen Fällen eine Datenübertragung zu ermöglichen, habe ich dem ZIP-Archiv ein Programm namens CCUPLWIN beigelegt. Es wird mittels "CCUPLWIN.EXE 2" aufgerufen, falls die C-Control über COM2 verbunden ist, und legt die empfangenen Daten in der Datei CCUPLOAD.DAT ab. Diese DAT-Datei kann anschließend, wie oben gezeigt, als Eingabe für den Decompiler dienen. Falls es sich bei dem Programm in der C-Control um ein CCPLUS-Programm handelt, darf das "-autoccplus" beim Aufruf des Decompilers nicht vergessen werden.
Eine vom C-Control/PLUS-Compiler temporär abgelegte CODE.TXT-Datei
wird übersetzt, indem zunächst die CODE.TXT-Datei in das Verzeichnis
des
Decompilers kopiert und anschließend "CCTOKBAS.EXE code.txt -autoccplus"
gestartet wird. Die CODE.TXT-Datei befindet sich im gleichen Verzeichnis
wie die CPF-Datei des Programms, das zur Zeit in der PLUS-Entwicklungsumgebung
bearbeitet wird. Jeder Kompiliervorgang aktualisiert die CODE.TXT-Datei.
Auf diese Weise wurden das Ursprungskompilat, das durch einen verloren gegangenen Quellcode oder durch ein CCPLUS-Programm erzeugt wurde, mit dem aus dem neuerstellten Quellcode generierten Kompilat verglichen. Wenn beide gleich sind, ist der Quellcode fehlerfrei. Diese einfache Kontrollmöglichkeit ist bei mittels Autoccplus-Funktion (siehe nächstes Kapitel) dekompilierten Programmen leider nicht mehr möglich.
Die Autoccplus-Funktion sorgt dafür, daß zu BASIC inkompatible IF..THEN-Kombinationen automatisch kompatibel gemacht werden. Außerdem wird das Stackproblem durch einen effizienten Workaround behoben. Leider werden die veränderten IFs etwas langsamer ausgeführt und, was schwerer wiegt, es werden andere Tokenbefehle benutzt. Das heißt, die Programme unterscheiden sich nun in ihrer tokensierten Form und es kann nicht mehr durch einen einfachen Binärvergleich kontrolliert werden, ob die Dekompilierung fehlerfrei durchgeführt wurde. Aus diesem Grund sollte der neuerstellte BASIC-Quellcode kompiliert, in die C-Control übertragen und besonders gründlich ausgetestet werden.
Leider ist auch die Autoccplus-Funktion kein Garant dafür, daß sinnvoller, kompilierbarer CCBASIC-Code erstellt wird. Es können beispielsweise Zeilen entstehen, die zu lang für den BASIC-Compiler sind. Diese müssen manuell aufgeteilt werden. Befehle wie "PRINT INPUT#" werden von CCPLUS (und von verschiedenen CCBASIC-Erweiterungen) verwendet und können daher auch in der Übersetzung auftauchen. Hier ist eine Zerlegung in "INPUT# var : PRINT var" erforderlich. Im Einzelfall ist ein erfahrener Anwender erforderlich, der die notwendigen Anpassungen vornimmt. Deshalb gebe ich an dieser Stelle keine umfangreichen Konvertierungstips, sondern möchte alle registrierten Anwender des Decompilers bitten, mich per E-mail anzuschreiben, falls der erstellte Quellcode nicht kompiliert werden kann. Wie unten angegeben ist diese Hilfe bei geringem Aufwand kostenlos.
Mit dem Decompiler kann man dem CCPLUS-Kompiler übrigens sehr gut "in die Karten schauen". Das ist mitunter äußerst nützlich, denn über Fehler in diesem Compiler ist bisher kaum etwas bekannt. Ein mit dem Decompiler aufgedeckter Fehler in der Dokumentation ist, daß CCPLUS bei Verwendung des LCDs nicht nur die letzten 2, sondern die letzten 4 Byte des Variablenspeichers belegt.
Da in der Regel bekannt ist, an welche Sensoren und Aktoren die C-Control elektrisch angeschlossen ist, sollten zunächst die verschiedenen Ports sinnvoll benannt werden. Dann wird die Funktion der Subroutinen erkundet und deren Label sinnvoll umbenannt. Zum Schluß folgen die Variablen. Zum Umbenennen ist übrigens die "Alles ersetzen"-Funktion in der C-Control/BASIC-Entwicklungsumgebung äußerst nützlich. CCPLUS verwenden für das LCD, die Tastatur, die Datenaufzeichnung, etc. immer die gleichen Programm-Module, die allerdings bei jedem Programm an anderer Stelle stehen können. Erst nach dieser Fleißarbeit sollten die gewünschten Veränderungen und Erweiterungen am Programm in Angriff genommen werden.
Der Decompiler fügt automatisch an jedes kompilierte Programm ein END-Token (255) an. Bei Tabellen, die ganz am Ende des Programms stehen, führt das häufig dazu, daß ein Eintrag zuviel in der Tabelle steht.
Manche CCBASIC-Befehle bestehen aus mehreren Tokenbefehlen. Es handelt sich im wesentlichen um die Befehlskombinationen IF..THEN, IF..THEN..ELSE, BEEP, WAIT, FOR..NEXT und ON..GOTO/GOSUB. Der Decompiler versucht solche Befehlskombinationen zu erkennen und durch die entsprechenden BASIC-Befehle zu ersetzen. In fehlerhaften Programmen ist das nicht immer möglich, so daß eventuell von Hand nachgebessert werden muß.
|
|
Unbekannte IF..THEN-Kombination | Diese Fehlermeldung tritt in Programmen, die in CCPLUS erstellt wurden, häufig auf und ist durch Aktivieren der Autoccplus-Funktion zu beheben. Die Autoccplus-Funktion sollte nur in Programmen die in CCPLUS erstellt wurden aktiviert werden. |
In dieser Zeile tritt ein Stack Underflow (STACKUVL) auf | Diese Fehlermeldung tritt in Programmen, die in CCPLUS erstellt wurden, häufig auf und ist durch Aktivieren der Autoccplus-Funktion zu beheben. Bei aktiver Autoccplus-Funktion kann diese Meldung ignoriert werden. |
Durch Autoccplus kompatibel gemachte IF..THEN-Kombination | Die Autoccplus-Funktion hat eine "unbekannte IF..THEN-Kombination" automatisch zu CCBASIC kompatibel gemacht. |
Durch Autoccplus eingefuegt | Kennzeichnet den von der Autoccplus-Funktion verwendeten Workaround zur Behebung des Stack-Underflow-Problems in CCPLUS-Programmen. |
PUSH: Der Ausdruck oder Wert ... verursacht einen Stack Overflow, ... geht verloren. | Diese Warnung kann auf einen Fehler im ursprünglichen Programm hinweisen. Die Ressourcen der C-Control, die für Berechnungen verwendet werden, sind erschöpft und ein Wert oder Ausdruck geht verloren. Es sollte kontrolliert werden, ob die Berechnung in der folgenden Quellcodezeile von der C-Control fehlerfrei ausgeführt wird. |
Unbekannte FOR..NEXT-Kombination | Diese Fehlermeldungen sollten niemals auftreten. Vermutlich ist das zu dekompilierende Programm fehlerhaft oder es wurde eine Tabelle als Code ausgewertet, da das zugehörige LOOKTAB nicht gefunden werden konnte. Es ist auch denkbar, daß das zugrundeliegende Programm unter Verwendung von Programmiertricks erstellt wurde, die kein Äquivalent in der Standard-CCBASIC-Syntax besitzen. Wer bei der Behebung dieser Fehler Unterstützung benötigt, kann mich per E-mail anschreiben. |
STACKRESET: ... wurde auf den Stack geschoben, aber nicht entfernt | |
Unbekannte Befehlskombination | |
Ungueltige Tokenkombination | |
Ungueltiges Token |
Zusätzlich gibt es nun eine Debug-Option, mit der der Decompiler veranlaßt werden kann, die übersetzten Token als Kommentar mit in die Ausgabedatei zu übernehmen. Wenn diese Option aktiv ist, werden darüberhinaus keine Tokenbefehle zusammengezogen. Unter Zuhilfenahme des Binärdumps der Token (CCTOKBAS.BIN) können fehlerhafte Tokenkombinationen so leicht untersucht werden, da zu jedem Tokenbefehl die Adresse (bzw. der Offset im Binärdump) erscheint.
Vom C-Control/PLUS-Compiler erstellte temporäre CODE.TXT-Dateien und Token im eigenen Binärformat (CCTOKBAS.BIN) können nun direkt eingelesen werden.
Bis zur Version 2.02 traten einige Bugs auf, die nun behoben sind: PRINT-mit-String-Anweisungen, die von CCTOKBAS verwendete Schlüsselwörter im String enthalten, konnten zu Fehlinterpretationen führen. PRINT mit Parameter und Semikolon gefolgt von PRINT ohne Parameter wurde immer zusammengezogen. Das führte zum Verschwinden von Labels, die zwischen diesen beiden Befehlen standen. Die Extension der Namen von BIN-Dateien wurde casesensitiv ausgewertet. RETURN mit Parameter wird jetzt erkannt und entsprechend ausgegeben.
Bis Version 3.0 gab es Probleme mit IF-Abfragen, die aus mehreren Tokenbefehlen bestehende CCBASIC-Befehle im Anweisungsteil enthielten. Beispiele hierfür sind unter anderem "IF ... THEN WAIT ..." oder "IF ... THEN FOR ... TO ...". Solche Konstrukte erzeugten nicht kompilierbaren Zwischencode. In der Version 3.1 sind diese Fehler beseitigt, so daß ab jetzt jede gültige Standard-CCBASIC-Syntax anstandslos übersetzt werden sollte.
Mehr Übersichtlichkeit im DOS-Fenster wurde dadurch erreicht, daß Pfadnamen nun, falls möglich, unterdrückt werden. Auch entspricht die Numerierung in den Variablen- und Portnamen jetzt der Define-mit-Index-Konvention. Es können jetzt praktisch beliebig lange Programme verarbeitet werden. In Warn- und Fehlermeldungen werden, soweit möglich, immer die zugehörigen Adressen angegeben. Darüber hinaus wurde diese Dokumentation erheblich erweitert und verbessert.
Da einige Anwender mit neueren Windows-Versionen Schwierigkeiten bei der Kommunikation mit der C-Control über die serielle Schnittstelle hatten, habe ich ein Extra-Programm für die Datenübertragung unter Windows beigelegt. Es handelt sich um ein Console-Programm für Win32. Ich bin gespannt, ob damit weniger Probleme auftreten, als mit dem eingebauten Terminalmodul des Decompilers. Außerdem habe ich die Abfrage des Versionstrings der C-Control mit Hinblick auf die neue C-Control-Generation modifiziert.
In der Demoversion werden nun 150 statt 100 Zeilen ausgegeben.
Der Decompiler unterstützt keine langen Dateinamen (LFN), sondern wie der Compiler von Conrad Electronic nur 8.3-Dateinamen (SFN).
Weitgehend ungetestet ist der Decompiler bisher im Zusammenspiel mit der neuen C-Control-1-Generation (Version 1.2, 2.0 und Micro). Die neuen Features der Controller werden über eine Umleitung der seriellen Schnittstelle angesprochen, weshalb der Decompiler diese als normale PRINT-, GET- und PUT-Befehle erkennt und, soweit ich feststellen konnte, sinnvollen Quellcode erzeugt.
Es gibt eine Voll- und eine Freeware-Version des Decompilers. Die Freeware-Version ist gegenüber der Vollversion eingeschränkt, da sie nur die ersten 150 Zeilen des erzeugten Quelltextes ausgibt.
Viel Spaß beim C-Controllern!
Dietmar Harlos.