3 System
3.1 Speicher
Die Einführung macht klar, daß irgendeine Form von Kontrolle über die benutzten Speicherbereiche erforderlich ist. Ohne diese könnten alle möglichen Jobs zur selben Zeit in denselben Bereichen arbeiten und einander die Daten verderben. So ist eine der wichtigsten Aufgaben des Qdos, dafür zu sorgen, daß keinesfalls irgendwelche zwei Jobs zufällig in dieselbe Speicherstelle schreiben. Was natürlich nicht heißt, daß wir einfach irgendein Programm zusammenstellen können und darauf vertrauen, daß Qdos nun die Schutzfunktion gegenüber anderen Programmen übernimmt. Schreiben von Daten irgendwohin in den Speicher wird mit einiger Sicherheit zum Zusammenbruch des Systems führen. Damit der Schutz wirksam werden kann, sind Regeln zu befolgen, wie sie hier beschrieben werden.Der Ort, an den Qdos die Codeteile, also auch Programme, lädt, ist vorher nicht bekannt. Darum müssen sie folgenden Bedingungen genügen:
Auch sollte der Speicher in koordinierter Weise benutzt werden. Zwar übernimmt Qdos den Schutz alter und die Zuteilung neuer Bereiche, doch die Reihenfolge hängt vom Verlauf der Programme ab. Bei häufig veränderter Speicheraufteilung werden Teilbereiche freigegeben und in neuer Größe besetzt. So können bei unkontrolliertem Vorgehen Sperren durch noch vergebene Stücke entstehen, die den gesamten Speicher zerteilen. Geschlossene größere Bereiche lassen sich danach nur schwer wiedergewinnen. Ohne überlegte Anwendung richten die Hilfsmittel zur Speicherverwaltung auch nichts mehr aus. Ein "garbage collection" könnte durch Neuorganisation den Speicher aufräumen. Da so ein Zustand jedoch leicht vermeidbar ist, bietet das System dergleichen nicht an.
- Lageunabhängigkeit:
Programme müssen so aufgebaut sein, daß sie "relocatibel" sind, d.h. an beliebiger und nicht vorhersagbarer Speicheradresse einsetzbar.- Wiederaufrufbarkeit:
Interruptgesteuerte Programme müssen außerdem Wiedereitrittstauglich sein ("reentrant"), d.h. in beliebigem Zustand unterbrechbar und fortsetzbar. Darum ohne feste Datenbereiche, die durch mehrfachen Aufruf desselben Codeteils verdorben werden könnten, und auf jeden Fall ohne sich selbst modifizierenden Code.
3.1.1 * Speicheraufteilung
Als ersten Hinweis verfügen wir im Handbuch {20} über die "memory map", eine Tabelle der Speichereinteilung, die nun einzeln zu betrachten ist. Gelegentliche Hinweise auf noch nicht behandelte Systemdaten lasse man getrost erst einmal unbeachtet. Sie werden später nützliche Referenzen sein. Die hier angegebenen Adressen sind der Abstand in positiver Richtung (offset - Versatz) zur Basis der Systemvariablen, immer abgekürzt als (sb).
SV_RAMTOP : Ram Top
- $0020(sb) Obergrenze des Speichers
Diese Systemvariable enthält die Adresse, die auf die erste nicht mehr verfügbare Speicherstelle zeigt, die für das System also eigentlich keine ist.
SV_RESPR : Resident Procedure Area, rpa
- $001C(sb) Bereich residenter Proceduren
Alles, was ständig im Speicher "residiert", ist hier sicher vor Überschreiben durch das Betriebssystem geschützt. Systemerweiterungen gehören hierher.
Das Betriebssystem kann in diesem Bereich nach niedrigen Adressen hin Speicher an Programme vergeben und diesen auch wieder zurückholen. Beides aber nur, solange der Bereich transienter Programme "darunter" frei ist. Für gewöhnlich wird der residente Speicher gleich nach dem Kaltstart reserviert. Später kann er nicht wieder aufgegeben werden.
Erweiterungen {TK2} und neue Betriebssysteme haben meist eine Möglichkeit, residente Erweiterungen auch später noch in anderen Bereichen unterzubringen.
Bei den SQ-Systemen können die wirklichen Grenzen bis RAMTOP nur gemutmaßt werden. SV_RAMTOP hat dort denselben Wert wie SV_RESPR, was schlicht falsch ist: Der Bereich (SV_RESPR) bis (SV_RAMTOP) ist zum Schutz von Anwendungsdaten gegen Zugriff durch das System gesichert, nicht umgekehrt. Und wenn auch aus rein prinzipiellen Erwägungen nicht unbedingt ratsam, kann dorthin durchaus auch geschrieben werden, gegen Lesen dieses Bereich gibt es ohnehin keinen vernünftigen Einwand.SV_TRNSP : Transient Program Area, tpa
- $0014(sb) Nicht fest umgrenzte Programme
Die hierher mit EXEC oder EXEC_W etc. geladenen Codeteile gelten als selbständige Programme, Jobs. Sie können jederzeit aus dem Speicher gelöscht werden. Den Ort, an den sie geladen werden, wählt das Betriebssystem nach Maßgabe des verfügbaren Speichers aus. Darum ist deren Position nicht vorherbestimmbar. So ist es sinnvoll, sie relocatibel aufzubauen. Bei den verwendeteten Processoren ist das kein Problem. Sonst muß vor dem Aufruf immer erst ein besonderes Programm, der "Linker", die Adressierung anpassen. im Gefolge solcher Anpassungen treten insbes. bei den jüngeren Systemen für Processoren ab 68020 nicht immer leicht zu bewältigende Probleme mit den Processor-Caches auf.
SV_BASIC : SuperBASIC Area, sba
- $0010(sb) Bereich des Basic-Interpreters
Der einzige frei verschiebliche Speicherbereich wird vom Basic benutzt. Nahezu jeder Vorgang darin kann sowohl solch eine Verlagerung bewirken, als auch die Änderung der eigenen Bereichsgröße. Der Zugriff erfolgt durch eine Art virtueller Speicherverwaltung: Eine Basisadresse, die dem Programm selbst nicht bekannt sein muß, steht in einem Register bereit. Jegliche Referenz auf Daten oder Programmteile erfolgt mittels Offsetangaben dazu. Hier in SV.BASIC findet sich diese Adresse nur für die Verwaltung durch Qdos und den Interpreter selbst. Wegen des nie gewissen Zeitpunktes einer eventuellen Verlagerung ist sie von anderen Jobs nicht zuverlässig nutzbar. Das Register für die Basisadresse ist A6, wie (im Startzustand) bei allen Jobs im QL. Es muß in den Teilen der residenten Erweiterungen stets erhalten bleiben, wenn sie vom Basic aus aufgerufen werden. In diesem besonderen Fall darf auch innerhalb der Aufrufe das Register nur unter gewissen Bedingungen verändert werden. Wie für Qdos gibt es eine Anzahl Systemvariabler, die nur für die vielfältigen Aufgaben des Basic-Interpreters gelten. Diese BV_.. benannten Variablen liegen als besondere Datengruppe innerhalb des Basic-Jobs.
SV_FREE : Bereich (bedingt) frei nutzbaren Speichers
- $000C(sb)
Dieser Bereich erstreckt sich bis zur Obergrenze des Heap, der anschließend beschrieben wird. Er ist "frei" zur allgemeinen Verwendung DURCH DAS SYSTEM. Dort werden u.a. in "slave blocks", das sind einer verwaltenden Einheit zugeordnete Hilfsspeicher, Daten von und für Files zwischengespeichert. Durch dieses "slaving" wird die Zahl der Hardwarezugriffe gering gehalten und der Datentransport beschleunigt. Der Bereich steht gleichzeitig aber ungehindert neuen Programmen zur Verfügung. Dafür müssen gelegentlich einige Blöcke aufgegeben werden. Qdos sorgt dafür, daß gültige Daten zuvor gesichert werden. Diese erzwungene Operation heißt dann "forced slaving". So ist hier eine ganz besondere Verwaltung erforderlich, die im Wesentlichen durch Qdos und sein "filing subsystem", einem Hilfssystem zur File-Verwaltung, wahrgenommen wird. Sicher ist es dem Leser schon aufgefallen, daß der QL gelegentlich beim Laden das betreffende Laufwerk nur kurz anlaufen läßt, es sonst aber nicht weiter aktiviert. Das ist Resultat dieser im Hintergrund ablaufenden Zwischenspeicherung.
SV_CHEAP : Common Heap, System Heap, User Heap
- $0004(sb) Spezielle Speicherbereiche
Hier richtet Qdos die Kanaltabellen und -Definitionen ein, dazu den Arbeitsspeicher für die Gerätebedienung und andere Aufgaben des IOSS (input/output subsystem) und des FSS (filing subsystem). Jobs können sich hier einen eigenen Speicher reservieren und geben ihn mit ihrer Auflösung automatisch wieder frei.
Die verschiedenen Bezeichnungen dienen entsprechend dem jeweiligen Verwendungszweck nur der begrifflichen Unterscheidung. Ihre Verwaltung wird durch besondere Sytemaufrufe unterstützt.SV_BASE : Die Basisadresse der Systemvariablen.
- $0000(sb) (mit der Identifizierung SV_IDENT)
In allen "offiziellen" Versionen des QL auf $28000 angesiedelt, heißt das jedoch nicht, daß die Systemvariablen immer dort vorhanden sein müssen. Es wird dagegen vielmehr ausdrücklich darauf hingewiesen, daß die Adresse nicht bindend gilt {1,2}. Besonders {2} regt eine Verlegung nach $30000 an, damit der bereits vorbereitete zweite Bildschirmbereich genutzt werden kann. Dies ist in einer besonderen Betriebsart der MINERVA der Fall, und in verschiedenen der jüngeren QDOS-Varianten oder z.B. auch im UQLX-Emulator. Gewinnung der betr. Adressen ist völlig problemlos durch MT.INF für die Systemvariablen rsp. eine kurze SD.EXTOP-Routine für die Bildadresse möglich. "Gewußte" Fixzahlen führen hier leicht zu Fehlern.
3.1.2 * Speicherverwaltung
Neben den später behandelten Hilfsmitteln ist der Speicher das wesentliche Arbeitsgebiet eines jeden Computers. Alle Programme werden dort für den Zugriff durch den Processor bereitgehalten. Alle seine Operationen finden darin statt oder werden mit Hilfe dort abgelegter Daten gesteuert. So hat ein Betriebssystem auch die Verwaltung des Speichers zu ermöglichen.Der Speicher kann vom Qdos jederzeit und in ständig wechselnder Aufteilung vergeben worden sein. Das System selbst oder Jobs und andere Programme veranlassen dies mittels einiger der Manager-Traps und Vectoren. Auch Routinen beim Einrichten oder Schließen von Kanälen haben neben der eigentlichen Aufgabe solche Funktionen zu erfüllen.
Daneben wickelt die Speicherverwaltung nicht nur Zuweisung und Freigabe von Speicherbereichen ab, sie erfüllt auch eine Schutzfunktion. Diese steckt tief im System und betrifft auch nur dessen Wirkungen. So kann es schnell geschehen, daß durch direkten Eingriff in einen reservierten Arbeitsbereich das ganze System zusammenbricht.
Die Datentypen erfordern jeweils besonderes Vorgehen:
3.1.2.1 - Residente Proceduren
(von SV.RESPR(sb) bis SV.RAMT(sb)-1)Der Bereich ist gegenüber Veränderungen durch das System geschützt. Darum können hier eingetragene Codeteile ohne Gefahr auch das Betriebssystem selbst verändern.
Es gibt je eine Manager-Trap, MT.ALRES (1/22) und MT.RERES (1/23), mit der dort Platz reserviert oder wieder freigegeben werden kann. Dies aber nur solange in der tpa noch kein Programm steht. Da jener Bereich nicht verschiebbar ist, wird dann eine Veränderung hier nicht mehr erlaubt.
MT.RERES wurde erst mit MINERVA funktionsfähig.
3.1.2.2 - Transiente Programme
Dieser Bereich ist jederzeit veränderbar - nicht in seiner Lage, jedoch in seiner Größe und Aufteilung. Werden die Veränderungen an seinem offenen Ende vollzogen, so kann sich sein gesamter Bereich in den restlichen Speicher hinein ausdehnen oder Teile an ihn zurückgeben. "Offen" ist die Seite nach niedrigen Adressen zum Basic-Bereich hin, der sich als einziger auch in der Lage jederzeit verändern läßt. Sonst entstehen bei der Freigabe Lücken, die bei neuer Zuweisung im allgemeinen nur teilweise ausgefüllt werden, oder offen bleiben, wenn sie dafür zu klein sind. Qdos verwaltet diese Teilbereiche derart, daß sie später vollständig freigegeben werden können, sobald zum Ende hin keine besetzten Stellen mehr verzeichnet sind.(von SV.TRNSP(sb) bis SV.RESPR(sb)-1)Die hier untergebrachten Programme sind das, was allgemein Job heißt. Die Traps MT.CJOB (1/1) oder MT.RJOB (1/4) und MT.FRJOB (1/5) richten dort Jobs ein und organisieren die zugehörigen Speicheranteile. Mit MT.FREE (1/6) wird der größte freie Bereich ermittelt. Weitere Möglichkeiten der Speicherzuweisung gibt es hier nicht.
Jedoch kann etwa ein Puffer in Gestalt eines niemals zu aktivierenden Jobs eingerichtet werden, oder es steht zur Sicherheit gleich an dessen Anfang eine endlose Schleife in Form eines Sprunges auf dieselbe Adresse. Ein Beispiel liefert QUILL, und es zeigt zugleich, welch ein Unsinn das ist. Reine Bunker-Jobs kosten unnötig Zeit durch die Systemverwaltung und wegen der zusätzlichen Daten auch Speicher. Sie bieten kaum Vorteile gegenüber der ordentlichen Zuweisung und Freigabe mit MT.ALCHP rsp MT.RECHP (1/24, 25).
3.1.2.3 - Basic
(von SV.BASIC(sb) bis SV.TRNSP(sb)-1)Der (erste) Basic-Befehlsinterpreter wird durch das System automatisch als Job mit der Nummer (Job-ID) Null eingerichtet, sofern nicht eine ROM-Erweiterung das Betriebssystem sofort übernommen hat. Er reklamiert für die eigenen Daten und für das Programm, in diesem Falle nicht als Processorcode, sondern in Form eines tokenisierten Basic-Programms, seinen Teil des Speichers. Damit der nun für weitere Programme - Jobs - nicht versperrt wird, ist er, neben weiteren Basic-Interpretern bei MINERVA, der einzige Job, der sich in den Speicher hinein ausdehen oder auch Teile seiner selbst wieder aufgeben kann. Hierzu dienen MT.ALBAS (1/22) und MT.REBAS (1/23) - deren Funktion für SQ jedoch nicht mehr erklärt wird und zweifelhaft ist {15}.
3.1.2.4 - Heap in Varianten
(SV.HEAP(sb) bis SV.BASIC(sb)-1)
IOSS und File-Systeme kontrollieren ihre Speicherbereiche selbst, wie das in den betreffenden Handlern (s. dort) vorgegeben ist.
- Common Heap:
Ein "Haufen" (heap) allgemein (common) für Programme freien Speichers.- System Heap:
Dort richtet das Betriebssystem Tabellen ein, oder weist den Kanälen Bereiche für ihre Tabellen zu; die Hilfssysteme erhalten hier ihre Arbeitsspeicher.- User Heap:
Programme können in zuvor reservierten Heap-Blöcken eigene Bereiche ähnlich verwalten, wie dies bei o.g. "heap" durch das System geschieht.
Heap Verwaltung durch das System
Für die freie Verwendung des Heap einmal ein Beispiel {1}:Anfangs sei er unbenutzt und leer.
Dann reklamiert Job 'A' einen Teil davon beim Qdos, indem er den Bedarf mit MT.ALCHP (1/24) anmeldet. War genügend Platz frei, erhält er die Anfangsadresse in A0 mitgeteilt und der Heap sieht etwa so aus:
- frei - Bereich A
Dann kommt irgendein Job 'B', und will auch seinen Teil haben, ein weiterer Job 'C' setzt seinen Speicher darüber:
- frei - Bereich C Bereich B Bereich A
Nun wird irgendwann der Job 'B' entfernt. Weil Qdos über die Speichervergabe Buch führt, und erfährt, daß der Job auch ein Stück Speicher besaß, gibt es dieses frei:
- frei - Bereich C - frei - Bereich A
Ein weiterer Job reklamiert Speicher, und nachdem Qdos den erstbesten ausreichend großen Bereich gefunden hat, erhält dieser Job 'D' das entsprechende Stück in der eben freige-wordenen Lücke zugeteilt:
- frei - Bereich C - frei - D Bereich A
Der nächste Job 'E' benötigt einen weit größeren Bereich, der nicht mehr zwischen 'D' und 'C' paßt, und so erhält ihn im noch unbenutzten Teil oberhalb von 'C'.
Bereich E Bereich C - frei - D Bereich A
Schließlich kommt 'A' mit einer neuen Anforderung. Qdos weist ihm dann nach der Suche im Speicher die Stelle nach dem Bereich von 'D' unterhalb von 'C' zu, wo gerade noch genug Platz ist:
Bereich E Bereich C mehr A D Bereich A
Werden nun etwa die Jobs A und C aufgegeben, ist vielleicht noch eine sonstwie genutzte Reservierung hinzugekommen, so kann ein neuer Job F von derselben Größe wie E nicht mehr ausgeführt werden, da der zusammenhängede Bereich trotz ansich genügend freien Speichers zu klein ist.
Bereich E - frei - S D - frei -
Vermeiden der "heap fragmentation"
Jetzt läßt sich auch erkennen, wie nach zahlreichen Zuweisungen und Freigaben der Speicher total zerstückelt sein wird:Vor jedem reservierten Teilbereich stehen vier Langwort-Posten, mit deren Hilfe Qdos die Zuteilung verwaltet. Es ist darin zuerst die eigene Länge verzeichnet, und dann die Kennung des Besutzer-Jobs dieses Bereichs, weiter die Adresse des bei und zur Freigabe aufzurufenden Programmteils und schließlich ein für Markierungen durch das System freigehaltener Langwort-Platz.
SQ wandelt einmal mehr auf eigenen und geheimen Pfaden: Was herausgefunden werden konnte ist, daß statt der Adresse der Freigaberoutine u.U. eine Null eingetragen wird. Wie man damit ggf. umgehen kann, zeigt ein Beispiel im Anhang.Nach der Freigabe steht am Anfang die Länge des von da an freien Bereichs und die Adresse des ggf. nächsten freien Blocks, rsp. eine Null am Ende der Kette.
Nur, wenn in Reihenfolge und mit absteigenden Adressen unmittelbar aneinander anschließende Bereiche reserviert wurden, kann Qdos die Teile später wieder zusammenfügen. Die Freigabe beginnt bei einem beliebigen Teilbereich und man fährt in unregelmäßiger Folge so fort. Benachbarte freie Felder werden dann zu einem entsprechend größeren Einzelblock zusammengefaßt. Irgendwann wird das Ende der Kette erreicht sein. Danach steht der gesamte Bereich ab dem zuerst freigegebenen Teil geschlossen zur Verfügung.
Der Anwender wird die Vergabe im allgemeinen nicht direkt kontrollieren können, denn diese geschieht vorrangig durch das System. Indirekt ist die Steuerung jedoch durch Wahl der Reihenfolge möglich, in der die betreffenden Jobs eingerichtet werden. So wird dann die geschlossene Freigabe aufgrund der zu erwartenden Reihenfolge beim Löschen wahrscheinlich.
Umso wichtiger sind geeignete Maßnahmen bei der Programmgestaltung. Dort ist es ein leichtes, und sinnvoll, statt der Zuweisungen eines einzigen Monster-Blocks oder gar mit den Datenbereich des Jobs selber die Reservierung bedarfsweise in mehreren sinnfällig gestückelten Einzelposten vorzunehmen. Diese fügen sich dann sehr viel leichter in bestehende Lücken des Gesamtspeichers ein. Ein aufschlußreiches Beispiel gibt etwa die "zip"-Dateienkomprimierung mit über 300K "dataspace".Verschachtelung von verketteten Speicherblöcken entsteht sehr leicht, wenn verschiedene länger im Speicher verweilende Jobs in unregelmäßiger Reihenfolge Reservierungen vornehmen.
Wurde der Block mit MT.ALCHP reserviert, und ist er auch weiterhin besetzt, steht an dritter Stelle die Adresse des nächsten besetzten Speicherteils, die anderen Werte beziehen sich dann ebenfalls auf besetzte Bereiche {MGG}. Die vierte Eintragung ist "unbenutzt", nicht aber zur freien Verwendung geeignet, denn spätere Betriebssysteme mögen durchaus Gebrauch davon machen (z.B. MINERVA).
Die Heap-Verwaltung bietet zugleich einen Ausweg aus der Misere. Qdos erlaubt nämlich auch das Einrichten eines User-Heap. Das ist ein Speicherblock, der von einem Job selbst in gleicher Weise verwaltet wird, wie der Common Heap durch Qdos. Mit Hilfe besonderer Aufrufe der Traps MT.ALLOC (1/12) und MT.LNKFR (1/13) richtet sich der betreffende Job den größtmöglichen oder -nötigen Block ein und teilt ihn dann nach Bedarf selber auf.
Der Vorgang beginnt mit dem Aufruf von MT.ALCHP, oder es dient dazu der eigene Datenbereich des Jobs. Der User-Heap wird dadurch errichtet, daß das Programm ein Pointerfeld der beschriebenen Art an den Anfang des Speicherblocks setzt.
Sein Pointer für den nächsten freien Bereich steht auf Null und das Längenfeld gibt die Größe des gesamten verfügbaren Bereiches an. Letzteres signalisiert später dem System das Ende der Liste. Die Pointer auf die jeweilige Folgeadresse sind relativ zu ihrer eigenen Position. Die A6-relative Adresse des Pointerfeldes dient dann als Basis für die Trap-Aufrufe. Das Programm muß neben der Adresse des aktuellen Pointerfeldes die Gesamtlänge speichern und verfügbar halten.
Ein so eingerichteter User-Heap kann durch Ankoppeln an das Ende der Liste freier Bereiche des Common Heap dorthin ausgedehnt werden. Aufgrund der vollständig relativen Adressierung ist er auch verlagerbar.
Auch die Vectoren MM.ALCHP ($C0) und MM.RECHP ($C2), dann MM.ALLOC ($D8) und MM.LNKFR ($DA), sind hierfür einsetzbar. Im Unterschied zu den Trap-Aufrufen wird dort absolut adressiert, sodaß diese Vectoren weniger flexibel anzuwenden sind.
Die ersten beiden sind vornehmlich zum Gebrauch innerhalb von Device-Handlern gedacht. Sie dürfen keinesfalls aus einem Interrupt-Service heraus und nur im Supervisor-Betrieb aufgerufen werden. A6 muß die Basisadresse der Systemvariablen enthalten.
Im Vorgriff auf später zu Erklärendes schon einmal der Hinweis, daß die erstmalige Zuweisung von Kanälen auf die einzelnen Geräte vor allen anderen Reservierungen erfolgen sollte. Ganz besonders, wenn Directory Devices betroffen sind, z.B. Microdrive oder Floppy. Diese richten sich für jedes Laufwerk besondere Tabellen in unteren Speicherbereich ein, die auch nach Schließen aller Kanäle ihre Speicherblöcke nicht mehr zurückgeben.
Eine einfache Maßnahme besteht darin, gleich zu Anfang auf allen Laufwerken einen Kanal aufzumachen und ihn sofort wieder zu schließen. Dann stehen die Tabellen am Anfang des System Heap und können von nun an keinem Job mehr hinderlich werden.
3.1.2.5 * Queue
Wie bei einer einfachen Speicherreservierung wird auch hier ein Header aus 16 Bytes aufgebaut, den aber diesmal das IOSS betreut. Es folgt der Pufferspeicher.Eingerichtet wird solch eine Queue mit dem Vector IO.QSET ($DC), dem neben der Puffergröße in D1 die Basisadresse eines um mindestens 16 Bytes größeren freien Speicherbereichs mitzugeben ist.
eoff | nextq end nextin nextout queue 0 = basis 4:ende 8:schreiben 12:lesen 16+: Daten...
- Q.EOFF
Das erste Bit (bit#7 im ersten Byte an der Queueadresse) siganlisiert den EOF-Zustand der Queue, wenn es gesetzt ist.- Q.NEXTQ
kann auf eine Anschluß-Queue zeigen.- Q.END
zeigt hinter die letzte Stelle des Puffers.
SQ: in CON-Kanal-Queues Adresse des letzten Byte INNERHALB der Queue.- Q.NEXTIN
zeigt auf die Adresse, an die das nächste Byte zu schreiben ist.- Q.NEXTOUT
ist die Adresse, ab der die noch ungelesenen Daten abzuholen sind.- Q.QUEUE
Beginn der Daten-Schlange ("queue").
Pufferspeicher dieser Art sind auch ohne ausdrückliche Bereichszuweisung einzurichten. Wie das Betriebssystem die Organisation übernimmt, wie es solche Bereiche freigibt, und wie Programme sich dieser Einrichtung bedienen können, erklären die Darstellungen zu den verschiedenen Devices. - Mit, was will man anderes erwarten, gewissen "Ausnahmen" für die SQ-Systeme.
3.1.2.6 * Allgemeine Strukturen
Die Queue ist Vorstufe eines Device, der PIPE, wo selbst eine Basisadresse nicht mehr bekannt sein muß. Damit ist eine Form virtuellen Speichers vollständig installiert. rsp, um mit der Mode zu gehen, ein "Objekt", auf das mit den "Methoden" in Gestalt der Qdos-Traps zugegriffen wird.In weiter gefaßtem Sinne sind auch alle anderen Geräte des QL, soweit sie mit der Speicherung von Daten zu tun haben, virtuelle Speicher und "Objekte". Zugriffsmittel (oder "Methoden" des Zugriffs) sind dabei die Traps und Vectoren des Qdos. So wird die Position in einem File etwa der Ram-Disc auf dieselbe Weise eingestellt, wie das bei der Floppy Disc geschieht. Anschaulicher noch wird das mit dem MEM-Device aus {4}, dessen Arbeitsbereich der gesamte als RAM oder ROM "wirkliche" Speicher ist. Es kann sogar über Netzwerk gleichermaßen im Speicher eines anderen QL wirksam werden, für die Anwendung erscheint es prinzipiell ohne Unterschied.
Geräteabhängiges braucht uns nicht zu kümmern, es wird bestens und zuverlässig vom jeweiligen Handler betreut.
Wie die noch folgenden Ausführungen zeigen werden, ist diese konsequent durchgeführte Einrichtung der virtuellen Speicher eine große Stärke des Betriebssystems.