Evolution oder Revolution? Mark Williams C 3.0

Was bietet die brandneue Version 3.0 des C-Entwicklungspakets von Mark Williams?

Gereon Steffens Julian F. Reschke

Gerade auf dem Atari ST ist C sehr beliebt. Schneller Code, nur wenige Einschränkungen, die Assembler nötig machen und ausgezeichnete Entwicklungspakete haben der C-Sprache auf dem Atari ST viele Anwender beschert.

Häufig findet der C-Compiler von Mark Williams Einsatz. Mit der Version 3.0 hat die Mark Williams Company eine komplett überarbeitete Fassung ihres C-Entwicklungssystems auf den Markt gebracht. Bereits die Vorgängerversionen genossen unter Software-Entwicklern einen hervorragenden Ruf und Atari USA übernahm das System für ihr Entwicklungspaket. Wie sehen nun die Neuerungen in dieser überarbeiteten Version aus?

Um dem auf dem Grund zu gehen, entwickelten wir nicht nur neue Benchmarks, die wir in Zukunft bei allen Tests von Hochsprachen-Compilern anwenden, sondern sahen uns auch den erzeugten Maschinencode an und untersuchten alle Bibliotheken auf Vollständigkeit.

Der Compiler versteht den üblichen Kernighan und Ritchie-Sprachstandard. Wie viele andere Compiler kennt er zusätzlich auch die Schlüsselwörter »void« und »enum«. Die im ANSI-Standard hinzugekommenen Sprachattribute »const« und »volatile« führen zwar zu keinen Fehlermeldungen, werden aber ansonsten ignoriert (siehe dazu Artikel über den neuen ANSI-C-Standard auf Seite 115). Alle weiteren ANSI-Spracherweiterungen kennt unser Testkandidat nicht.

Gegenüber der Version 2.1 erhöhte sich die Maximalgröße für statische Felder auf 64 KByte. Ferner kann man nun über Compilerswitches auf generell PC-relative Adressierung — nur bis zu einer Codegröße 32 KByte möglich — oder PC-relative Adressierung der Daten umschalten. Auch ein einfacher »Peephole«-Optimierer kann hinzugeschaltet werden. Eine deutliche Codeverbesserung stellten wir allerdings dabei nicht fest.

Wer mit dem Compiler ohne RAM-Disk und Hard-Disk arbeiten will, muß sich auf ausgedehnte Wartezeiten gefaßt machen, da er in drei Phasen arbeitet und dabei temporäre Dateien anlegt.

Genauso solide wie der Compiler ist auch der Präprozessor, der seinen Dienst makellos verrichtet. Beim Standard-Benchmark »Dhrystone 1.1« liefert der Mark Williams C-Compiler mit 1087 Dhrystones, beziehungsweise 1020 ohne Register-Variablen, ein gutes Ergebnis, das ihm eine Plazierung im oberen Mittelfeld der C-Compiler auf dem ST garantiert.

Mit Benchmarks kann man viel »beweisen«, vorausgesetzt man hat den passenden zur Hand — nach dem Motto »Benchmarks lügen nicht, aber Lügner machen Benchmarks«. So ist der oben erwähnte Dhrystone-Benchmark dafür bekannt, daß insbesondere die String-Library das Gesamtergebnis stark beeinflußt. I/O-Routinen und Floating-Point-Arithmetik mißt er hingegen überhaupt nicht.

Aus diesem Grund haben wir eigene Benchmarks entworfen, die eine genaue Aufschlüsselung von Stärken und Schwächen eines Compilers erlauben:

Für das eine Programm ist vielleicht die Geschwindigkeit der Floating-Point-Routinen ausschlaggebend, während ein anderes Programm mit der String-Library steht und fällt!

Die Codequalität spielt eine Hauptrolle. Selten war es so leicht, den erzeugten Code einer Analyse zu unterziehen: Der Compiler speichert den Maschinencode auf Wunsch als Assembler-Quelltext. Ein Blick in den Assembler-Code brachte keine Überraschungen: Kontrollstrukturen und Integer-Arithmetik-Ausdrücke übersetzt er in einen ausgesprochen kompakten Code, wie ihn ein Assembler-Programmierer auch nicht anders schreiben würde.

Für die Darstellung von Floating-Point-Zahlen verwendet unser Testkandidat das »DECVAX«-Format, dessen Aufbau ebenso wie der des IEEE- und des BCD-Formats im Handbuch dokumentiert ist. Den Floating-Point-Coprozessor MC68881 unterstützen die Libraries leider nicht.

Ebensowenig wie die Linker anderer C-Compiler optimiert der Mark-Williams-Linker den Code, das heißt einzelne Objektmodule aus einer Library bindet er in voller Länge ein. Besondere Geschwindigkeitswunder darf man selbst bei Nutzung einer RAM-Disk nicht erwarten. Da die Maximallänge der Symbole 16 Zeichen beträgt, ist eine Kompatibilität zum Objektfile-Format von Digital Research nicht gegeben. Ein Konvertierungs-Programm liegt bei, das seinen Job allerdings nur in einer Form verrichtet: Es erzeugt als Quellcode immer Mark Williams-Format. Am Rande sei noch erwähnt, daß dieses Dateiformat auch »MadMac«, der Assembler aus dem Atari-Entwicklungspaket, unterstützt und man insofern doch von einem »Standardformat« sprechen kann.

Als Werkzeug zur Fehlersuche enthält der Lieferumfang den symbolischen Maschinensprache-Debugger »DB«. Damit muß man sich zwar auf das Niveau der Maschinensprache herunterbegeben, er zeigt dafür aber die verwendeten Labels für Funktionen und Variablen, ähnlich wie bei »SID68« von Digital Research. Breakpoints, Stack-Backtracing und Direkteingabe von Symbolnamen machen diesen Debugger komfortabler als die meisten anderen auf dem ST.

Zusätzlich bietet Mark Williams den symbolischen Source-Code-Debugger »csd« an, mit dem man das Programm im C-Klartext debuggen kann. Dabei lassen sich Breakpoints setzen und beliebige C-Ausdrücke direkt auswerten. In der Kombination mit dem extra zu zahlendem Debugger ist das C-Entwicklungspaket von Mark Williams erstklassig und in dieser Form einzelartig, »csd« beschreiben wir in einer der kommenden Ausgaben näher.

Ein wichtiger Gesichtspunkt eines C-Entwicklungssystems sind Umfang und Qualität der mitgelieferten Libraries. Bei Mark Williams C erhält man eine weitgehend vollständige UNIX-Library, die gerade das Portieren von Programmen von diesem Betriebssystem her vereinfacht. Warum man allerdings mit »scanf()« keine vorzeichenlosen Variablen einlesen kann, wird vermutlich auch den Mark Williams-Programmierern ein Rätsel sein. Die mitgelieferten Line-A-Bibliotheken gehen schon über den üblichen Lieferumfang hinaus.

Der Startup-Code des C-Runtime-Moduls unterstützt weder I/O-Redirection, die wird normalerweise von der Mark Williams-Shell übernommen, noch das »xArg«- Schema zur Übergabe von Kommandozeilen. Statt dessen benutzt er ein Mark Williams-eigenes Format, das allerdings im Handbuch genau dokumentiert wird. Glücklicherweise liegt der gesamte Startup-Code als Assembler-Sourcecode bei, so daß der ambitionierte Programmierer leicht eigene Erweiterungen vornehmen kann. Schade ist es allerdings, daß sich die Softwarehäuser so schwer mit Standards auf dem ST tun.

Bei den GEM- und TOS-Libraries interessiert naturgemäß, ob alle Funktionen genauso eingebunden sind, wie man es gewohnt ist. Ganz vollständig sind die Libraries allerdings nicht — beispielsweise fehlen rätselhafterweise die Bindings für »form_keybd()« und »form_button()«, die noch bei der Vorgängerversion 2.1 bekannt waren. Ebenso fehlen Bindings für einige VDI-Funktionen genauso wie für die im GEM 2.2 und in der neuen TOS-Version hinzugekommenen Funktionen. Zum Glück sind die Low-Level-GEM-Bindings wiederum als Assembler-Source vorhanden, so daß man sie mit erträglichem Aufwand selbst nachbessern kann.

	for (i=0; i<20000; ++i)
	{
		y = 3;
		x += (y*y-y) / y;
		++y;
	} 
	return (cardinal)(x+y);
}

void While()
{
	REG int i , j; 

	dummy=0;
	for (j=0; j<10; ++j) 
	{
		i=0;
		while (i<10000)
		{
			++i;
			++dummy;
		}
	}
}

Links und unten: Mit neu entwickeln Benchmark-Tests prüften wir den C-Compiler.

Die gesamte Arbeit wickelt bei diesem C-Compiler die Tastatur-Shell »msh« ab. Bei »msh« handelt es sich um eine überzeugende Kopie der UNIX-C-Shell, mit der sich UNIX-Programmierer sofort wohlfühlen: Command-Line-History, Environment-Variablen, I/O-Redirection und Pipes nutzt man mit »msh« auch auf dem ST. Anfänger und Maus-Fans brauchen jedoch einige Zeit zur Einarbeitung. Eine Einbindung in eine GEM-Shell dürfte wegen der ausgiebigen Nutzung von Environment-Variablen nicht einfach sein.

Darüber hinaus erhält man noch eine Fülle von Dienstprogrammen mitgeliefert wie »make«, das dem »augmented make« von UNIX System V entspricht, das Archiv-Programm »arg«, den Ok-tal-Dump »od« und den Textformatierer »pr«.

Der mitgelieferte TOS-Editor »MicroEMACS« dürfte vielen Lesern bereits von anderen Programmen wie der »Guläm-Shell«, »Little Smalltalk« und ähnlichen bekannt sein. MicroEMACS ist ein Public Domain-Programm, das es speziell auf größeren Computersystemen in einer großen Versionsvielfalt gibt und dessen C-Sourcen frei verfügbar sind und auch hier beiliegen.

Mit MicroEMACS steht dem Programmierer ein solider Editor zu Verfügung, der alle wichtigen Funktionen bietet und außerdem gut in die Shell eingebunden ist. So kann man mit einem einzigen Tastendruck in die Shell zurückkehren, ohne daß der aktuelle Text verlorengeht. Tatsächlich wird die Shell als neuer Prozeß im Speicher gestartet. Der Compiler kann angewiesen werden, den Editor bei auftretenden Fehlern automatisch zu starten und in einem zweiten Fenster die Fehlerdatei anzuzeigen. Schließlich gibt es noch die Help-Funktion, die automatisch zu jedem Standardaufruf, auf dem der Cursor steht, wertvolle Zusatzinformationen liefert. Das heißt, Parameter der Funktion und sehr kurze Beschreibung dessen, was die Funktion macht.

Ein Programmpaket, das die Bezeichnung »Entwicklungssystem« für sich in Anspruch nimmt, muß auf dem ST auch ein Resource Construction Set bieten. Bei diesem Paket liegt das ursprünglich von Kuma entwickelte Programm »NRSC« unter dem Namen »Resource Editor«. Diese aktualisierte Fassung läuft auch auf dem Blitter-TOS. Zusätzlich erhält man einen Resource-Compiler/Decompiler, mit dem man Resourcen aus Textdateien erzeugen kann.

Das Mark Williams-Entwicklungssystem ist in einer ähnlichen Version auch für MS-DOS als »Let’s C« und andere Betriebssysteme erhältlich. Damit darf man bei der Programmierung von Anwendungen, die nur Standardfunktionen aufrufen, einen sehr geringen Portierungsaufwand erwarten. Da der Compiler schon seit einiger Zeit verfügbar ist, und auch schon viel Software auf diesem Paket entwickelt wurde, ist es ausgereift. Ein Beispiel ist das CAD-Programm »Drafix 1«.

Leider war zur Zeit des Tests noch kein Handbuch zur neuen Version fertig. Das Handbuch zur Version 2.1 beschreibt auf über 700 Seiten ausführlich alle Funktionen, Kommandos und Programme in alphabetischer Reihenfolge — gewöhnungsbedürftig, aber in der Praxis gar nicht mal unpraktisch.

Wer braucht die neue Version 3.0? Wer nicht länger ohne C-Source-Code-Debugger auskommen will, ist mangels Alternative auf die Kombination mit dem »csd« angewiesen. UNIX-Fans und Programmierer, die Programme aus einer UNIX-Umgebung auf den ST portieren wollen, beeindrucken sowohl die Handhabung als auch die mitgelieferten Bibliotheken. Um das Update auf Version 3.0 zu erhalten, senden Sie die Originaldisketten ein. Kostenpunkt für das Update: 99 Mark. MWC ist ein absolut professionelles System, das Anfängern und Maus-Fans zunächst Anfangsschwierigkeiten bereiten wird. (hb)

Markt & Technik Verlag AG, Unternehmensbereich Buchverlag, Hans-Pinsel-Str. 2, 8013 Haar

Benchmark AG Version 1.0 for C

Intmath short	: 0.8150 Sekunden
Intmath long	: 2.0600 Sekunden
Realmath short	: 18.4750 Sekunden
Realmath long	: 18.2950 Sekunden
Triglog short	:25.7100 Sekunden
Triglog long	:25.6950 Sekunden
For	: 0.9250 Sekunden
Loop	: 0.8250 Sekunden
Repeat	: 0.8250 Sekunden
While	: 0.9250 Sekunden
ArrayAccess	: 1.3900 Sekunden
RecordAccess	: 1.0300 Sekunden
RecordArray	: 0.6050 Sekunden
WriteToFile	:18.6400 Sekunden
ReadFromFile	:53.8400 Sekunden
Pass Parameters	:40.5550 Sekunden
Pass Structures	: 1.8950 Sekunden
Conversions	:32.4450 Sekunden
Strings	: 0.4000 Sekunden
------------------
Dhrystone 1.1	:1087 (mit Register)
		1020 (ohne Register)

Bei einer ganzen Anzahl Benchmark-Tests bewies Mark Williams C seine Qualität.

Wertung

Produktname: Mark Williams C
Preis: 299 Mark
Hersteller: Mark Williams

Stärken:
□ UNIX-Shell □ viele Dienstprogramme □ vollständige UNIX-Library □ Resource-Construction-Set beiliegend □ ausführliches Handbuch □ guter Code-Generator

Schwächen:
□ TOS- und GEM-Libraries unvollständig

Fazit: Ein System für Profis