Turbo C contra Laser C
Nachdem wir Ihnen die Vorabversionen der beiden Entwicklungssysteme bereits vorgestellt haben, präsentieren wir Ihnen hier noch einmal die endgültigen Produkte. Ring frei zur zweiten Runde...
Turbo C aus dem Hause Heimsoeth/Borland steigt mit einem Kampfgewicht von 660 deutsch geschriebenen Handbuchseiten und drei einseitig formatierten Disketten in den Ring. Der Kontrahent Laser C wartet mit 640 englischen Seiten (das deutsche Handbuch ist noch in Arbeit) und zwei doppelseitigen Floppies auf. Lassen wir die beiden den Ring (Partition D meiner Harddisk) besteigen, um sich zu messen.
Turbo C gibt sich unkompliziert. Neuen Ordner anlegen, die drei Floppies hineinkopieren, TC.PRG anklicken, läuft. Die Installation auf Disketten gestaltet sich ähnlich einfach. Ist man mit einem einseitigen Floppylaufwerk gestraft, muß man auf die Hilfstexte von Turbo C vezichten. Kein Wunder, denn die Datei mit den Hilfstexten ist fast 300 KB groß.
Vom Prinzip her geht das alles bei Laser C genauso einfach. Dummerweise merkt die Laser C-Shell nicht, von welchem logischen Laufwerk sie gestartet wurde, und tut dementsprechend auch nicht das Naheliegende, nämlich alle anderen Dateien der Entwicklungsumgebung auch von diesem Laufwerk laden. Nein, beim ersten Start von der Harddisk lädt die Shell alle ihre benötigten Daten zunächst von Laufwerk A. Dann müssen die Unterverzeichnisse für die Hilfsprogramme,
Bibliotheken und so weiter auf Laufwerk D (in meinem Fall) gesetzt und in der Konfigurationsdatei gespeichert werden. Erst dann kommt auch mit der Harddisk Freude auf. Wer sich immer noch nicht an grafische Benutzeroberflächen gewöhnt hat und ein Feind des kleinen grauen Tierchens ist, kann auch einen der vielen Kommandointerpreter, die es für den ST inzwischen gibt, benutzen, um seine Programme zu erstellen. Beide Systeme sehen diese Möglichkeit vor. Bei Laser C kann man sogar die Shell dazu verwenden, in einem Fenster über Kommandos mit Compiler, Linker und was es sonst noch so gibt zu kommunizieren.
Für beide Systeme benötigt man einen ATARI ST mit mindestens einem Megabyte Speicher und TOS im ROM. Will man Laser C mit einem einseitigen Diskettenlaufwerk betreiben, muß man jemanden haben, der die doppelseitigen Originaldisketten auf einseitige umkopiert. Fraglich bleibt dabei, wer mit so einem System überhaupt noch arbeitet, geschweige denn programmiert. Trotzdem finde ich es erfreulich, daß die Entwickler dies berücksichtigt haben. An dieser Stelle möchte ich auch auf einen Mangel hinweisen, auf den mangelnden Kopierschutz der beiden Kandidaten. Meiner Meinung nach sollte jedes Handbuch den Satz “Bitte fertigen Sie zuerst Sicherheitskopien Ihrer Originaldisketten an und verwahren Sie die Originale an einem sicheren Ort” enthalten. Die Handbücher von Turbo und Laser C tun es. Und sie enthalten noch eine ganze Menge mehr (kein Wunder bei dem Umfang). Mehr als die Hälfte verschlingt die Beschreibung der Bibliotheken, als da wären AES, VDI, BIOS, XBIOS, GEMDOS, UNIX-kompatible Funktionen und die Line-A- Bibliothek. Letztere braucht im Turbo C-Handbuch nicht beschrieben zu werden, weil sie dort nämlich fehlt. Mit 21 Seiten ist der Index der Turbo C-Dokumentation dreimal so lang wie der von Laser C. Beide Handbücher sind übersichtlich gegliedert und relativ vollständig. Besonders gut haben mir bei Turbo die Erläuterungen zur Implementation des Compilers gefallen.
Shell und Editor
Beide Systeme werden über eine GEM-Shell bedient und sind einfach und schnell zu handhaben. Beide stellen Tastaturkürzel für die Menüfunktionen zur Verfügung, ein allgemeiner und, wie ich meine, vorteilhafter Trend. Der Teufel steckt natürlich, wie immer, im Detail, und welche Benutzerschnittstelle ist schon so perfekt, daß niemand mehr eine Verbesserung einfällt? Tatsächlich ist es so, daß beide Systeme sowohl Stärken als auch Schwächen haben und eine Kombination aus beiden ideal wäre. Das gilt nicht nur für Shell und Editor, sondern allgemein. Im folgenden möchte ich eine Liste der Vor- und Nachteile aufführen. Beginnen wir mit Turbo. Die Tastaturkommandos des Editors sind stark an die des Apple Macintosh angelehnt. Da ich öfter mit dem Mac als mit dem ST arbeite, bin ich davon natürlich begeistert. Allerdings bin ich Mac II-Geschwindigkeit gewohnt, und der Editor von Turbo ist ziemlich lahm. Beim Scrollen läßt er sich ca. fünfmal soviel Zeit wie der Laser C- Editor, der seinerseits in dieser Disziplin an Tempus herankommt. Toll finde ich die Möglichkeit, durch einen Doppelklick auf die Zeile, in der eine Fehlermeldung des Compilers steht, auf die dazugehörige Zeile im Quelltext zu springen. Für diesen Fall bietet Laser C keine komfortable Lösung an. Sehr bemerkenswert ist die Hilfsfunktion von Turbo C. Sie ersetzt in den meisten Fällen das Handbuch. Vergleicht man die Hilfstexte mit der Dokumentation, entdeckt man auffällig große Ähnlichkeit. Auch der Umfang ist mit ca. 300 KB (in Worten dreihundert Kilobyte) so groß, daß die Bezeichnung On-Line Manual (ich weiß beim besten Willen keine deutsche Übersetzung für diese Redewendung) eigentlich treffender wäre.
Nun zu Laser C: Was die turn-around Zeiten angeht, ist Laser C das Schnellste, was ich bisher gesehen habe. Das liegt zum einen an dem flotten Editor, der wirklich in vielen Funktionen an Tempus heranreicht und zum anderen an dem Cache-Prinzip der Shell. Das mit dem Cache funktioniert so: Programme (Compiler, Linker, Make usw.) und Daten werden im Hauptspeicher gehalten, und man spart den Zugriff auf einen (langsamen) Massenspeicher. Man darf das aber nicht mit einer RAM-Disk verwechseln. Bei der muß nämlich das auszuführende Programm trotzdem noch in den Speicher geladen bzw. umkopiert werden.
Das kostet zusätzlichen Platz und natürlich auch Zeit. Bei Laser C wird z.B der Compiler nicht mehr im Speicher umkopiert, sondern direkt gestartet, und das geht erheblich schneller als das Laden von einer RAM-Disk. Die genauen Zeiten stehen im Kasten nebenan. Die Zahlen neben den Programmnamen geben die Länge des Quelltextes in Bytes an. Die untere Zahl bei Laser C (2.Mal) gibt die Zeiten an, die gemessen wurden, wenn der Quelltext bereits im Cache der Shell war. Einweite-res Plus für die Laser-Shell ist der integrierte Kommandozeileninterpreter für die UNIX-Süchtigen. Auch die mitgelieferten Hilfsprogramme können sich sehen lassen. Das Make ist eine der wichtigsten Anleihen an UNIX und übertrifft die Projektverwaltung von Turbo bei weitem. Soviel zu Shell und Editor.
Der Compiler Turbo erzeugt schnelleren und kürzeren Code. Die exakten Werte entnehmen Sie bitte den beiden Tabellen.
Zur Erklärung der Laufzeiten ist zu sagen, daß es bei dem ersten Wert jeweils Optimierungen, Registervariablen usw. ausgeschaltet und beim zweiten Wert eingeschaltet waren. Die Ergebnisse für Sieve sind in Sekunden angegeben, die Dhrystones sind in Dhrystones pro Sekunde gemessen. Die Ergebnisse des Dhrystone-Tests sind ungewöhnlich hoch. Das liegt vermutlich an der cleveren Optimierung von Turbo C. Ein Kommentar im Quelltext warnt vor den Ergebnissen eines optimierenden Compilers, da der Test jede Menge Operationen enthält, die wegoptimiert werden können. Zum Beispiel die Zuweisung eines Werts an eine Variable, die anschließend nicht mehr verwendet wird. Anders kann ich mir das Ergebnis auch nicht erklären. Der Macintosh II, der einen 68020 mit 16 MHz Takt verwendet, kommt mit dem schnellsten mir bekannten Compiler (MPW 2.02) gerade auf ca. 2500 Dhrystones. Ich glaube, die Geschwindigkeiten des Siebs sind aussagekräftiger, und das bedeutet, daß Turbo ca. 25% schneller ist als Laser C. Das ist zwar nicht mehr so überwältigend wie die ca. 100%, die der Dhrystone-Test suggeriert, aber immer noch beeindruckend.
| LEER | APPACC | DHRYSTONE |
|---|---|---|
| Laser C | 3350 | 4403 |
| Turbo C | 410 | 1231 |
Bild 2: Programmlängen in Byte
Haben Sie schon vom ANSI-C-Standard gehört? Den erfüllt nämlich Turbo. Was verbirgt sich dahinter? Erweiterungen zum K&R-Standard, die von der amerikanischen Normungsbehörde ANSI gerade definiert werden. Einige davon sind auch in Laser C vorhanden, als da wären Strukturzuweisungen, Aufzählungstypen und der Typ void für Funktionen, die keinen Wert zurückliefern. Der wesentliche Vorteil von ANSI-C sind aber die Funktionsprototypen, die es erlauben, die Typen der Übergabeparameter an Funktionen anzugeben. Der Compiler prüft dann beim Aufruf der Funktion, ob die Parameter zulässig sind. Außerdem stellt ANSI-C zusätzliche Bibliotheksfunktionen zur Verfügung. Zum Beispiel vprintf. Die Wirkung ist identisch mit dem bekannten printf, lediglich die Übergabe der Parameter ist unterschiedlich. Während printf eine Parameterliste als Argument benutzt, verwendet vprintf einen Zeiger auf eine Parameterliste.
| Sieve | Dhrystones |
|---|---|
| Laser C | 4,22 |
| 2,52 | 848 |
| Turbo C | 2,00 |
| 2,00 | 1708 |
Bild 3: Programmlaufzeiten
Eine C-Erweiterung, die nur Laser C anbietet, ist die Möglichkeit, Assembler direkt in C-Programme einzubinden. Bei Turbo C müssen Assembler und Debugger zusätzlich erworben werden. Da beide zum Zeitpunkt dieses Tests noch nicht fertig waren, kann ich dazu nur soviel sagen, daß der Assembler 680X0 (CPU), 68881-68882 (FPU) und 68851 (MMU) Code erzeugen kann. Der Debugger arbeitet auf Assemblerebene und versteht die Symbole, die der Compiler erzeugt.
Bleibt zu den beiden Compilern nur noch zu sagen, daß Turbo C Objektdateien im DRI-Format erzeugt, und Laser C ein eigenes Objektformat verwendet. Allerdings verstehen Linker und Librarian von Laser C auch DRI-Objektdateien.
Das Ambiente
Allgemein ist es so, daß Laser C eine Menge Hilfsprogramme enthält, die für die Entwicklung nützlich sind. Turbo C ist in dieser Hinsicht eher spartanisch ausgestattet. Laser C enthält zusätzlich zu Shell, Compiler, Linker und Librarian ein Resource Construction Set, einen Debugger, ein Hilfsprogramm zum Untersuchen von Textdateien (egrep), ein Programm zum Disassemblieren von Objektdateien und einige Hilfsprogramme aus der UNIX-Toolbox (Is, cat, echo usw). Das RCS liegt in der Version 2.0 vor. Gegenüber älteren Versionen können Resourcen bis zu 64 KB Länge (früher 32 KB) erzeugt werden. Ein einzelner Objektbaum kann jetzt maximal 2000 Objekte enthalten (früher 256). Außerdem kann eine Resource auch als C-Quelltext abgespeichert werden. Um diesen Quelltext auch praktisch nutzen zu können, wird in den Bibliotheken eine Funktion bereitgestellt, die den Objektbaum dem GEM bekannt macht. Dabei wurde auch an Entwickler gedacht, die ein anderes Resource Construction Set verwenden. Für diesen Fall wird ein Programm mitgeliefert, das jede Resource in einen C-Quelltext umsetzt.
Der Debugger von Laser C ist kein separates Programm, sondern wird als Objektdatei zu dem zu bearbeitenden Programm gelinkt. Er arbeitet symbolisch und ist ein gutes Hilfsmittel, um C-Programme zu entwanzen.
Ein Bonbon, das der Initialisierungscode der beiden Systeme enthält, ist die globale Variable “_appIst der Wert dieser Variablen ungleich Null, wurde das Programm als Applikation gestartet, sonst als Accessory geladen. Das Listing zeigt ein Beispiel, wie man sein Programm sowohl als Accessory als auch als Applikation verwenden kann. Man muß bei dem fertigen Programm lediglich die Extension auf “.PRGG”bzw. “.ACC” setzen. Wie man sieht, sind die #include-Dateien nicht namensgleich. Je nachdem, welchen Compiler man verwendet, muß man die entsprechen Makros definieren, um die richtige Headerdatei einzubinden. Erstaunlich an dieser Erweiterung ist die Übereinstimmung des Namens der globalen Variablen. Wer hat da wohl von wem abgeguckt?
Fazit
Zunächst hört sich 198 DM für ein C-Entwicklungssystem wie Turbo C im Vergleich zu 398 DM für Laser C sehr viel günstiger an. Bedenkt man jedoch den Lieferumfang von Laser C, muß man zu Turbo noch das Assembler-/Debugger-Paket und ein Resource Construction Set kaufen. Wenn man an den Cache von Laser C denkt, kommt noch eine RAM-Disk dazu. Erst dann sind die beiden Pakete etwa auf dem gleichen Stand, auch, was den Preis angeht.
JL
Bezugsadressen:
Turbo C: Heimsoeth Software GmbH Lindwurmstr. 85 8000 München 2
Laser C: Application Systems Heidelberg Englerstr 3 6900 Heidelberg
#ifdef LASER
#include <gemdefs.h>
#endif
#ifdef TURBO
#include <AES.H>
#endif
extern int _app;
main_loop()
{
form_alert(1,"[1][Hello World][OK]");
}
main() {
int desk_id, appl_id, msg_buf[8];
appl_id = appl_init(); /* Hallo AES hier bin ich */
if(_app) { /* PRG oder ACC ? */
main_loop(); /* Programm ausführen */
}
else { /* Titel eintragen in's Deskmenü */
if ( (desk__id = menu_register(appl_id, " Hello World")) == -1)
{ /* Schade, schon voll, sorry user */
form_alert(1,"[1][Kein Platz mehr in der Menueleiste][ OK ]");
appl_exit();
}
do { /* warten auf eine Nachricht... */
evnt_mesag(msg_buf);
if((msg_buf[0] == AC_OPEN) && (msg_buf[4] = desk_id))
{
main_loop (); /* Wir sind gemeint, also Los */
}
} while(l); /* immer und immer wieder... */
}
appl_exit(); /* bis zum bitteren Ende */
}
Listing: So kann man eine Anwendung wahlweise als Accessory oder normales Programm starten.