Turbo-C Version 2.0: Borlands spurtschneller Nachwuchs
Turbo-C war das erste Produkt, das Borland für den Atari anbot. Es spielte seit der allerersten Vörsion stets eine Ausnahmerolle in der Sprach- und Compilerlandschaft. Seit der CeBIT 1990 bietet Borland nun eine neue Programmversion und einen völlig neuen Debugger.
Sein äußerst schneller und kurzer Code und die ideale Integration der verschiedenen Komponenten wie Editor, Compiler oder Linker in ein einziges Hauptprogramm machten Turbo-C binnen kürzester Zeit zu einem beliebten Programmierwerkzeug auf dem ST.
Auf den ersten Blick hat sich am altbekannten TUrbo-C-Menü nicht viel geändert. Allein ein neuer Menüeintrag, mit dem Sie einen über die Systemvariable »_shel_p« installierten Kommandozeileninterpreter aufrufen (Bild 1), kam hinzu. Ob Sie diese Fähigkeit je nutzen, sei dahingestellt — echte Kommandozeilenfreaks verwenden meist ohnehin die auf CLls angepaßte Turbo-C-Compilerversion, die der Produzent auch zur Version 2.0 wieder mit liefert.
Neu an der Version 2.0 sind vor allem seine Innereien: So compiliert Turbo-C jetzt etwa 8000 Zeilen pro Minute — wie gewohnt in einem einzigen Durchlauf. Der erzeugte Programmcode wurde offensichtlich weiter optimiert. Besonders die entscheidenden Ein- und Ausgaberoutinen arbeiten jetzt mit einer wesentlich höheren Geschwindigkeit. Die Geschwindigkeit der Turbo-C-eigenen I/O-Redirection wurde mehr als verdoppelt, die Länge des entsprechenden Startup-Codes dabei auf etwa 800 Byte gekürzt. Neue Optimierungsstufen sorgen für hervorragende Ausnutzung des Systems.
Der Editor präsentiert sich hingegen gewohnt träge, von einem wirklich »schnellen« Editor, wie ihn Borland in einem Fact-Sheet anpreist, keine Spur. Er ist dafür jetzt noch weitergehender via Tastatur zu steuern. Auch die typische Turbo-Fileselect-Box ist nun völlig ohne Maus bedienbar. Um Compilerswitches zu setzen, müssen Sie aber immer noch zur Maus greifen — wie immer bestätigen Ausnahmen die Regel. Hier sind allerhand Verbesserungen realisiert worden, beispielsweise ein abschaltbares Fast-Load-Bit oder Funktionsaufrufe per Parameterübergabe über den Stack.
Die einzigartige Hilfsfunktion, die dem Programmierer zu fast jeder Frage ein Nachblättern im Handbuch erspart, ist weiter verbessert und wesentlich erweitert worden. Beispielsweise findet Turbo-C seine Hilfsdateien jetzt auch dann, wenn es aus einem nicht-aktuellen Zugriffspfad (also z.B. als Anwendung angemeldet) startet.
Großbildschirme — kein Problem
Das Programm läuft auch auf Großbildschirmen und unterstützt sowohl alle Prozessoren der MC680x0-Reihe als auch FPU-Zusätze für schnelle Fließkomma-Berechnungen.
Ein Inline-Assembler fehlt immer noch, im Hinblick auf die Portabilität der C-Programme auf andere Rechner aber ein zu verschmerzender Punkt. Assemblerprogramme fügen sie deshalb immer noch per DRI-Objektdatei ihrem C-Listing bei.
Um die Bearbeitungsgeschwindigkeit des Linkers weiter zu erhöhen, haben die Entwickler zu einem recht eigenwilligen Mittel gegriffen: Man wählte ein völlig neues Linkformat. Daß dieses Format Symbole bis zu 255 Zeichen unterstützt, sei — weil unrealistisch — nur am Rande erwähnt. Wesentlich allerdings ist die enorm verkürzte »Wartezeit« während des Linkvorgangs und die geschrumpften Bibliotheksdateien.
Die Zeit- und Platzersparnis hat allerdings auch Nachteile: Während Sie bislang einzelne Bibliotheksroutinen isolieren, deassemblieren und verbessern, ergänzen oder einfach nur ansehen konnten, ist dies jetzt unmöglich. Zwar liefert Borland ein kurzes Programm zur Analyse und Deassemblierung der Bibliotheksdateien mit, jedoch kann dieses gehobenen Ansprüchen bei weitem nicht genügen. Zum Glück erkennt und verarbeitet der Linker aber nach wie vor auch Bibliotheken im DR1-Format, so daß Sie auf Ihre selbsterstellten Bibliotheken nicht verzichten müssen.
Allen ausgelieferten Turbo-C-Exemplaren legt der Produzent die sog. »BGI«-Bibliothek bei. Das Kürzel steht für »Borland Graphics Interface«. Diese Bibliothek soll die Portabilität von Programmen, die Grafikfunktionen nutzen, verbessern. Ein sicherlich weiser Schritt — wenn man bedenkt, daß GEM und dessen VD1 in der MS-DOS-oder gar Unix-Welt weitgehend unbekannt sind, C jedoch weitgehend genormt ist.
Turbo-C in seiner neuen Version ist sicher den Updatebetrag wert, zumal es Programme jetzt noch schneller erstellt und die C-Compilate durch ihre eigene Ausführungsgeschwindigkeit überzeugen.
Einsteigern empfiehlt sich das Programm vor allem aufgrund der vollen Unterstützung des ANSI-Standards und der vielfältigen Fehlererkennung, die unsaubere Programmierung schon im Keim erstickt und Programmierfehler schon vor der Programmerstellung abfängt. Darüber hinaus führt es durch die volle Unterstützung des ANSI-Standards an die portable Programmierung heran und erlaubt damit die Nutzung einer einzigen Quelldatei auf den verschiedensten Systemen.
Auch Programmierer sind nur Menschen. Dementsprechend laufen Programme selten auf Anhieb fehlerfrei. In lnterpretersprachen wie Basic oder Logo sind diese meist recht schnell zu lokalisieren. Assembler oder Compilersprachcn wie C stellen den Programmierer jedoch vor einige Probleme: Kein Interpreter »federt« Fehler ab, sondern der Programmcode wird »ohne Netz und doppelten Boden« aufs System losgelassen. Fehler führen im Extremfall zum totalen Systemabsturz. Die genaue Fehlerursache zu ermitteln ist Aufgabe spezieller Programme, die in keinem Entwicklungspaket fehlen sollten: die Debugger.
»BUG-68« wurde abgesetzt
In der »professional«-Ausführung des Turbo-C-Programmpakets liefert der Münchener Generalvertrieb nun zum stolzen Preis von insgesamt 458,28 Mark (ein Produkt von Borland erkennt man allein schon am einzigartig krummen Preis) einen gänzlich neuen Debugger. Der schäbige, alte und völlig überteuerte »BUG-68« hat endgültig ausgedient. Geliefert wird die Programmdiskette mit einem gut 160seitigen Handbuch. Es führt wie gewohnt ausführlich in die Materie ein und beschreibt die einzelnen Funktionen ausführlich. Reichlich vorhandene Illustrationen und Hardcopies verbessern die Übersicht. Die Fehlersuche selbst bleibt natürlich nach wie vor Ihnen überlassen, das Handbuch gibt allerdings einige, wenn auch recht spärlich gesäte Tips zur Fehlersuche, bei der der Turbo-Debugger Ihnen hilfreich zur Seite steht.
Dieser Debugger gibt dem Entwickler nun endlich Gelegenheit, sein Programm sowohl auf C- als auch auf Assembler-Ebene ablaufen zu lassen. Die dazu nötigen Informationen fügt Turbo-C auf Wunsch dem gelinkten Programm bei. Obwohl der Debugger GEM-Pro-gramme debuggen kann und allein schon deshalb nicht auf GEM-Routinen zurückgreifen darf, bietet er dem Benutzer einen erstaunlichen Bedienungskomfort.
Der Anwender braucht nicht etwa auf GEM-typische Windows oder die liebgewonnenen Menüs zu verzichten. Dank eigener Routinen funktioniert das Scrolling wesentlich schneller als im schläfrigen Turbo-C-Editor. Das Window-Update funktioniert selbstverständlich auch bei denjenigen Windows, die im Hintergrund liegen. Die Zahl der benutzten Windows ist nicht auf GEM-typische acht beschränkt. Jedoch müssen Sie auf Accessories verzichten, während Sie im Debugger arbeiten.
Alle Menüeinträge und einige Sonderfunktionen sind auch per Tastaturkommando erreichbar, was den Bedienungskomfort merklich erhöht. Der Debugger bietet Ihnen vielfältige Einblicke in Ihr Programm. So können Sie Variable oder Felder, Zeiger oder Strukturen in C-Syntax betrachten, während Sie das Programm schrittweise ablaufen lassen. Dabei beobachten Sie Ihr Programm sowohl als compiliertes Assemblerprogramm oder als C-Quelldatei (Bild 2). Der Debugger läßt Sie Ihr Programm an beliebigen Stellen anhalten und dann Inhalte von allen verwendeten Variablen verändern. Anschließend haben Sie Gelegenheit, die Auswirkungen dieser Veränderungen sofort zu beobachten.
Ebenso komfortabel zeigt sich der Debugger in der Verarbeitung von Breakpoints (Bild 3). Es sind sowohl einfache Breakpoints (solche, die an bestimmten Stellen das Programm unterbrechen) als auch globale (solche, die unterbrechen, wenn eine Variable einen vorgegebenen Wert erreicht) und sogar Kombinationen daraus, die komplexen Breakpoints, vorgesehen. Darüber hinaus können alle Breakpoints mit weiteren Bedingungen verknüpft werden, z.B. einer bestimmten Durchlaufzahl oder irgendeiner Bedingung in C-Syntax. Sobald alle gestellten Bedingungen erfüllt sind, stoppt der Debugger den Programmablauf. Wünschenswert ware hier eine Abbruchmöglichkeit, sobald das Programm eine frei wählbare TOS-Routine aufruft. Leider ist dies derzeit nicht vorgesehen.
Mit der Funktion »Animate« lassen Sie das Programm in Einzelschritten ablaufen. Die Länge der Pause, die der Türbo-Debugger zwischen der Ausführung der einzelnen Befehle einlegt, dürfen Sie frei bestimmen. Dieser Ablauf läßt sich jederzeit per Tastendruck unterbrechen.
Der Debugger kann gleich mehrere C-Quelltexte gleichzeitig im Speicher halten, die er bei Bedarf aufruft und ins Quellcode-Fenster befördert. Dies ist beispielsweise dann von Vorteil, wenn Sie anhand einer Projektdatei ein Programm aus vielen einzelnen C-Modulen zusammensetzen lassen und nur eines davon fehlerhaft ist.
Ein Arbeitsprotokoll zeigt der Debugger in einem Window und speichert es auf Kommando. Das ist z.B. dann hilfreich, wenn ein Fehler in verschiedenen Programmen auftaucht. Für die Übersicht des Prozessorstatus kann ein eigenes Window angefordert werden. Registerinhalte oder den Zustand des Statusregisters ändern Sie durch einfaches Anklicken im »CPU«-Fenster (Bild 4). Dieses Fenster zeigt nicht nur den Status der bislang verwendeten MC68000-Prozessoren an, sondern ist — ebenso wie TOS 1.6 — auf Motorolas MC68010- und -20-CPUs sowie den TT-Prozessor MC68030 und FPUs vorbereitet. Auch im Debugger haben Sie bei allen Aktionen Zugriff auf die vom Compiler bekannte ausführliche Hilfestellung, was Ihnen Zeit und Nerven spart.
Doch leider gibt es im Debugger auch etliches zu bemängeln. Es ist mir schleierhaft, warum Borland sich die Mühe macht, den Debugger an so exotische Geräte wie Großbildmonitore anzupassen, Farbmonitorbesitzer jedoch mit einer Alert-Box enttäuscht, welche da lautet: »TD can’t run in low or mid resolution.« Unbegreiflich ist auch, warum dies nirgendwo unter »Systemvoraussetzungen« Erwähnung findet.
Den Turbo-Debugger darf man als sehr brauchbare Programmierhilfe bezeichnen, die allerdings in vielen Punkten Mängel aufweist. So bleibt derzeit nur auf ein baldiges Update zu hoffen, in dem Borland die bekannten Probleme beseitigt. Auch die angekündigte Funktion, mit der die gesamte Arbeitsumgebung gespeichert und wieder geladen werden kann.
Unter »Arbeitsumgebung« wäre in diesem Zusammenhang wirklich Wesentliches gemeint: Bei den geöffneten Windows angefangen und beim Zustand von Prozessor, Systemvariablen und sonstiger Speicherbelegung aufgehört. Doch leider speichert der Debugger nur eine kurze Konfigurationsdatei, die ihm lediglich über die Kommandozeile und einige Pfade sowie die Lage der Fenster Auskunft gibt. Wer gehofft hat, daß der Debugger nach einem erneuten Laden automatisch die Windows öffnet, die beim letzten Verlassen des Programms geöffnet waren, wird enttäuscht. Dies ist für den Programmierer besonders nervtötend, muß er doch nach jedem Sprung vom Compiler in den Debugger alle Windows erneut öffnen. Der Sprung zwischen den beiden Programmen ist auch nicht gerade geglückt. Besonders beim Aufruf der »Editor-Funktion, mit der ein Textverarbeitungssystem zur Sofortkorrektur kleinerer Fehler aufgerufen werden kann, ist bei nur 1 MByte RAM selten fehlerfrei zu bewerkstelligen. Der Debugger meldet den Fehler — und stürzt ab. Solche Abstürze kamen während unserer ausgiebigen Tests nicht gerade selten vor, ein Faktum, das bislang bei Bor-land-Produkten noch nie zu bemängeln war. Darüber hinaus benötigt der Turbo-Debugger zum Auf finden des Editors einen kompletten Programmpfad, denn der aktuelle Pfad kann ja durch das untersuchte Programm verändert werden. Für diesen Programmpfad gönnt die Benutzeroberfläche dem Anwender gerade 24 Zeichen, für einen längeren Programmpfad auf der Festplatte viel zu wenig.
Handarbeit bei den Windows
Beim Rücksprung vom Debugger in den Editor übergibt der Turbo-Debugger leider keine Zeilenangabe, anhand der der Editor errechnen könnte, an welcher Stelle Sie das Programm unterbrochen haben, um zurückzuspringen. So bleibt Ihnen die lästige Aufgabe, die Stelle, an der ein Fehler lokalisiert wurde, selbst zu finden.
Der Debugger benötigt, um seine Arbeit korrekt zu erfüllen, spezielle Debug-lnformationen. Mittels eines Schalters fügen Sie diese dem Programm zu, das aber dennoch voll funktionstüchtig bleibt. Der Schalter muß jedoch im Compiler- als auch im Linkermenü umgelegt werden — unverständlich, warum ein einziger Switch nicht genügte. Nachdem Sie diesen Schalter betätigt haben und eine neue Compilation an fordern, passiert gar nichts. Erst wenn Sie den Quelltext verändern (z.B. durch Einfügen eines Leerzeichens mit anschließender Tilgung), werden die Debugger-Informationen auch wirklich angefügt. Der Debugger hat die Fähigkeit, eine Kommandozeile zu übergeben und diese während der Laufzeit zu verändern. Daß diese Kommandozeile der relativ jungen Atari-Spezifikation für die erweiterte Parameterübergabe noch nicht entspricht, ist noch verständlich. Daß der Turbo-Debugger dem Anwender jedoch nur lächerliche 39 Byte zur Eingabe überläßt, ist schlichtweg dreist. Mindestens die von Atari garantierten 124 Byte für die Kommandozeile sollte er zur Verfügung stellen.
Zum Debuggen von ROMs eignet sich der Turbo-Debugger überhaupt nicht. Trifft er auf einen »trap«-Befehl, so offeriert er keine Funktion, mit der TOS-Routinen zu beobachten wären. Die nächste Unterbrechung wird erst wieder nach der Rückkehr aus der Exception ausgeführt. So bleiben Sie für sehr hardwarenahe Untersuchungen weiterhin auf spezielle Assembler-Debugger wie »Bugaboo« angewiesen.
Abschließend können wir den Turbo-Debugger als sehr brauchbare Programmierhilfe bezeichnen. Sie weist allerdings in vielen Punkten Mangel auf. Es bleibt deshalb nur auf ein baldiges Update zu hoffen, in dem Borland die bekannten Probleme beseitigt. (mb)
Laurenz Prüßner