GnuC 2.6.3
Modernes C/C++ System für Atari ST/STE/TT,Falcon
Der aktuelle Stand der Dinge:
Auf dem Atari gab es bisher Pure C 1.1, GNU C 2.5.8, Lattice 5.6. Diese drei teilen im wesentlichen die Atari C-Welt unter sich auf.
An den Universitäten ist GNU C, der C-Compiler schlechthin, weil er im Source vorliegt und auf alle Rechner portiert werden kann. Nirgends ist die Rechnervielfalt so groß wie dort: SUN, Vax, Apollo, HPs, Silicon Graphics, Ataris und viele andere Rechner mehr sind vorhanden.
Der einzige C/C++ Compiler, der für diese Rechner existiert, ist GNU C. Außerdem möchten Universitäten und Institute sich nur ungern von einem kommerziellen Anbieter abhängig machen da man dort auf die (möglichst) komplette Implementation von C++ angewiesen ist.
Features wie z.B.: Vererbung lassen sich in konventionellem C nicht sinnvoll realisieren. Man müßte solch ein Verhalten in C umständlich simulieren. In C++ hingegen gehört es einfach zum Sprachumfang. Da man mit C++ Code viel effektiver und rascher arbeitet, ist es die Sprache der Wahl. Wer einmal damit gearbeitet hat, wird nicht wieder zu "konventionellem C" zurück wollen. Die Einarbeitung in C++ ist zwar zeitintensiv, da man vom sich vom "prozeduralen Denkansatz" lösen und lernen muss in Objekten und Klassen zu denken.
Das Umdenken macht sich aber rasch bezahlt, da C++ auf allen Plattformen, außer z.Zt.: Atari, der (!) Standard ist. Wo auch immer man programmieren muss, überall wird meist C++ verlangt. Hobbyprogrammierer schreiben ihre Programme oft in Basic, genau wie auf dem Atari, aber Profis nutzen auf UnixRechnern, PCs, Macs & Amigas C++ (auf dem Amiga: Maxon C++). Dadurch ergeben sich für diese Plattformen erhebliche Zeitvorteile, die bei Verwendung fertiger Klassenbibliotheken noch größer werden.
Auch wenn sich Programmierer kommerzieller Atari-Software bisher häufig sträuben ihre liebgewonnen Gewohnhei- ten zu ändern, wird eine mittel- und langfristige Umstellung auf C++ (also GNU C ++) sich klar durchsetzen. Diesen Schritt mussten Atari-Programmierer, die auch unter Unix programmieren müssen, ohnehin schon bestreiten. Niemand wird auf der SUN, Iris Indigo, VAX, HP 9000, etc. in C++ und auf dem Atari wieder "nur" in C denken. Dies wäre ziemlich unlogisch und inkonsequent.
Ähnlich wie ObjectGEM für Pure Pascal, können dann mit der verstärkten Verbreitung von C++ auch "C++"- Klassenbibliotheken entstehen, die das Programmieren der GEM-Oberfläche auf dem Atari endlich erheblich vereinfachen. Von C zu C++ ist ein ähnlich wichtiger Schritt wie von Fortran zu Pascal oder gar C.
Die Abhängigkeit, bezüglich des Entwicklungssystems kommerzieller Anbieter birgt das Risiko in sich, plötzlich "im Regen zu stehen", weil das Softwarehaus sich umorientiert hat oder gerade Konkurs anmelden musste. Sie meinen so etwas passiert nicht so oft und ist eher unwahrscheinlich? Nun, Borland hat z.B. 40 % der Belegschaft entlassen - der Firmengründer, Philippe Kahn hat das Unternehmen auch schon verlassen. Dies bedeutet sehr oft das Ende einer Firma, denn Finanzexperten können zwar Gelder verwalten, aber selten neue Perspektiven entwickeln. Zur Zeit wird Borland provisorisch vom bisherigen Finanzchef Gary Wetzel geleitet. So etwas passiert in der Computerwelt ganz überraschend.
Nun, zur Zeit ist es so, dass Pure C 1.1 nicht mehr lieferbar ist und Pure C 2.0, ist noch nicht lieferbar, da es ein sehr großer Aufwand ist, ein C-Entwicklungssystem von Grund auf neu zu schreiben. Einen konkreten Liefertermin gibt es, zumindest bisher, leider noch nicht.
Man kann also im Moment Lattice C (z.B.: von ROM Software) und GNU C 2.5.8 von diversen Versendern erwerben. Neu auf dem Markt ist GNU C 2.6.3. Es ist gerade fertig geworden.. Sobald definitiv feststeht, wer GNU C 2.6.3 vertreiben wird, werden wir Sie natürlich informieren.
GNU C 2.6.3 Anforderungen
Sollten Sie Interesse an GNU C 2.6.3 haben, so möchten Sie selbstverständlich wissen, welche Anforderungen an das System gestellt werden.
Nun, es wird 3-3.5 MB freier Speicher benötigt (also nicht 2 MB ST RAM & 1 MB TT RAM, sondern: 3-3.5 MB ST oder TI RAM.), MINT 1.12 H2 (und/oder MultiTOS) und weiterhin ist eine Festplatte zwingend erforderlich, da ca. 13-14 HD bzw. 26-28 DD Disketten geliefert werden, deren Inhalt komprimiert ist. Wobei Sie sich um die Software keine Gedanken machen müssen. Alles was benötigt wird, also inkl. MINT 1.12 H2, Minix XFS 0.60 PL 11 & die Mupfel 1.a, ist im GNU C 2.6.3-Paket enthalten. Ausnahme: MultiTOS wird nicht unbedingt benötigt, wäre aber sinnvoll. Außerdem wäre Gemini 1.a ganz sinnvoll, darf aber aus lizenzrechtlichen Gründen nicht mitgeliefert werden.
Um nun wieder zu den Systemanforderungen zurückzukehren:
Es wird ein Atari-Rechner mit TOS 1.04 oder höher benötigt. Ideal ist TOS 2.06, 3.06 oder TOS 4.Ox. TOS 1.0 & TOS 1.02 sind völlig zwecklos, da das Arbeiten auf der Festplatte mit altem TOS keinen Sinn macht. Das GNU C 2.6.3 ist ab 68000 lauffähig, obwohl ein ST/STE mit PAK/3 (wird z.B.: von MW Electronic angeboten) oder ein 68030/68040 besser ist. Genügend freier Speicher (ab 3-3.5 MB) ist aber unverzichtbar.
Zur Installation von GNU C 2.6.3 ist MINT 1.12 H2 (von Michael Hohmuth) zu empfehlen. Da lange Namen in den Sourcen vorkommen, ist es erforderlich MINT bzw. MultiTOS & Minix XFS 0.60 PL11 zu installieren.
MINT liegt im Auto-Ordner und heißt MINTNP.PRG oder MINT.PRG. Um Mißverständnisse zu vermeiden, möchte ich hier die Unterschiede zwischen MINT und MultiTOS kurz klären.
MINT 1.12 H2 ist frei verfügbar; MultiTOS ist eine lizensierte Software von Atari & Compo. Die Treiberfunktionalität ist in MINT enthalten (also XFS & XDD Schnittstelle, u:\pipe, u:\dev, u:\proc, u:\shm etc.). MultiTOS hat zusätzlich ein MultiAES 4.x, welches ermöglicht, GEM-Programme parallel laufen zu lassen!
Dies kann mit MINT alleine nicht erzielt werden. Unter MINT kann man lediglich TOS-Programme parallel laufen lassen.
Minix XFS 0.60 PL11
Minix XFS hat zwar eine Menge Dokumentationen, aber im Moment der Installation kann man noch gar nicht wirklich wissen, welche Informationen relevant sind und welche nicht.
Da sich nicht alles nachträglich, ohne weiteres, (ohne größeren Aufwand) ändern laßt, möchte hier kurz die Installation von Minix XFS 0.60 PL11 erklären.
Natürlich enthält nur die Originaldokumentation alles Wissenswerte. Da die Dokumentation außerdem noch in Englisch verfaßt ist, sind Anwender, die lediglich Deutsch verstehen, natürlich im Nachteil. Aber nachdem ich Minix XFS in der 0.60 PL 9, PL 10 und neuerdings PLII benutze, habe ich natürlich einige Erfahrung, die ich gerne weitergeben möchte, um Fehler vermeiden zu helfen.
Man nimmt die Binärdistribution von Minix XFS 0.60 PLll (MFS6011B.ZOO) und entpackt das Archiv mit einem Zoo- Packer. ,Also z.B.: "zoo.ttp x d:\Minix\mfs6011b.zoo"
Analog kann man auch die anderen Archive entpacken (also die Quelltexte und den Defragmentierer). Zuvor sollte man erstmal die Platte so installieren, dass sie unter GEMDOS fehlerfrei läuft. Also Formatieren, Partitionieren und Installation eines Festplattentreibers.
Wichtig ist es sinnvolle Partitionsgrößen zu wählen; nicht zu klein! GNU C 2.6.3 benötigt alleine ca. 27 MB an Sourcen und ca. 10 MB an Binärfiles. Nicht jedes TOS unterstützt jede Partitionsgröße.
Minix XFS 0.60 PL11 weigert sich, zumindest auf meinem Rechner, Partitionen ab einer gewissen Größe zu initialisieren.
Als Abhilfe bietet es sich an, notfalls selbst die richtigen Daten einzugeben und zwar folgendermaßen: "minit.ttp -t d:" testet Laufwerk d: und gibt die Anzahl der blocks & Inodes an. Jetzt gibt man statt "minit.ttp -P -V -n 4 d:" das
"minit.ttp -b Blöcke -i Inodes -P -V -n 4 d:"
an. Wobei zuvor mit "minit.ttp -t d:" ermittelt wurde. Gleiches gilt auch für Inodes ! Minix XFS 0.60 hat seit Patchlevel 11 keine (!) Beschränkung der Festplattengröße mehr und auch der "triple indirection bug" ist inzwischen behoben.
Um Minix XFS zu installieren startet man:
- minit.ttp -P -V -n 4 d: (Stellt alle Parameter ein....)
- mfsconf.ttp d: (Konfiguriert die Partition...)
- fsck.ttp -S d: (Prüft die Daten...)
- csize.ttp minix.xfs 64 64 64 (statt 64 können auch andere Werte hier stehen.)
Wichtig ist es nur, Laufwerke im Minix-XFS Format einzurichten die "d:" oder höher sind. Am besten kopiert man csize.ttp dorthin wo Minix.XFS ist, da Versuche mit einem kompletten Pfadnamen, zumindest bei mir, nicht von Erfolg gekrönt waren. Wenn sich csize.ttp dort befindet, wo Minix.XFS ist, klappt es aber problemlos. Man sollte es so einstellen, dass lästige Harddiskzugriffe unterbleiben. Ein möglicher Wert wäre "csize.ttp minix.xfs 64 64 64".
Dies installiert jeweils 64 KB für den System-, User- und Inode-Cache, also insgesamt 192 KB Cache. Das wäre es im Prinzip.
Nun noch ein paar Erläuterungen zu den Parametern, um ein besseres Verständnis zu gewährleisten:
Also der Parameter -P sorgt dafür, dass ein Schutz für den Fall eingeschaltet wird, dass der Rechner, aus Versehen, einmal ohne Minix.XFS gestartet wird.
Der Parameter -V ist sehr wichtig, denn er sorgt dafür, dass ein V2-Dateisystem installiert wird, welches moderner und besser als ein V1-Dateisystem ist. V2-Dateisysteme finden z.B.: auch unter Atari Linux 68K Verwendung.
Der Parameter -n ist frei wählbar: 1,2,4 oder 8 und legt fest wie groß Dateinamen und Ordnernamen werden dürfen. Das ganze berechnet sich gemäß der Formel: "directory-increment (n* 16) 2".
Also:
n=l: 16-2 = 14 (macht keinen Sinn)
n=2: 32-2 = 30 (manchmal zu kurz)
n=4: 64-2 = 62 (ideal)
n=8: 128-2 = 126
(n=8: ist meist zu groß und bringt meist keinen zusätzlichen Nutzen, funktioniert aber).
Ideal ist n=4, da somit auch sehr lange Dateinamen abgedeckt werden. Unter Umständen reicht auch schon n=2, aber dieser Parameter lässt sich nicht nachträglich ändern. Daher ist n=4 am sichersten ! Andere Werte außer 1,2,4 und 8 sind unzulässig. Mit n=4 ist man eigentlich immer gut beraten.
Das Benutzerinterface
Wer zuvor GNU C 2.5.8 benutzt hat, wird mit GNU C 2.6.3 auf Anhieb zurecht kommen. Denn die Binaries sind in "h:\usr\Iocal" und die Sourcen von GNU C 2.6.3 in "i:\gcc263". Relevant ist erstmal der Pfad "h:\usr\local". Dort sind alle Binaries, Libraries & Includefiles drin. Also in: "h:\usr\local\bin", "h:\usr\local\include", "h:\usr\local\lib ... etc. Man muss also lediglich seinen GNU C Hauptordner umstellen, oder den Pfad in "profile.mup" abändern. Z.B.: auf "f:\usr\Iocal" oder wo auch immer man Platz haben sollte (sollte aber eine Minixpartition sein, also d:\ oder höher.)
Wer von z.B.: Pure C 1.1 kommt, vermißt aber den GEM-Komfort. Daher hatte ich die Überlegung, die Benutzung trotzdem so einfach wie möglich zu gestalten.
So empfiehlt es sich, eine Shell oder einen Desktop mit Shell zu verwenden. Also z.B.: Gemini 1.a !
Die Arbeit unter Gemini sehr komfortabel und teilweise sogar unerläßlich, da man lange Dateinamen nur mit Gemini 1.a (bzw. der Mupfel von Gemini 1.a) korrekt bearbeiten kann. Der normale Desktop verkraftet lediglich "8+3"- Namen und ist daher kaum geeignet.
Leider war es den Entwicklern nicht möglich gewesen, eine Lizenz zu erhalten, um Gemini 1.a der GNU C 2.6.3 Distribution beizulegen. Dabei würde es eigentlich keine Rolle spielen, ob jemand Gemini via ftp & MausNet oder auf der GNU C 2.6.3 Distribution erhielte. Ein Problem haben diejenigen, die kein ftp- & MausNet-Anschluß haben, da auf einen Vertrieb für GNU C angewiesen sind. Außerdem kommen sie an Gemini nur schwer bis gar nicht heran.
Aus diesem Grund wird nur die Mupfel mitgeliefert, um als Shell für GNU C 2.6.3 zu fungieren.
Außerdem wird ein gepatchtes Resourcefile für Gemini 1.a geliefert, um unter MiNT/MultiTOS korrekt zu laufen.
GNU C 2.6.3 liegen noch diverse Hilfedateien bei, die man sich unbedingt beachten sollte. Unter anderem in "gcc263" in den Ordnern:
- "gcc263\Changes\ChangeLog*"
- "gcc263\Manuals_.l\cccp.1"
"gcc263\Manuals_.l \cpp.1"
"gcc263\Manuals_.l \gcc.1" - "gcc263\Readme"
- "gcc263\gcc infos"
Fazit:
GNU C hat von der Version 2.5.8 zur Version 2.6.3 viele Erweiterungen erfahren.
Während die Version 2.6.1 nur eine Zwischenversion war, die schnell wieder überholt wurde, ist die GNU C 2.6.3 eine besonders gute und stabile Version. Nachdem Pure C, zumindest vorerst (da, nach dem Ablauf der Vereinbarung, nun mehr keine (!) BORLAND-Sourcen verwendet werden dürfen), aus dem Rennen ist, hat GNU C gute Chance ein großes Stück vom Atari-C-Markt für sich zu gewinnen.
Das größte Manko von GNU C ist die fehlende GEM-Einbindung. Dank der Mupfel 1.a ist das Arbeiten jedoch deutlich komfortabler geworden, ja richtig elegant. Zwar reicht es nicht an den Komfort von Pure C heran, dafür ist es vom C++ Sprachumfang auch einer Pure C 2.0 Version, die ein paar OOP- Elemente haben wird, aber kein vollständiges C++ werden soll, haushoch überlegen.
Dank der MINT Libraries z.Zt. PL 45 und der MINT Patches von Andreas Schwab ist GN-LJ C 2.6.3 nicht nur vom Sprachumfang, sondern auch bezüglich der Anpassung an das Betriebssystem auf dem neuesten Stand.
Der Programmierer, der erst einmal von C zu C++ umgestiegen ist, wird seine Effektivität deutlich erhöhen, auch wenn die Umstellung von C nach C++ am Anfang schwer fallen sollte.
Mit dem Erscheinen möglicher C++ Klassenbibliotheken würde sich die Effektivität noch weiter steigern, denn, außer auf dem Atari, arbeiten eigentlich alle anderen Plattformen mit C++. Vielleicht gibt es ja in Zukunft jemanden, der eine C++ Klassenbibliothek zur Programmierung von GEM schreibt? Sozusagen "ObjectGEM" für GNU C.
Nicht nur unter DOS/Windows & OS/2, sondern auch auf Mac OS & Amiga OS (z.B.: Maxon C++) ist C++: "State of the art". Daher hat GNU C 2.6.3 das Zeug dazu DAS (!) C-ENTWICKLUNGSSYSTEM schlechthin zu werden, denn Konkurrenz im Sprachumfang braucht es nun wirklich nicht zu fürchten, auch wenn Pure C 2.0 schon morgen erhältlich sein sollte.
Denn ein paar OOP-Elemente machen noch keinen C++ System.
Trotzdem steckt in Pure C natürlich sehr viel Arbeit und alle Sourcen von Borlandroutinen zu befreien und, aus rechtlichen Gründen, nur noch eigene Routinen zu verwenden.
Der Vorteil von GNU C 2.6.3 ist aber, dass die ganze C++ Programmiererwelt ihr Knowhow und Können in dieses System einfließen lässt, weil es der GNU Public License unterliegt und somit immer frei verfügbar ist.
Filipe P. Martins