Programmierecke - Der Schrumpfschlauch im Speicher
Viele Dokumentationen weisen darauf hin, daß bei der Programmierung von Accessories dringend unbenötigter Restspeicher freigegeben werden sollte. Warum sagt eigentlich keiner, daß GEM dies beim Start von Accessories von selbst tut!
Gemäß dem Wahlspruch, daß man sich nicht auf andere verlassen kann, sollte jeder Programmierer seinem Accessory-Startup-Code eine Routine zur Berechnung der eigenen Codelänge und der Freigabe des übrigen Speichers spendieren. Es entbehrt jedoch nicht einer gewissen Logik, daß GEM eigenhändig nicht benötigten Speicher ans System zurückgibt: Solange ein Accessory sämtlichen Speicher besitzt, kann es weder weitere Accessories nachladen, noch könnte es überhaupt einen sauberen GEMBetrieb garantieren, da schließlich auch das AES einigen Speicher für seine Verwaltung anfordert.
Dennoch ist es sehr hilfreich, von diesem Feature zu wissen, beispielsweise bei der Konstruktion selbstentpackender Programme. So erzeugen beispielsweise »BAPACK« und »PFXPACK« ausführbare gepackte Programme, die sich vor dem eigentlichen Start erst einmal selbst entpacken. Das wiederum setzt voraus, daß ausreichend freier Platz für das entpackte Programm bereitsteht. Bis vor kurzem entpackten »PFXPAK«-Programme dementsprechend ihre Daten jenseits der eigentlichen Programmgrenzen im Heap, weil sie einfach davon ausgingen, daß dieser dem entpackenden Programm gehört.
Das Resultat war, daß alle Applikationen problemlos starteten, denn ihnen gehört der »Heap« ja grundsätzlich vollständig. Accessories jedoch warfen Bomben, da die Programmdaten in einen Speicherbereich entpackt wurden, der gar nicht mehr ihnen, sondern in den meisten Fällen später geladenen Accessories gehörte. Damit wurde der Code der anderen Accessories beschädigt und das System unbrauchbar.
Deshalb fügen neue Versionen von PFXPAK passend größere Werte für das »Block Storage Segment« (BSS) im Header der gepackten Programme ein. Damit wird sichergestellt, daß ein entsprechender Speicherbereich auch bei Accessories reserviert bleibt und keine Schädigung fremder Daten mehr auftritt.
Nun, da der TT endlich in größeren Stückzahlen verkauft wird, offenbaren sich nach und nach kleinere Fehler in den erhältlichen Programmen. Einer davon ist immer noch weit verbreitet: der »vro_cpyfm()«-Fehler.
Die VDI-Funktion »vro_cpyfm()« benutzen Programmierer gern und oft, um beispielsweise Bildschirmhintergründe bei der Überlagerung durch eine Fileselector-Box oder Dialogboxen zu retten. Leider mußten einige Entwickler feststellen, daß ihre Programme in den erweiterten TT-Auflösungen nach dem Aufruf dieser Funktion geradezu wirre Dinge zu tun begannen oder gänzlich abstürzten. Nach einigem Suchen konnten wir die Ursache dieser rätselhaften Crashs ermitteln: fehlerhafte Koordinatenangaben an die »vro_cpyfm()«-Funktion. Diese erwartet nämlich im Parameter »pxyarray« echte Bildschirmkoordinaten für das zu kopierende Rechteck. Manche Programme übergaben statt dessen jedoch allein die Koordinaten der linken oberen Ecke und Angaben bezüglich Breite und Höhe. So wurden beispielsweise zum Kopieren eines Standard-ST-Monochrombildschirms die Werte 0, 0, 640, 400 übergeben. Richtig wäre jedoch 0, 0, 639, 399, denn auf der gängigen ST-Monochromauflösung gibt es keinen Punkt mit den Koordinaten 640/400.
Während die älteren Betriebssysteme diesen Fehler mehr oder weniger tolerierten, verhält sich der TT wesentlich »pingeliger«. Falsche Angaben produzieren in der mittleren TT-Auflösung unvorhersehbare Ausfälle, meist einfache Busfehler, manchmal Pixelmüll, selten einen vollständigen Systemabsturz. Provisorische Abhilfe ließe sich mit einem kleinen Patch-Programm schaffen. Da es sich jedoch im engeren Sinne nicht um einen Fehler im Betriebssystem, sondern in den Programmen handelt, bleibt es die Aufgabe der Entwickler, solche Patzer zu beheben.
Entgegen anderslautenden Gerüchten sind AES-Aufrufe im Supervisor-Modus durchaus erlaubt [1]. Das AES hat nur leider einige Angewohnheiten, welche die Arbeit verkomplizieren.
Zum einen kehren etliche Funktionen, die im Supervisor-Modus aufgerufen wurden, im User-Modus zum Programm zurück. Um welche es sich dabei genau handelt, hat Atari nicht dokumentiert, es sind aber, so konnten wir durch Versuche feststellen, eine ganze Reihe. Deshalb bleibt es am Programmierer, nach dem AES-Aufruf den CPU-Status zu erfragen, und zwar durch
long state = Super(1L);
Enthält die Variable "state« nach dem Aufruf den Wert 0L, dann befindet sich das System im User-Modus. Beim Wert 1L dementsprechend im Supervisor-Modus.
Weiterhin bereiten AES-Aufrufe im Supervisormodus dann Probleme, wenn derselbe Stack wie im User-Modus Verwendung findet, was z.B. dann der Fall ist, wenn der Supervisor-Modus via
Super (0L);
betreten wurde. Bei jedem Aufruf rettet das AES nämlich verschiedene Register stets auf den User Stack. Und das unabhängig davon, in welchem Modus der Aufruf geschah. Dabei überschreibt es dann prompt wertvolle Daten. Dementsprechend muß ein umsichtiger Programmierer unbedingt einen eigenen Stack einrichten, mit dem die Routine dann arbeiten kann.
Und zum dritten schreibt die CPU bei einem AES-Call im Supervisor-Modus sogar hinter den Stack, weshalb oberhalb des Stackpointers noch ein kleiner Speicherbereich (Atari empfiehlt mindestens 12 Byte - mehr sind natürlich besser) freigelassen werden muß.
Somit ist der AES-Aufruf im Supervisor-Modus zwar ziemlich kompliziert, aber dennoch zu bewerkstelligen und in manchen Fällen sehr praktisch.
(uw)
Nachtrag
Ausgerechnet in der 25. Programmiererecke (Ausgabe 3/91, »Von Fenstern und Speicherplatz«, Seite 92ff) hat ein Druckfehler allerhand Verwirrung gestiftet [2]. Dort war zu lesen, der Speicher würde sich bei Verwendung unseres "Mxalloc/2-Listings" »in wesentlich kürzerer Zeit« füllen als das bisher geschah. Tatsächlich füllt sich der Speicher erheblich langsamer als zuvor, es bleibt also längere Zeit freier Speicher erhalten.
Laurenz Prüßner/uw
Literatur:
[1] »Rainbow TOS Release Notes«, Atari Corp. Sunnyvale 1989
[2] L. Prüßner: Von Fenstern und Speicherplatz, ST-Magazin 3/91, Seite 92, Markt & Technik Verlag
Egbert Meyer