Sprachentwirrung in Babylon: Programmiersprachen für den ATARI

Ist die Einarbeitungszeit am neuen Computersystem glücklich überstanden, und gibt die Bedienung des Computers keine unüberwindlichen Fragen mehr auf, so steht meist für den Anwender die Entscheidung vor der Tür, welche Programmiersprache für seine Anforderungen und Kenntnisse die beste Lösung darstellt.

Bei der großen Sprachenvielfalt die auf den ATARI-Rechnern existiert, ist dies nicht einfach zu beantworten.

Gerade Anfängern fällt es schwer, Leistungsumfang und Zielsetzungen der unterschiedlichen Sprachen zu vergleichen. Ist schon die Wahl der Computersprache schwierig zu treffen, so folgt gleich im Anschluß darauf das Problem, welche der Umsetzungen der verschiedenen Hersteller in Ausstattung, Preis und Leistung den besten Kompromiß darstellt. Die Werbeinformationen bieten da nur wenig Anhaltspunkte, ist doch jeder Hersteller überzeugt, sein Programmpaket sei ohne Fehl und Tadel und das ideale System zur Programmierung. Messen oder Vorführungen im Geschäft können zwar erste Einblicke geben, tiefergehende Informationen sind aber meist wegen Hektik und Zeitmangel nicht zu bekommen.

In diesem Schwerpunkt soll nun versucht werden, die Sprachen und Dialekte möglichst objektiv vorzustellen und einige Entscheidungshilfen zu geben. Um diesen Vergleich objektiver zu gestalten, hat nicht ein Autor allein alle Sprachen getestet, sondern jeweils ein Autor die Umsetzungen seiner Lieblingssprache. Dargestellt werden sollen sowohl die Stärken und Schwächen der einzelnen Systeme untereinander als auch die der jeweiligen Sprachimplementation.

Schwerpunkte

Die folgenden Schwerpunkte erscheinen uns dabei von besonderer Wichtigkeit:

Modernität

Eine Programmiersprache sollte sich durch eine moderne Konzeption auszeichnen. Dazu gehört eine zeitgemäß-komfortable Oberfläche, die GEM-konform sein sollte. Erweiterungen wie fliegende Dialoge und tastaturgesteuerte Menüs und Dialoge gehören heute bereits zum guten Ton vieler Programme. Besonders wichtig ist auch, daß alle ATARI-Rechner unterstützt werden. Eine Oberfläche, die Farbgrafikkarten oder die hohe TT-Auflösung nicht unterstützt sowie mit neuen Erweiterungen wie dem zu erwartenden MultiTOS nicht einigermaßen zurechtkommt, sollte nicht mehr erworben werden.

Unterlagen

Das Handbuch spielt eine nicht zu unterschätzende Rolle. Es muß sowohl dem Anfänger wertvolle Hilfe zum Einstieg in Sprache und System geben als auch dem Profi ein schnelles Nachschlagewerk für Funktionen, Fehlermeldungen und Interna von Parametern und Strukturen sein. Die Einführung und Lehre der Sprache kann von einem Handbuch jedoch nicht erwartet werden. Hierfür gibt es weit bessere Sekundärliteratur und auch Kurse verschiedener Anbieter, wie z.B. der Volkshochschulen. Im Anhang der einzelnen Sprachen sind einige Literaturangaben gemacht, die Anregungen geben können, aber natürlich bei weitem nicht vollständig sind. Neben einem guten Handbuch sollte der Hersteller auch eine Hotline betreiben, die bei nicht zu lösenden Problemen eine schnelle Hilfe bieten kann.

Strukturen

Es ist von Vorteil, wenn eine Programmiersprache einen sinnvollen strukturellen Aufbau besitzt. Ein gut strukturiertes Programm ist besser zu überschauen als eines, das wie ein kompakter Block aussieht und in dem wild zu verschiedenen Unterprogrammen gesprungen wird. Ein solches Programm ist darüber hinaus nur sehr schwer nachzuvollziehen, und Fehlerbeseitigung und Wartung erweisen sich als sehr schwierig. Die Unterstützung von größeren Projekten und daß die internen Strukturen der jeweiligen Sprache nicht zur Blockade bei der Programmierung werden, ist vorauszusetzen.

Funktionsumfang

Die volle Unterstützung des Betriebssystems ist eine fundamentale Voraussetzung, um auf einer Rechnerplattform programmieren zu können. Andererseits sollte die Portierung auf ein anderes System (z.B. MS-DOS) nicht zu unüberwindlichen Problemen führen. Da kaum ein Programm ohne Fehler entsteht, ist ein Debugger im System ein sinnvoller bis dringend notwendiger Bestandteil einer Sprache. Bei besonders zeitkritischen Anwendungen ist ein eingebauter Assembler ein nicht zu unterschätzender Vorteil. Eine Arbeitserleichterung ergibt sich, wenn dem Compiler noch zusätzliche Bibliotheken mit nützlichen Routinen und Unterprogrammen beigefügt sind. Gerade für Anfänger können Bibliotheken vom Hersteller oder Drittanbietern, welche die GEM-Programmierung erleichtern und erweitern, den großen Frust mit Bombenhagel und Absturz verringern und optisch ansprechende Applikationen ermöglichen.

Sprachen

Nachdem wir jetzt in der Theorie wissen, welche Anforderungen eine Sprache erfüllen muß, wollen wir versuchen, die Theorien mit Leben zu füllen. Aus der Vielzahl der Sprachen wurden die am meisten verwendeten ausgewählt. Hier sind zu nennen: Assembler, BASIC, C, Modula und Pascal. Zu jeder Sprache finden Sie am Anfang eine kleine Einführung über Herkunft und Zielsetzung, aber auch über vorhandene Stärken und Schwächen. Danach folgt eine Vorstellung der einzelnen Dialekte. Neben obigen Sprachen gibt es selbstverständlich noch weitere auf dem ATARI, wie z.B. Prolog, Forth, Fortran, Lisp und Perl. Alle diese Sprachen auch noch zu testen, würde den Rahmen dieses Beitrages bei weitem sprengen. Teilweise handelt es sich dabei um auf spezielle Anwendungen angepaßte Sprachen, die nicht so allgemeine Verwendung finden können wie die weiter oben angeführten.

Zum Schluß

Am Ende dieses Schwerpunktes möchten wir den Versuch wagen, einen Rat zu geben, welche Sprache für welchen Anwender am geeignetsten ist. Wie Sie ja schon gesehen haben, ist diese Entscheidung nicht ganz einfach zu treffen, letztendlich müssen Sie selbst einen Beschluß fassen. Wir wünschen Ihnen in jedem Falle viel Erfolg bei der Arbeit mit Ihrer neuen Programmiersprache und wenig Abstürze und Programmiererfrust!

# Zu den einzelnen Sprachen

Assembler

Mit einem Assembler ist man dem Prozessor am nächsten, kann diesen daher zwar am besten ausnutzen, sei es in bezug auf Speicherplatz oder Laufzeit, muß dafür aber einen erhöhten Schrcibaufwand und geringe Abstraktion vom Problem in Kauf nehmen. Dies gipfelt in einer gegenüber Hochsprachen deutlich erhöhten Fehleranfälligkeit und damit einem Debugging-Aufwand, was letztlich zu längeren Entwicklungszeiten führt. Die Gründe. Assembler dennoch in diesen Überblick prozedural orientierter Hochsprachen aufzunehmen, liegen darin, daß sich Assembler-Kenntnisse beim Umgang mit Debuggern auszahlen und einige Aufgaben, besonders hardwarenahe, nur in Assembler realisieren lassen.

Auch in zeitkritischen Abschnitten kann eine Programmierung in Assembler wegen einer Geschwindigkeitssteigerung von oft bis zu Faktor zwei sinnvoll sein. Dabei muß man den Einsatz von Assembler jedoch auch immer dem damit verbundenen Verlust der Portabilität gegenüberstellen. Die Möglichkeit. Assemblercode in Hochsprachen einzubinden, sollte auf jeden Fall vorhanden sein - sei es durch den Linker oder einen Inline-Assembler. Einigen Entwicklungssystemen liegt auch bereits ein Assembler bei. Makros stellen oft eine wertvolle Erweiterung dar.

C

Für Einsteiger ist C sicherlich weniger geeignet. zumindest erfordert es doch einiges an Disziplin und Einarbeitungszeit. Das liegt zum einen an der anfangs etwas kryptisch anmutenden Schreibweise und zum anderen dem Zeigerkonzept, welches man schon verstanden haben sollte, bevor man damit arbeitet. Durch Zeiger werden in C nämlich Referenzparameter realisiert, die als Sprachelement erst in C++ vorhanden sind.

Dann bietet sich jedoch ein enormes Betätigungsfeld. da man in C bis hin zur hardwarenahen Programmierung nahezu alles realisieren kann. Mit Zeigern, abstrakten Datentypen, Typprüfungen, einem Modulkonzept. das seinen Namen verdient, und einem leistungsfähigen Umfang der systemunabhängigen und portablen Standardbibliotheken nach ANSI bzw. deren POSIX-Erweiterungen bietet sich schon mit ANSI C ein äußerst leistungsfähiges Werkzeug. Dazu kommt ein Präprozessor, der nochmals einige Möglichkeiten, wie Makros, bietet, aber auch Fallstricke birgt. C ist zudem auf praktisch jedem Rechnertyp verfügbar und so weit verbreitet, daß man es als Standard bezeichnen kann. Von Systemen nach dem alten Kernighan/Ritchie Standard. wie z.B. dem als Public Domain erhältlichen Sozobon C, sollte man allerdings Abstand nehmen.

Durch die weite Verbreitung sind auch Bibliotheken meist zuerst oder sogar nur in C verfügbar, sowohl was GEM-Programmierung, als auch Erweiterungen neuerer Betriebssystem Versionen, insbesondere MiNT und MultiTOS angeht. Verständlich, wenn man bedenkt, daß diese Systeme selbst fast vollständig in C entwickelt sind. Auf ANSI C basieren die objektorientierten Sprachen C++ und Objective C, wovon zumindest C++ durch GNU C verfügbar ist. Eine GNU-Objeclive-C-Portierung für den ATARI konnte ich bislang nicht ausfindig machen. Daß auf dem ATARI noch kein kommerzielles C++-System verfügbar ist, kann zweifellos als Nachteil gewertet werden. Aus Frankreich wird es aber bald ein auf Lattice C aufbauendes C++-Frontend geben, welches auch bereits Templates bietet. So, wie C derzeit als Standard bezeichnet werden kann, wird C++ sicherlich der, mindestens aber einer der Standards der kommenden Jahre werden.

Pascal

Ursprünglich als Lehrsprache entwickelt und vor allem zur Beschreibung von Algorithmen gut geeignet, bietet Pascal alle wichtigen Kontrollstrukturen und Datentypen, außerdem Referenzparameter, hat im Vergleich zu C aber ein weniger mächtiges Zeigerkonzept. Man muß bei Pascal deutlich zwischen zwei Arten unterscheiden. Zum einen gibt es ein normiertes Standard-Pascal nach Wirth, dessen Entwickler. Es hat neben den Vorteilen, normiert und auf vielen Systemen verfügbar zu sein, den eklatanten Nachteil, sich kaum zur Programmierung größerer Programme zu eignen. Dazu ist die IO zu rudimentär, und ein Modulkonzept fehlt ganz. Ein solches System. wenngleich mit Erweiterungen, stellt CCD Pascal dar. Zum anderen gibt es den de facto Standard namens Turbo Pascal, auf dem ATARI in einer sehr guten Version als Pure Pascal verfügbar, weiches ein Modulkonzept ebenso wie objektorientierte Erweiterungen von Turbo Pascal 6.0, wenngleich sie nicht die Mächtigkeit von C++ erreichen, bietet. Trotz allem bleibt die IO eine Schwäche von Pascal, die nur durch unportable Programmierung zu umgehen ist. Außerdem sind Standard- und Turbo Pascal zueinander nur in Grundzügen kompatibel und Turbo-Pascal-kompatible Quelltexte nur auf PCs und ATARIs verwendbar.

Modula

Einige Jahre später als Pascal und ebenfalls von Wirth entwickelt, sind sich beide Sprachen recht ähnlich. Wie schon am Namen zu erkennen, gibt es in Modula aber ein Modulkonzept. welches dem von C sehr ähnlich ist. Außerdem existiert ein leistungsfähigerer Sprachstandard als der von Standard Pascal. Was die Schreibweise angeht, ist Modula geradezu das Gegenteil von C. Statt kryptischer Kurzschreibweise gibt es fast Klartextbefehle, was leider auch mit entsprechender Tipparbeit verbunden ist und einen Editor mit Textkürzeln wünschenswert macht. Hinderlich ist auch die gemischte Groß-/Kleinschreibung vieler Standardbezeichner, die Tippfehler geradezu provoziert, zumal sämtliche externen Funktionen im Hauptprogramm explizit bekannt gemacht werden müssen.

Eine etwas exotische Besonderheit von Modula stellen die Coroutinen dar. die eine synchronisierte, quasi-nebenläufige Ausführung von Programmteilen erlauben, bei denen die Kontrolle über die Ausführung dieser Prozeduren explizit übertragen werden muß. Es handelt sich also durchaus nicht um eine parallele oder quasi-parallele Ausführung von Prozeduren.

Neben der Tipparbeit und umständlichen IO kam Modula vermutlich außerdem zu spät, um sich gegen C durchzusetzen. Trotzdem ist Modula auf dem ATARI recht weit verbreitet, und mit Hanisch Modula liegt außerdem ein System vor, das sich auf dem Stand der Technik befindet. Zudem gibt es das Public-Domain-System LPR Modula. welches ein vollständiges System darstellt, aufgrund diverser Fehler in den Standardbibliotheken sowie der eingestellten Weiterentwicklung aber nicht separat getestet wurde. Zum Hineinschnuppern eignet es sich trotzdem.

BASIC

Auf dem ATARI hat BASIC, vor allem durch GFA-BASIC. schon lange nichts mehr mit dem verpönten Spaghetti-Code vergangener Jahre zu tun, sondern erinnert mit den Kontrollstrukturen eher an Pascal. Doch einen Sprachstandard sucht man vergebens, und die beiden vorherrschenden ATARI Implementationen sind zueinander kaum weniger kompatibel als GFA-BASIC auf dem ATARI zu dem unter MS Windows. Omikron und GFA BASIC gemeinsam ist, daß ihnen sowohl ein Modulkonzept als auch abstrakte Datentypen und Konstanten fehlen. Daß man nur einen verschwindend kleinen Teil der BASIC-Compilate als saubere GEM-Programme. also unter anderem in beliebigen Auflösungen, Farbtiefen und Betriebssystemversionen lauffähig, bezeichnen kann, spricht ebensowenig für die Erstellung von GEM-Programmen in BASIC wie die Tatsache, daß die Oberflächen der BASIC-Interpreter fast völlig am GEM vorbei programmiert sind. Nur Omikron.BASIC ist zudem auf einigen Farbgrafikkarten lauffähig. Saubere GEM-Programme in GFA-BASIC sind ohne Patches nicht einmal möglich, doch soll das in Entwicklung befindliche GFA-BASIC 4.0 hier Abhilfe schaffen. Ohne komplexe Datenstrukturen. Stichwort MFDB, ist man aber auch dann vor Poke-Orgien nicht sicher.

Einige Vorteile zeichnen BASIC dennoch aus. Zum einen läßt sich mit beiden Interpretern selbst von Diskette noch arbeiten. Da ist zum zweiten die Interaktivität, mit der sich BASIC-Programme im Interpreter erstellen und austesten lassen, auch wenn man aufgrund des fehlenden Modulkonzeptes bei der Compilierung wieder größere Tum-around Zeiten in Kauf nehmen muß. Lcarning by doing erweist sich jedoch nur solange als Vorteil, wie es nicht in einer Trial-and-error-Mentalität endet. Eine sehr schöne und doch letztlich mit Einschränkungen verbundene Eigenschaft von BASIC ist die dynamische String-Verwaltung.

Ein weiterer Vorteil liegt in der schnellen Erstellung von Grafiken und Berechnungen, ohne daß man sich um GEM-konforme Programmierung zu kümmern braucht, wenn diese für die Aufgabenstellung gar nicht verlangt ist. Natürlich muß man sich im klaren darüber sein, daß so etwas weder portabel noch als sauberes GEM-Programm sonderlich brauchbar ist, doch um schnell sichtbare Ergebnisse zu erzielen, ist BASIC bestens geeignet. Dazu trägt auch die Mächtigkeit der Befehlssätze bei. Vor größeren Projekten in BASIC, zumal mit mehreren Personen, kann man nur abraten.

Konverter

Beim Umstieg zwischen einigen Hochsprachen ist es möglich, seine alten Quellen weiter zu verwenden, zumal eine Mischung zwischen Objektcodes verschiedener Hochsprachen oft nicht möglich ist. Beim Umstieg von Pascal nach C gibt es einen hervorragenden Konverter als Freeware unter der GNU Licence namens p2c von D. Gillespie (1). Dieser generiert wartbaren und vielfältig optischen und technischen Bedürfnissen anpaßbaren C-Quelltext, ohne zusätzliche Bibliotheken einbinden zu müssen. Selbst bei der Umsetzung von Modula Quelltexten nach C hilft einem p2c noch. Die Portierung des p2c auf dem ATARI ist allerdings nicht sonderlich stabil. Schwieriger ist schon die Umsetzung von BASIC-Quelltexten. Für GFA-BASIC-Quellen bietet sich der BASIC-nach-C-Konverter von Cicero an, der allerdings den Schwerpunkt auf die Nachbildung des GFA-BASIC-Befehlsumfanges legt und somit C-Quelltext erzeugt, der zwingend die Verwendung der Konverterbibliotheken verlangt. (2)

(1) zu finden z-B. auf ftp.uni-sh.de

(2) siehe ST Computer 9/92, S.40ff

Assembler

Assembler gehört mit zu der Muttersprache eines jeden Computers und hat auch heute noch, trotz immer besser optimierender Hochsprachencompiler, seine Daseinsberechtigung, wenn es darum geht, zeitkritische oder genau an die Hardware eines Computers angepaßte Programmteile zu schreiben. Es lohnt sich heute allerdings kaum mehr, größere Projekte komplett in Assembler zu verwirklichen.

Easy-Rider

Zum Glück haben sich auf dem ATARI mittlerweile drei Standards für Objektdateien (das sind Zwischendateien, die von Assemblern oder Compilern erzeugt wer den. um dann von einem Linker zu einem lauffähigen Programm verbunden zu werden) entwickelt. Hierbei handelt es sich um das DR-Format (entwickelt von Digital Research), das GST-Format (entwickelt von dem gleichnamigen englischen Software-Haus) und das Pure-Format (benutzt von den Pure-Compilern von ASH).

Der Easy Rider-Assembler, der mittlerweile in der Version 4.0 vorliegt, unterstützt das DR- und das GST-Format. Damit stehen dem Programmierer alle Wege offen, um seine mühevoll erstellten Assembler-Module auch anderen Hochsprachen als Module zugänglich zu machen.

Doch kommen wir erstmal zu den Besonderheiten dieses Assemblers. Man kann zwischen drei verschiedenen Ausbaustufen des Easy-Rider-Paketes wählen. Da wäre zum ersten nur der Assembler alleine. Er wird in einer stabilen Kunstoffbox auf zwei Disketten zusammen mit einem. 128seitigen, sehr gutem Handbuch und einem 38seitigen Ergänzungshandbuch, das auf die neuen Adressierungsarten des 68030- und des 68881/2-Prozessors eingeht, geliefert und kostet DM 199,-. Dann wäre da der sehr gute Reassembler, der ebenfalls in einer Kunststoffbox auf einer Diskette zusammen mit einem 116seitigen Handbuch und einem 34seitigen Ergänzungshandbuch, das auf die neuen Funktionen der Version 4.0 eingeht, für DM 249,- ausgeliefert wird. Und zu guter Letzt gibt es beide Programme auch als ein Komplettpaket für DM 425,-.

Der Easy Rider-Assembler ist allerdings auch in der vorliegenden Version (siehe auch ST-Computer 3/92 Seite 44ff. "Take it Easy") immer noch nicht in eine GEM-Umgebung integriert und schreibt direkt in den Bildschirmspeicher.

Aus diesem Grund läuft der Assembler auf einem TT oder Falcon nur in der mittleren bzw. hohen ST-Auflösung. Besonders im Hinblick auf das angekündigte MultiTOS ist das doch ein Manko, das mit der nächsten Version unbedingt behoben werden sollte. Aber sonst macht der sehr schnelle Assembler einen guten Eindruck, zumal man die Funktionstasten per ASCII Datei frei belegen und sich damit eine persönliche Arbeitsumgebung schaffen kann. Das ist auch nötig, da dem Assembler ein integrierter Debugger oder Editor fehlt. Dem Paket liegt allerdings der Editor Tempus V1.1 bei. der allerdings auf dem Falcon nicht funktioniert. Man kann aber ohne Probleme seinen Lieblingseditor einbauen, wobei ich hier auf EDISON (siehe ST-Computer 1/93, Seite 24, "6 Texteditoren im Vergleich") hinweisen möchte, da man diesen Editor als Shell für den Assembler auch frei programmieren kann.

Ein typischer Arbeitsablauf mit dem Easy Rider sieht folgendermaßen aus. Zuerst wird mit einem beliebigen Editor der Assembler-Quelltext erstellt. Dann wird Easy Rider aufgerufen und als Parameter der Pfad der Quelltextdatei übergeben. Nun assembliert Easy Rider den Quelltext und führt auf Wunsch automatisch Optimierungen im Objektcode vor. Auch kann der im Assembler integrierte Linker Objekt-Dateien im Pure-Format lesen, womit man auf diese Art auch in einer Hochsprache (Pure C oder Pure Pascal) geschriebene Module vom Assembler aus ansprechen kann. Der Linker erstellt dann ein lauffähiges Programm. Falls der Quelltext noch nicht fehlerfrei war muß man wieder in den Editor wechseln, den Fehler beseitigen und das Programm nochmal neu assemblieren.

Dem Easy-Rider-Paket liegen auch noch einige Tools wie ein Bibliotheksmanager, Beispielmakros und AES- und VDI-Libraries bei. Auch sind alle Systemvariablen des ATARI ST definiert, so daß sie im Programm mit ihrem symbolischen Namen angesprochen werden können.

Und dann gibt es ja noch den Reassembler...

Auf den Easy-Rider-Re- und -Disassembler (siehe auch ST-Computer 3/92, Seite 44ff., "Take it Easy") möchte ich hier nur kurz eingehen, da sich dieser Artikel ja mit Programmiersprachen beschäftigt. Die in dem Artikel genannten Schwachpunkte der GEM Einbindung sind alle behoben. Die Textausgabe erfolgt sauber in ein Fenster, welches auch mit allen Randelementen (Sizer, Slider) versehen ist. Die im Artikel noch angesprochenen Probleme mit MultiTOS sind damit hoffentlich aus der Welt. Auch läuft der Reassembler sauber in allen Auflösungen des Falcon.

Leider liegt dem sonst sehr guten Programmpaket kein Debugger bei, so daß man zum Entwanzen seiner Programme einen anderen Debugger benutzen muß. Aber auch das kann man wieder als Vorteil sehen, da man auf diese Art seinen bekannten Lieblings-Debugger benutzen kann.

Fazit

Das Easy Rider-Paket eignet sich bei dem Lieferumfang und dem Preis eigentlich nur für die Leute, welche sich ernsthaft mit der Assembler-Programmierung auf dem ATARI ST/TT/Falcon beschäftigen wollen. Falls man nur mal so in die Programmierung von MC680x0-Prozessoren auf Assembler-Ebene reinschnuppern möchte, sollte man doch auf einen günstigeren Assembler aus dem PD- oder Shareware-Bereich zurückgreifen. Allerdings lohnt sich auch für solche Leute der Erwerb des Reassemblers. Und die dritte Gruppe von Programmierern, die nur kurze Routinen in Assembler schreiben wollen, sollten die in die Hochsprachen integrierten Assembler benutzen, da man dann gleich eine Hochsprache zum Assembler dazu hat.

Bezugsquelle: Andreas Borchard Wiesenbachstraße 2a W-4500 Osnabrück

Arbeitsumgebung des Assemblers
Arbeitsumgebung des Disassemblers

Turbo Ass

Als zweiten Assembler in dieser Übersicht möchte ich den Shareware-Assembler Turbo Ass von Markus Fritze vorstellen. Das Programm wird gepackt mit einigen ebenfalls gepackten Zusatzprogrammen und einem Installationsprogramm auf einer doppelseitigen Diskette ausgeliefert.

Zum Installieren benötigt man entweder ein zweites Diskettenlaufwerk oder eine Festplatte. Die Installation selber ist dank des Installationsprogrammes sehr einfach. Man wählt in einer Auswahlbox einfach alle Programmteile an, die man benötigt. Da wären zum Beispiel der Assembler selber. Demo-Sourcen, Libraries, Dokumentation und noch einiges mehr.

Der Autor verlangt für den Assembler einen Shareware-Betrag von DM 50,-. Dafür bekommt man die aktuelle Version des Assemblers, ein kostenloses Update und eine 240seitige Bedienungsanleitung. Außerdem gibt es noch einen zusätzlichen Anreiz, sich registrieren zu lassen. Man erhält nach der Registrierung seine persönliche Version mit eigener Seriennummer. Wenn sich nun Bekannte ebenfalls für den Turbo Ass registrieren lassen wollen und als Referenz eine Seriennummer angeben, bekommt der Inhaber dieser Seriennummer bis zu 10 mal 10,-DM für die neue Registrierung. Dies ist als Entschädigung für das Vorführen des Assemblers gedacht.

Was ist nun alles in diesem Paket enthalten? Nun, da wäre zuerst der Assembler, der mir in der Version 1.70 vorlag. Desweiteren ist ein symbolischer Debugger enthalten, der vom Assembler aus aufgerufen werden kann. Ferner gibt es noch diverse Tools, wie den Text- und Bildbetrachter Guck, der in der Version 1.7 dem Paket beigelegt ist. Dann gibt es da noch ein Resource-Construction-Set, mit dem die grafischen Elemente für GEM-Programme auf einfache Weise selbst in kurzer Zeit erstellt werden können. Auch an Beispiel-Sourcen für alle Probleme, auf die ein Hobby Programmierer so treffen kann, fehlt es dem Paket nicht. Außerdem sind, wie bei Easy Rider auch, diverse Libraries für die AES- und VDI-Programmierung des ATARI beigelegt. Selbstverständlich fehlen auch solche Dinge, wie einige Packer samt Packer-Shell und eine sehr gute Kurzanleitung und Einführung in den Turbo Ass ebenso wenig, wie einige Druckertreiber und ein Programm, mit dem auf einfache Weise das TOS des ATARI gepatcht werden kann. Man sieht, es ist alles dabei, was das Programmiererherz begehrt.

Der Assembler läuft auf allen ATARI-Computern, einschließlich dem neuen Falcon, ohne Probleme. Im Assembler ist ein eigener Editor integriert, der allerdings mit solchen Funktionen wie Kopieren, Suchen, Einfüge- und Überschreibmodi und einigem mehr aufwarten kann. Der integrierte Editor nimmt auch schon zur Eingabezeit einen Online-Syntax- und Semantikcheck der gerade eingegebenen Zeile vor und findet so mit hoher Zuverlässigkeit all die Fehler, die gerade einem Anfänger immer wieder sehr schnell passieren können. Zusätzlich kann der Editor auch schon zur Eingabezeit selbständig optische Verschönerungen wie das Großschreiben von Labeln, Assembler Befehlen und Variablen, das Austauschen von der Schreibweise A7 für den Stackpointer gegen die ebenfalls gebräuchliche Schreibweise SP oder das Entfernen von führenden Nullen bei Konstanten durchführen. Bei all diesen Fähigkeiten wundert es einen eigentlich kaum noch, daß der Editor die eingegebene Zeile in eine Token-Form vorübersetzt, um so das Assemblieren wesentlich zu beschleunigen.

Der Editor kann Quelltexte sowohl als ASCII-Text als auch in seinem eigenen Formal, in dem der gesamte Quelltext in Token-Form abgespeichert wird, lesen und schreiben. Außerdem wird im eigenen Format die gesamte Arbeitsumgebung wie markierte Blöcke, Position des Cursors, Schreibmodus und das Datum der letzten Änderung am Quelltext mitabgespeichert. Das ist besonders angenehm, wenn man an längeren Projekten arbeitet und zwischendurch den Computer mal ausschalten muß. Wenn man dann den Source-Text neu lädt, findet man alles so vor, wie man es vor dem letzten Speichern verlassen hat.

Assembler

Bei so einem gut durchdachtem Editor wundert es einen eigentlich auch nicht mehr, daß der Assembler natürlich bei der Assemblierung das Programm sowohl im Hinblick auf die Ausführungszeit als auch auf die Programmlänge optimiert. Viele von diesen Optimierungen wie Sprung-und PC-relativ-Optimierungen, PC-relativ nicht über Segmentgrenzen, Absolut-short-Warnungen und die Wandlung nach PEA bzw. LEA lassen sich manuell ein-und abschalten. Außerdem ist der Assembler sehr kontaktfreudig. So kann er Objektdateien im DR-Format ebenso erzeugen wie Data-Zeilen für BASIC-Programme und GFA- bzw. Omikron.BASIC-Inline-Dateien. Außerdem kann man den Source-Text absolut auf eine bestimmte Adresse assemblieren lassen und so einfach Programme für EPROMs erstellen. Der Assembler gehört mit zum Schnellsten, was man zur Zeit bekommen kann. Dies liegt aber daran, daß der Assembler schon vom Editor vorübersetzte Dateien vorgesetzt bekommt.

Wie schon geschrieben wurde, ist der Turbo Ass Shareware. Das bedeutet natürlich auch, daß dem Programm eine Komplettanleitung fehlt. Es liegt aber eine 28KB lange Kurzanleitung als Datei dem Paket bei, in der der Umgang mit dem Assembler ausführlich beschrieben wird. Die Anleitung reicht für den interessierten Einsteiger auf jeden Fall aus, um den Assembler nach den ersten Fehlschlägen in der Assembler-Programmierung nicht sofort wieder wegzulegen. Die Anleitung geht sogar auf solche Dinge wie die automatische Code-Optimierung mit Beispielen ein. Auch dies ist für ein Shareware-Programm ein löbliches Beispiel. Und wer mehr wissen möchte, hat sich meistens so lange mit dem Assembler beschäftigt, daß es nur fair ist, sich für die DM 50,- registrieren zu lassen und so ein 240seitiges Handbuch zu erwerben.

Der Debugger erfüllt alle Aufgaben, die man von einem Debugger erwartet. Leider läuft er auf dem Falcon nur in den ST Auflösungen. Der Assembler macht auf einem Falcon unter TOS 4.01 auch keine Probleme. Auf alle sonstigen beigefügten Tools weiter einzugehen, ist nicht Sinn dieses Berichts und würde auch den Rahmen dieses Artikels sprengen.

Fazit

Der Turbo Ass ist eigentlich für alle die Leute interessant, die sich generell mit Assembler auf dem ATARI beschäftigen wollen. Leider unterstützt der Assembler zur Zeit nur den Befehlssatz des 68000-Prozessors. Man müßte abwarten, ob der 68030-Prozessor und der 68882-Fließkommaprozessor, die im TT und Falcon Verwendung finden, ab einem der nächsten Updates unterstützt werden.

Bezugsquelle:

Markus Fritze Birkhahnkamp 38 W 2000 Norderstedt 1

C

GNU C

Das GNU-C-System der Free Software Foundation ist kostenlos und mittlerweile auf fast jeder Rechnerplattform verfügbar. Es stellt allerdings die höchsten Anforderungen aller getesteten Systeme an den Rechner. Ein Hauptspeicher von 2 MB reicht allenfalls für kleine Projekte, 4 MB RAM sollten zum sinnvollen Arbeiten schon vorhanden sein, für C++ sind sie auch so ein Muß. Auch auf der Festplatte gibt sich GNU C kaum mit weniger als 4 MB zufrieden, nimmt man C++, die Dokumentation, die ebenfalls verfügbaren Quelltexte zu Compiler und Bibliotheken und einige Tools dazu, sind es bereits über 16 MB.

C und C++

Allein C- und C++-Compiler sind jeweils um 1 MB groß. Verglichen mit Lattice oder gar dem schnellen Pure C ist GNU C bei der Compilierung zudem um mehrere Faktoren langsamer, zur ständigen Programmentwicklung ist ein TT daher sehr zu empfehlen. Will man nur bisweilen fremde Quellen, z.B. aus der UNIX- oder GNU-Welt übersetzen, reicht ein 16-MHz-Rechner allerdings auch, vor allem, wenn man auf Optimierungen verzichtet.

Eine integrierte Entwicklungsumgebung wie bei Pure oder Lattice C gibt es für GNU C nicht, üblicherweise arbeitet man mit einer Shell und Make. Etwas mehr Komfort erreicht man durch MiNT in Verbindung mit TOSWIN und, je nach Geschmack, vi oder Emacs, oder aber einen guten GEM-Editor(3). Erst mit MiNT und MultiTOS, möglichst in Verbindung mit einem schnellen Rechner, erschließt sich die Leistungsfähigkeit von GNU C auf dem ATARI.

Und da sind wir auch gleich bei einer Stärke dieses Systems. Es bietet den vollen ANSI-Standard, umfangreiche Bibliotheken und ist, da nahezu überall verfügbar, hervorragend zur Portierung von Programmen geeignet. Bei Pure C und Lattice C muß man diesbezüglich, bei ersterem wegen eingeschränkter Bibliotheken und Beschränkung auf 16 Bit ints. bei letzterem wegen beschränkter Codegröße einzelner Module, nämlich Abstriche machen. Nicht nur, daß es für den Compiler Anpassungen an die verschiedensten Hardware-Plattformen gibt, auch Crosscompiler lassen sich erstellen. Somit ist es möglich, auf einer Workstation Code für den ATARI zu compilieren. Ein solches System ist auf einer Sun SparcStation an der Uni Paderborn bereits seit längerem recht erfolgreich im Einsatz.

Die Codequalität ist, besonders bei Einsatz der zeitaufwendigen Optimierungsstufen. sehr gut und kann sich mit der der beiden anderen Systeme messen, wenngleich die ausführbaren Programme meist etwas größer sind.

Da nicht nur Compiler, sondern auch die Bibliotheken im Quelltext vorliegen, hat man die Möglichkeit, Fehler darin selbst zu beheben oder sich die Implementation anzusehen. Die Bibliotheken - es gibt neben der Aufteilung zwischen 16- und 32-Bit-ints zwei verschiedene, einmal die GNU-Lib und dann die MiNT-unterstützende MiNT-Lib sind mittlerweile aber fast fehlerfrei. Der Compiler selbst ist sehr ausgereift und meiner Erfahrung nach eher fehlerfrei als die beiden anderen C Systeme. Er erzeugt auf Wunsch auch FPU-Code für den TT. der sich mit einem Emulator (4) auch auf STs mit Coprozessorkarte nutzen läßt.

Auch die Einbindung von Assembler-Modulen ist möglich, erzeugt GNU Cdoch selbst Assemblersource, die erst durch den nachfolgenden Assemblerlauf in Code übersetzt wird. Die Assembler-Syntax ist allerdings ungewohnt, und etwas Komfort, wie bei den Makro-Assemblern bei Pure und Lattice C, sucht man vergebens.

Mit GNU C bietet sich auf dem ATARI derzeit noch die einzige Möglichkeit, in C++ zu programmieren. Die Implementation ist stabil und bietet alle relevanten und standardisierten Merkmale. Wer auf dem ATARI in einer praxisnahen Sprache objektorientiert arbeiten will, kommt an GNU C nicht vorbei. Seit kurzem liegt auch eine Erweiterung in Richtung Objective C, das mehr Ähnlichkeit zu Smalltalk aufweist, vor, die zum Test aber leider nicht zur Verfügung stand.

Schwächen der GNU-Implementation auf dem ATARI liegen im Debugger, der bei jeder sich bietenden Gelegenheit das Drücken des Resettasters übernimmt. Auch das make sollte man besser gegen ein anderes, beispielsweise aus dem Sozobon (ein Public-Domain-C-Compiler nach altem Kernighan/Ritchie-Standard)-Compiler-Paket oder ein in einen Editor wie PKS-Edit integriertes, austauschen.

Bei der Bewertung der Dokumentation muß man verschiedene Maßstäbe anle-gen. Neben den in manchen Distributionen vorhandenen TeX-Dokumenten und Installationsanleilungen gibt es gute Unterstützung durch Newsgroups im Usenet sowie auch in einigen Mailbox-Netzen. Dies hilft einem natürlich nur dann, wenn man Zugriff darauf hat und Englischkennt nisse mitbringt, ohne die man gerade bei GNU C nicht weil kommen und vermutlich schon bei der Installation scheitern wird.

Fazit

GNU C ist hervorragend zur Portierung von Programmen fremder Systeme auf den ATARI geeignet. Ebenso stellt GNU C++ momentan das einzige C++-System für den ATARI dar, welches zudem noch vollständig ist. Bedingt durch die Größe des Systems, sowohl was die Anforderungen in bezug auf Übersetzungszeit als auch Speicherplatz angeht, und vor allem die nicht jedem zugänglichen Support-Möglichkeiten ist GNU C allerdings nur für einen bestimmten Benutzerkreis interessant. Für moderne GEM-Programme eignen sich außerdem Pure und Lattice C deutlich besser, da für GNU C praktisch weder GEM Bibliotheken mit fliegenden oder Fensterdialogen noch Unterstützung seitens Interface oder ACS verfügbar sind.

(3) siehe ST Computer 1/93, "Texteditoren im Vergleich"

(4) Line-F-Emulator von M. Hauschild, in Mailboxen

Bezugsquelle:

Erhältlich ist GNU C in einigen Mailboxen, vor allem aber auf ftp-Servern, z. B. ftp.uni-paderborn.de

Lattice C

Umfangreiche Projekte komfortabel im Griff

Mit Lattice C erhält man eine komplette Entwicklungsumgebung, zu der neben dem eigentlichen Compiler-System ein RCS, Hilfsprogramme und Beispiele gehören. Mit dem Installationsprogramm sind die benötigten Daten komfortabel auszuwählen und schnell auf Festplatte, die zum Betrieb sehr zu empfehlen ist, kopiert. Eine Komplettinstallation benötigt 4 MB. eine Minimalinstallation findet gerade noch auf einer Diskette Platz, so daß man rein theoretisch auch mit Diskettenlaufwerk und RAM-Disk arbeiten kann. Sämtliche Programme sind sowohl über die integrierte GEM-Oberfläche als auch separat aus einer Shell zu starten. Die Übersetzung von Programmen kann daher unter MiNT und MultiTOS auch im Hintergrund ablaufen, wenn man auf die GEM-unterstützte Bedienung verzichtet. Zur Erstellung von GEM-Programmen wird WERGS, ein Resource-Construction-Set, mitgeliefert, zwar nicht ganz auf dem Stand der Technik, aber brauchbar. Die Libraries enthalten auch ein Modul zur Erstellung von CPX-Modulen. Inzwischen gibt es auch vom ACS eine an Lattice C angepaßte Bibliothek.

Die Dokumentation umfaßt zwei gute englische, allerdings im betriebssystemabhängigen Teil nicht ganz aktuelle Referenzhandbücher sowie ein mäßiges deutsches Benutzerhandbuch. Insgesamt um die 1000 Seiten recht dichte Information, wobei es dem Benutzerhandbuch jedoch sowohl am Index, manchmal der Verständlichkeit und oft ausführlicheren Informationen mangelt.

In der integrierten Entwicklungsoberfläche ist vor allem die Projektverwaltung hervorzuheben, in welcher sich komfortabel Abhängigkeiten zwischen Dateien festlegen lassen. Auch die Einstellung der vielen Compiler-Optionen ist nahezu optimal gelungen. Die Dialoge sind trotz der Vielzahl an Einträgen übersichtlich aufgebaut. jedoch leider nicht tastaturbedienbar. Beim Betrieb auf Farbgroßbildschirmen gab es ebensowenig Probleme wie unter MiNT und MultiTOS, wenn man vom fehlerhaften Scrolling im Hintergrund absieht.

Im Editor lassen sich bis zu 7 Texte gleichzeitig bearbeiten, doch muß der Speicher für die Textpuffer generell statisch fest eingestellt werden. Sieht man von der ungewöhnlichen Tastatursteuerung, die sich weder an den Standard hält noch durch Assoziativität glänzt, ab, läßt sich mit dem Editor durchaus vernünftig arbeiten. Unterstützung des Clipboards und Einrücken von Blöcken sucht man allerdings auch vergebens. Warnungen oder Fehlermeldungen des Compilers können nur dann angesprungen werden, wenn der Quelltext zum Zeitpunkt der Compilierung bereits in den Editor geladen war. außerdem ist der Speicher für die Compiler-Meldungen begrenzt, so daß die älteren Meldungen verlorengehen.

Compiler

Der Compiler kennt nicht nur 16- und 32-Bit-ints. sondern ist auch sonst sehr vielfältig konfigurierbar. Zusätzlich kann ein globaler Optimierer den erzeugten Programmcode hinsichtlich Größe und/oder Geschwindigkeit optimieren. Wegen dessen Zeitbedarf bietet sich das hauptsächlich im späteren Stadium der Programmentwicklung an. Compiler und Optimierer versehen ihre Aufgabe sehr gründlich und geben differenzierte Fehlermeldungen und Warnungen, optional in Deutsch, von sich. Neben der vollen Unterstützung des ANSI Standards, sonst nur in GNU C zu finden, ist dies einer der Hauptvorteile des Lattice-C-Systems. FPU-Unterstützung gibt es sowohl für den TT als auch, wahlweise mit automatischer Erkennung, für den ST, diese funktioniert allerdings erst nach einem Patch auf allen Rechnern.

Assembler

Der Makro-Assembler reicht für die Entwicklung von Modulen völlig aus, erlaubt 68000- bis 68030- und FPU-Code, wird aber in der Dokumentation nur unzureichend beschrieben.

Bibliotheken

Die Bibliotheken sind umfangreich und enthalten neben den ANSI-Funktionen Erweiterungen aus dem POSIX- und Lattice-Bereich, die man bei Portierungen, gerade aus dem UNIX-Umfeld, schnell schätzen lernt. MiNT-Unterstützung findet man aber auch hier erst in der bereits erwähnten MiNT-Lib. Außer natürlich Accessories lassen sich mit Hilfe spezieller Start-Up-Codes auch CPX-Module erstellen, ein gut kommentiertes Beispiel liegt im Quelltext bei.

RCS

Als einziges C-Entwicklungssystem enthält das Lattice-Paket ein RCS. Es ist weitgehend auf Tastaturbedienung ausgelegt, und obwohl man mit WERCS, so dessen Name, nur eine Resource bearbeiten und kaum moderne Dialoge gestalten kann, reicht er doch für einfachere Zwecke aus. Für moderne GEM-Umgebungen muß man, wie bei Pure C auch, auf Bibliotheken von Fremdanbietern, Interface oder das ACS ausweichen.

Debugger

Leider sind bislang weder eine Online-Hilfe noch ein Source-Level-Debugger verfügbar, und die Arbeit mit dem nur in den ST - und TT-Standardauflösungen lauffähigen Debugger gestaltet sich oft derart mühsam, daß man bald dazu übergeht, Debug-Ausgaben in den Quelltext einzubauen. Zusammen mit dem mäßig schnellen Compiler erhöhen sich dadurch natürlich die Turn-around-Zeiten. Erfreulich ist hingegen, daß der Debugger selbst unter MultiTOS noch außerordentlich stabil läuft. Was der Dokumentation an Information fehlt, wird zum Teil durch die Hotline, auch mit eigener Mailbox, wettgemacht, in der registrierte Benutzer neben neuen Versionen auch einen C-Einführungskurs finden.

Fazit

Stärken des Lattice-C-Systems sind die volle ANSI-Unterstützung, die umfangreichen Bibliotheken, 16 und 32 ints sowie der Support. Mittelmäßig hingegen sind der Editor und zum Teil die Dokumentation. Gegenüber dem Hauptkonkurrenten Pure C fallen vor allem der recht schwache Debugger und die fehlende Online-Hilfe ins Gewicht.

Bezugsquelle:

CCD Creative-Computer-Design
Hochheimer Straße 5
W-6228 Einville

Differenzierte Warnungmeldungen sind eine Stärke des Lattice-Systems

Pure C

Ohne Übertreibung kann man Pure C wohl als das Standard-Entwicklungssystem auf dem ATARI bezeichnen. Die Installation beschränkt sich auf das Kopieren der drei Disketten auf die Festplatte. An Dokumentation gibt es drei deutsche Handbücher mit zusammen über 600 sauber gedruckten Seiten zu Compiler, Assembler und Debugger, die auch eine gute Kurzeinführung in C enthalten, letztlich nur im Compiler-Teil manchmal Detailinformationen vermissen lassen. Ein Referenzhandbuch fehlt völlig.

In die Entwicklungsumgebung sind Editor und Compiler optimal integriert, so daß Meldungen des Compilers in ein eigenes Fenster erfolgen und man von dort aus direkt zur entsprechenden Quelltextstelle gelangt. Ebenso gilt das für Fehler in Projektdateien oder Referenzen der projektbasierten Volltextsuche. Die automatisch geführte Projektdatenbank bietet zudem auf Tastendruck das Anspringen programminterner Bezeichner, gleich, ob Funktion, Variable, Struktur, Definition oder Deklaration.

Die gute Integration hat ihren Nachteil allenfalls darin, daß einem der Umstieg auf einen externen Editor schwergemacht wird. Der eingebaute ist zwar in sich sehr logisch und konsequent aufgebaut, funktionell jedoch recht spartanisch, bietet nicht einmal ständige Zeilenanzeige oder Marken. Auch hinsichtlich der Geschwindigkeit bricht der Editor keine Rekorde. Die meisten Funktionen sind über Tastatur erreichbar. zudem mit den standardisierten und bekannten Tastenkombinationen. Um auch die Dialoge per Tastatur zu bedienen, bedarf es des Freeware-Utilitys Let 'em Fly (5).

In der integrierten Entwicklungsumgebung gibt es weder mit unterschiedlichen Grafikauflösungen, Betriebssystemversionen noch dem aktuellen MultiTOS Probleme, doch die Compilierung im Hintergrund ist darin nicht möglich. Hintergrund-Scrolling und beliebig viele Editorfenster bereiten Pure C aber keinerlei Schwierigkeiten.

Compiler

Obwohl mit Abstand der schnellste unter den vorgestellten C-Compilern, was nicht nur auf Caching von Header- und Objektdateien zurückzuführen ist, ist kein separater Optimierungslauf notwendig, um Programmcode zu erzeugen, der meist sogar schneller als der der anderen Systeme ist. Dies trifft insbesondere auf kleine Funktionen zu und liegt zum einen an der sehr guten Registerausnutzung, zum anderen an den optimierten Bibliotheken. Die Einschränkungen des Compilers liegen bei großen Datenfeldern, welche nicht mit int-Variablen indizierbar sind, und der Beschränkung auf 16 Bit ints. Bei Programmportierungen aus dem UNIX-Bereich bereitet das ebenso wie die knappen, zwar ANSI-kompatiblen, aber eben unvollständigen Bibliotheken oft große Probleme, die sich zum Teil durch den Einsatz der MiNT-Lib (5) mindern lassen.

Der Compiler kann auch Code für 68030 erzeugen, ebenso Code für die FPU im TT. Eine ATARI-kompatible FPU-Karte auf STs wird automatisch erkannt und bei Fließkommaberechnungen angesprochen, so daß solche Compilate auch auf Rechnern ohne FPU lauffähig sind. Compiler, Assembler und Linker liegen ebenfalls als TTP-Versionen vor, so daß man sie extern, unter MiNT auch im Hintergrund, einsetzen kann.

Assembler

Mit dem mitgelieferten, sehr schnellen externen Makro-Assembler, der den kompletten Befehlssatz bis hin zu 68040, PMMU und FPU verarbeitet, kann man dem C-Code einfach Assembler Module, auch mit Debugging-Informationen, hinzufügen. Sowohl vom Leistungsumfang als auch der Geschwindigkeit her ist der Assembler für einzelne Module mehr als ausreichend, eignet sich sogar für eigenständige Programme

Debugger

Mit dem in eine GEM-ähnliche Oberfläche eingebundenen Source Level Debugger ist Pure C nicht nur seinen C-Konkurrenten auf diesem Gebiet weit voraus. Die Bedienung des Debuggers ist sowohl komfortabel als auch effizient, die Arbeit in höheren Auflösungen oder Farbgrafikkarten möglich. Von Breakpoints, die man sowohl an Bedingungen wie auch an Zähler knüpfen kann, über Watchpoints, das Überwachen von Datenstrukturen, die ruhig auch komplex sein können, behält man bis hinunter zur Assembler-Ebene den Überblick, selbst modulübergreifend. Überspringen aufgerufener Funktionen, Abarbeitung bis zum Ende der aktuellen Funktion gehören ebenso zum Umfang wie die obligatorische Einzelschrittverarbeitung, wahlweise auf C oder Assembler-Ebene, oder die "Animation" genannte Abarbeitung in Zeitlupe. Leider ist der Debugger nur sehr eingeschränkt unter MiNT bzw. MultiTOS verwendbar. Mittlerweile kann ich mir eine Programmentwicklung auf dem ATARI ohne dieses hervorragende Werkzeug aber kaum mehr vorstellen.

Ein RCS ist im Lieferumfang nicht enthalten, was für den Einsteiger sicher ärgerlich ist, doch kommt man mittlerweile, will man moderne GEM-Programme erstellen, an Interface, ACS bzw. separaten Libraries kaum mehr vorbei. Davon sind jedoch eine ganze Reihe verfügbar.

Schwerer wiegt da schon das Fehlen eines Referenzhandbuches, das auch die umfangreiche und bis auf die MiNT-Funktionen vollständige und aktuelle, selbst die Funktionen des Falcon bereits berücksichtigende Online-Hilfe nicht völlig ersetzen kann. Die kontextsensitive Pure-C-Online-Hilfe ist zweifellos die beste und aktuellste aller getesteten Entwicklungssysteme. Auch eigene Hilfetexte mit Querverweisen lassen sich einfach erstellen und einbinden, allerdings läßt die Pure-Hilfe leider nur ein einziges eigenes Hilfesystem zu. Davon und von einer wünschenswerten inkrementellen Anzeige im Inhaltsverzeichnis abgesehen, ist die angebotene Hilfe wohl optimal, da sie, in einem GEM-Fenster laufend und auch als Accessory vorhanden, ständig verfügbar ist, auch im Debugger. Auch in mehreren wichtigen externen GEM-Editoren findet die Pure-C-Hilfe Unterstützung (6).

Volltextsuche in Dateibäumen

Fazit

Insgesamt ist Pure C für mich aufgrund der guten Turn-around-Zeiten und des hervorragenden Debuggers das vor allem für ATARI-spezifische Programmentwicklungen bevorzugte Entwicklungssystem. Eine Erweiterung des Editors vor allem aber der Bibliotheken erscheinen längst überfällig.

(5)) Quelle siehe GNU C.

(6) siehe ST Computer 1/93, "Texteditoren im Vergleich"

Bezugsquelle:

Application Systems Heidelberg Englerstraße 3 W-6900 Heidelberg 1

Pascal

MAXON Pascal

MAXON Pascal wurde 1990 veröffentlicht und brachte neuen Wind in den von ST-Pascal dominierten Markt der Pascal-Compiler. Es ermöglichte erstmalig den lang gehegten Wunsch vieler Programmierer, zum auf PCs weit verbreiteten Turbo Pascal V5.0 kompatibel zu sein und damit den Zugriff auf eine riesige Menge an Sourcecodes und Bibliotheken zu ermöglichen.

Das Paket wird in einem Ringbuch mit etwa 800 Seiten Umfang auf zwei Disketten ausgeliefert, auf denen sich die Entwicklungsumgebung, die Bibliotheken und einige Beispielprogramme befinden. Das Gesamtsystem belegt etwa ein Megabyte.

Bei MAXON Pascal handelt es sich um ein sogenanntes integriertes System. Dies bedeutet, daß alle benötigten Funktionen wie Editor, Compiler und Linker in einem Programm integriert sind. Der Vorteil ist hierbei, daß lästige Wartezeiten beim Nachladen der einzelnen Programme entfallen, was besonders den Anwender ohne Festplatte erfreuen wird. Der Editor stellt die üblichen Standardfunktionen zur Verfügung und erweist sich in allen Belangen als recht schnell. Sehr nützlich und komfortabel sind die Funktionen der Online-Hilfe gelöst. Sie wird aufgerufen, indem man ein Wort im Text selektiert und dann die Help-Taste drückt. Befindet sich das Stichwort im Hilfsregister, erscheint ein Fenster, indem sich die gewünschten Informationen und meist auch ein kleines Programmbeispiel abrufen lassen. Diese lassen sich auch in den Sourcecode kopieren. Die Online-Hilfe stellt das gesamte Handbuch zur Verfügung und erspart damit oft lästige Sucherei. Ein kleiner Wermutstropfen ist in der Verwendung der englischen Sprache zu sehen. Wem die Oberfläche nicht gefällt, der kann Compiler und Linker auch als TTP starten.

Compiler

Er zeichnet sich durch eine sehr hohe Übersetzungsgeschwindigkeit aus, und auch größere Projekte lassen sich ohne Kaffeepause abarbeiten. Wegen der auf PCs vorhandenen 64 KB-Segmente mußte in Turbo Pascal schon recht früh ein Modulkonzept entwickelt werden, mit dem erst größere Projekte möglich wurden. Ein großes Programm wird dabei in einzelne Programmteile (Module) zerlegt. MAXON Pascal hält sich hier an den PC-Standard, der 32 KB an Sourcecode für eine Unit zuläßt, was bei übersichtlicher Programmierung keine Einschränkung bedeutet. Zwischen einzelnen Modulen lassen sich sehr komfortabel Daten und Variablen austauschen. Der Compiler läßt sich vom Programm aus mit Direktiven steuern und kann auch Includefiles verarbeiten. Der erzeugte Code ist kompakt und recht schnell.

Inline-Assembler

Eine Besonderheit für die Programmierung besonders zeitkritischer Aufgaben stellt der Inline-Assembler dar. Mit ihm kann direkt im Sourcecode geschrieben werden. Prozeduren und Funktionen beginnen statt mit BEGIN mit dem Wort ASM. Aus solch einem Block heraus kann auch direkt auf Pascal-Variablen zugegriffen werden. Leider werden manche Befehle noch nicht korrekt übersetzt.

Funktionsumfang

Die angestrebte Kompatibilität sowohl zu Turbo Pascal als auch zum ATARI-Betriebssystem führt zu einer Reihe von Bibliotheken, die viele Funktionen anbieten und damit dem Programmierer die Arbeit sehr erleichtern. So stehen Bibliotheken für alle Teile des TOS zur Verfügung. Die AES- und VDI-Funktionen wurden nach dem C-Standard implementiert, wodurch die Konvertierung von GEM-Programmen, die in anderen Sprachen verfaßt wurden, stark erleichtert wird. Die Standard-Grafikbibliothek. unerläßlich auf PCs wegen der unterschiedlichen Grafikkarten und -auflösungen, ist ebenfalls vorhanden und erleichtert die Konvertierung von PC-Programmen auf den ST. Für Umsteiger ist die ST-Pascal-Unit von unschätzbarem Wert, ermöglicht sie doch die Übernahme alter Sourcen und Programme.

MAXON Pascal ist bemüht, soweit es die Unterschiede zwischen DOS- und TOS-Rechner zulassen, kompatibel zu Turbo Pascal 5.0 zu sein. Dieses Ziel ist weitgehend erreicht worden, so daß meist ohne große Änderungen Sourcecodes aus dem PC Bereich übernommen werden bzw. für diese Rechner geschrieben werden können. Probleme gibt es immer dann, wenn zu sehr auf die unterschiedliche Hardware und die unterschiedlichen Prozessoren (Assembler) eingegangen wird. Allerdings ist es schlechter Programmierstil, wenn man sich auf solche Details stützt.

Das umfangreiche Handbuch ist etwas knapp im Einsteigerteil, weist jedoch auf weiterführende Literatur hin. Dafür sind sowohl die Syntax als auch die Beschreibung der Units recht ausführlich und gut mit lauffähigen Beispielen versehen. Ein umfangreicher Index und ein Anhang über Datenformate und Aufrufkonventionen von MAXON Pascal runden das Bild ab.

Auch MAXON Pascal ist nicht ohne jeden Tadel. So wird nur der 68000er-Prozessor unterstützt, nicht aber dessen Weiterentwicklungen. Ein mathematischer Coprozessor wird unterstützt, allerdings nicht beim TT und Falcon. Einige mehr oder weniger kleine Fehler auch beim Assembler können teilweise zu Problemen führen. Parametrische Prozeduren sind zur Zeit nicht möglich.

Die Oberfläche und die Compiler-Optionen von MAXON Pascal

Fazit

MAXON Pascal stellt ein mächtiges Paket für den Pascal-Programmierer zur Verfügung. Die Kompatibilität zu Turbo Pascal 5.0 und auch die Übernahmemöglichkeit von ST-Pascal-Programmen neben der guten Unterstützung des ATARI Betriebssystems machen diesen Compiler für jeden Pascal-Programmierer sehr geeignet.

Bezugsquelle

MAXON-Computer GmbH Industrie Straße 26 W-6236 Eschborn

Pure Pascal

Pure Pascal ist der jüngste Sproß unter den Pascal-Compilern. Mit seiner Kompatibilität zu Turbo Pascal 6.0 und hohem Bedienungskomfort erhebt es den Anspruch, das beste auf ATARI-Computern erhältliche Pascal-System zu sein.

Ausgeliefert wird Pure Pascal in einem Einschubkarton, in dem sich ein 300 Seiten umfassendes Handbuch sowie drei Disketten befinden. Das System belegt etwa 1.7 MB. Während die anderen Compiler mit 1 MB Arbeitsspeicher auskommen, ist hier für sinnvolle Anwendungen ein größerer Speicher erforderlich.

Auch Pure Pascal ist ein integriertes System. Neben Editor, Compiler und Linker enthält es zusätzlich einen Debugger. Das Programm bietet ein eigenes GEM-ähnliches Desktop an, das in einigen Punkten von den Standards abweicht, aber eine komfortable Bedienung ermöglicht. Der Editor ist sehr schnell und komfortabel. Programme und Sourcecodes können als Icons auf der Oberfläche abgelegt und direkt aufgerufen werden. Implementiert ist auch eine Online-Hilfe, die in Deutsch sowohl die Syntax der einzelnen Befehle als auch kleine lauffähige Programmbeispiele dazu enthält. Auch hier können Teile aus der Hilfe in den Programmtext übernommen werden. Die Installation als TTP ist ebenfalls möglich.

Compiler

Der Pure-Pascal-Compiler erreicht eine extrem hohe Übersetzungsgeschwindigkeit. Nimmt man normale Projekte als Grundlage, machen sich die Übersetzungszeiten kaum mehr bemerkbar. Module werden ebenfalls unterstützt, die von PCs gewohnte Begrenzung einzelner Datenstrukturen auf 64 KB entfällt für globale Variablen. Lokale Variablen einer Prozedur dürfen jedoch insgesamt nur 32 KB belegen. Die Compilierung läßt sich über vielfältige Optionen steuern. Unterstützt werden ebenfalls mathematische Coprozessoren auch des Falcon und TT und die erweiterten Befehle der 68020/30-Serie. Programme prüfen beim Start, ob ein Coprozessor vorhanden ist. Pure-C-Libraries und -Objektmodule lassen sich ebenfalls verwenden. Der Compiler nimmt es bei der Übersetzung sehr genau, was schon einmal dazu führen kann, daß Fehler bei auf anderen Compilern erstellten Programmen aufgedeckt werden. Optimierungen, z.B. von Schleifen, werden selbständig durchgeführt. Ein nützliches Feature stellen Warnungen dar. Diese zeigen z.B. nie gebrauchte Variablen an. so daß unnötiger Variablenmüll vermieden wird. Der erzeugte Code ist kompakt und sehr schnell. Pure Pascal ist zur Zeit die schnellste Pascal-Implementation auf ATARI Rechnern.

Die Geschwindigkeit fertiger Programme kann sich mit der guter C-Compiler messen.

Assembler

Pure Pascal enthält keinen Inline-Assembler. Dieser steht dem System in Form eines TTPs zur Verfügung. Es werden alle 680X0-Prozessoren unterstützt, ebenso die mathematischen Coprozessoren. Dank vieler Optionen sowie umfangreicher Fehlermeldungen nebst einer eigenen Online-Hilfe ist die Einbindung von Assemblersourcen kein Problem.

Debugger

Als einziges Pascal-System bietet Pure Pascal einen integrierten Debugger auf Quelltextebene an. Damit lassen sich nicht syntaktische Fehler leicht aufspüren. Der gerade abgearbeitete Quelltext kann ebenso dargestellt werden wie die Werte der verwendeten Variablen und die aufgerufenen Units. Die im Debugger enthaltenen Möglichkeiten können an dieser Stelle nicht alle aufgezählt werden, da dies den Rahmen des Artikels sprengen würde.

Funktionsumfang

Auch Pure Pascal wartet mit einer Reihe von Bibliotheken auf. Sämtliche Betriebssystemroutinen sind implementiert. AES-und VDI-Aufrufe erfolgen nach dem C-Standard. Dabei übernimmt der Compiler selbständig die Konvertierung von Pascal-in C-Strings. Einige zusätzliche Befehle erleichtern den Umgang mit Resource-files. Zusätzlich sind die Bibliotheken für die PC-Kompatibilität enthalten. Neben der Graph-Unit sind sogar die recht schwierig zu implementierenden Funktionen der Interrupt-Programmierung enthalten wie auch Routinen für Environment-Variablen und DOS-Parameter. Als Besonderheit ermöglicht Pure Pascal auch die objektorientierte Programmierung. Diese Fähigkeit stellt dem Programmierer ein mächtiges Werkzeug zur Verfügung. Leider ist es im Rahmen dieses Artikels nicht möglich, näher auf dieses Gebiet einzugehen.

Die Kompatibilität ist als sehr hoch zu bewerten. Da sogar die häufig auf PCs verwendete Interrupt-Programmierung implementiert ist, ermöglicht Pure Pascal eine sehr hohe Kompatibilität. Programme, die sich zu sehr auf spezielle Hardware-Eigenschaften von PCs verlassen oder Assembler-Routinen benutzen, setzen Grenzen, die kein Compiler überwinden kann.

Verglichen mit den Handbüchern anderer Compiler und auch von Turbo Pascal ist das Pure-Pascal-Handbuch recht dünn ausgefallen. In einem lockeren Stil geschrieben, gibt es zwar eine recht gute Anfängereinführung, als Profi vermißt man aber schmerzlich einen besseren Index, eine bessere Darstellung der Datenformate und Aufrufkonventionen. Auch eine Syntaxbeschreibung der einzelnen Befehle fehlt leider. Positiv ist zu bewerten, daß nach jedem wichtigen Abschnitt umfangreiche Literaturangaben gemacht werden.

Pure Pascal hält das umfangreichste Paket an Möglichkeiten von allen getesteten Pascal-Compilern bereit. Aufgrund des integrierten Debuggers kann die Oberfläche kein GEM-Programm sein. Dies führt zur Einschränkung der Lauffähigkeit bei zu erwartenden Betriebssystemänderungen. So läuft Pure Pascal nicht mit Multi-TOS zusammen, und bei Verwendung bestimmter Grafikkarten kann es zu Problemen kommen. Das Handbuch ist, wie bereits oben erwähnt, ebenfalls verbesserungswürdig. Als jüngstes Kind unter den Pascal-Programmen enthält Pure Pascal noch einige kleinere Fehler, die sich ASH so schnell wie möglich zu beseitigen bemüht.

Fazit

Pure Pascal wird seinem Anspruch gerecht. Hohe Geschwindigkeit, mächtige Programmierwerkzeuge und komfortable Bedienung zeichnen diesen Compiler ebenso aus wie seine ausgezeichnete Kompatibilität zu Turbo Pascal 6.0 auf dem PC.

Bezugsquelle:
Application Systems Heidelberg Englerstraße 3 W-6900 Heidelberg 1

Die Oberfläche und die Compiler-Optionen von Pure Pascal

ST-Pascal

Als eine der ersten Sprachen überhaupt erblickte ST-Pascal bereits 1986 das Licht der Welt. Seit diesem Zeitpunkt hat diese Sprache einige Weiterentwicklungen und Verbesserungen erfahren und liegt nun in der Version 2.10 vor.

ST-Pascal wird auf zwei Disketten mit einem stabilen Ringordner als Handbuch ausgeliefert. Auf den Disketten befinden sich neben Editor, Compiler und Linker auch die Bibliotheken und einige Beispielprogramme. Das Paket hat eine Gesamtgröße von etwa 1MB.

Bei ST-Pascal handelt es sich nicht um ein integriertes System, sondern es wird mittels eines Programm-Managers auf die einzelnen Unterprogramme zugegriffen. Der Manager ist sehr komfortabel ausgelegt und muß nur in seltenen Fällen verlassen werden. Da es sich um ein GEM-Programm handelt, stellt die Bedienung kein Problem dar. Von hier aus können Anweisungen an den Compiler und den Linker gegeben werden, die sie beim Start übernehmen. Bei größeren Projekten erweist es sich von Vorteil. Link-Dateien erstellen und speichern zu können, so daß der Linker automatisch alle benötigten Files einladen kann. Die gesamten Einstellungen der Oberfläche und vom Compiler lassen sich ebenfalls abspeichern.

Editor

Als Editor wird Tempus, Version 1.11, verwendet. Er ist recht schnell und komfortabel, kann aber Schwierigkeiten bei Verwendung von Grafikkarten oder Rechnern wie dem Falcon machen. Aufgrund des offenen Systems lassen sich auch andere Editoren verwenden, um diese Probleme zu umgehen. Das ganze System ist auch als TTP installierbar. Als Editor empfiehlt sich Edison, da er direkt die Steuerung übernehmen kann.

Compiler

Der Compiler verrichtet seine Aufgabe mit zufriedenstellender Geschwindigkeit. Bei größeren Projekten kann jedoch wegen der dann doch recht langen Übersetzungszeiten eine Kaffeepause angesagt sein. Unterstützt wird sowohl modulare Programmierung als auch das Hinzuladen von Include-Files. Dazu können auch Code für den Debug-Modus und Symbole für symbolische Debugger erzeugt werden. Neben dem 68000er-Prozessor werden auch die Nachfolgetypen 010 und 020 unterstützt. Ab dieser Version kann mittels einer Zusatzbibliothek ein mathematischer Coprozessor angesprochen werden, jedoch nicht für TT oder Falcon. Der Compiler ermöglicht als einziger der hier getesteten parametrische Prozeduren. Der erzeugte Programmcode ist ausreichend schnell und kompakt.

Funktionsumfang

ST-Pascal ist als Entwicklersystem konzipiert und muß daher recht umfangreiche Bibliotheken zur Systemunterstützung aufweisen. Neben einigen Erweiterungen wie zusätzlichen Schleifenstrukturen ist hier vor allem eine eigenständige GEM-Bibliothek zu nennen, welche teilweise mehrere Einzelbefehle zu einem einzigen zusammenfaßt. Dies hat den Vorteil, daß selbst Anfänger sehr leicht auch ohne RCS GEM-Programme schreiben können, hat jedoch den Nachteil, daß die standardisierten Befehle nicht benutzt werden können. Aus diesem Grund liegt ab der Version 2.10 eine weitere Bibliothek bei, welche die bekannten GEM-Aufrufe zur Verfügung stellt. Weiterhin gibt es eine Bibliothek mit nützlichen Zusatzroutinen, die unter anderem die Adressenermittlung von Variablen und deren Setzen auf bestimmte Adressen ermöglicht.

Das Handbuch ist mit einem Umfang von etwa 700 Seiten recht umfangreich. Es gibt eine gute Einführung in das System und in die GEM-Programmierung mit den compilereigenen Befehlen. Kleine Beispielprogramme im Text verdeutlichen die Zusammenhänge. Auch als Nachschlagewerk ist es sehr gut geeignet. Das ist von besonderer Wichtigkeit. da ST-Pascal über keinerlei Online-Hilfe verfügt.

Mit ST-Pascal ist ein sehr ausgereifter Pascal-Compiler erhältlich, der seine Kinderkrankeiten bereits hinter sich gelassen hat. Diese Ausgereiftheit und das Alterder Konzeption haben jedoch auch einige Einschränkungen zur Folge, die nicht unerwähnt bleiben sollen. So ist eine Umsetzung von ST-Pascal-Programmen auf andere Compiler wegen der eigenständigen GEM-Befehle nur mit recht großem Aufwand möglich. Das Modulkonzept ist nicht so umfangreich und komfortabel wie auf moderneren Systemen verwirklicht. Das System selbst enthält weder einen Assembler noch einen Debugger. Assembler-Unterroutinen lassen sich jedoch einbinden. Der Einsatz eines externen Debuggers ist ebenfalls möglich, jedoch nur auf Assembler-Ebene. Einige Beispielprogramme enthalten noch die inzwischen verpönten LINE-A-Befehle. Da die Weiterentwicklung inzwischen eingestellt wurde, werden Systemfehler nicht mehr korrigiert und auch Neuerungen wie die Unterstützung neuer Rechner oder Betriebssystemerweiterungen nicht mehr durchgeführt.

Fazit

Durch den großen Befehlsumfang und die gute Systemeinbindung stellt das System eine gute Arbeitsgrundlage dar. Für ST-Pascal existieren mehrere Bücher, die dem Anfänger das Erlernen vereinfachen. Weiterhin gibt es verschiedene Zusatzbibliotheken sowohl kommerziell als auch als Public Domain, die viele nützliche Zusatzroutinen enthalten.

Bezugsquelle
CCD Creative-ComputerDesign
Hochheimer Straße 5
W-6228 Eltville

Die Oberfläche von ST Pascal+ und die Compiler-Optionen

Modula 2

Hänisch Modula

Das Hänisch Modula-System wird mit einem knapp 180 Seiten starken Handbuch auf 5 Disketten ausgeliefert. Sie enthalten Editor, Compiler, Debugger, Libraries, diverse Utilities und die Online-Hilfe. Erfreulicherweise sind auch die Quelltexte der Libraries enthalten.

Clix, der Editor des Systems, ist ein reinrassiges GEM-Programm mit GDOS-Unterstützung und ermöglicht die gleichzeitige Bearbeitung von bis zu 8 Texten. Er ist ein mächtiges Werkzeug und bietet neben den üblichen Editierfunktionen Text- und Funktionsmakros und Textvergleich. Leider halten sich die Shortcuts nicht an den Standard, und einige Tasten sind mit zu vielen Funktionen belegt. Die Tastaturbelegung ist aber in sich stimmig, und man gewöhnt sich recht schnell daran.

Und welcher andere Editor bietet schon Funktionen wie "Suchen+Ersetzen rückwärts ab Textende fortsetzen" auf einen Tastendruck? Bis man aber die Tastaturkürzel für die ausgefalleneren Funktionen kennt, vergeht einige Zeit.

Clix ist nicht nur der Editor, sondern auch die Shell der Entwicklungsumgebung. Aus ihm heraus werden alle anderen Teile des Systems aufgerufen. Logisch, daß Clix dann auch die Fehlermeldungen des Compilers auswerten und die entsprechenden Zeilen des Quelltextes anzeigen kann.

Compiler

Der Compiler wird als Accessory mitgeliefert, ist aber auch als Programm lauffähig, wenn man ihn entsprechend umbenennt. Gibt man ihm dann noch in der Kommandozeile eine Make-Datei an, arbeitet er als TOS-Programm und verzichtet vollkommen auf GEM. Wer wenig Speicherplatz hat und/oder den Compiler unter MiNT oder MultiTOS ihm Hintergrund laufen lassen will, wird diese Möglichkeiten sicher zu schätzen wissen.

Der Übersetzer arbeitet in zwei Durchgängen, unterstützt bedingte Compilierung, 68020-Code und die TT-FPU (7) und ermöglicht sogar die Programmierung von CPX-Modulen. Dabei erzeugt der Compiler einen sehr kurzen und auch schnellen Code. Das Code-Segment eines Moduls darf nur 32 KB lang werden, was zwar für Quelltextmodule völlig ausreicht, aber bei ins Programm integrierten Resourcen lästig werden kann, da man längere Resourcen splitten muß, wenngleich dies durch die Libraries unterstützt wird. Im Gegensatz dazu kann der Datenbereich eines Moduls ebenso wie Datentypen beliebig groß werden, im Compiler integriert ist eine Make-Funktion, die die Abhängigkeiten der Module selbsttätig feststellt.

Assembler

Assembler-Einbindung ist möglich, indem Assembler-Module mit einem bestimmten Aufbau hinzugelinkt werden. Der sogenannte Präprozessor-Assembler ONYX, von dem eine auf 80 Byte Code beschränkte Version dem Paket beiliegt, erstellt diese Module recht bequem. Ein echter In-line-Assembler wäre dennoch besser.

Debugger

Zwei Debugger liegen dem System bei. Der Runtime-Debugger RTD ermöglicht es, den Programmablauf Schritt für Schritt auf Quelltext- oder Assembler-Ebene auch durch mehrere Module zu verfolgen. Seine Oberfläche ist der des GEM nachempfunden, da Debugger unter TOS nicht als GEM-Programme realisierbar sind. Die Maus wird aber nicht unterstützt. Nach kurzer Einarbeitung kann man aber auch ohne sie effizient mit dem Debugger umgehen. Nachteilig ist jedoch, daß die Anzeige von Variablen nur relativ umständlich möglich ist. Der zweite Debugger PMD ist für den Einsatz nach dem Absturz eines Programmes gedacht. Zu seinem Einsatz ist es notwendig, daß ein abgestürztes Programm einen Speicher-Dump auf Diskette oder Festplatte sichert (diese Möglichkeit kann durch eine Compiler-Option gesteuert werden). Der Einsatz des PMD bietet sich besonders dann an, wenn ein Fehler nur selten oder nach längerem Programmlauf auftritt.

Ein großer Pluspunkt des Systems sind die mitgelieferten Bibliotheken, die sich nicht hinter denen der C-Compiler verstecken müssen. Erwähnen will ich an dieser Stelle nur GEMplus, die den Umgang mit dem GEM erheblich vereinfacht und dabei auch die üblichen Flydials bietet, und Window, die eine komfortable Fensterverwaltung ermöglicht. Auch Aufrufe von AES 4.0 (im Falcon und MultiTOS) sowie MiNT sind in den Libraries implementiert, werden aber innerhalb der anderen Libraries noch nicht genutzt. Einige mitgelieferte Tools erleichtern die Arbeit. Die wichtigsten in Kürze: RSC2 MOD wandelt eine Resource-Datei aus allen verbreiteten Formaten in Definitions- und Implementationsmodule um, MANUAL erzeugt Online-Manuals für den Editor Clix, und LIB ermöglicht es, Objektmodule zu Libraries zu linken.

Das Handbuch bietet eine Kurzeinführung in Modula 2 und geht dann auf die Bedienung des Systems ein. Dabei werden die Funktionen hinreichend beschrieben und auch auf Interna eingegangen, wenn es nötig ist. An einigen Stellen hätte ich mir Beispiele gewünscht. Ärgerlich ist, daß ein Referenzhandbuch fehlt. So ist man auf die Online-Hilfe und, da diese bei den Betriebssystemroutinen nicht viel hergibt, auf weiterführende Literatur angewiesen. Die Beispielprogramme helfen zwar beim Verständnis der GEM-Libraries, würden aber durch reichlichere Kommentierung noch gewinnen.

Hänisch Modula läuft unter MultiTOS, MiNT und selbstverständlich auch unter älteren TOS-Versionen. Es ist auflösungsunabhängig programmiert, verträgt sich auch mit meinen 15 aktiven Autoordnerprogrammen und kann als stabil bezeichnet werden. Ein MB RAM und mindestens 2 MB freier Harddisk-Speicher sind für den Betrieb mindestens erforderlich. Ist mehr RAM vorhanden, wächst die Com-piliergeschwindigkeit drastisch, da mehr Module im Cache gehalten werden können. Ein Betrieb ohne Harddisk ist zwar möglich, aber nicht sonderlich sinnvoll.

Fazit

Zu einem akzeptablen Preis von DM 389,- erhält man eine stabile und schnelle Entwicklungsumgebung, deren einzige echte Schwäche in der Dokumentation liegt. Dennoch hat mich das System überzeugt, und ich würde größere und vor allem GEM-Program me jederzeit mit Hänisch Modula schreiben.

(7) siehe GNU C, Line-F-Emulator

Bezugsquelle:

Modular Systems GbR Z. Hd. Thomas Uhl Obere Heerbergstr. 17 W-8700 Würzburg

Editor mit inkrementeller Suche, im Hintergrund die Online-Hilfe

BASIC

Omikron.BASIC

Omikron BASIC ist ein aus Interpreter und Compiler bestehendes Paket, vielen sicherlich bekannt, da die ältere Interpreter-Version 3.0 einigen Modellen der ST-Serie beiliegt. Technisch betrachtet ist Omikron.BASIC gegenüber dem ewigen Konkurrenten GFA-BASIC sicherlich moderner. Dies äußert sich in kontinuierlicher Weiterentwicklung und Fehlerbeseitigung. Zwar ist der Interpreter nur im langsameren, aufgrund seiner Knappheit aber wertvollen ST-RAM, nicht aber im schnelleren TT-RAM lauffähig, doch Compilate sind dies sehr wohl, so daß diese Einschränkung nicht allzu sehr ins Gewicht fällt.

Interpreter

Die Oberfläche des Interpreters wirkt mittlerweile steinzeitlich: eine selbstgestrickte, mausbedienbare und mit Menüleiste ausgestattete Oberfläche, die von GEM nichts gesehen hat, wenngleich Accessories über einen Zwischenschritt erreichbar sind. Durch einen Schalter bekommt man zwar theoretisch die Möglichkeit, per VDI-Ausgabe auf anderen als den Standardauflösungen, also beispielsweise mit Grafikkarten. zu arbeiten, doch harmoniert dies nicht mit jeder Grafikkarte und ist zudem sehr langsam. Ein paralleler Betrieb unter MultiTOS ist trotz dieser Oberfläche und der starren Speicherverwaltung des Interpreters in relativ sicherem Betrieb möglich, wenngleich umständlich. An die Tastaturbedienung kann man sich hingegen schnell gewöhnen.

Im Interpreter ist eine Online-Hilfe mit mäßigem Umfang verfügbar, deren Texte in einer viel zu kleinen Dialogbox dargestellt werden, sich somit nicht gleichzeitig mit dem Quelltext einsehen lassen, die zudem beim Scrollen furchtbar flackert. Allerdings ist es möglich, eigene Hilfetexte einzubinden. Daß nur ein Quelltext bearbeitet werden kann, ist für einen BASIC-Interpreter ohne Modulkonzept durchaus akzeptabel.

Omikron.BASIC erlaubt es, sowohl mit als auch ohne Zeilennummern zu arbeiten und mehrere Befehle, durch Doppelpunkte voneinander getrennt, in einer Zeile unterzubringen. An Pascal angelehnte Kontrollstrukturen machen Spaghetti-Code überflüssig. Neben dem großen Befehlsvorrat, der auch die AES- und VDI-Befehle umfaßt, kann man beliebige Anweisungsblöcke einklappen, ein Feature, das sehr zur Übersichtlichkeit beiträgt. Auf einem TT wird bei Fließkommaberechnungen selbst im Interpreter die FPU verwendet. Überhaupt liegt eine Stärke des Omikron.BASIC im mathematischen Bereich, es seien bloß die FPU-Unterstützung als auch die hohe Rechengenauigkeit von 19 Stellen oder die integrierten Matrizenbefehle genannt. Aber auch sonst ist die Abarbeitungsgeschwindigkeit des Interpreters sehr hoch.

Compiler

Selbst ein Omikron.BASIC-Compilat übersetzt der Compiler nicht nur recht fix, sondern erzeugt auch schnellen Code. Von der Nutzung der FPU in ST oder TT bis hin zu 68020-Code, welcher gegenüber 68000-Code allerdings nur marginale Verbesserungen bringt, wird alles unterstützt. Die Compilate laden beim Start eine Laufzeitbibliothek nach, die man aber auch in das Compilat integrieren kann. Dabei wird die Bibliothek komplett hinzugefügt, was natürlich zu recht großen Programmen führt. Im Gegensatz zur Version 3.5 ist es in Version 4.0 noch nicht möglich, die unbenutzten Funktionen von einem weiteren Hilfsprogramm nachträglich wieder entfernen zu lassen. Daß diesem System ein Linker fehlt, ist also ebenso deutlich wie die Unmöglichkeit, Routinen aus anderen Sprachen in BASIC-Compilaten zu verwenden. Immerhin bietet die Firma Omikron eine Reihe von Bibliotheken zur Erweiterung an.

Als Dokumentation standen nur das Handbuch zur Version 3.0 und die Readme-Dateien auf Diskette zur Verfügung, da das neue Handbuch nicht mehr rechtzeitig ankam. Obwohl so natürlich nicht alles getestet werden konnte, hat man mit Omikron.BASIC doch die Möglichkeit, saubere, auch unter MultiTOS lauffähige GEM-Programme zu erstellen. CPX-Module allerdings sind nicht erzeugbar.

Einen Debugger gibt es nicht, wozu hat man schließlich einen Interpreter? Daß sich Omikron.BASIC-Compilate nicht mit dem Pure-C-Debugger vertragen, ist daher ebenso ärgerlich wie die Unverträglichkeit mit Sysmon (8).

Fazit

Mit einem Preis von DM 698,- für die TT-Version 4.0 erscheint mir Omikron.BASIC doch reichlich überteuert. Wer saubere GEM-Programme in BASIC pflegen muß oder sonst auf die BASIC-spezifischen Vorteile angewiesen ist, sollte zu Omikron.BASIC greifen, ebenso bei Programmportierungen von GW-BASIC und kompatiblen Quellen aus dem MS-DOS-Bereich. Auch im mathematischen Bereich ist Omikron.BASIC stark. Aufgrund der angegebenen Schwächen, die mehr die Konzeption der Entwicklungsumgebung denn die technische Mängel betreffen, fallen mir aber nur wenige Gründe für die Verwendung von Omikron.BASIC ein. Andere Entwicklungssysteme sind zu einem geringeren Preis leistungsfähiger.

(8) Sysmon von Karsten Isakovic, Overscan GbR, Berlin

Bezugsquelle: Omikron.SOFTWARE Sponheimerstraße 12 W-7530 Pforzheim

Abschluß

Sie haben sicherlich bemerkt, daß in unserer Aufstellung das bekannte GFA-BASIC fehlt. Zur Zeit wird GFA-BASIC von einem jungen Entwickler-Team komplett neu entwickelt (wir berichteten). Sobald das neue GFA-BASIC verkaufsfertig vorliegt, werden wir es ausführlich besprechen. Zu unserer Übersicht sei noch angemerkt. daß die Sprachwahl selbst gar nicht so entscheidend ist, sondern es vielmehr darauf ankommt, die den Sprachen zugrundeliegenden Konzepte zu erlernen. Gerade die Kontrollstrukturen und Datentypen gleichen sich dabei doch sehr. Dazu eignen sich vor allem Pascal und Modula. Beherrscht man eine dieser Sprachen, bereitet einem auch die Programmierung in der jeweils anderen (sowie in BASIC) kaum Probleme. Auch fällt der Umstieg auf C einfacher als der direkte Einstieg darin. Kenntnisse in Assembler erwirbt man sich besser nebenbei, oder wenn es die Bedienung des Debuggers erforderlich macht. Zum Einstieg halten wir konkret Pure Pascal und Hänisch Modula für am besten geeignet, als C-Compiler bei vorrangiger Verwendung für ATARI-spezifische Programmierung Pure C.

Rainer Esser / Frank Baumgart / Uwe Ohse / Peter Hilbring

Literatur:

Assembler:

ST-Computer 3/1992, Seite 44ff., "Take it Easy", Heim-Verlag

M6HOOO-Familie, Teil 1, "Grundlagen und Architektur", te-wi Verlag

M68000-Familie, Teil 2, "Anwendung und 68000-Bausteine ", te-wi-Verlag

ATARI ST - Programmieren in Maschinensprache, Sybex Verlag

C

Kernighan und Ritchie, Programmieren in C, Hanser Verlag

C++:

Als Einstieg und Referenz:
Stroustrup, The C++ Programming Language, Second Edition, Addison Wesley

Für Fortgeschrittene:
James Coplien. Advanced C+ + Programming Styles and Idioms, Addison Wesley

Modula:
Dal Cin, Lutz, Risse, Programmierung in Modula-2. Teubner Verlag

Auf einen Blick

Sprache Easyrider Turbo Assembler GNUC Lattice C Pure C MAXON Pascal Pure Pascal Hänisch Modula Omikron .BASIC
Version 4.0 1 76 2.3.1 5.52 11 1.5 1.0 409
GEM-Oberfläche 0 - - + + + - + -
- Sprache deutsch deutsch englisch deutsch englisch deutsch deutsch deutsch deutsch
- Komfort + + - + ++ ++ ++ ++ 0
auflösungsunabhängig + - + + + + + + 0
Editor beliebig Tempus VI .11 liegt bei 0 0 0 0 + + 0
MultiTOS - - + + + 0 - + 0
Compiler-Geschwindigkeit ++ ++ - + ++ + ++ + +
FPU (ST/TT) +/+ - -/+ +/+ +/+ -/+ +/+ -/+ +/+
TTP-Version + - + + + + + -
Bibliotheken + + ++ + 0 + + +4- 0
Assembler + + 0 + + - + - -
Debugger - + - 0 ++ - ++ + -
RCS - - - 0 - - - - -
Online-Hllfe - - - - ++ + + + 0
Dokumentation ++ + sTest 0 + + 0 0 0
- Sprache deutsch deutsch englisch dt /engl deutsch deutsch deutsch deutsch deutsch
Preis in DM 199.- 50,- (Shareware) (PO) 398,- 398- 259,- 398,- 389, 698,-


Aus: ST-Computer 02 / 1993, Seite 20

Links

Copyright-Bestimmungen: siehe Über diese Seite