Solide Leistung: Aztec-C wendet sich an Profis
J. Resehke G. Steffens
Die Popularität von C auf dem Atari ST und die Schwemme neuer Compiler nimmt kein Ende. Seit einiger Zeit bietet nun auch das amerikanische Softwarehaus Manx einen C-Compiler für den ST an. Manx Software Systems Inc. war schon vor Jahren mit den Aztec-C-Compilern für CP/M und den Apple II im Geschäft. Mittlerweile hat Manx außerdem noch Compiler für MS-DOS, den Macintosh, den Amiga und eben jetzt auch für den ST im Programm. Es bietet diesen Compiler für den ST in zwei Konfigurationen an: Das »Professional System«, das nur Compiler, Linker und Libraries umfaßt, und das »Developer System« mit zusätzlichen Utilities wie beispielsweise »make«, »diff« und »grep«.
Zum Test stand uns das »Aztec Atari C/68K Developer System« in der Version 3.6A zur Verfügung. Bei diesem System handelt es sich um einen C-Compiler nach der »alten« Sprachdefinition. Die Entwickler haben zwar einige Vorschläge der ANSI-Kommission berücksichtigt, aber die wichtigsten Neuerungen wie beispielsweise die Form von Funktionsdeklarationen (»function prototyping«) nicht übernommen (siehe [1]). Es scheint aber auch bei Manx der Trend in Richtung ANSI-C zu gehen, da die jetzige Version die neuen Schlüsselworte »const«, »signed« und »volatile« zumindestens schon erkennt. Immerhin unterstützt sie bereits den neuen Datentyp »void * «. Die Header-Dateien sind ebenfalls nach dem ANSI-Standard aufgebaut, das heißt, daß jede Headerdatei beliebig oft und in beliebiger Reihenfolge zum Einsatz kommen darf, ohne daß dies zu Konflikten führt.
Wie bei den meisten anderen C-Compilern für den ST, handelt es sich auch bei Aztec-C um einen 16-Bit-Compiler. Dies bedeutet, daß der Datentyp »int« und ganzzahlige Konstanten als 16-Bit-Werte dargestellt werden. Da dies aber bei der Portierung von C-Program-men oft zu Problemen führt, läßt sich der Aztec-C-Compiler per Schalter zu einem 32-Bit-Compiler umstellen. Diese Funktion sollten Sie aber nur mit großer Vorsicht gebrauchen, da Sie bei ihrer Verwendung auch die entsprechenden Bibliotheken verwenden müssen.
Aztec-C bietet noch ein weiteres Merkmal, das man sonst nur von Compilern auf 80x86-Computern kennt: die sogenannten »Memory Models« (Speichermodelle). Dabei lassen sich voneinander unabhängig Code-und Datensegmentgröße einstellen. So werden im sogenannten »Small Model« alle Sprungbefehle PC-relativ ausgeführt und die Daten über das Register A4 relativ adressiert. Im »Large Model« erreicht man Code und Daten über absolute 32-Bit-Adressen. Wichtig sind hierbei die Beschränkungen des »Small Models«: Es sind zusammen nicht mehr als 64 KByte globale und statische Daten erlaubt, und Sprungbefehle reichen nicht weiter als 32 KByte.
Ein anderer Compilerschalter legt fest, ob Floatingpoint-Arithmetik im IEEE-, »Motorola Fast Floating Point« (FFP)- oder im 68881-Format erfolgt. Besitzer einer FPU- oder 68020-Karte danken es bestimmt. Für das »Motorola Fast Floating Point«-Format gibt es allerdings keine Unterstützung durch die Libraries.
Aztec-C erzeugt beim Compilieren aus dem C-Quelltext zunächst Assembler-Source. Es handelt sich also um einen Compiler mit streng getrennten Phasen, wie dies auch von Mark Williams - C her bekannt ist. Normalerweise löscht der Compiler die Assembler-Quelldatei nach dem Lauf des Assemblers — diese Funktion läßt sich aber ausschalten. Bei Aztec-C können Sie den Compiler sogar dazu bewegen, die C-Statements als Kommentar in die Assembler-Datei einzufügen. Dadurch vereinfachen Sie sich unter Umständen die Fehlersuche sehr. Inline-Assemblierung geschieht durch die Prä-Prozessoranweisungen # asm und #endasm. Leider erzeugt der Assembler keine Standard- (sprich Digital Research-kompatiblen-) Objektmodule, so daß die Kombination von Aztec-C mit anderen Sprachen problematisch ist. Insgesamt handelt es sich beim Aztec-Com-piler um einen recht ordentlichen Compiler mit zufriedenstellendem Codegenerator (siehe Benchmark-Kasten).
Neben dem Compiler erhalten Sie bei Aztec selbstverständlich noch weitere Tools. Bei der Shell hat Manx sich für das Public Domain-Programm »Guläm« (sprich: Gulaam) entschieden, das dem Paket in der Beta-Version 3.xx beiliegt. Guläm ist eine sehr stark an die UNIX-C-Shell (csh) angelehnte kommandoorientierte Shell — von Grafik, Menüs oder Mäusen ist im ganzen Aztec-Paket weit und breit nichts zu sehen. Für den Profi, der auch schon mal mit UNIX gearbeitet hat, ist Guläm bestimmt eine feine Sache, aber für den Gelegenheitsprogrammierer ist eine ordentliche GEM-Shell wie die von Turbo-C oder Laser-C sicherlich angebrachter. Auch der Profi hat seine Probleme mit Guläm: Dieses Programm installiert automatisch eine neue Tastaturbelegung, und zwar die US-amerikanische. Das läßt sich zwar mit einigem Aufwand patchen, aber der erweiterte Zeichensatz des ST (so beispielsweise die deutschen Umlaute) ist dem Anwender dennoch nicht zugänglich — und das bei einem Programm mit Umlaut im Namen.
Gleich zwei Editoren gehören zu Aztec-C: Der mitgelieferte Editor »Z« stellt eine recht gelungene Nachahmung des UNIX-Editors »vi« dar. Wer »Z« nicht benutzen will, greift auf den in Guläm integrierten »microEMACS« zurück. Auch hier gilt: Eher etwas für Profis, da beide Editoren zumindestens für den unerfahrenen Benutzer doch recht umständlich zu bedienen sind. In puncto Shell und Editor verliert Aztec-C eindeutig gegenüber anderen Systemen, speziell Turbo-C und Laser-C.
Weiterhin gibt es noch den Linker »In« für das Aztec-Objektformat. Es handelt sich hierbei — genau wie bei der gesamten Konkurrenz — um einen nicht-optimierenden Einpass-Linker. Er bindet also immer komplette Objektmodule zusammen, auch wenn diese Funktionen enthalten, die nie aufgerufen werden. Wie bei Einpass-Linkern üblich, hat der Benutzer für die richtige Reihenfolge von Modulen in eigenen Bibliotheken zu sorgen. Schlimmstenfalls muß er eine Library zweimal in der Kommandozeile von In aufführen, damit alle Referenzen aufgelöst werden.
Zu einem Compiler, der so deutlich auf den Profisektor abzielt wie Aztec-C, gehört mittlerweile selbstverständlich auch ein »make«. Hier hat sich Manx nicht lumpen lassen: Ein fast komplett UNIX-kompatibles »make« liegt bei der Developers Version bei. Hier bleiben keine Wünsche mehr offen. Weitere mitgelieferte Tools umfassen unter anderem einen Librarian, mit dem der Anwender Bibliotheken selbst zusammenbaut, sowie bekannte UNIX-Werkzeuge wie grep, cmp und diff.
| Aztec-C | Turbo C | |
|---|---|---|
| Intmath short: | 0,8350 Sekunden | 0,6000 Sekunden |
| Intmath long: | 2,3550 Sekunden | 1,0750 Sekunden |
| Realmath short: | 17,4300 Sekunden | 12,0600 Sekunden |
| Realmath long: | 12,1050 Sekunden | 11,7200 Sekunden |
| Triglog short: | 7,3000 Sekunden | 12,0450 Sekunden |
| Triglog long : | 7,1150 Sekunden | 11,9800 Sekunden |
| For: | 0,7700 Sekunden | 0,4650 Sekunden |
| Loop: | 0,8750 Sekunden | 0,6200 Sekunden |
| Repeat: | 0,7700 Sekunden | 0,4650 Sekunden |
| While: | 0,8700 Sekunden | 0,4600 Sekunden |
| ArrayAccess: | 1,2850 Sekunden | 0,6700 Sekunden |
| RecordAccess: | 0,9750 Sekunden | 0,6200 Sekunden |
| RecordArray: | 0,6000 Sekunden | 0,2800 Sekunden |
| WriteToFile: | 14,8400 Sekunden | 11,3000 Sekunden |
| ReadFromFile: | 9,9800 Sekunden | 9,9800 Sekunden |
| Pass Parameters: | 3,9550 Sekunden | 3,0600 Sekunden |
| Pass Structures: | 1,3850 Sekunden | 1,1200 Sekunden |
| Conversions: | 12,7250 Sekunden | 1,6250 Sekunden |
| Strings: | 0,8100 Sekunden | 0,3200 Sekunden |
Benchmark AG Version 1.2 für Aztec-C und Turbo-C
Die Standard-Libraries von Aztec-C, die wegen den verschiedenen Memory Models und der 16/32-Bit-Umschaltung übrigens in vier Versionen beiliegen, sind in drei Teile gegliedert: Zunächst die C-Library, die sämtliche bekannten Bibliotheksfunktionen wie beispielsweise das stdio-Paket enthält; hier sind auch die ST-spezifischen Funktionen gem-dos(), biosO und xbios() enthalten. Dann die Mathe-Library, die Routinen für die Floatingpoint-Arithmetik und die Floatingpoint-Versionen der printf- und scanf-Routinen enthält. Schließlich gibt es noch die GEM-Library, in der die Bindings für AES und VDI zu finden sind. Die C- und Mathe-Library umfaßt bereits einen großen Teil der vom ANSI-Standard geforderten Routinen, allerdings mit kleinen Schönheitsfehlern.
Ein nicht zu unterschätzender Punkt bei einem Entwicklungssystem ist die Dokumentation. Manx hat insgesamt knapp 600 Seiten in einem stabilen DIN-A5-Ordner verpackt. Einige durchaus wichtige Bereiche sucht man aber auch in dieser Menge an Informationen vergeblich. So gibt es weder Installationshinweise für Festplattenbesitzer, noch wird an irgendeiner Stelle auf die Existenz von GEM hingewiesen, geschweige denn die Funktionen der GEM-Library dokumentiert. Allerdings findet man ein sehr informatives Kapitel (immerhin 20 Seiten stark) mit nützlichen allgemeinen Hinweisen zur C-Programmierung. Zur Dokumentation (die uns übrigens nur im amerikanischen Original vorlag) ist noch anzumerken, daß einzelne Abschnitte von Rechtschreib- oder Grammatikfehlern wimmeln.
Ein Programm, das normalerweise zu einem wirklich professionellen Compiler gehört, fehlt bei Aztec-C ganz: ein Resource Construction Set. Ein Einzelschritt-Debugger ist für 128 Mark als Extratool erhältlich.
Für welchen Anwender eignet sich dieser Compiler besonders? Diese Frage ist bei Aztec-C schwer zu beantworten, da das System in keinem Anwendungsbereich überragende Leistungen bietet. Bei der großen Auswahl von Entwicklungssystemen für den ST darf man mit einer soliden Durchschnittsleistung eben nicht auf großen Ruhm hoffen.
(uh/ps)
Wertung
Name: Aztec-C/68K
Hersteller: Manx
Preis: Professional-System 348 Mark Developer-System 548 Mark
Stärken: □ Floating-Point-Unterstützung □ Profi-Shell und Editor □ Library-Quellcode erhältlich
Schwächen: □ Dokumentation unvollständig und schlecht redigiert □ kein RCS □ kein ANSI-Compiler □ kein Debugger
Fazit: nichts für Anfänger oder Gelegenheitsprogrammierer
Literaturhinweise:
[1]: Steffens, G.: Der Stand des Standards, ST-Magazin 9/88, S. 115 Bezugsquelle: Raab Datentechnik, Friedhofstr. 36, 8605 Hallstadt