7-1 Der VT52 Emulator Inhalt | 7-3 Tabelle der MIDI-Noten


Kapitel 7-2

Speicherorganisation im Omikron Basic

Speicherorganisation
Application Heap
Block Storage Section (BSS)
Data-Section


Speicherorganisation:

Application-Heap

Der Application-Heap ist ein Speicherbereich, der Ihrem Programm vom Betriebssystem zugeteilt wird. Wenn Sie zum Beispiel mit dem MEMORY-Befehl einen Speicherblock anfordern, so wird er aus dem Application-Heap genommen.

Weiterhin gibt es eine ganze Reihe von Betriebssystemfunktionen, die Speicherblöcke im Application-Heap allozieren. Auch wenn Sie selber keine MAC_OS-Befehle in Ihrem Programm verwenden, so kann es trotzdem zu solchen Speicheranforderungen kommen, da diverse Omikron Basic Befehle in MAC_OS-Aufrufe umgesetzt werden.

Auch der Pufferspeicher der Omikron Basic Ausgabefensters wird im Application-Heap angelegt. Der dafür notwendige Speicher berechnet sich dabei zu: Speicher für Ausgabefenster = Breite * Höhe * Farbebenen/8+ 1024. Wenn Sie also die Ausgabefenster benutzen, sollten Sie den Application-Heap mindestens auf diese Größe einstellen und zusätzlich noch wenigstens 65K für das Betriebssystem reservieren.

Die Größe des Application-Heaps kann man mit den beiden Compiler-Steuerwörtern COMPILER "MIN_SIZE X" und COMPILER "PRE_SIZE X" schon zur Compilierungszeit festlegen. Dabei gibt X im ersten Fall an, wie groß der Speicher mindestens sein muß, damit Ihr Programm überhaupt läuft und im zweiten Fall, wieviel Speicher Ihr Programm bevorzugt benötigen würde.

Falls genug freier Speicher vorhanden ist, bekommt Ihr Programm den bei PRE_SIZE angegebenen Wert, ansonsten weniger. Falls nicht mal die bei MIN_SIZE eingetragene Speichermenge frei ist, wird der Programmstart mit einer Fehlermeldung abgebrochen.

Hinweis: Beide Größen lassen sich auch nachträglich verändern, indem man das Programm-Icon selektiert und dann im Finder 'Information' anklickt.

Block Storage Section (BSS)

Am oberen Ende der BSS befindet sich der vom Omikron Basic verwaltete Stack. Er dient hauptsächlich dazu, lokale Variablen zu speichern. Im allgemeinen reichen für den Stack 16K aus. Wenn Sie allerdings rekursive Prozedur- oder Funktionsaufrufe mit hoher Schachteltiefe machen, so sollten Sie für den Stack mehr Speicher reservieren, um das Risiko zu vermeiden, daß der Stack in den Garbage-Bereich wächst.

Auch der SORT-Befehl benötigt größere Mengen Speicher auf dem Stack. Wenn Sie diesen Befehl zum Umsortieren größerer Felder benötigen, sollten Sie auf jedenfall mehr Stackspeicher reservieren. Dazu dient das Compiler-Steuerwort COMPILER "STACK X", wobei X die gewünschte Stackgröße angibt.

Unterhalb des Stacks liegen die Bereiche Garbage, String-Heap und Arrays. Dabei werden die Grenzen zwischen diesen Bereichen vom Omikron Basic dynamisch verwalten. Wenn z. B. im Array-Bereich durch einen DIM-Befehl mehr Platz gebraucht wird, dann wird der String-Heap nach oben geschoben und damit der Garbagebereich verkleinert. Da zur Compilierungszeit ja noch nicht bekannt ist, wie groß Ihre Felder mal dimensioniert werden bzw. wieviele Strings Ihr Programm zur Laufzeit anlegt und wie lang die einzelnen Strings sein werden, kann der Compiler nicht ausrechnen, wieviel Platz er für diese drei Bereiche reservieren muß. Sie müssen darum mit dem Compiler-Steuerwort COMPILER "BAS_MEM X" einen Wert vorgeben.

Um abzuschätzen, welcher Wert für X einzusetzen ist, nachfolgend einige Hinweise:

1. Der Platzbedarf von numerischen Arrays berechnet sich aus der Anzahl der enthaltenen Elemente mal der Bytezahl, die der verwendete Datentyp benötigt (Bit=1/8 Byte, Byte=1 Byte, Short-Integer=2 Byte, Long-Integer=4 Byte, Single-Float=4 Byte und Double-Float=8 Byte). Dazu kommen noch mindestens 16 Byte Verwaltungsinformationen für das Feld.

2. Für String-Felder sind 8 Byte pro Feldelement anzusetzen. Dazu kommt dann noch die Länge des eigentlichen Strings auf eine durch 8 teilbare Zahl aufgerundet und mit 2 multipliziert und weitere 8 Byte Verwaltung pro String. Wenn genug Speicher frei ist, kann man das Ergebnis auch noch gerne mit 2 oder 3 multiplizieren.

3. Der Garbagebereich wird benutzt, um vorübergehend Strings anzulegen. Z.B. wird bei einer String-Addition das Ergebnis zunächst im Garbagebereich zusammengebaut und dann erst einer String-Variablen zugewiesen. Auch Matrizenoperationen benötigen Platz im Garbagebereich. Dabei muß ein Feld der verwendeten Größe einmal in den Garbagebereich passen.

Unterhalb der Arrays befindet sich noch ein weiterer Block, der intern vom Omikron Basic verwaltet wird.

Data-Section

Die Data-Section enhält z.B. die TOC (Table of Contents) und die im Programm verwendeten Konstanten. Die Data-Section wird intern vom Omikron Basic verwaltet und hat nichts mit dem Befehl DATA zu tun.




 

7-1 Der VT52 Emulator Inhalt | 7-3 Tabelle der MIDI-Noten

Support | Bestellen | Start | Home: http://www.berkhan.de


© 1997-2001 Berkhan-Software