The British Way of Pascal im Vergleich mit einem Produkt aus deutschen Landen, frisch auf den Tisch.

Zwei der ältesten Pascal-Systeme für den ST, das Prospero ProPascal-System (das jetzt den Untertitel 'for GEM’ trägt, um seine Anpassung an das DR GEM-System zu dokumentieren - übrigens auch für den MS-DOS Bereich erhältlich) und das CCD Pascal Plus liegen seit kurzem in neuen Versionen vor. Die Veteranen haben sich, diese Bemerkung sei vorab erlaubt, wirklich gut gehalten, was ihrem Überleben auch sehr förderlich sein dürfte, angesichts einer ganzen Flut von angekündigten neuen Pascal-Compilern und Entwicklungssystemen, die zum Teil zum Zeitpunkt des Erscheinens dieses Berichtes bereits erhältlich sein dürften.

Zuerst ein paar Gemeinsamkeiten: Beide Pascal-Systeme werden vollständig aus einer GEM-Shell bedient, das Verlassen dieser Shell dürfte während der Entwicklung eines Programmes in den seltensten Fällen notwendig sein. Bei Pascal Plus ist eine derartige Bedienerführung ja nichts neues, bereits in der älteren Version war eine Shell vorgesehen, auf den Komfort eines GEM-Texteditors mußten CCD-User aber bisher verzichten, es sei denn, sie waren stolze Besitzer des CCD-Editors TEMPUS, der seinen Beinamen 'DER Editor’ nicht zu Unrecht trägt. Ein GEM-Editor mit allen notwendigen Funktionen (zwar nicht TEMPUS, aber auch nicht schlecht) ist in Pascal Plus jetzt enthalten, die Shell ist erheblich umfangreicher geworden.

Auch Prospero Pascal, dessen Handling bisher eher ein Denkmal der Vorzeit war, wurde völlig neu eingekleidet, und zwar in eine sehr funktionale Shell. Die Besonderheit dieser Shell ist, daß der Editor hier nicht als Overlay nachgeladen wird, wie es sich gebührt, sondern fest in die Shell integriert ist. Das ist hübsch, weil man einen Text compilieren kann, ohne ihn vorher abzuspeichern, einfach so, wie er im Rechner steht. Besonders schön ist dann allerdings, wenn man nach getaner Arbeit und dem Griff zum Ausschalter des Rechners feststellt, daß man sein Programm auch nach erfolgreicher Kompilierung nicht abgepeichert hat. Frohes Tippen. Die Shell gefällt aber ebenfalls sehr.

Lieferumfang

Beide Systeme sind im Grunde ähnlich aufgebaut: Geliefert werden Shell, Editor, Compiler und Linker. Zusätzlich enthält das CCD-Paket einen sehr leistungsfähigen und auch ausreichend schnellen Quelltextformatierer, der sehr übersichtliche und informative Listings liefert (z.B. reservierte Worte fettgedruckt, korrekt eingerückt, am Rande die Schachtelungstiefe der Zeile angegeben usw.). Prospero liefert einen Cross-Reference-Generator, der leider nicht der schnellste ist, sowie ein Library-Utility mit. Einige Hilfsbibliotheken (für GEM, TOS, Nützliches) sind ebenfalls beiden gemeinsam. Eine große Besonderheit, die sich jedoch in den illustren Kreisen der Compilerbauer immer mehr durchzusetzen beginnt, hat das ProPascal-System seiner deutschen Konkurrenz voraus: Einen Source-Level Debugger. Häh ? Nun, einige findige Entwickler auf größeren Rechnern und Workstations sagten sich vor geraumer Zeit, daß es doch eine Schande sei, über modernste Sprachen, Compiler usw. zu verfügen, aber bei der Fehlersuche nach obligatorischem Absturz auf die reine Intuition oder gar -igitt- auf Maschinensprache-Kenntnisse angewiesen zu sein. Auch Debugger wie SID, der ja zum C-Entwicklungspaket des Atari gehört, helfen nicht allzuviel, wenn es darum geht, lokale Variablen in einer zweieinhalbtausendmal rekursiv aufgerufenen Prozedur zu finden, oder auch einfach eine bestimmte Variable während der Ausführung des Programmes zu verändern - ohne erneuten Compilerlauf, versteht sich. Kurzum, herkömmliche Werkzeuge für die Fehlersuche lassen einen geplagten Programmierer immer dann im Stich, wenn er sie am nötigsten braucht, nämlich dann, wenn man die Möglichkeiten einer Hochsprache zur Strukturierung und ähnliche Annehmlichkeiten des modernen Programmierens nutzen will und Fehler in derartigen Gebilden auch halbwegs schnell beseitigen will. Um es kurz zu machen: So entstanden die ersten Source-Level Debugger, die eben genau die Fähigkeit besitzen, die ihr Name andeutet: In einem Testlauf eines kompilierten Programmes jederzeit Zugriff auf den Source-Text des gerade ausgeführten Programmes zu haben, Breakpunkte im Source-Code zu setzen, Variablen (auch rein lokal) tracen und ändern oder die Ausführung des Programmes an beliebiger Stelle fortsetzen zu können. Sie sehen also, ein guter Source-Level Debugger ist eine Art eierlegendes Wollmilchsau-Raubtier in der Welt der Wanzen.

Ein solcher Source-Level-Debugger, der über wirklich beachtenswerte Fähigkeiten verfügt, ist im ProPascal-System enthalten - und der Autor ist nach seinen ersten Erfahrungen mit diesem wohl ersten auf dem ST erhältlichen Muster seiner Art ganz hingerissen. Aber auf diesem Feld ist Konkurrenz bereits in Sicht: Die Version 2.0 des Pascal-Systems von Metacomco, das bei Erscheinen dieser Ausgabe ebenfalls erhältlich sein soll, verfügt ebenfalls über einen derartigen Debugger, über den man sich wahre Wunderdinge erzählt - nun, man wird sehen.

GEM-Einbindung

Der nächste Punkt der allgemeinen Ausführungen über die Herren Pascal betrifft die Einbindung der GEM-Aufrufe ins System. Hier scheiden sich die Geister ganz erheblich. Prospero hat sich für einen sehr eleganten Weg entschieden, nämlich den, sämtliche Datentypen, Konstanten und Prozeduraufrufe des Betriebssystem in Include- und Linkdateien zur Verfügung zu stellen, wodurch GEM-Programme aus anderen Sprachen, z.B. aus C. leicht nach Prospero Pascal (oder Fortran, das im letzten Heft getestet wurde und sich lediglich im Compiler von dem Pascal-System unterscheidet) übersetzt werden können bzw. umgekehrt. Die Implementierung der GEM-Aufrufe ist extrem geschickt gelöst, die unflexible Handhabung von Prozeduren versus Funktionen in Pascal ist elegant umgangen worden. Zusätzliche Funktionen, die nicht direkt in GEM enthalten sind, erleichtern manch unangenehme Arbeit. Leider hat man an einem Punkt, der allerdings alles andere als selbstverständlich ist, eine Möglichkeit versäumt: In die Objekt-Library wurde keine Routine eingefügt, die es ermöglicht, Pascal-Prozeduren zur Bearbeitung von ‘Userdef’-Objektstrukturen zu verwenden, was wunderhübsch, die Krönung sozusagen, gewesen wäre, eben weil es in Pascal (in korrektem Pascal) völlig unmöglich ist, so etwas zu programmieren. Aber wie gesagt, das war eigentlich auch nicht zu erwarten, aber bei der Qualität der GEM-Bindings wird man schnell unverschämt. Ein dickes Lob für die Prospero GEM-Library.

CCD macht es dem an die Standard-Aufrufe gewöhnten Programmierer da erheblich schwerer. Benutzern älterer Pascal Plus-Versionen ist die GEM-Library des Systems bekannt, Newcomern sei berichtet, daß in der Library eine Auswahl von Funktionen des GEM vorhanden ist, die entweder einige Standard-GEM-Aufrufe unter neuem Namen zusammenfaßt oder für Verwirrung sorgt, indem sie nur einen einzigen Standard-GEM-Aufruf mit neuem Namen enthält oder gar, um das Durcheinander komplett zu machen, gar einzelne Aufrufe unter ihrem Original-Namen verwendet. Manche der so entstandenen Aufrufe machen es dem Neuling möglicherweise leichter, ans GEM heranzutreten, aber im allgemeinen möchte ich bestreiten, daß diese Art der GEM-Einbindung sehr nützlich ist, zumal, entgegen der anderslautenden Werbung, der Handbuchteil, der sich mit diesen Bindings beschäftigt, keineswegs sehr viel leichter verständlich und kürzer als viele der bisher erschienenen Bücher über die Standard-Aufrufe ist. Der Umstieg auf andere Sprachen oder die Verwendung von Hilfsroutinen für besondere Aufgaben, die man zum Beispiel in Zeitungen entdecken kann, wird meines Erachtens durch eine solche GEM-Einbindung unnötig erschwert. Außerdem sind, wie bereits erwähnt, nicht alle GEM-Funktionen enthalten, einige zusätzliche hinzugefügt usw. In der bisherigen Version des Pascal Plus Systems konnte man ja wenigstens völlig problemlos mit Hilfe der Dateien ‘aes-bind’ und ‘vdibind’ die Originalfunktionen verwenden, vorausgesetzt, man brachte den Fleiß auf, erst einmal die korrekten Procedurdefinitionen für die vielen, vielen GEM-Funktionen in seinen Computer einzutippen, da ein Include-File mit solchen Definitionen leider nie vorgesehen war. Mit der verbesserten GEM-Bibliothek der neuesten Pascal-Plus Version ist das nicht mehr ganz so problemlos: Zwar wurden viele Fehler aus der alten GEM-Library entfernt und viele Einschränkungen durch neu eingeführte Funktionen hinfällig, doch leider wurde im Zuge dieser Verbesserungen auch einiges verändert, so daß es nicht mehr so ohne weiteres möglich ist, einfach eine GEM-Prozedur zu definieren und sie dann durch linken mit ‘aesbind’ oder ‘vdibind’ auch tatsächlich nutzen zu können. Nein, etwas Mühe gehört dazu; einige Spezialvariablen, die beim alten System automatisch definiert waren, sind jetzt in die Include-Dateien, die zur CCD-GEM-Library gehören, abgewandert, so daß man diese mitkompilieren, außerdem aber auch die GEM-Library von CCD mitlinken muß, um ein Programm mit Standard-GEM lauffähig zu machen, was die ganze Sache etwas unbequem macht. Dummerweise tragen einige Prozedur-Aufrufe in der CCD-Library in der neuen Version aber doch wieder Standard-Namen, was dazu führt, das unter Umständen auch noch einiges an Änderungen fällig wird, damit ein älteres Programm fehlerfrei kompiliert und gelinkt werden kann. Mir erscheint diese Art der GEM-Einbindung recht ungeschickt, nichts gegen Erleichterungsversuche für geplagte Anfänger, aber bitte doch mit Wahrung der Kompatibilität, ohne den Standard-gewöhnten durch große Mühen zu verschrecken oder quasi zur Benutzung eines uneleganten Bindings zu zwingen.

Sehr gelungen ist dagegen eine Bibliothek namens PASTRIX (welch hübscher Name...), die wirklich äußerst nützliche Funktionen enthält, die es z.B. ermöglichen, ganze Bildschirminhalte in einer Variable abzuspeichern, zu peeken und poken, Adressen von Variablen zu finden, Datum und Zeit und Strings zu konvertieren usw., usw. Einige Probleme, die die strenge Pascal-Typüberprüfung besonders bei der systemnahen oder GEM-Programmierung bietet, lassen sich mit Hilfe dieser Funktionen recht einfach umgehen.

Bei Prospero sind derartige Funktionen bereits im Sprachumfang enthalten (Peek, Poke usw.) bzw. in die TOS-Bibliothek integriert (Zeit-/Datums-Konvertierung).

Dokumentation

Das CCD-Pascal wird selbstverständlich mit einem deutschen Handbuch geliefert. Die gesamte Dokumentation besteht aus dem Original-Handbuch der letzten Pascal-Plus-Version sowie einem dünnen Ergänzungsband, der die Erweiterungen und Änderungen der neuen Version beschreibt. Die Anleitung ist gut brauchbar, aber nicht immer optimal übersichtlich.

Für ProPascal gibt es, wie könnte es auch anders sein, nur eine englische Anleitung. Drei Bände sind es, einer für den Compiler, die TOS- und Hilfsbibliotheken, sowie jeweils einer für die VDI- und AES-Bindings. Die Anleitung ist gut und leicht verständlich geschrieben; ärgerlich in der AES-Anleitung ist, daß dort auch alle Funktionen der GEM-Version 2.0 (unter MS-DOS) enthalten sind, was an sich nicht weiter schlimm wäre, wenn man nicht vergessen hätte, irgendwo aufzulisten, was das GEM im Atari nun eigentlich kann und was nicht. Etwas ungeschickt ist auch der Compiler-Band, der sich aus mehreren Teilen zusammensetzt, die leider kein gemeinsames Register haben, so daß man, wenn man nicht weiß, wo genau man etwas suchen soll, immer etwas blättern muß.

Tabelle: Pascal Benchmarks

Spracherweiterungen

Beide Pascal-Compiler sind in einigen Punkten gegenüber der Norm erweitert. Fast schon Standard ist der Stringtyp samt den dazugehörigen Funktionen zu seiner Manipulation. In ProPascal sind Strings voll dynamisch, das heißt, ihre Länge (bis zu 32KByte) muß nicht festgelegt werden.

Beide Compiler erlauben auch modulares Kompilieren. Dabei können globale Variablen von allen Programmteilen genutzt werden, aber auch geschützte Variablenbereiche sind möglich.

In Sachen Zahlen: Der Prospero-Compiler versteht verschiedene Real-Formate, nämlich mit 7 und 16 Stellen Genauigkeit, sowie 32-Bit-Integer-Zahlen. Vordefiniert sind Subranges mit 8 und 16 Bit Größe mit und ohne Vorzeichen.

Ein genereller Pointer-Typ ist vorhanden, der mit jedem beliebigen Pointer kompatibel ist.

Bei CCD gibt es ein Real-Format, das 11 Stellen Genauigkeit bietet. Inte-ger-Zahlen sind 16 Bit, vordefiniert ist der Unterbereich Byte, Long_Integer-Zahlen sind für 32 Bit-Werte vorgesehen.

Weitere gängige Erweiterungen wie ‘Else’ in ‘CASE’-Anweisungen, Random Access-Files und bitweise logische Operationen sind ebenfalls in beiden Compilern enthalten.

Eine hochinteressante Erweiterung bietet nur ProPascal: Eine ‘ownerr’-Routine erlaubt es, Run-Time-Fehler, wie z.B. Division durch Null, an eine eigene Fehlerbehandlungsroutine zu übergeben. Auf diese Weise kann man Programme sehr sicher gegen Fehler machen.

Der CCD-Compiler erlaubt noch etwas, das eigentlich der Pascal-Philosophie strikt entgegengeht: Variablen dürfen, wie in Basic, an jeder beliebigen Stelle des Programms definiert werden und sind dann nur allen später definierten Teilen des Programmes bekannt. Eine besonders glückliche Idee scheint mir das nicht zu sein, aber CCD hat diese Möglichkeit laut Handbuch auf Wunsch zahlreicher Kunden implementiert.

Praxis

Mit beiden Systemen, dem Manager von CCD und der Prospero-Workbench, kann man vernünftig und schnell arbeiten. Mir persönlich gefällt die Prospero-Workbench etwas besser, weil bei ihr die Ladezeiten für den Editor entfallen. Dafür ist der CCD-Editor etwas besser, denn der ProPascal-Editor hat ein kleines Problem, das man von den ersten 1st_Word-Versionen kennt: Der Cursor läuft nach. Sehr nützlich bei der CCD-Shell sind die Kopierkommandos, so daß man die Shell nicht dauernd verlassen muß. In der Praxis ist das Pascal Plus-Paket wegen der kürzeren Turn-around-Zeiten immer dann im Vorteil, wenn keine schwierigeren Fehler zu suchen sind. Durch den integrierten Source-Level-Debugger macht ProPascal die Fehlersuche extrem angenehm, was manchen Compiler-Zyklus spart. Auf der Disk braucht der CCD-Compiler weniger Platz, weil er ohne Zwischenfiles auskommt. ProPascal erzeugt eines. Der Compiler-Output von CCD ist kompatibel zu anderen Sprachen, oder besser gesagt, der CCD-Linker versteht das Digital-Research-Linkformat.

Prospero benutzt, wie schon in der alten Version, das Objektcode-Format von GST.

Beim Testen der Compiler entstand bei mir immer stärker der Wunsch, einen Compiler zu besitzen, der die guten Eigenschaften beider Systeme in sich vereinigt. Beide Compiler haben nützliche Bibliotheken, praktische Verbesserungen gegenüber der Pascal-Norm, es erlauben z.B. beide modulare Kompilierung. Ich hätte gerne die Erweiterungen beider. Beide Shells haben einiges für sich. Besonders deutlich wird der Wunsch aber bei den Benchmark-Tests: Während der CCD-Compiler wirklich in Windeseile arbeitet (er ist in der neuen Version noch schneller geworden, als er sowieso schon war), also für extrem niedrige Turn-around Zeiten sorgt, ist das ProPascal eher etwas gemächlich. Leider gilt für die Ergebnisse der Entwicklung, vor allem im Bereich Fließkommarechnung, genau das Gegenteil: Der CCD-Compiler hat hier seine deutliche Achillesferse. Den kompakteren Code erzeugt nun wiederum das CCD-System, die Fehlersuche bei ProPascal ist durch Probe, wie der Source-Level-Debugger sich zu nennen beliebt, natürlich ganz erheblich vereinfacht.

Zur Dokumentation einige Benchmarks im einzelnen (siehe Tabelle ). Zusammenfassung: Dieser Compiler-Vergleich ist irgendwie frustrierend. Beide Compiler haben in bestimmten Gebieten ganz besondere Vorzüge. Im Handling erweist sich der CCD-Compiler wegen seiner Geschwindigkeit als etwas angenehmer, mir persönlich gefällt das Arbeiten mit der Prospero-Shell etwas besser, aber der Compiler ist leider ein bißchen langsam. Debuggen ist natürlich die Stärke von ProPascal, was bei komplexen Programmen den Nachteil der niedrigen Geschwindigkeit durchaus aufwiegen kann. Beim Arbeiten mit GEM ist die Bibliothek des ProPascal-Systems klarer Sieger. Bei den fertigen Programmen dreht sich das Bild: Prosperos Pascal ist plötzlich viel schneller, die Programme sind allerdings um einiges länger, weil anscheinend grundsätzlich ein aufwendigeres RunTime-Paket dazugelinkt wird (je länger die Programme, desto weniger fällt dieser Anteil ins Gewicht...). CCD Pascal rechnet arg langsam, eine Version für den Arithmetik-Coprozessor soll da demnächst Abhilfe schaffen. Aber auch außerhalb der Arithmetik ist CCD-Pascal langsamer in der Ausführung, wie die Benchmarks erweisen.

Das Preis-/Leistungs-Verhältnis der Pakete ist in Ordnung.

Kurzum: Es soll jeder nach seiner Fasson selig werden, mir gefallen die Pascals beide sehr gut, weil man mit beiden Systemen vernünftig und professionell arbeiten kann. Trotzdem bin ich sehr gespannt auf das, was die Konkurrenz, allen voran Metacomco, in Kürze auf dem Pascal-Sektor zu bieten hat. Vielleicht findet sich ja doch noch das Pascal meiner Wunschträume, das frei von Fehl und Tadel mir nur zur Freude dienet...

CS

Beispiel einer formatierten Ausgabe mit Pascal Plus