Lattice C 5.0 - Wer A sagt muß auch C sagen
Aus England kommt ein neuer ANSI-C-Compiler auf den von Pure C beherrschten ATARI-Compiler-Markt. Für den ATARI liegt hiermit von HiSoft/CCD eine neue und zum Teil eingedeutschte Portierung des auf vielen Rechnerplattformen verfügbaren Compilers vor, der dort wegen seiner Portabilität und Codequalität einen ausgezeichneten Ruf genießt.
In den USA und England bereits seit etwa 2 Jahren verfügbar und mittlerweile auch von ATARI USA zur Entwicklung eingesetzt, hat die aktuelle Version nun ihren Weg nach Deutschland gefunden.
Der Lieferumfang...
...umfaßt 7 Disketten, ein deutsches System-Handbuch sowie zwei englische Handbücher über die Bibliotheken, insgesamt etwa 1000 saubere spiralgebundene DIN-A5-Seiten. Dazu kommt die neueste Ausgabe des bekannten Profibuches, das auf 1500 Seiten alle ATARI spezifischen Aspekte abdeckt. Auf den Disks befinden sich die integrierte Entwicklungsumgebung, Compiler, Optimierer, Linker, Assembler, Debugger, ein RCS, Librarian, RAM-Disk, die Bibliotheken sowie einige Hilfsprogramme und Beispiele.
Die Systemanforderungen...
...für ein vernünftiges Arbeiten verlangen nach 2 MB RAM und Festplatte, für größere Projekte ist aber mehr RAM sehr zu empfehlen. Mit nur 1 MB RAM ist die Benutzung zwar möglich, wird aber wegen viel IO stark verlangsamt. Die Installation ist recht einfach und beschränkt sich auf das Kopieren der Disks in ein Verzeichnis der Festplatte. Eine Komplettinstallation beansprucht etwa 6 MB, bei sorgfältiger Auswahl der für eigene Bedürfnisse benötigten Bibliotheksvarianten kann man jedoch 2 bis 3 MB einsparen, wobei das Handbuch dazu leider wenig Hilfestellung gibt. Allerdings dürfte dies wohl nur für festplattenlose Zeitgenossen von Bedeutung sein.
Die Dokumentation...
...ist vom Umfang her wirklich beeindruckend. So deckt das bekannte Profibuch als Referenzwerk alle ATARI-spezifischen Aspekte ab, während die ebenfalls recht ausführlichen und gut geordneten englischen Bibliothekshandbücher auf die ATARI-spezifischen und allgemeinen Funktionen eingehen und dabei auch Anmerkungen zu Fehlerursachen geben. Der ATARI-Teil ist leider nicht auf dem neuesten Stand, so fehlen z.B. Informationen zur Programmierung von CPX-Modulen. Wahrscheinlich einer der Gründe, das Profibuch mitzuliefern, das dieses Bibliothekshandbuch vollständig ersetzen kann. Das deutsche Benutzerhandbuch hingegen enttäuscht völlig. Von den vielen Rechtschreibfehlern einmal abgesehen, erkennt man auf den ersten Blick, daß hier eine fast wörtliche Übersetzung aus dem Englischen vorliegt, in der auch Wortschöpfungen nicht fehlen. Vieles bleibt unverständlich und erst nach einer Rückübersetzung ins Englische lassen sich einige Ausdrücke verstehen. Dazu kommen inhaltliche Fehler, die gerade einem Einsteiger die Einarbeitung erschweren werden. Viele Optionen lassen sich kaum anwenden, weil sie entweder zu knapp, irreführend oder gar nicht beschrieben sind. So werden z.B. nicht einmal alle Direktiven des Assemblers aufgeführt.
Implementationsspezifische Details, Arbeitsweise des Optimierers usw. sucht man ebenso wie einen roten Faden erst recht vergeblich. Zu allem Überfluß gibt es dann noch nicht einmal einen Index.
Hier sollte CCD schnellstens Abhilfe schaffen und entweder für ein neues deutsches Handbuch sorgen oder das englische Originalhandbuch nachliefern, das in den vergangenen Versionen sehr ausführlich war.
Die Bedienung...
...des Systems, die natürlich auch per Kommandozeile möglich ist, übernimmt normalerweise eine GEM-Oberfläche mit integriertem Editor, welche je nach RAM-Ausbau Programmteile resident halten kann.
Die Oberfläche ist in jeder Auflösung, selbst hochauflösender Farbgrafik, lauffähig, obwohl sie leider immer noch Gebrauch von LineA macht. Auch ein kurzer Test unter MultiTOS bereitete keine offensichtlichen Probleme. Bis zu 20 Programme lassen sich mit Parametern einstellen und jederzeit über Maus oder Tastatur aufrufen.
Die Oberfläche läßt sich mit der Maus recht gut bedienen, wenngleich es unter TOS 2.06 und 3.06 noch Probleme mit den Pop-Up-Menüs gibt. Die Bedienung über Tastatur hält sich dagegen in keinem Punkt an bestehende Standards. Hier hätte ein Blick ins Profibuch dem Hersteller sicherlich nicht geschadet. Oder hätten Sie gedacht. daß Ctrl-Q ein Löschkommando im Editor ist?
Die Tastaturbelegung bedarf also dringend einer Anpassung, um mit ihr sinnvoll arbeiten zu können, solange man auch andere Programme benutzt. Leider sind sämtliche Dialogboxen nur über Maus bedienbar, woran auch Utilities wie Let-EmFly nichts ändern können. Von etlichen weiteren Fehlern, bis hin zum Überschreiben von Speicher, abgesehen, ist die Shell jedoch ideal geeignet, die Optionen für die einzelnen Programmteile, von denen allein der Compiler etwa 100 bietet, zu verwalten. Trotz der Fehler ist die Arbeit mit der Oberfläche möglich, wenngleich manchmal schwierig und nervenaufreibend.
Mit dem in der integrierten Entwicklungsumgebung eingebundenen Editor lassen sich bis zu 7 Dateien in GEM-Fenstern gleichzeitig bearbeiten, ansonsten fällt er aber nur durch die im Pure-C-Editor vermißte Anzeige der aktuellen Cursor-Spalte und -Zeile, Marken sowie die Möglichkeit, Blöcke direkt abzuspeichern und hinzuzuladen, angenehm auf. Blockmarkierung ist sowohl mit Maus als auch über Tastatur möglich. Lästig sind dagegen die stark gewöhnungsbedürftige Tastaturbelegung, fehlende Clipboard-Unterstützung und die auf eine einzelne Zeile beschränkte Undo-Funktion.
Die Projektverwaltung...
...erinnert an Think C auf dem Macintosh und gehört zweifellos zu den Stärken der Shell. Interaktiv lassen sich hier Projekte zusammenstellen, die sowohl C- und Assembler-Module als auch wiederum Unterprojekte oder Libraries enthalten können. Selbst die Angabe von Abhängigkeiten oder speziellen Optionen für einzelne Quelltexte ist interaktiv mit der Maus möglich. Dabei werden aus der Vielzahl an Library-Varianten automatisch die für die aktuelle Einstellung erforderlichen in das Projekt aufgenommen. Auch wenn man leider in der Projektdatei keine Kommentare einfügen kann, erleichtert einem die hervorragende Projektverwaltung die Arbeit enorm.
Der Compiler...
...besteht aus zwei Programmen. Dabei wird vom ersten eine recht große Zwischendatei erzeugt, die man daher möglichst auf einer RAM-Disk (im Lieferumfang) unterbringen sollte. Diese läßt sich dann über den Global Optimizer, ebenfalls ein separates Programm, optimieren, bevor der letzte Compiler-Teil dann aus der Zwischendatei den Code, wahlweise im Lattice, GST- oder DRI-Format, erzeugt.
Der Compiler ist über viele Optionen, die alle aufzuzählen den Rahmen dieses Tests sprengen würde, steuerbar. So kann man bei der Größe des Datentyps int zwischen 16 und 32 Bit wählen, die Art der Parameterübergabe (Stack und/oder Register) und das Speichermodell festlegen, Debug Informationen, Cross-Referenz-Listings aber auch Prototypen aus alten K&R-Sourcen generieren lassen.
Lattice C beinhaltet den vollen ANSI-Standard inkl. der bei Pure C vermißten locals mit länderspezifischen Anpassungen von Währungs- und Datumsformaten. Die Gründlichkeit, mit der der Compiler zu Werke geht, läßt keine Wünsche offen und deckt so manche Schwachstelle in Quelltexten auf. die andere Compiler noch übergehen. Daß dies seinen Tribut in Sachen Geschwindigkeit fordert, ist einsichtig.
Leider fällt dieser selbst bei Verwendung vorcompilierter Header-Dateien mit der ca. 3fachen, bei Benutzung des Global Optimizers sogar etwa 6fachen Zeit dessen, was Pure C benötigt, recht hoch aus. Außerdem traten bei der Arbeit mit dem Compiler mehrmals interne Fehler auf, bei deren Beseitigung bzw. Umgehung einiges an Zeit zu investieren war, nicht zuletzt, da sich das Handbuch dazu recht bedeckt hält.
Damit kommen wir zur Qualität des erzeugten Codes. Weniger Gewicht hat sicherlich, daß von Lattice erzeugte Programme, unabhängig von der Art der Optimierung, etwas größer als die Pure-C-Pendants sind. Wichtiger ist zweifellos die Geschwindigkeit des Codes, und diese hängt ganz entscheidend von der Komplexität der jeweiligen Funktionen ab. Bei großen, komplizierten Funktionen erzeugt Lattice, besonders, wenn der Optimierer verwendet wird, deutlich besseren Code, bei kleinen Pure C.
Mit sehr komplizierten Funktionen allerdings kam der Optimizer nicht zurecht und produzierte fehlerhaften Code, so daß er abgeschaltet werden mußte. Die auf 32 KB beschränkte Codegröße je Modul stellt für den professionellen Einsatz durchaus eine Einschränkung dar. Bei fehlerhaften Compiler-Läufen werden die erzeugten defekten Objektdateien nicht gelöscht, so daß ein make bzw. die Projektverwaltung meint, einen aktuellen Code vor sich zu haben.
Lattice C unterstützt neben allen 680x0-CPUs auch LineF-Code für 68882 im TT bzw. PAK und nutzt dazu im Gegensatz zu Pure C auch die internen FPU-Register aus, so daß je nach Anwendung deutlich schnellerer Code erzielt wird. Leider hat man bei der Unterstützung der IO-FPU wie z.B. im Mega STE oder Mega ST mit FPU-Karte geschlampt, diese funktioniert nämlich überhaupt nicht.
Wie sich gezeigt hat, wird leider nur ein Teil der FPU-intemen Konstanten verwendet. Die reinen Software-Fließkommaberechnungen per Bibliothek sind im Mittel etwa 25% langsamer als bei Pure C.
Testergebnisse
| Übersetzung | Größe | Ausführung | |
|---|---|---|---|
| Dhrystone 2.0 | |||
| Lattice | |||
| -normal | 0:18 | 22.282 | 2167 |
| -optimiert | 0:25 | 22.178 | 2627 (1) |
| Pure | 0:07 | 20.128 | 2974 |
| Autorouter | |||
| Lattice | |||
| -normal | 1:33 | 22.172 | 17530 |
| -optimiert | - | - | -(2) |
| Pure | 0:26 | 17.779 | 12108 |
| Netzgrafik | |||
| Lattice | |||
| -normal | 0:30 | 23.320 | 5:06 |
| -optimiert | 0:45 | 23.056 | 5:00 |
| -mit IO-FPU | 0:45 | 20.812 | (3) |
| Pure | 0:13 | 20.791 | 3:41 |
| -mit IO-FPU | 0:13 | 20.791 | 0:58 |
| Datenbank | |||
| Lattice | |||
| -normal | 1:54 | 46.172 | 3:35 |
| -optimiert | 3:20 | 45.122 | 3:24 |
| Pure | 0:35 | 33.213 | 2:39 |
| Reversi | |||
| Lattice | |||
| -normal | 4:59 | 80.980 | - |
| -optimiert | 9:53 | 75.816 | - |
| Pure | 1:33 | 73.396 | - |
Bestimmende Faktoren für das Testergebnis:
Dhrystone : Datenflußanalyse, Stringcopy
Autorouter : Integer- und Pointer-Arithmetik, Datenflußanalyse
Netzgrafik : Fließkommabibliothek und FPU-Unterstützung
Datenbank : stream-IO. String- und Memory-Bibliothek
Reversi : GEM-Programm, 9000 Zeilen C, 1500 Zeilen Assembler, 300 KB Source
(1) Der Code der alten Lattice-Version war 15 % schneller.
(2) Optimierer versagte beim entscheidenden Modul.
(3) Führte zum Absturz.
Referenzrechner: Mega ST 4, 16 MHz Speeder, TOS 1.04, RAM-Disk, Quantum LPS 105.
Die Übersetzungszeiten enthalten die Zeiten für Compilieren und Linken. Die Programme wurden jeweils bzgl. Geschwindigkeitsoptimierung compiliert. Niedrige Zeiten bezeichnen bessere Werte, mit Ausnahme des Dhrystone-Benchmarks und des Autorouters, wo höhere Werte für linear bessere Ergebnisse stehen. Zeiten sind im Format Minuten:Sekunden Programmgrößen in Bytes angegeben.
Der Assembler...
...beherrscht Makros nach Motorola- und Lattice-Konvention und verarbeitet auch 68020-/68030-/68040- und FPU-Code, bietet aber im Vergleich zum Pure Assembler, selbst wenn man die im deutschen Handbuch nicht einmal beschriebenen dazunimmt, wenige Direktiven und ist um etwa Faktor 10 langsamer als dieser. Auch ist er nicht in der Lage, DRI-Objektcode zu erzeugen. Bei der Benutzung von 68020-/68030-spezifischen Adressierungsarten mußte der Assembler ebenfalls in einem Falle passen. Außerdem hat man offenbar das Status-Register vergessen.
Der Linker...
...arbeitet ausreichend schnell und ist in der Lage, selbst größere Objektcodes bis etwa 100 KB PC-relativ binden zu können, da er bei größeren Sprungdistanzen selbständig Sprungbefehle einfügt.
Mit DRI-Code kommt er jedoch nicht zurecht.
Der Debugger...
...ist derzeit ein Schwachpunkt des Systems, der Vergleich zum hervorragenden Pure C Source Level Debugger schon fast ungerecht zu nennen. Es handelt sich bei MonSTC um die Anpassung des für einen Assembler entwickelten Low-level-Debuggers für C, der immerhin in der Lage ist, einen C-Quelltext in einer Art Fenster darzustellen. Er bietet zwar Breakpoints, Disassembly von 68000 bis 68030 sowie FPU-Code, Speicher-Dump, läßt aber keine Änderungen an Strukturen und Variablen zu. Oft ist es einfacher, im Quelltext an den kritischen Stellen einige printfs einzufügen, als sich selbst und das Programm durch den Debugger zu quälen.
Der Debugger ist leider auch nicht mit Grafikkarten lauffähig. Ein Source Level Debugger befindet sich jedoch in Arbeit und soll in einigen Monaten, frühestens jedoch zur ATARI-Messe, verfügbar sein.
Das RCS...
...namens WERCS erlaubt zwar nur die Bearbeitung einer einzelnen Resource-Datei, läßt jedoch das Hinzuladen von weiteren zu und läuft in jeder Auflösung, sogar in ST-niedrig. Ein einfacher Icon-Editor ist enthalten, aber leider nicht auflösungsunabhängig, und stürzt mit Grafikkarten u.U. sofort ab. Die Bedienung erfolgt stark tastaturorientiert und unterscheidet sich somit von den meisten anderen RCS; mit etwas Gewöhnung läßt sich aber damit arbeiten.
Bibliotheken...
...sind neben den ATARI-spezifischen für GEM, TOS und LineA, die auch bereits aktuelle Entwicklungen wie FSMGDOS, CPX und Cookies berücksichtigen, sowie Erweiterungen dazu, auch noch aus dem UNIX- und dem Lattice-Bereich vorhanden. Sämtliche Bibliotheken sowie Start-up-Codes liegen in achtfacher Ausfertigung, je nach Einstellung des Compilers zu benutzen, vor. Als da wären Kombinationen aus 16- und 32-Bit-ints, Parameterübergabe in Registern bzw. Stack sowie basisregisterrelative oder absolute Datenadressierung. Die String- und Speicherfunktionen sowie Strukturübergaben sind relativ langsam, was sich auch beim Dhrystone-Benchmark negativ bemerkbar macht. Erfreulicherweise konnten in den Bibliotheken bis auf einige Ungenauigkeiten keine Fehler festgestellt werden.
Support...
...bietet CCD an zwei Tagen je Woche über Hotline-Zeiten sowie jeden Tag für zwölf Stunden via lokaler Mailbox, über die Fehler-Reports entgegengenommen, aber keine Update-Leistungen angeboten werden.
Resümee
Durch Fehlen einer Online-Hilfe, lange Compiler-Laufzeiten mit gutem Code für komplizierte Funktionen, die Vielzahl an Compiler-Optionen, Portabilität sowie umfangreiche Bibliotheken ist das System vorrangig für den professionellen Bereich interessant. Die 32-Bit-ints sowie einige Library-Funktionen sind für die Portierung vieler UNIX-Sourcen unentbehrlich. sofern man nicht den frei verfügbaren GNU-C-Compiler verwendet. Wer dagegen schnell und komfortabel Programme speziell für den ATARI entwickeln möchte, ist derzeit bei Pure C noch deutlich besser aufgehoben.
Den günstigen Preis dieses vollständigen Entwicklungswerkzeuges trüben die vielen kleinen Schwächen, die für den Hersteller jedoch zu beseitigen sein sollten. Eine Online-Hilfe zumindest soll zur ATARI-Messe im Herbst fertig sein.
Bliebe noch der Preis: 198,- DM zahlt man beim Umtausch gegen einen beliebigen anderen ATARI-C-Compiler, 398,-DM beim Neukauf.
Bezugsadresse:
CCD
Creative Computer Design Hixhheimer Straße 5 W-6228 Eltville
Positiv:
- voller ANSI-Standard
- guter Code
- umfangreiche Bibliotheken
- gute Bibliotheksdokumentation
- Profibuch
- 16-und 32-Bit-ints
- 68000 bis 68040, 68882
- Vollständigkeit
- Projektverwaltung
Negativ:
- schlechtes dt. Systemhandbuch
- schlechter Debugger
- keine Online-Hilfe
- langsamer Compiler u. Assembler
- viele kleinere Fehler
- IO-FPU fehlerhaft
Fazit: gutes Preis-/Leistungsverhältnis
Frank Baumgart