Fortschrittlich: Turbo C 2.0 und sein Source-Level-Debugger
Als Borland vor einigen Monaten auf dem ST-Markt in Erscheinung trat, waren viele überrascht. Nicht Turbo Pascal, das immer wieder angekündigt worden war und bis heute nicht erschienen ist, war nun zu erwerben, sondern Turbo C wurde Borlands erstes Zugpferd. Die Kunden stürzten sich geradezu auf den neuen mit ANSI-Standard ausgerüsteten C-Compiler. War es bisher der Megamax-Compiler, der den Markt beherrschte, so gab es nun auf dem Markt zwei Compiler, die konkurrierten. Während es von Megamax schon länger die neue Laser-C-Version gibt, kam Mitte letzten Jahres der erste Source-Level-Debugger für den ST auf den Markt, der Laser-C stark aufwertete. Jetzt schlägt Borland mit Turbo 2.0 zurück, das als Unterstützung ebenfalls einen Source-Level-Debugger zur Seite bekommt.
Borland hat es schon schwer. Nicht nur, daß sie sich mit der Konkurrenz auf dem ATARI messen müssen, auch die Software auf dem IBM (und dessen kompatiblen) ist ein Vorbild. Dies ist sicherlich eine schwierige Aufgabe. Ich vermute nämlich, daß Borland immer die Entwicklung auf dem IBM-Markt forcieren wird. Schade sicherlich für Turbo Pascal-Anhänger, die gerne auch Turbo Pascal auf dem ATARI sehen würden. Aber dies ist ein anderes Thema und vielleicht auch noch nicht abgeschlossen - Borland ist immer für Überraschungen gut. Beschäftigen wir uns also etwas eingehender mit dem neuen Turbo C.
Das neue Turbo C 2.0
Wenn man ehrlich ist, muß man zugeben, daß sich in Sachen Turbo C relativ wenig im Vergleich zum Turbo Debugger getan hat. So finde ich es schon fast etwas übertrieben, dieser Version eine um eins erhöhte Nummer zu geben, da dadurch normalerweise umfangreiche Änderungen angekündigt werden. Trotzdem sind auch diese hier erwähnenswert. Zunächst möchte ich den neuen Linker erwähnen, der in seiner neuen Gestalt nicht nur das allseits bekannte Digital Research-Format, sondern auch ein neues, von Borland definiertes Format linkt, welches von Turbo C erzeugt wird. Dieses Format ist so kompakt, daß sich ein separates Bibliotheksformat nicht lohnt. Das Link-Format ersetzt damit die übliche Bibliotheksstruktur, da der Linker sowieso nur die benötigten Dateien zum Hauptprogramm hinzufügt. Des weiteren fordert der ANSI-Standard die Mindestlänge eines Bezeichners von 32 Zeichen, die mit nur acht Zeichen bei bei Digital Researchs Link-Format nicht gegeben ist - Borland hat es sogar auf 255 Zeichen erweitert. Ab Turbo C 2.0 kann eine Kommando-Shell angegeben werden, die, aus der C-Shell heraus, ausführbar ist.
Vergeblich
Wer darauf gewartet hat, daß Turbo C 2.0 endlich einen Inline-Assembler enthält, hat vergeblich gewartet. Zugegeben, es gibt einen Makro-Assembler im Professional-Paket, aber für mich ist der nicht eingebaute Inline-As-sembler immer noch das größte Manko von Turbo C überhaupt (Portabilität kann man, wenn man unbedingt will, durch conditional defines erreichen). Daß diese Test-Autoren auch immer etwas zu meckern haben... Wahrscheinlich ist das o.g. Politik, denn auf MS-DOS-Rechnern gibt es sowas wie einen Inline-Assembler in Turbo C auch nicht!
Standardisierte Grafik
Als wohl umfangreichste Erweiterung des Turbo C kann man sicherlich die Grafikbibliothek nennen. Schon vor einigen Jahren von Borlands IBM-Programmierern aus der Taufe gehoben, stellt sich nun auch auf dem ST der BGI-Treiber (Borlands Graphic Interface) vor. Mit diesem Treiber ist es standardisiert möglich, Grafiken (Linien, Kreise, Füllmuster, Buchstaben usw.) auf dem Bildschirm auszugeben, wobei der Treiber für die gängigen Grafikkarten ausgelegt wird. Sicherlich könnte man einwenden, daß man dafür auf dem ATARI das VDI hat, was sicherlich richtig ist. Nur können Programme, die den BGI-Treiber nutzen, direkt auf den IBM portiert werden, wobei dies natürlich auch für den umgekehrten Fall (IBM -> ST) gilt. Auch die dafür definierten Vektorzeichensätze lassen sich vom ST auf den IBM (und umgekehrt) portieren. Den Umfang der Anwendung kann ich noch nicht abschätzen, es werden aber sicherlich einige Entwickler auf dem ST diese Tatsache begrüßen. Ein Vektor-Font-Editor wird nicht mitgeliefert und kann (soweit mir bekannt) auch nicht erworben werden, es sind aber zehn Zeichensätze vorhanden.
Flags
Natürlich ist Turbo C 2.0 ab sofort in der Lage, Debug-Informationen in den Code zu integrieren. Dazu gibt es die Y-Option beim Compiler und beim Linker. In der Shell ist (schon seit der Version 1.1) ein Menüpunkt vorhanden, der nach dem (eventuell nötigen) Compilieren automatisch den Debugger aufruft. Wer jetzt denkt, daß dabei automatisch das Y-Flag für Compiler und Linker gesetzt werden, hat weit gefehlt. Dadurch ist es mir nicht nur einmal passiert, daß ich mich nach geglücktem Compiler-Lauf im Debugger befand, der natürlich nichts besseres zu tun hatte, als eine Meldung auszugeben, der Code habe keine Debug-Information; selbst ein Compiler-Lauf, der mit Debug eingeleitet wurde, führt bei einem Link-Error trotzdem zum Aufruf des Debuggers...!?!? Ärgerlich ist auch, daß, wenn Flag-Einstellungen innerhalb der Shell geändert wurden (Beispiel: Y-Flag in Compiler und Linker eingeschaltet), die Make-Option dies nicht erkennt. Mit anderen Worten: Ist das Programm vorher schon einmal ohne Y-Einstellungen compiliert worden, weigert sich die Shell standhaft, mit MAKE neu zu compilieren. Sicherlich gibt es Fälle, bei denen man Debuggen will und Teile nicht mit Debug-Info versehen möchte - ich möchte aber behaupten, das sei der seltenere Fall. Ich hoffe, daß das automatische Setzen des Y-Flags bei DEBUG und das Erkennen von Änderungen von Optionen durch MAKE noch implementiert wird, denn die Shell soll ja Arbeit abnehmen! Man bedenke, daß man sonst eigentlich nicht viel an ihr aussetzen kann, denn fast alles läßt sich mit der Tastatur steuern (lobenswert!). Wenn da nicht der Editor wäre: Mir ist bewußt, daß ich ab diesem Moment alle GEM-Fans gegen mich habe, aber warum muß dieser Editor so langsam sein? Ich weiß, daß er ausschließlich mit GEM-Routinen programmiert ist und daher auf jeder Grafik laufen wird. Dies ist aber nur eine Vereinfachung der Programmierung von Borlands Seite. Ich als Anwender habe mit einem solchen Editor zu kämpfen. Ich gebe zu, daß man die unsaubere Programmierung übertreiben kann, aber trotzdem bin ich ein Anhänger kurzer Turn-Around-Zeiten, die mit diesem Editor auf gewisse Weise zunichte gemacht werden. Daß es auch anders geht, zeigen die Windows im Turbo-Debugger, die angenehm zu bedienen sind.
Turbo-Debugger
Womit wir beim Thema wären: Der Debugger ist in der Lage, alle Programme, die mit Turbo C geschrieben wurden, zu debuggen. Das heißt, daß er auch GEM-Programme debuggen kann, womit indirekt erwähnt ist, daß er das Original-GEM des ATARIs nicht verwenden darf. Deshalb wurden die entsprechenden Routinen nachprogrammiert und so müssen Sie auch im Debugger nicht auf Drop-Down-Menüs und Fenster verzichten. Im Gegenteil, alles funktioniert merklich schneller und trotzdem ist er lauffähig auf Großbildschirmen (dafür mag er die Farbgrafik überhaupt nicht). Wo bleibt die Konsequenz? Turbo Cs Editor wird wegen Grafik-Kompatibilität nicht schneller - und beim Debugger macht man es doch. Hoffen wir für Borland, daß es in Zukunft nicht allzu viele Grafikkarten unterschiedlicher Machart für den ST gibt: Ich bin jedenfalls begeistert von der Bedienerfreundlichkeit und Arbeitsweise des Turbo Debuggers. Daß man es hier nicht mit GEM zu tun hat, merkt man spätestens an der Tatsache, daß sich eine Menge Fenster öffnen lassen (beispielsweise sieben Fenster gleichzeitig, wie in Bild 1 zu sehen), auch wenn es die Übersichtlichkeit nicht unbedingt fördert. Dennoch hat man dadurch die Möglichkeit, seine Debugging-Informationen so darzustellen, wie man möchte.
Source-Level-Debugging
Bevor ich darauf eingehe, was Borlands jüngstes Kind so alles kann, möchte ich für alle, die noch nicht wissen, was ein Source-Level-Debugger ist, den Begriff kurz erläutern. Fehler in einem Programm hat sicherlich schon jeder gesucht. Die gängigste Methode dafür in Hochsprachen ist beispielsweise das Einfügen von Tastaturabfragen und Ausgaben von bestimmten Informationstexten oder auch Variablenwerten. Daß dies keine schöne Methode und auch alles andere als schnell ist, kann sicher jeder bestätigen, der schon so vorgegangen ist. Assembler-Programmierer kennen schon viel länger die Möglichkeiten, ein Programm schrittweise, (Single-Step) oder Teile eines Programmes bis zu einem Breakpoint (Haltemarkierung) abzuarbeiten. Dabei bietet der Debugger die Möglichkeit, Register oder Speicherbereiche darzustellen und diese auch zu ändern. Ein solches Debugger-Konzept für Hochsprache zu realisieren, ist natürlich nur mit einem vergleichsweise hohen Aufwand möglich. Trotzdem gibt es inzwischen auf vielen Rechnern solche Debugger, die es dem Programmierer ermöglichen, auf Quelltextebene (source-level) ein Programm in Einzelschritten oder bis zu einem Breakpoint zu bearbeiten und dabei Variablen zu untersuchen. Wichtig ist, daß der Debugger ‘standhafter’ ist als das eigentliche Programm, das heißt, daß der Debugger nicht unbedingt in Mitleidenschaft gezogen wird, wenn das zu debuggende Programm nicht das tut, was es eigentlich soll. Soviel zum Konzept, nun zur Praxis von Borlands Realisierung.
Schlaraffenland
Jemand, der noch nie mit einem Source-Level-Debugger gearbeitet hat, fühlt sich am Anfang wahrscheinlich wie erschlagen von der Funktionsvielfalt, die der Turbo Debugger zu bieten hat (siehe Bild 2). Dennoch wird es ihm relativ leicht gemacht, da erstens die von Turbo C bekannte Online-Hilfe auch für den Debugger erhältlich ist, und zweitens das Handbuch kaum einen Wunsch offen läßt. Das Handbuch zeichnet sich durch 160 Seiten, ein umfangreiches Inhaltsverzeichnis und einen ausreichendem Index aus. Gut ist, daß nicht nur das Programm selbst dokumentiert ist, sondern in einem Kapitel der Ablauf eines Debug-Laufs an einem Beispiel erklärt wird. Außerdem werden prinzipielle Vorgehensweisen beim Debuggen aufgezeigt. Wahrscheinlich ist das Handbuch wieder so umfangreich, daß viele es nicht lesen werden (Wie sagte schon mein Kollege J. Leonhard: “Real programmers don’t read handbooks”) - wie man es macht, ist es falsch. Das Handbuch verdient sicherlich ein Lob.
Untersuchung
Prinzipiell kan man behaupten, es ist alles da, was man so zum Debuggen braucht. Viele der Dinge, die ich im folgenden erkläre, können Sie in Bild 1 näher betrachten. Der Quelltext oder Assemblercode kann im Einzelschritt (Pfei I zeigt auf aktuellen Befehl) durchgegangen werden oder bis zu einem bestimmten Breakpoint (dicker Punkt im linken Teil des Quelltext- oder Assembler-Fensters). Dabei ist besonders erwähnenswert, daß man gleichzeitig in zwei verschiedenen Fenstern Assembler und Quelltext bearbeiten kann, obwohl sogar im Assembler-Fenster die Quelltextzeilen mit in den Assembler-Text ‘eingestreut’ werden. Fast selbstverständlich erscheint da schon die Tatsache, daß man alle Breakpoints übersichtlich auflisten und sie dabei auch abhängig von bestimmten Bedingungen setzen kann. Dadurch muß also nicht immer an einer bestimmten Stelle angehalten werden, sondern beispielsweise nur beim lOten Mal oder dann, wenn sich eine bestimmte Speicherstelle geändert hat. Wichtig für den Anwender ist, daß sich dadurch der Programmablauf, auch wenn man sich nicht im Single-Step befindet, verlangsamt, da ja der Debugger vor jedem Befehl alle Bedingungen überprüfen muß, die zum Abbruch führen könnten. Damit Sie nicht alles im langsamen Single-Step oder im schnellen Ablauf bis zu Breakpoints testen müssen, gibt es noch ein Mittelding, die sogenannte Animation. Bei dieser Animation wird ein Single-Step ausgeführt, der (einstellbar) zeitgesteuert das Programm selbständig durchläuft.
Mit einer der wichtigsten Eigenschaften eines Source-Level-Debuggers ist das Anzeigen von Variablen: Dies kann global, statisch, lokal oder funktionsbezogen durchgeführt werden. Beispielsweise können Sie sich aller Variablen darstellen lassen, die momentan lokal von einer bestimmten Unterroutine verwendet werden. Dabei werden die Variablen in gängiger C-Systax dargestellt, so daß auch Felder im Fenster erscheinen. Zeiger auf Strukturen werden zunächst als Adressen dargestellt, können aber durch INSPECT und ein weiteres kleines Fenster (on-line) in den einzelnen (bezeichneten) Elementen untersucht werden. Nur der Vollständigkeit halber erwähne ich noch zum Schluß, daß es möglich ist, Speicherbereiche anzuschauen, Dateien über einen startbaren Editor (nicht im Turbo Debugger selbst) zu ändern und Register der CPU anzuschauen. Sie können ein Log-File erstellen, in dem alles festgehalten wird, was während des User-Programmablaufes passiert (Breakpoints, Absturz Ihres Programms etc.). Diese Ausgaben eines Anwenderprogramms können natürlich nach wievor ausgeführt werden, da diese auf einen anderen Bildschirm umgeleitet werden. Der Debugger kann so eingestellt werden, daß bei einer Ausgabe, die er erkennen kann, automatisch auf den anderen Bildschirm umschaltet. Praktisch ist, daß man alle Einstellungen (wie beispielsweise die Fenster-Konfiguration) abspeichern kann.
Zusammenfassung
Sicherlich hat Borland mit dem Debugger ein neues, hervorragendes Produkt auf den Markt gebracht - der Debugger scheint gut debuggt zu sein... Trotzdem fragt man sich, warum nicht, wie bei Turbo C auf dem IBM, ein in seinen Funktionen nicht so umfangreicher Source-Level-Debugger in die Turbo C-Shell integeriert wird. Nicht immer braucht man die umfangreichen Möglichkeiten des Turbo Debuggers, den es in der MS-DOS-Version zusätzlich zum eingebauten Debugger zu kaufen gibt. Es wäre sicherlich wünschenswert gewesen, wenn die Shell etwas mehr überarbeitet worden und endlich ein Inline-Assembler in Turbo C vorhanden wäre. Trotzdem erhält man sicherlich inzwischen ein absolut professionelles Paket, indem man Turbo C 2.0 und Debugger kauft. Allerdings ist ab sofort das Preisverhältnis ein anderes zum Hauptgegner Laser-C. Turbo C 2.0 für den ATARI ST wird ab März 1990 erhältlich sein und kostet 248.52 DM. Das Professional-Paket enthält Turbo C 2.0, den Assembler MASM und den neuen Turbo Debugger und kostet 458.28 DM. Hält man dagegen den Laser C-Compiler, der ab März 349,- DM. inklusive Source-Level-Debugger kostet, wird es sicherlich keine einfache Entscheidung für den Kunden, der noch keinen C-Compiler besitzt.
SH
Bezugsadresse: Heimsoeth + Borland Lindwurmstr. 88 8000 München 2