DE3280446T2

DE3280446T2 - Digitales Datenverarbeitungssystem.

Info

Publication number: DE3280446T2
Application number: DE88200921T
Authority: DE
Inventors: Richard Glenn Bratt; Gerald F Clancy; Edward S Gavrin; Ronald Hans Gruner; Craig James Mundie; Stephen I Schleimer; Steven J Wallach
Original assignee: Data General Corp
Current assignee: EMC Corp
Priority date: 1981-05-22
Filing date: 1982-05-21
Publication date: 1994-05-11
Anticipated expiration: 2002-05-22
Also published as: DE3280152D1; DE3280446D1; AU8017882A; EP0300516A2; AU556499B2; JPS57197652A; JPH0746316B2; JPH06324948A; EP0067556A3; JPH08263284A; EP0067556B1; EP0300516B1; JPH08278917A; EP0067556A2; EP0300516A3; JPH08263305A

Description

Die Erfindung betrifft ein digitales Datenverarbeitungssystem der im Oberbegriff des Anspruchs 1 angegebenen Gattung.
Ein allgemeiner Trend bei der Entwicklung von Datenverarbeitungssystemen weist in Richtung von Systemen, die zur Benutzung in vernetzten Datenverarbeitungseinrichtungen geeignet sind. Ein weiterer Trend geht in Richtung von Datenverarbeitungssystemen, bei denen die innere Struktur des Systems flexibel, vor Benutzern geschützt und tatsächlich unsichtbar für den Anwender ist und bei denen der Benutzer mit einer flexiblen und vereinfachten Schnittstelle dem System präsentiert wird.
Das System der Erfindung benutzt eine auf Objekten basierende Architektur, die an sich aus Computer Architecture News, Oktober 1980, Seiten 4-11, von J. Rattner et al bekannt ist.
Frühere Datenverarbeitungssysteme sahen keinen wirksamen Schutzmechanismus vor, der verhinderte, daß ein Anwender ohne Erlaubnis auf die Daten und Programme eines anderen Benutzers einwirken konnte. Derartige Schutzmechanismen erlaubten keine eindeutige, positive Identifikation von Benutzern, die den Zugang zu Informationen forderten, oder von Informationen selbst, noch waren derartige Mechanismen ausreichend flexibel im Betrieb. Außerdem gehörten Zugangsrechte mehr zu den Benutzern als zu den Informationen, so daß eine Kontrolle der Zugangsrechte schwierig war. Schließlich erlaubten Schutzmechanismen des Standes der Technik die Benutzung von "Trojanisches Pferd"-Argumenten. Das bedeutet, daß Benutzer, die keine Zugangsrechte zu gewissen Informationen hatten, in der Lage waren, durch einen anderen Benutzer oder eine andere Prozedur mit solchen Zugangsrechten Zugang zu diesen Informationen zu erhalten.
Es ist jedoch bekannt, eindeutige Identifizierungscodes zu benutzen, die einem entsprechenden Objekt zugeordnet sind, wie z. B. in Proceedings of the Spring Joint Computer Conference, 1072, S. 417-429, Afips Press, Atlantic City, N.J. USA; G. Scott- Graham et al offenbart ist. Es ist weiter bekannt, einen Speicherschutz dadurch vorzusehen, daß Zugangsrechte Objekten zugeordnet werden, vgl. Compcon Spring 80, Object of Papers, San Francisco, 25th-28th February 1980, S. 340-343, IEEE, N.Y., USA; T.D. McCreery.
Die Aufgabe der Erfindung besteht in der Schaffung eines verbesserten Schutzmechanismus, der auf Zugangsrechten in einer auf Objekten basierenden Computerarchitektur beruht.
Die Erfindung ist im unten angegebenen Anspruch 1 definiert.
Das Ausführungsbeispiel der Erfindung, das weiter unten beschrieben ist, bezieht sich auf die innere Struktur und Betriebsweise eines Datenverarbeitungssystems, das zur Benutzung in vernetzten Datenverarbeitungsnetzwerken geeignet ist, wobei die innere Struktur flexibel, gegen Anwender geschützt und für Benutzer in effektiver Weise unsichtbar ist und dem Anwender eine flexible und vereinfachte Schnittstelle darbietet. Das Datenverarbeitungssystem sieht einen Adressiermechanismus, der eine permanente und eindeutige Identifizierung aller im oder durch den Betrieb des Systems erzeugten Informationen erlaubt, und einen extrem großen Adressenraum vor, der allen diesen Datenverarbeitungssystemen gemeinsam und für diese zugänglich ist.
Der Adressiermechanismus sieht Adressen vor, die unabhängig von der physikalischen Konfiguration des Systems sind, und erlaubt mit einer einzigen Adresse die vollständige Identifizierung von Informationen bis auf Bitebene hinunter und bezüglich der Art oder des Formats der Informationen. Das System sieht weiter einen Schutzmechanismus vor, durch den variable Zugangsrechte einzelnen Körpern der Informationen zugeordnet sind. Informationen sowie Benutzer, die Zugang zu Informationen fordern, werden durch den Adressiermechanismus des Systems eindeutig identifiziert. Der Schutzmechanismus verhindert außerdem die Benutzung von "Trojanisches Pferd"-Argumenten. Das System sieht außerdem eine Befehlsstruktur vor, wobei auf hohem Niveau befindliche Befehle in Benutzersprache in gleichförmige, auf einem Zwischenniveau befindliche Befehle in einem Dialektcode transformiert werden, um für eine Vielzahl von Benutzersprachen gleiche Ausführungsmittel zu schaffen.
Ein weiteres Merkmal ist die Schaffung eines Operanden-Referenzmechanismus, wobei in Anwenderprogrammen auf Operanden durch gleichförmige Formatnamen Bezug genommen wird, die durch einen internen, für den Benutzer transparenten Mechanismus in Adressen transformiert werden. Das vorliegende System sieht zusätzlich vielstufige Steuer- und Stapelspeichermechanismen vor, die den internen Mechanismus des Systems vor Störungen durch Anwender schützen. Noch ein anderes Merkmal ist ein Datenverarbeitungssystem, das eine flexible innere Struktur besitzt, die befähigt ist, mehrere, gleichzeitige Operationen auszuführen, und eine Vielzahl von getrennten, unabhängigen Prozessoren enthält. Jeder dieser unabhängigen Prozessoren hat eine separate Mikrobefehlssteuerung und wenigstens einen separaten, unabhängigen Kanal (Port) zu einem zentralen Übertragungs-und Speicherknoten. Der Übertragungs- und Speicherknoten ist außerdem ein unabhängiger Prozessor, der eine separate und unabhängige Mikrobefehlssteuerung aufweist. Der Speicherprozessor ist intern aus einer Vielzahl von unabhängig arbeitenden, durch Mikrobefehle gesteuerten Prozessoren aufgebaut, die vielfache, gleichzeitige Speicher- und Übertragungsoperationen ausführen können.
Es ist vorteilhaft, die vorliegende Erfindung in ein Datenverarbeitungssystem einzubauen, weil das weiter unten beschriebene System einen Adressiermechanismus aufweist, der zur Benutzung in großen, vernetzten Datenverarbeitungsanlagen geeignet ist. Ein weiterer Vorteil des Systems besteht darin, daß es einen Schutzmechanismus für Informationen schafft, der zur Benutzung in großen, vernetzten Datenverarbeitungsnetzwerken geeignet ist. Vorteilhaft ist ferner, daß das System eine vereinfachte, flexible und wirkungsvollere Schnittstelle zu einem Datenverarbeitungssystem schafft. Ein weiterer Vorteil des Systems besteht darin, daß es ein Datenverarbeitungssystem schafft, das in gleicher Weise mit jeder Benutzersprache wirksam ist, indem ein Mechanismus, der auf Operanden in Anwenderprogrammen durch gleichförmige Formatnamen bezug nimmt, und eine Befehlsstruktur geschaffen werden, die gleichförmige, auf einem Zwischenniveau befindliche Befehle in einem Dialektcode vorsieht. Zusätzlich schützt das System innere Mechanismen von Datenverarbeitungsanlagen vor Benutzerstörungen, indem mehrstufige Steuer- und Stapelspeichermechanismen vorgesehen werden. Ein weiterer Vorteil des Systems besteht schließlich in der Schaffung einer flexiblen inneren Systemstruktur, die befähigt ist, mehrfache, gleichzeitige Operationen auszuführen, und eine Vielzahl von separaten, unabhängigen Prozessoren aufweist, von denen jeder eine separate Mikrobefehlssteuerung und wenigstens einen separaten und unabhängigen Port zu einem zentralen, unabhängigen Übertragungs- und Speicherprozessor aufweist, der aus einer Vielzahl von unabhängigen Prozessoren besteht, die vielfache, gleichzeitige Speicher- und Übertragungsoperationen ausführen können.
Weitere Vorteile und Merkmale der Erfindung werden dem Fachmann durch Bezugnahme auf die folgende, ausführliche Beschreibung von bevorzugten Ausführungsbeispielen und die Zeichnungen verständlich. Es zeigen:
Fig. 1 ein teilweises Blockdiagramm eines mit der Erfindung ausgerüsteten Computersystems;
Fig. 2 ein Diagramm, das die erfindungsgemäße Adressenstruktur des Rechnersystems darstellt;
Fig. 3 ein Diagramm, das den erfindungsgemäßen Befehlsstrom des Rechnersystems darstellt;
Fig. 4 ein Diagramm, das die Steuerungsstruktur eines konventionellen Rechnersystems darstellt;
Fig. 4A ein Diagramm, das die Steuerungsstruktur eines die vorliegende Erfindung ausnutzenden Rechnersystems darstellt;
Fig. 5-Fig. 472 einschließlich Diagramme, die sämtlich die vorliegende Erfindung betreffen, und zwar:
Fig. 5 ein Diagramm, das einen Stapelspeichermechanismus darstellt;
Fig. 6 ein Diagramm, das Prozeduren, Prozedurobjekte, Prozesse und virtuelle Prozessoren darstellt;
Fig. 7 ein Diagramm, das Operationsniveaus und Mechanismen des vorliegenden Rechners darstellt;
Fig. 8 ein Diagramm, das eine physikalische Implementierung von Prozessen und virtuellen Prozessoren darstellt;
Fig. 9 ein Diagramm, das einen Prozeß und Prozeßstapelspeicherobjekte darstellt;
Fig. 10 ein Diagramm, das die Betriebsweise von Makro- und Sicherheits-Stapelspeichern darstellt;
Fig. 11 ein Diagramm, das die genaue Struktur eines Stapelspeichers zeigt;
Fig. 12 ein Diagramm, das einen physikalischen Beschreiber darstellt;
Fig. 13 ein Diagramm, das die Beziehung zwischen logischen Seiten und Rahmen im Speicherraum eines Speichers zeigt;
Fig. 14 ein Diagramm, das die Zugangskontrolle zu Objekten darstellt;
Fig. 15 ein Diagramm, das virtuelle Prozessoren und virtuelle Prozessor-Ein- und -Auslagerung zeigt;
Fig. 16 ein teilweises Blockdiagramm eines Eingabe/Ausgabe- (Input/Output-) Systems des vorliegenden Rechnersystems;
Fig. 17 ein Diagramm, das die Betriebsweise eines Ringzuteilungsgenerators darstellt;
Fig. 18 ein teilweises Blockdiagramm eines Speichersystems;
Fig. 19 ein teilweises Blockschaltbild einer Zugriffseinheit des vorliegenden Rechnersystems;
Fig. 20 ein teilweises Blockschaltbild einer Ausführungseinheit des vorliegenden Rechnersystems;
Fig. 101 ein genaueres, teilweises Blockdiagramm des vorliegenden Rechnersystems;
Fig. 102 ein Diagramm, das gewisse Informationsstrukturen und -mechanismen des vorliegenden Rechnersystems zeigt;
Fig. 103 ein Diagramm, das Prozeßstrukturen zeigt;
Fig. 104 ein Diagramm, das eine Makrostapelspeicherstruktur zeigt;
Fig. 105 ein Diagramm, das eine Sicherheits-Stapelspeicherstruktur zeigt;
Fig. 106A, B, C Diagramme, die die Adressierstruktur des vorliegenden Rechnersystems zeigen;
Fig. 107 ein Diagramm, das den Adressiermechanismus des vorliegenden Rechnersystems darstellt;
Fig. 108 ein Diagramm, das einen Namenstabelleneingang zeigt;
Fig. 109 ein Diagramm, das einen Schutzmechanismus des vorliegenden Rechnersystems zeigt;
Fig. 110 ein Diagramm, das einen Befehls- und Mikrobefehlsmechanismus des vorliegenden Rechnersystems zeigt;
Fig. 201 ein genaues Blockdiagramm eines Speichersystems;
Fig. 202 ein genaues Blockdiagramm einer Zugriffseinheit;
Fig. 203 ein genaues Blockdiagramm einer Ausführungseinheit;
Fig. 204 ein genaues Blockdiagramm eines Input/Output-Systems;
Fig. 205 ein teilweises Blockschaltbild eines Diagnoseprozessorsystems;
Fig. 206 ein Diagramm, das die Zusammensetzung der Fig. 201 bis 205 zur Bildung eines genauen Blockdiagramms des vorliegenden Rechnersystems zeigt;
Fig. 207 ein genaues Blockdiagramm eines Speicherschnittstellencontrollers;
Fig. 209 ein Diagramm einer Kanalschnittstelle vom Speicher zum Input/Output-System;
Fig. 210 ein Diagramm einer Speicher-Operandenkanal-Schnittstelle;
Fig. 211 ein Diagramm einer Speicher-Befehlskanal-Schnittstelle;
Fig. 230 ein genaues Blockdiagramm einer Speicherfeldschnittstelleneinheit-Logik;
Fig. 231 ein Diagramm, das Manipulationsoperationen für das Speicherformat darstellt;
Fig. 238 ein genaues Blockdiagramm eines Zugriffseinheit-Abstandsmultiplexers;
Fig. 239 ein genaues Blockdiagramm einer Zugriffseinheit-Biaslogik;
Fig. 240 ein genaues Blockdiagramm eines verallgemeinerten Vierwegesatzassoziativ- Zwischenspeichers, der einen Namenszwischenspeicher, einen Schutzzwischenspeicher und eine Adressenübersetzungseinheit repräsentiert;
Fig. 241 ein genaues Blockdiagramm von Teilen der Befehls- und Mikrobefehlssteuerlogik des Rechnersystems;
Fig. 242 ein genaues Blockdiagramm von Teilen der Mikrobefehlssteuerlogik des Rechnersystems;
Fig. 243 ein genaues Blockdiagramm von weiteren Teilen der Mikrobefehlssteuerlogik des Rechnersystems;
Fig. 244 ein Diagramm, das Betriebszustände des Rechnersystems zeigt;
Fig. 245 ein Diagramm, das Betriebszustände des Rechnersystems für "Ablaufverfolgungsfalle" - (Trace-Trap-) Anforderung zeigt;
Fig. 246 ein Diagramm, das Betriebszustände des Rechnersystems für eine Speicherwiederholungsunterbrechung darstellt;
Fig. 247 ein Diagramm, das das Prioritätsniveau und Maskierungen von Rechnersystemereignissen darstellt;
Fig. 248 ein genaues Blockdiagramm einer Ereignislogik;
Fig. 249 ein genaues Blockschaltbild einer Mikrobefehlssteuerspeicher-Logik;
Fig. 251 ein Diagramm, das einen Stapelspeicher eines Rückkehrsteuerungswortes darstellt;
Fig. 252 ein Diagramm, das Maschinensteuerungsworte darstellt;
Fig. 253 ein genaues Blockdiagramm eines Registeradressengenerators;
Fig. 254 ein Blockdiagramm eines Intervall- und Eieruhrschalters;
Fig. 255 ein genaues Blockdiagramm einer Ausführungseinheit-Steuerlogik;
Fig. 257 ein genaues Blockdiagramm der Datenpfade und eines Speichers eines Multiplizierers der Ausführungseinheit;
Fig. 260 ein Diagramm, das den Ablauf des Ladens einer Befehlswarteschlange der Ausführungseinheit und eine Schnittstelle zu einer Zugriffseinheit zeigt;
Fig. 261 ein Diagramm, das den Ablauf des Ladens eines Operandenpuffers der Ausführungseinheit und eine Schnittstelle zu einer Zugriffseinheit zeigt;
Fig. 262 ein Diagramm, das den Ablauf einer Zurückspeicherung oder Ergebnisübertragung von der Ausführungseinheit und eine Schnittstelle zu einer Zugriffseinheit zeigt;
Fig. 263 ein Diagramm, das den Ablauf einer Überprüfung von Prüfbedingungen der Ausführungseinheit und eine Schnittstelle zu einer Zugriffseinheit zeigt;
Fig. 264 ein Diagramm, das den Ablauf einer Ausführungseinheit-Ausnahmeüberprüfung und eine Schnittstelle zu einer Zugriffseinheit darstellt;
Fig. 265 ein Blockdiagramm eines Stapelspeichermechanismus für arithmetische Operationen der Ausführungseinheit;
Fig. 266 ein Diagramm, das einen Quittungsbetrieb zwischen der Ausführungseinheit und der Zugriffseinheit bei Unterbrechungen und ein Interface darstellt;
Fig. 267 ein Diagramm, das eine Schnittstelle zwischen der Ausführungseinheit und der Zugriffseinheit und den Betrieb für verschachtelte Unterbrechungen zeigt;
Fig. 268 ein Diagramm, das eine Ausführungseinheit- und Zugriffseinheit-Schnittstelle und die Betriebsweise zum Laden eines Ausführungseinheit-Kontrollspeichers zeigt;
Fig. 269 ein genaues Blockdiagramm und die Darstellung der Betriebsweise eines Input/Output-System-Ringzuteilungsgenerators;
Fig. 270 ein genaues Blockdiagramm einer Zugriffseinheit-Mikromaschine des vorliegenden Rechnersystems;
Fig. 271 ein Diagramm, das einen logischen Beschreiber zeigt;
Fig. 272 ein Diagramm, das die Benutzung von Zugriffseinheit-Stapelspeicherregistern zeigt;
Fig. 273 ein Diagramm, das Strukturen zeigt, die Ereignisaufrufe steuern;
Fig. 301 ein Diagramm, das Zeigerformate darstellt;
Fig. 302 ein Diagramm, das eine zugeordnete Adressentabelle zeigt;
Fig. 303 ein Diagramm, das einen Überblick über einen Adreßraum eines Prozedurobjektes darstellt;
Fig. 304 ein Diagramm, das Namenstabelleneingänge darstellt;
Fig. 305 ein Diagramm, das ein Beispiel einer Namensauflösung darstellt;
Fig. 306 ein Diagramm, das Namenszwischenspeichereingänge darstellt;
Fig. 307 ein Diagramm, das universelle Kennzeichnungen von S-Interpretierungen in Dialektnummern darstellt;
Fig. 401 ein Diagramm, das Betriebssysteme und Systemressourcen darstellt;
Fig. 402 ein Diagramm, das Mehrprozeßbetriebssysteme darstellt;
Fig. 403 ein Diagramm, das ein erweitertes Betriebssystem und ein Kernbetriebssystem darstellt;
Fig. 404 ein Diagramm, das ein Objekt aus der Sicht des EOS darstellt;
Fig. 405 ein Diagramm, das Pfadnamen zu eindeutigen Identifizierern darstellt;
Fig. 406 ein Diagramm, das Einzelheiten von eindeutigen Identifizierern darstellt;
Fig. 407 ein Diagramm, das eine Adressenübersetzung mit einer Adressenübersetzungseinheit, einer Speicher-Hashtabelle und einem Speicher darstellt;
Fig. 408 ein Diagramm, das die Hashfunktion in einer aktiven Subjekttabelle darstellt;
Fig. 409 ein Diagramm, das eine logische Zuordnungseinheit und Objekte darstellt;
Fig. 410 ein Diagramm, das eine Tabelle der aktiven logischen Allokationseinheit und aktive Allokationseinheiten darstellt;
Fig. 411 ein Diagramm, das die konzeptionelle Struktur des Verzeichnisses einer logischen Allokationseinheit darstellt;
Fig. 412 ein Diagramm, das Einzelheiten eines Verzeichniseintrags einer logischen Allokationseinheit darstellt;
Fig. 413 ein Diagramm, das universelle Identifizierer und Nummern von aktiven Objekten darstellt;
Fig. 416 ein Diagramm, das Subjektschablonen, ursprüngliche Zugangskontroll-Listeneinträge und erweiterte Zugangskontroll-Listeneinträge darstellt;
Fig. 421 ein Diagramm, das eine aktive, primitive Zugangsmatrix und einen aktiven, primitiven Zugriffsmatrixeintrag darstellt;
Fig. 422 ein Diagramm, das eine Überprüfung auf primitiven Datenzugriff darstellt;
Fig. 448 ein Diagramm, das Ereigniszähler und Erwartungseinträge zeigt;
Fig. 449 ein Diagramm, das einen Erwartungstabellenüberblick zeigt;
Fig. 453 ein Diagramm, das einen Überblick über einen virtuellen Prozessor zeigt;
Fig. 454 ein Diagramm, das die Synchronisation eines virtuellen Prozessors zeigt;
Fig. 467 ein Diagramm, das einen Überblick über ein Makrostapelspeicherobjekt darstellt;
Fig. 468 ein Diagramm, das Einzelheiten einer Makrostapelspeicherobjektbasis darstellt;
Fig. 469 ein Diagramm, das Einzelheiten eines Makrostapelspeicherrahmens zeigt;
Fig. 470 ein Diagramm, das einen Überblick über einen Sicherheits-Stapelspeicher darstellt;
Fig. 471 ein Diagramm, das Einzelheiten eines Sicherheits-Stapelspeicherrahmens darstellt; und
Fig. 472 ein Diagramm, das einen Überblick über Prozedurenobjekte zeigt.

Beschreibung des bevorzugten Ausführungsbeispiels

Die nachfolgende Beschreibung gibt die Struktur und Betriebsweise eines Rechnersystems an, das eine gegenwärtig bevorzugte Ausführungsform der Erfindung enthält. Wie in der nachfolgenden Inhaltstabelle angegeben ist, werden einige Merkmale der Struktur und des Betriebs des Rechnersystems zunächst in einem einführenden Überblick beschrieben, danach werden diese und weitere Merkmale in weiteren Einzelheiten in einer genaueren Einführung zu genaueren Beschreibungen des Rechnersystems beschrieben. Im Anschluß an die Einführung werden die Struktur und die Betriebsweise des Rechnersystems in Einzelheiten erläutert. Die genauen Beschreibungen werden Beschreibungen der Struktur und Betriebsweise jedes größeren Subsystems oder Elements des Rechnersystems, der Schnittstellen zwischen diesen größeren Subsystemen und der gesamten Betriebsweise des Rechnersystems umfassen. Danach werden gewisse Merkmale der Betriebsweise der individuellen Subsysteme in weiteren Einzelheiten dargestellt.
Durch die ganze Beschreibung hindurch werden gewisse Konventionen benutzt, um die Klarheit der Darstellung zu verbessern. Zunächst, aber mit Ausnahme des einführenden Überblicks, wird in der nachfolgenden Beschreibung auf jede Figur durch eine dreistellige Zahl Bezug genommen. Die höchstwertige Ziffer stellt die Zahl des Kapitels in der folgenden Beschreibung dar, indem zuerst auf eine besondere Figur Bezug genommen ist. Die beiden geringstwertigen Ziffern stellen die laufende Nummer der Erscheinung einer Figur in einem besonderen Kapitel dar. Beispielsweise würde die Fig. 319 die 19. Figur sein, die im dritten Kapitel erscheint. Auf Figuren, die im einführenden Überblick erscheinen, wird durch eine ein- oder zweistellige Nummer Bezug genommen, welche die Reihenfolge wiedergibt, in welcher diese Figuren im einführenden Überblick erwähnt werden. Es sollte beachtet werden, daß einige Figurennummern, beispielsweise Fig. 208, nicht bei den nachfolgend erwähnten Figuren und Beschreibungen erscheinen; zur Verbesserung der Klarheit der Darstellung wurde der Gegenstand dieser Figuren während der Abfassung der folgenden Beschreibung in andere Figuren übernommen und wurden diese Figuren gestrichen.
Sodann enthalten die Bezugszeichen eine zweistellige Zahl (00-99), denen die Zahl der Figur vorangestellt ist, in welcher die entsprechenden Elemente zuerst erscheinen. Beispielsweise würden Bezugszeichen 31901 bis 31999 auf Elemente 1 bis 99 Bezug nehmen, die in Fig. 319 erscheinen.
Schließlich werden Verbindungen zwischen in Beziehung stehenden Schaltkreisen auf zweifache Weise dargestellt. Erstens können Verbindungen zwischen Schaltkreisen zur Verbesserung der Klarheit der Darstellung durch gemeinsame Signalnamen oder Referenzen anstatt durch gezeichnete Drähte oder Busse dargestellt werden. Zweitens können die Figuren, wenn in Beziehung stehende Schaltkreise in zwei oder mehreren Figuren gezeigt sind, eine gemeinsame Figurennummer besitzen und durch ein Buchstabenkennzeichen unterschieden werden, z. B. Fig. 319, 319A und 319B. Gemeinsame elektrische Anschlußpunkte zwischen solchen Schaltkreisen können durch eine Klammer angezeigt sein, die eine Zuführung zu einem solchen Anschlußpunkt und eine Bezeichnung der Art "A-b" enthält. "A" zeigt andere Figuren an, die denselben gemeinsamen Anschlußpunkt enthalten, z. B. 319A, und "b" bezeichnet den besonderen gemeinsamen elektrischen Anschlußpunkt. In Fällen, in denen in Beziehung stehende Schaltkreise auf diese Weise in zwei oder mehr Figuren gezeigt sind, werden die Bezugszeichen zu Elementen in fortlaufender Reihenfolge durch die Gruppe von Figuren hindurch zugeordnet; der die Figurennummer enthaltende Teil dieser Bezugszeichen ist stets derjenige der ersten Figur einer Gruppe von Figuren.

Einführender Überblick

A. Hardware-Überblick (Fig. 1)
B. Individuelle Betriebsmerkmale (Fig. 2, 3, 4, 5, 6)
1. Adressierung (Fig. 2)
2. S-Sprachenbefehle und Adressierung von Namensräumen (Fig. 3)
3. Architektur Basiszeigeradressierung
4. Stapelspeichermechanismus (Fig. 4-5)
C. Prozedurprozesse und virtuelle Prozessoren (Fig. 6)
D. CS 101 Gesamtstruktur und Betrieb (Fig. 7, 8, 9, 10, 11, 12, 13, 14, 15)
1. Einführung (Fig. 7)
2. Compiler 702 (Fig. 7)
3. Programmverknüpfer 703 (Fig. 7)
4. EOS 704 (Fig. 7)
5. KOS und Architektur des Interface 708 (Fig. 7)
6. Prozesse 610 und virtuelle Prozessoren 612 (Fig. 8)
7. Prozesse 610 und Stapelspeicher (Fig. 9)
8. Prozesse 610 und Aufrufe (Fig. 10, 11)
9. Speicherreferenzen und das Managementsystem des virtuellen Speichers (Fig. 12, 13)
10. Zugangskontrolle (Fig. 14)
11. Virtuelle Prozessoren und Austausch virtueller Prozessoren (Fig. 15)
E. CS 101 Strukturelle Implementierung (Fig. 16, 17, 18, 19, 20)
1. IOS 116 (Fig. 16, 17)
2. Speicher (MEM) 112 (Fig. 18)
3. Zugriffseinheit (FU) 120 (Fig. 19)
4. Ausführungseinheit (EU) 122 (Fig. 20)

1. Einführung (Fig. 101-110)

A. Allgemeine Struktur und Betriebsweise (Fig. 101)
a. Allgemeine Struktur
b. Allgemeiner Betrieb
c. Definition von bestimmten Ausdrücken
d. Mehrprogrammbetriebsweise
e. Mehrsprachenbetriebsweise
f. Adressierstruktur
g. Schutzmechanismus
B. Computersystem 10110: Informationen, Struktur und Mechanismen (Fig. 102, 103, 104, 105)
a. Einführung (Fig. 102)
b. Prozeßstrukturen 10210 (Fig. 103, 104, 105)
1. Prozedurobjekte (Fig. 103)
2. Stapelspeichermechanismen (Fig. 104, 105)
3. FURSM 10214 (Fig. 103)
C. Virtuelle Prozessorzustandsblöcke und virtuelle Prozeßerzeugung (Fig. 102)
D. Adressierstrukturen 10220 (Fig. 103, 106, 107, 108)
1. Objekte UIDs, AONs, Namen und physikalische Adressen (Fig. 106)
2. Adressiermechanismen 10220 (Fig. 107)
3. Namensauflösung (Fig. 103, 108)
4. Auswertung von AON-Adressen zu physikalischen Adressen (Fig. 107)
E. CS 10110 Schutzmechanismen (Fig. 109)
F. CS 10110 Mikrobefehl-Mechanismen (Fig. 110)
G. Zusammenfassung von bestimmten CS 10110-Merkmalen und alternative Ausführungsbeispiele.

2. Genaue Beschreibung der wichtigsten Subsysteme von CS 10110 (Fig. 201-206, 207-274)

A. MEM 10110 (Fig. 201, 206, 207-237)
a. Terminologie
b. MEM 10112-Physikalische Struktur (Fig. 201)
c. MEM 10112-Allgemeiner Betrieb
d. MEM 10112-Kanalstruktur
1. IO-Kanal-Kennzeichen
2. JO-Kanal-Kennzeichen
3. JI-Kanal-Kennzeichen
e. MEM 10112-Steuerungsstruktur und Betrieb (Fig. 207)
1. MEM 10112-Steuerungsstruktur
2. MEM 10112-Steuerungsbetrieb
f. MEM 10112-Operationen
g. MEM 10112-Schnittstellen zu JP 10114 und IOS 10116 (Fig. 209, 210, 211, 204)
1. IO-Kanal 20910-Betriebskennzeichen (Fig. 209, 204)
2. JPO-Kanal 21010-Betriebskennzeichen (Fig. 210)
3. JPI-Kanal 21110-Betriebskennzeichen (Fig. 211)
h. FIU 20120 (Fig. 201, 230, 231)
B. Zugriffseinheit 10120 (Fig. 202, 206, 101, 103, 104, 238)
1. Beschreibungs-Prozessor 20210 (Fig. 202, 101, 103, 104, 238, 239)
a. Abstands-Prozessor 20218-Struktur
b. AON-Prozessor 20216-Struktur
c. Längenprozessor 20220-Struktur
d. Beschreibungs-Prozessor 20218-Betrieb
a.a. Abstandswähler 20230
b.b. Abstandsmultiplexer 20240, detaillierte Struktur (Fig. 238)
c.c. Abstandsmultiplexer 20240, detaillierter Betrieb
a.a.a. Interner Betrieb
b.b.b. Betrieb hinsichtlich des DESP 20210
e. Längenprozessor 20220 (Fig. 239)
a.a. Längen-ALU 20252
b.b. BIAS 20246 (Fig. 239)
f. AON-Prozessor 20216
a.a. AONGRF 20232
b.b. AON-Auswähler 20248
2. Speicher-Schnittstelle 20212 (Fig. 106, 240)
a.a. Beschreiberfalle 20256 und Datenfalle 20258
b.b. Namenszwischenspeicher 10226, Adreßübersetzungseinheit 10228 und Schutz-Zwischenspeicher 10234 (Fig. 106)
c.c. Struktur und Betrieb eines generalisierten Zwischenspeichers und NC 10226 (Fig. 240)
d.d. ATU 10228 und PC 10234
3. Zugriffseinheit-Steuerlogik 20214 (Fig. 202)
a. a. Zugriffseinheit-Steuerungslogik 20214, Gesamtstruktur
b.b. Zugriffseinheit-Steuerungslogik 20214, Betrieb
a. a. a. Voraufnehmer 20264, Instruktionspuffer 20262, Analysator 20264, Operationscoderegister 20268, CPC 20270, IPC 20272 und EPC 20274 (Fig. 241)
b. b.b. Zugriffseinheitaufteilungstabelle 11010, Ausführungseinheitaufteilungstabelle 20266 und Operationscoderegister 20268 (Fig. 242)
c.c.c. Nächste Adresse-Generator 24310 (Fig. 243)
c.c. FUCTL 20214-Steuerschaltkreis für CS 10110-interne Mechanismen (Fig. 244-250)
a.a.a. Zustandslogik 20294 (Fig 244A-244Z)
b.b. b. Ereignissteuerung 20284 (Fig. 245, 246, 247, 248)
c. c. c. Zugriffseinheit-S-Interpretertabelle 11012 (Fig. 249)
d.d. CS 10110-Steuerung der internen Mechanismen
a. a. a. Stapelspeicher des Rückkehrsteuerungswortes 10358 (Fig. 251)
b.b. b. Maschinensteuerungsblock (Fig. 252)
c.c.c. Registeradressengenerator 20288 (Fig. 253)
d.d.d. Zeitmeßgeräte 20296 (Fig. 254)
e.e.e. Zugriffseinheit 10120-Schnittstelle zur Ausführungseinheit 10122
C. Ausführungseinheit 10122 (Fig. 203, 255-268)
a. Allgemeine Struktur der Ausführungseinheit 10122
1. I/O der Ausführungseinheit 20312
2. Ausführungseinheit-Steuerlogik 20310
3. Multipliziererlogik 20314
4. Exponentenlogik 20316
5. Multipliziersteuerung 20318
6. Prüfungs- und Schnittstellenlogik 20320
b. Betrieb der Ausführungseinheit 10122 (Fig. 255)
1. Ausführungseinheit-Steuerlogik 20310 (Fig. 255)
a.a. Befehlswarteschlange 20342
b.b. Befehlswarteschlange-Ereignissteuerspeicher 25514 und Befehlswarteschlange-Ereignisadreßsteuerspeicher 25516
c. c. Ausführungseinheit-S-Interpretertabelle 20344
d. d. Mikrocodesteuerdecodierregister 20346
e. e. Nächste Adresse-Generator 20340
2. Operandenpuffer 20322 (Fig. 256)
3. Multiplizierer 20314 (Fig. 257, 258)
a.a. IO-Datenpfade und Speicher vom Multiplizierer 20314 (Fig. 257)
a. a. a. Behältergrößenüberprüfung
b.b.b. Endergebnisausgabenmultiplexer 20324
4. Überprüfungs- und Interfacelogik 20320 (Fig. 260-268)
a.a. FU 10120/EU 10122-Schnittstelle
a.a.a. Laden der Befehlswarteschlange 20342 (Fig. 260)
b.b.b. Laden des Operandenpuffers 20320 (Fig. 261)
c.c.c. Zurückspeichern (Fig. 262)
d.d.d. Prüfbedingungen (Fig. 263)
e.e.e. Ausnahmeüberprüfung (Fig. 264)
f.f.f. Leerlaufprogramm
g.g.g. EU 10122-Stapelspeichermechanismen (Fig. 265, 266, 267)
h.h.h. Laden der Ausführungseinheit-S-Interpreter-Tabelle 20344 (Fig. 268)
D. I/O-System 10116 (Fig. 204, 206, 269)
a. I/O-System 10116-Struktur (Fig. 204)
b. I/O-System 10116-Betrieb (Fig. 269)
1. Datenkanal-Geräte
2. I/O-Steuerprozessor 20412
3. Datenschieber 20410 (Fig. 269)
a.a. Eingangsdatenpuffer 20440 und Ausgangsdatenpuffer 20442
b.b. Prioritäterkennung und Steuerung 20444 (Fig. 269)
E. Diagnoseprozessor 10118 (Fig. 101, 205)
F. CS 10110 Mikromaschine-Struktur- und -Betrieb (Fig. 270-274)
a. Einführung
b. Überblick über die in der FU-Mikromaschine enthaltenen Geräte (Fig. 270)
1. Vom meisten Mikrocode genutzte Geräte
a.a. MOD-Bus 10144, JPD-Bus 10142 und DB-Bus 27021
b.b. Mikrocode-Adressierung
c.c. Beschreiberprozessor 20218 (Fig. 271)
d.d. EU 10122-Schnittstelle
2. Spezialisierte Mikromaschinengeräte
a.a. Befehlsstromleser 27001
b.b. SOP-Decodierer 27003
c.c. Namensübersetzungseinheit 27015
d.d. Speicherreferenzeinheit 27017
e.e. Schutzeinheit 27019
f.f. KOS-Mikromaschinengeräte
c. Mikromaschinen-Stapelspeicher und Mikroprogrammaufruf und -rückkehr (Fig. 272, 273)
1. Mikromaschinen-Stapelspeicher (Fig. 272)
2. Mikromaschinenaufruf und -rückkehr
3. Mittel von aufrufenden Mikroprogrammen
4. Auftreten von Ereignisinvokationen (Fig. 273)
d. Virtuelle Mikromaschinen und Überwachungs-Mikromaschine
1. Virtueller Modus
2. Überwachungs-Mikromaschine
e. Unterbrechungs- und Fehlerbehandlung
1. Allgemeine Grundsätze
2. Behandlung von Hardware-Unterbrechungen und -Fehlern in CS 10110
3. Überwachungsmodus, differenzierte Maskierung und Hardware- Unterbrechungsbearbeitung
g. FU-Mikromaschine und CS 10110-Untersysteme

3. Adreßraum S-Interpreter und Zeiger (Fig. 301-307, 274)

A. Zeiger und Zeigerauflösung (Fig. 301, 302)
a. Zeigerformate (Fig. 301)
b. Zeiger in SU 10120 (Fig. 302)
c. Beschreiber nach Zeiger-Umwandlung
B. Adreßraum und S-Interpreter (Fig. 303-307)
a. Überblick über Prozedurenobjekt 606 (Fig. 303)
b. Adreßraum
1. Namensauflösung und -auswertung
2. Die Namenstabelle (Fig. 304)
3. Architektonische Basiszeiger (Fig. 305, 306)
a.a. Namensauflösung und -auswertung (Fig. 305)
b.b. Implementierung der Namensauswertung und Namensauflösung in CS 10110
c.c. Eingänge des Namenszwischenspeichers 10226 (Fig. 306)
d.d. Treffer des Namenszwischenspeichers 10226
e.e. Fehler des Namenzwischenspeichers 10226
f.f. Löschen des Namenzwischenspeichers 10226
g.g. Ergreifen des I-Stroms
h.h. Analysieren des I-Stroms
c. Die S-Interpreter (Fig. 307)
1. Übersetzung eines SIP in eine Dialektnummer (Fig. 307)
2. Aufteilung
4. Das Kernbetriebssystem
A. Einführung
a. Betriebssysteme (Fig. 401)
1. Vom Betriebssystem gesteuerte Recourcen (Fig. 402)
b. Das Betriebssystem in CS 10110
c. Erweitertes Betriebssystem und Kernbetriebssystem (Fig. 403)
B. Objekte und Objektmanagement (Fig. 404)
a. Objekte und Benutzerprogramme (Fig. 405)
b. UIDs 40401 (Fig. 406)
c. Objektattribute
d. Attribute und Zugangskontrolle
e. Implementierung der Objekte
1. Einführung (Fig. 407, 408)
2. Objekte im Sekundärspeicher 10124 (Fig. 409, 410)
a.a. Darstellung der Inhalte eines Objekts im Sekundärspeicher 10124
b.b. LAUD 40903 (Fig. 411, 412)
3. Aktive Objekte (Fig. 413)
a.a. Übersetzungen von UID 40401 in AON 41304
C. Das Zugangskontrollsystem
a. Subjekte
b. Bereiche
c. Zugangskontroll-Listen
1. Subjektschablonen (Fig. 416)
2. Primitive Zugangskontroll-Listen (PACLs)
3. APAM 10918 und Schutzzwischenspeicher 10234 (Fig. 421)
4. Schutzzwischenspeicher 10234 und Schutzüberprüfung (Fig. 422)
D. Prozesse
1. Synchronisation von Prozessen 610 mit virtuellen Prozessoren 612
a. Ereigniszähler 44801, Erwartungseinträge 44804 und Erwartungstabellen (Fig. 448, 449)
b. Synchronisation von Ereigniszählern 44801 und Erwartungseinträgen 44804
E. Virtuelle Prozessoren 612 (Fig. 453)
a. Management der virtuellen Prozessoren (Fig. 453)
b. Virtuelle Prozessoren 612 und Synchronisation (Fig. 454)
F. Prozeß 610-Stapelspeichermanipulation
1. Einführung zu Aufruf und Rückkehr
2. Makrostapelspeicher (MAS) 502 (Fig. 467)
a.a. MAS-Basis 10410 (Fig. 468)
b.b. Bereichsbezogene Datenfläche 46853 (Fig. 468)
c.c. MAS-Rahmen 46709-Einzelheiten (Fig. 469)
3. SS 504 (Fig. 470)
a.a. SS-Basis 47001 (Fig. 470)
b.b. SS-Rahmen 47003 (Fig. 471)
a.a.a. Einfacher SS-Rahmen-Kopf 10514 (Fig. 471)
b.b.b. Detaillierte Struktur des Makrozustands 10516 (Fig. 471)
c. c. c. Bereichsübergreifender SS-Rahmen 47039 (Fig. 471)
4. Bereiche des Prozedurenobjekts 608, relevant für Aufruf und Rückkehr (Fig. 472)
5. Ausführung von vermittelten Aufrufen
a.a. SINs des vermittelten Aufrufs
b.b. Einfache vermittelte Aufrufe (Fig. 270, 468, 469, 470, 471, 472)
c.c. Invokationen von Prozeduren 602, die SEBs 46864 erfordern (Fig. 270, 468, 469, 470, 471, 472)
d.d. Prozedurobjektübergreifende Aufrufe (Fig. 270, 468, 469, 470, 471, 472)
e.e. Bereichsübergreifende Aufrufe (Fig. 270, 408, 418, 468, 469, 470, 471, 472)
f.f. Fehlgeschlagene bereichsübergreifende Aufrufe (Fig. 270, 468, 469, 470, 471, 472)
6. Nachbarschafts-Aufrufe (Fig. 468, 469, 472).

Einführender Überblick

Der folgende Überblick wird zuerst kurz die gesamte physikalische Struktur und Betriebsweise eines gegenwärtig bevorzugten Ausführungsbeispiels eines die vorliegende Erfindung beinhaltenden digitalen Rechnersystems beschreiben. Dann werden gewisse Betriebsmerkmale dieses Computersystems einzeln beschrieben. Danach wird dann die Gesamtbetriebsweise des Rechnersystems anhand dieser einzelnen Merkmale beschrieben.

A. Hardware-Überblick (Fig. 1)

In Fig. 1 ist ein Blockdiagramm eines die vorliegende Erfindung beinhaltenden Rechnerbzw. Computersystems (CS) 101. Hauptelemente von CS 101 sind ein Eingabe/Ausgabebzw. I/O-System (IOS) 116, ein Speicher (MEM) 112 und ein Auftrags- bzw. Job- Prozessor (JP) 114. JP 114 ist zusammengesetzt aus einer Zugriffseinheit (FU) 120 und einer Ausführungseinheit (EU) 122. CS 101 kann außerdem einen Diagnoseprozessor (DP) enthalten, der in der gegenwärtigen Beschreibung weder gezeigt noch beschrieben ist.
Im Hinblick auf IOS 116 ist festzustellen, daß eine primäre Funktion von IOS 116 die Steuerung der Übertragung von Informationen zwischen MEM 112 und der Außenwelt ist. Informationen werden von MEM 112 zum IOS 116 durch einen IOM-Bus 130 und vom IOS 116 zum MEM 112 durch einen MIO-Bus 129 übertragen. Ein IOMC-Bus 131 enthält bidirektionale Steuersignale, die den Betrieb von MEM 112 und IOS 116 koordinieren. IOS 116 hat außerdem eine Schnittstelle zur FU 120 durch einen IOJP-Bus 132. Der IOJP-Bus 132 ist ein bidirektionaler Steuerbus, der im wesentlichen aus zwei Unterbrechungs- bzw. Interrupt-Leitungen besteht. Diese Interrupt-Leitungen erlauben außerdem der FU 120, dem IOS 116 anzuzeigen, daß eine Anforderung für Informationen durch FU 120 in den MEM 112 gegeben worden ist, und erlauben IOS 116, FU 120 zu informieren, daß durch FU 120 angeforderte Informationen in eine Stelle von MEM 112 übertragen worden sind. MEM 112 ist der Hauptspeicher von C 101 und dient als Pfad für die Informationsübertragung zwischen der Außenwelt und JP 114. MEM 112 übermittelt Befehle und Daten an FU 120 und EU 122 durch einen Speicher-Ausgabedaten (MOD)-Bus 140 und erhält Informationen von FU 120 und EU 122 durch einen Jobprozessordaten (JPD)-Bus 142. FU 120 legt dem MEM 112 durch einen Bus 146 "Physikalischer Beschreiber" (PD) Lese- und Schreibanforderungen vor.
JP 114 ist die CPU (Zentraleinheit) von CS 101 und besteht, wie oben beschrieben, aus FU 120 und EU 122. Eine primäre Funktion von FU 120 ist es, Operationen eines Benutzerprogramms auszuführen. Als Teil dieser Funktion steuert FU 120 die Übertragung von Befehlen und Daten von MEM 112 und die Übertragung von Ergebnissen von JP 114-Operationen zurück zu MEM 112. FU 120 führt außerdem betriebssystemartige Funktionen aus und ist fähig, als vollständige, für allgemeine Zwecke bestimmte CPU zu arbeiten. EU 122 ist primär eine arithmetisch-logische Einheit, die dazu vorgesehen ist, FU 120 von gewissen arithmetischen Operationen zu entlasten. FU 120 ist jedoch befähigt, EU 122-Operationen auszuführen. In alternativen Ausführungsbeispielen des CS 101 kann EU 122 für Benutzer, die besondere arithmetische Anforderungen stellen, lediglich als Option vorgesehen sein. Die Koordination von FU 120- und EU 122- Operationen wird durch einen FU/EU (FUEU)-Bus 148 erreicht, der bidirektionale Steuersignale und wechselseitige Interrupt-Leitungen enthält. Wie weiter unten beschrieben werden wird, enthalten FU 120 und EU 122 zusätzlich zu Registern, die z. B. ALUs (arithmetisch-logischen Einheiten) zugeordnet sind, Registerdateivektoren, auf die als CRF und ERF Bezug genommen wird.
Ein primäres Merkmal von CS 101 ist, daß IOS 116, MEM 112, FU 120 und EU 122 jeweils getrennte und unabhängige Mikrobefehlssteuerungen besitzen, so daß IOS 116, MEM 112 und EU 122 unter der allgemeinen Steuerung von FU 120 asynchron arbeiten. EU 122 kann z. B. nach Empfang von Daten und eines einzigen, einleitenden Befehls von FU 120 eine komplizierte arithmetische Operation ausführen.
Nachdem die gesamte Struktur und Betriebsweise von CS 101 beschrieben wurden, werden nachfolgend gewisse Merkmale von CS 101 einzeln weiter beschrieben.

B. Individuelle Betriebsmerkmale (Fig. 2, 3, 4, 5, 6)

1. Adressierung (Fig. 2)

In Fig. 2 ist eine schematische Darstellung von Teilen der Adressenstruktur des CS 101 gezeigt. Die Adressenstruktur von CS 101 basiert auf dem Konzept von Objekten. Ein Objekt kann als Behälter zum Aufbewahren einer besonderen Art von Information betrachtet werden. Eine Art von Objekt kann beispielsweise Daten enthalten, während eine andere Art von Objekt Instruktionen oder Prozeduren, wie z. B. ein Benutzerprogramm enthalten kann. Noch eine andere Art von Objekt kann einen Mikrocode enthalten. Im allgemeinen kann ein besonderes Objekt nur eine Art oder Klasse von Informationen enthalten. Ein Objekt kann z. B. bis zu 232 Informationsbits enthalten, doch ist die aktuelle Größe eines besonderen Objekts flexibel. Das bedeutet, daß die aktuelle Größe eines besonderen Objekts anwachsen wird, wenn Informationen in dieses Objekt geschrieben werden, während es kleiner werden wird, wenn Informationen von diesem Objekt entnommen werden. Im allgemeinen sind die Informationen in den Objekten sequenziell, d. h. ohne Lücken gespeichert.
Jedes Objekt, das in irgendeinem CS 101-System jemals existieren kann, ist durch eine fortlaufende Nummer gekennzeichnet bzw. identifiziert, auf die nachfolgend als eindeutiger Identifizierer (UID) Bezug genommen wird. Eine UID ist ein 128-Bit-Wert, der eine fortlaufende Nummer, die beispielsweise vom besonderen CS 101-System und Benutzer abhängt, und einen Zeitcode enthält, der die Zeit der Erstellung dieses Objekts anzeigt. UIDs sind den Objekten permanent zugeordnet, keine zwei Objekte können dieselbe UID besitzen, und UIDs können nicht wieder verwendet werden. UIDs sehen eine Adressierungsbasis vor, die allen CS 101-Systemen gemeinsam ist, die jemals existieren können, wodurch irgendein jemals erstelltes Objekt permanent und eindeutig identifiziert werden kann.
Wie oben angegeben, sind UIDs 128-Bit-Werte und somit größer, als in gegenwärtigen Ausführungsbeispielen von CS 101 üblich sein mag. In jedem CS 101 sind daher jenen Objekten, die in diesem System aktiv bzw. gegenwärtig benutzt sind, vierzehn aktive Objektnummern (AONs) zugeordnet. Jedes in diesem System aktive Objekt hat eine eindeutige AON. Im Gegensatz zu den UIDs sind die AONs den besonderen Objekten nur temporär zugeordnet. AONs sind nur in einem bestimmten CS 101 gültig und zwischen Systemen nicht eindeutig. Ein Objekt muß nicht physikalisch in einem System vorhanden sein, um einem AON zugeordnet zu werden, kann aber in diesem System nur aktiv sein, wenn es einem AON zugeordnet ist.
Ein spezielles Bit innerhalb eines speziellen Objekts kann mittels einer UID-Adresse oder einer AON-Adresse identifiziert sein. Innerhalb des CS 101 sind die AONs und die AON- Adressen nur im JP 114 gültig, während die UIDs und UID-Adressen im MEM 112 und sonstwo benutzt werden. UID- und AON-Adressen werden dadurch gebildet, daß ein 32 Bit-Offset-(O)-Feld dem UID oder AON des Objekts angehängt wird. O-Felder zeigen den Abstand oder die Position eines speziellen Bits relativ zum Beginn eines speziellen Objekts an.
Informationssegmente (Sequenzen von Informationsbits) innerhalb eines speziellen Objekts können mittels Beschreibern identifiziert werden. Ein UID-Beschreiber wird dadurch gebildet, daß ein 32 Bit-Längen-(L)-Feld einer UID-Adresse angehängt wird. Eine AON- oder ein logischer Beschreiber wird durch Anhängen eines 32 Bit-L-Feldes an eine AON- Adresse gebildet. L-Felder identifizieren die Länge eines Segments von Informationsbits innerhalb eines Objekts, beginnend von dem Informationsbit, das durch die UID- oder AON-Adresse identifiziert wird. Zusätzlich zur Längeninformation enthalten UID- und logische Beschreiber außerdem Typenfelder, die Informationen bezüglich gewissen Eigenschaften der Informationen in dem Informationssegment enthalten. Auf AON basierende Beschreiber werden im JP 114, auf UID basierende Beschreiber dagegen in MEM 112 benutzt.
Nach Fig. 1 und 2 wird die Übersetzung zwischen UID-Adressen und -Beschreibern und AON-Adressen und -Beschreibern im Interface zwischen MEM 112 und JP 114 durchgeführt. Das bedeutet, daß Adressen und Beschreibern innerhalb von JP 114 in AON- Form vorliegen, während Adressen und Beschreibern in MEM 112, IOS 116 und der Außenwelt in UID-Form vorliegen. Bei anderen Ausführungsformen von CS 101, die AONs benutzen, kann die Transformation von UID- in AON-Adressierung in anderen Schnittstellen vorgenommen werden, beispielsweise im Interface von IOS 116 zum MEM 112 oder im Interface von IOS 116 zur Außenwelt. Andere Ausführungsbeispiele von CS 101 können durchgehend UIDs benutzen, d. h. AONs selbst in JP 114 nicht anwenden.
Schließlich werden Informationen innerhalb vom MEM 112 durch MEM 112-physikalische Adressen lokalisiert, die spezielle physikalische Orte innerhalb des Speicherraums des MEM 112 identifizieren. Sowohl IOS 116 als auch JP 114 adressieren Informationen innerhalb vom MEM 112, indem sie physikalische Adressen am MEM 112 geben. Im Falle von physikalischen Adressen, die vom JP 114 geliefert werden, wird auf diese Adressen als physikalische Beschreiber (PDs) Bezug genommen. Wie weiter unten beschrieben wird, enthält JP 114 Schaltkreise, um logische Beschreiber in physikalische Beschreiber zu übersetzen.

2. S-Sprachen-Befehle und Adressierung im Adreßraum (Fig. 3)

CS 101 ist sowohl eine S-Sprachen-Maschine als auch eine Adreßraum-Maschine. Das bedeutet, daß Operationen, die durch CS 101 auszuführen sind, als S-Sprache-Operationen (SOPs) bezeichnet werden, während Operanden durch Namen identifiziert werden. SOPs sind von einer niedrigeren, detaillierteren Ebene als Benutzersprache-Befehle wie z. B. FORTRAN und COBOL, jedoch von einem höheren Niveau als konventionelle Maschinensprache-Befehle. SOPs sind spezifisch für spezielle Benutzersprachen anstatt für eine besondere Ausführungsform des CS 101, während übliche Maschinensprache-Befehle für besondere Maschinen-spezifisch sind. SOPs werden der Reihe nach durch Mikrocode interpretiert und ausgeführt. Für jede Benutzersprache gibt es einen S-Sprache-Dialekt, einen Satz von SOPs. CS 101 kann beispielsweise SOP-Dialekte für COBOL, FORTRAN und SPL haben. Ein spezielles Unterscheidungsmerkmal von CS 101 ist, daß alle SOPs eine gleichförmige feste Länge von z. B. 16 Bit besitzen. CS 101 kann im allgemeinen einen oder mehrere Mikrocode-Sätze für jeden S-Sprache-Dialekt enthalten. Diese Mikrocode-Dialekt-Sätze können vollständig verschieden sein oder sich überlappen, wo mehr als ein SOP denselben Mikrocode verwendet.
Wie oben angegeben wurde, sind im CS 101 alle Operanden durch Namen identifiziert, die aus 8-, 12- oder 16-Bit-Zahlen bestehen. CS 101 enthält eine oder mehrere "Namenstabellen", die einen Eintrag für jeden Operandennamen enthalten, der in Programmen erscheint, die gerade ausgeführt werden. Jeder Namenstabelle-Eintrag enthält Informationen, die den Operanden, auf den durch einen speziellen Namen Bezug genommen werden soll, und Anweisungen beschreiben, die für das CS 101 erforderlich sind, um diese Information in einen entsprechenden logischen Beschreiber zu übersetzen. Wie oben beschrieben wurde, können die logischen Beschreiber dann in physikalische Beschreiber zum Lesen und Schreiben von Operanden aus dem bzw. in dem MEM 112 umgewandelt werden. Wie oben beschrieben wurde, sind die UIDs für alle CS 101-Systeme eindeutig, während die AONs innerhalb individueller CS 101-Systeme eindeutig sind. Namen sind jedoch nur im Zusammenhang mit einem Benutzerprogramm eindeutig. Das bedeutet, daß ein spezieller Name in zwei unterschiedlichen Benutzerprogrammen erscheinen kann und innerhalb jedes Programms einen unterschiedlichen Namenstabellen-Eintrag hat und auf unterschiedliche Operanden Bezug nimmt.
CS 101 kann dadurch als Benutzer von zwei Sätzen von Befehlen angesehen werden. Ein erster Satz enthält die SOPs, d. h. Befehle, die auszuführende Algorithmen auswählen. Der zweite Befehlssatz enthält Namen, die als Eintrittsstellen in Befehlstabellen zum Zwecke der Bezugnahme auf Operanden angesehen werden können.
In Fig. 3 ist eine schematische Darstellung eines CS 101-Befehlsstroms gezeigt. Ein typischer SIN enthält einen SOP und einen oder mehrere, auf Operanden Bezug nehmende Namen. Die SOPs und Namen ermöglichen es, Anwenderprogramme in einem sehr kompakten Code auszudrücken. Weniger SOPs als Maschinensprache-Befehle sind erforderlich, um ein Anwenderprogramm auszudrücken. Außerdem erlaubt die Anwendung von SOPs eine leichtere und einfachere Konstruktion von Compilern und ermöglicht die Anpassung der CS 101-Systeme an neue Anwendersprachen. Zusätzlich bedeutet die Anwendung von Namen zur Bezugnahme auf Operanden, daß SOPs unabhängig von der Form der Operanden sind, auf die sei einwirken. Dies wiederum ermöglicht einen kompakteren Code zum Ausdrücken von Anwenderprogrammen dadurch, daß SOPs, die von der Form der Operanden abhängige Operationen spezifizieren, nicht benötigt werden.

3. Architektonische-Basiszeiger-Adressierung

Wie weiter unten beschrieben wird, enthält ein im CS 101 residentes Anwenderprogramm ein oder mehrere Objekte. Erstens enthält ein Prozedurenobjekt wenigstens die SINs des Anwenderprogramms und eine Namenstabelle, die Einträge für Operandennamen des Programms enthält. Die SINs können Referenzen oder Aufrufe für andere Prozedurenobjekte enthalten, die beispielsweise Prozeduren enthalten, die gemeinsam für viele Anwender verfügbar sind. Zweitens kann ein statischer Datenbereich statische Daten enthalten, d. h. Daten, die für wenigstens eine Ausführung des Programms existent sind. Und drittens kann ein Makrostapelspeicher, der weiter unten beschrieben wird, lokale Daten enthalten, d. h. Daten, die während der Ausführung eines Programms generiert werden. Jedes Prozedurenobjekt, der statische Datenbereich und der Makrostapelspeicher sind individuelle Objekte, die durch UIDs und AONs identifiziert werden und durch UID- und AON-Adressen und Beschreiber adressierbar sind.
Orte von Informationen innerhalb der Prozedurenobjekte von Anwendern der statischen Datenbereiche und der Makrostapelspeicher werden als Abstände von einem von drei Werten oder Basisadressen ausgedrückt, auf die als architektonische-Basiszeiger (ABPs) Bezug genommen wird. Beispielsweise wird die Ortsinformation in Namentabellen als Abstand von einem der ABPs ausgedrückt. ABPs können ausgedrückt werden, wie oben beschrieben ist.
Die drei ABPs sind der Rahmenzeiger (FP), der Prozedurenbasiszeiger (PBP) und der statische Datenzeiger (SDP). Orte von lokalen Daten einer Prozedur, beispielsweise im Makrostapelspeicher einer Prozedur, werden als Abstände von FP beschrieben. Orte von nicht-lokalen Daten, d. h. statischen Daten, werden als Abstände von SDP beschrieben. Orte von SINs in Prozedurenobjekten werden als Abstände von PBP ausgedrückt; diese Abstände sind als Programmzähler-(PC)-Wert bestimmt. Werte der ABPs ändern sich während der Programmausführung und werden daher vom Compiler, der ein Anwenderprogramm in einer höheren Sprache in ein vom CS 101-System ausgeführtes Programm konvertiert, nicht angegeben. Wenn das Programm ausgeführt wird, liefert CS 101 die richtigen Werte für die ABPs. Wenn ein Programm gerade ausgeführt wird, werden die ABP-Werte im GRF der FU 120 gespeichert.
Andere Zeiger werden benutzt, beispielsweise zur Identifizierung des oberen Rahmens eines CS 101-Sicherheits-Stapelspeichers (ein Stapelspeicher auf Mikrocodeebene, der weiter unten beschrieben wird) oder zur Identifizierung des Mikrocodedialekts, der gerade bei der Ausführung der SINs einer Prozedur benutzt wird. Diese Zeiger sind ähnlich FP, SDP und PBP.

4. Stapelspeichermechanismen (Fig. 4-5)

Fig. 4 und 4A sind schematische Darstellungen der verschiedenen Kontrollebenen und Stapelspeichermechanismen von konventionellen Maschinen bzw. vom CS 101. Nach Fig. 4 ist das höchste Niveau durch Anwendersprache-Befehle 402, beispielsweise in FORT- RAN oder COBOL, gebildet. Die Anwendersprache-Befehle 402 werden in eine größere Anzahl von detaillierteren Maschinensprache-Befehlen 404 konvertiert, die in einer zur Ausführung des Anwenderprogramms bestimmten Maschine benutzt werden. Innerhalb der Maschine werden die Maschinensprache-Befehle 404 durch Mikrocode-Befehle 406 interpretiert und ausgeführt, d. h. durch Sequenzen von Mikrobefehlen, die ihrerseits direkt die Maschinenhardware 408 steuern. Einige konventionelle Maschinen können einen Stapelspeichermechanismus 410 aufweisen, der benutzt wird, um momentane Maschinenzustände, d. h. momentane Mikrobefehle und Inhalte von verschiedenen Maschinenregistern zu sichern, wenn ein momentaner Maschinensprache-Befehl 404 nicht ausgeführt werden kann oder unterbrochen wird. Im allgemeinen werden Maschinenzustände auf dem Mikrocode- und Hardwareniveau nicht gesichert. Die Ausführung eines momentane Maschinensprache-Befehls 404 wird später beim Start der Mikrobefehlsequenz für die Ausführung dieses Maschinensprache-Befehls 404 wieder aufgenommen.
Nach Fig. 4A ist das höchste Steuerniveau im CS 101 wie bei konventionellen Maschinen durch Anwendersprache-Befehle 412 gegeben. Im CS 101 werden jedoch die Anwendersprache-Befehle 412 in SOPs 414 übersetzt, die auf einem höheren Niveau als konventionelle Maschinensprache-Befehle sind. Im allgemeinen wird ein einziger Anwendersprache-Befehl 412 anstatt in eine ganze Sequenz von konventionellen Maschinensprache- Befehlen 404 in höchstens zwei oder drei SOPs 414 umgewandelt. Die SOPs 414 werden durch Mikrocode-Befehle 416 (Sequenzen von Mikrobefehlen) interpretiert und ausgeführt, welche direkt die CS 101-Hardware 418 steuern. CS 101 enthält auf dem Niveau der SOPs 414 einen Makrostapelspeichermechanismus (MAS) 420, der vergleichbar, aber in Konstruktion und Betriebsweise verschieden ist vom üblichen Maschinensprache-Stapelspeichermechanismus 410. CS 101 enthält außerdem einen Mikrocode-Stapelspeichermechanismus 422, der auf dem Mikrocodeniveau 416 arbeitet, so daß die Ausführung eines unterbrochenen Mikrobefehls einer Mikrobefehlssequenz später mit dem speziellen Mikrobefehl wiederaufgenommen werden kann, der zur Zeit der Unterbrechung gerade aktiv war. CS 101 ist daher bei der Behandlung von Unterbrechungen dahingehend wirkungsvoller, daß die Ausführung von Mikrobefehlssequenzen nicht vom Beginn der jeweiligen Sequenz an, sondern von der speziellen Stelle an wieder aufgenommen wird, bei der eine Mikrobefehlssequenz unterbrochen wurde. Wie weiter unten noch beschrieben wird, enthält der Mikrocode-Stapelspeichermechanismus 422 des CS 101 auf dem Mikrocodeniveau tatsächlich zwei Stapelspeichermechanismen. Der erste Stapel ist ein Mikrobefehl-Stapelspeicher (MIS) 424, während der zweite Stapel als Monitor-Stapelspeicher (MOS) 426 bezeichnet wird. SIN-Mikrocode 428 und MIS 424 des CS 101 sind vorwiegend mit der Ausführung von SOPs des Anwenderprogramms befaßt. Monitor- Mikrocode 430 und MOS 426 sind mit dem Arbeitsablauf gewisser interner Funktionen des CS 101 befaßt.
Die Unterteilung des Mikrocode-Stapelspeichers des CS 101 in einen MIS 424 und einen MOS 426 zeigt ein weiteres Merkmal des CS 101. Bei konventionellen Maschinen können Monitorfunktionen durch eine separate CPU ausgeführt werden, die mit der Haupt-CPU der Maschine zusammenarbeitet. Beim CS 101 wird eine einzige Hardware-CPU benutzt, um beide Funktionen auszuführen, wobei die aktuelle Ausführung beider Funktionen mit zwei separaten Mikrocodegruppen erfolgt. Monitormikrocode-Operationen können entweder durch gewisse SINs 414 oder durch Steuersignale initiiert werden, die direkt durch die Hardware 418 des CS 101 generiert werden. Der Aufruf des Monitormikrocode 430 durch von der Hardware 418 erzeugte Signale stellt sicher, daß die Monitorfunktionen des CS 101 immer aufgerufen werden können.
In Fig. 5 ist schematisch der Stapelmechanismus des CS 101 für ein einziges Anwenderprogramm oder eine einzige Anwenderprozedur gezeigt. Grundsätzlich und mit Ausnahme des MOS 426, sind die CS 101-Stapelspeicher im MEM 112 mit gewissen Teilen derjenigen Stapelspeicher vorhanden, die in die FU 120 und EU 122 hinein beschleunigt sind, um die Operationsgeschwindigkeit zu vergrößern.
Gewisse Bereiche des MEM 112 sind herausgenommen, um Makrostapelspeicher (MASs) 502 eines Stapelspeichermechanismus aufzunehmen, der, wie oben beschrieben wurde, auf dem Niveau der SINs arbeitet. Andere Bereiche des MEM 112 sind herausgenommen, um einen Sicherheitsstapelspeicher (SS) 504 zu enthalten, die, wie oben beschrieben, auf dem Mikrocodeniveau arbeiten und von dem MIS 424 ein Teil ist.
Wie weiter unten beschrieben werden wird, enthalten sowohl FU 120 als auch EU 122 zusätzlich zu Registern, die beispielsweise ALUs zugeordnet sind, Registerdateivektoren, die als GRF und ERF bezeichnet werden. Unter Bezugnahme auf FU 120 ist darin ein GRF 506 von FU 120 gezeigt. GRF 506 ist horizontal in drei Bereiche geteilt. Ein erster Bereich, der als allgemeine Register (GRs) 508 bezeichnet wird, kann im allgemeinen in derselben Weise wie die Register einer konventionellen Maschine benutzt werden. Ein zweiter Bereich des GRF 506 ist der Mikrostapelspeicher (MIS) 424 und beiseite gesetzt bzw. reserviert, um einen Teil eines Prozeß-SS 504 aufzunehmen. Ein dritter Abschnitt des GRF 506 ist beiseite gesetzt, um MOS 426 zu enthalten. Außerdem ist in FU 120 ein Block angedeutet, der als Mikrocode-Steuerstatus (mCS) 510 bezeichnet wird. mCS 510 repräsentiert Register und andere FU 120-Hardware, die momentane Betriebszustände von FU 120 auf dem Mikrobefehl-und Hardwareniveau enthalten. mCS 510 kann beispielsweise den momentanen Mikrobefehl enthalten, der die Operation von FU 120 steuert.
In der EU 122 sind ein erster, als Ausführungseinheit-Status (EUS) 512 bezeichneter Block und ein zweiter, als SOP-Stapelspeicher 514 bezeichneter Block angedeutet. EUS 512 ist ähnlich dem mCS 510 in der FU 120 und enthält alle Register und andere EU 122- Hardware, die Informationen enthalten, die den momentanen Betriebsstatus der EU 122 widerspiegeln. Der SOP-Stapelspeicher 518 ist ein Teil des EU 122-ERF 516, der als Stapelspeichermechanismus beiseite gesetzt bzw. reserviert wurde, um einen Teil eines zu EU 122-Operationen gehörenden Prozeß-SS 504 aufzunehmen.
Es wird nun zuerst auf MAS 502 Bezug genommen. Wie oben angegeben wurde, arbeiten die MASs 502 im allgemeinen auf dem Niveau der SINs. Die MASs 502 werden im allgemeinen dazu benutzt, den momentanen Status bei der Ausführung eines weiter unten erläuterten Prozesses eines Anwenderprogramms zu speichern.
Unter Bezugnahme auf MIS 424 ist festzustellen, daß bei einer derzeitigen Ausführungsform des CS 101 derjenige Abschnitt des GRF 506, der beiseite gesetzt wurde, um MIS 424 zu enthalten, eine Kapazität von acht Stapelspeicherrahmen aufweisen kann. Das bedeutet, daß im MIS 424 bis zu acht auf Mikrobefehlniveau befindliche Interrupts oder Aufrufe gestapelt werden können, die zur Ausführung eines Anwenderprogrammes gehören. In den MIS 424-Stapelspeicherrahmen gespeicherte Informationen sind im allgemeinen Informationen aus dem GR 508 und mCS 510. MIS 424-Stapelspeicherrahmen werden derart zwischen MIS 424 und SS 504 übertragen, daß wenigstens ein Rahmen, aber nicht mehr als acht Rahmen von SS 504 in GRF 506 resident sind. Dies stellt sicher, daß wenigstens die am weitesten oben befindlichen Rahmen eines Prozeß-SS 504 in der FU 120 vorhanden sind, wodurch die Betriebsgeschwindigkeit der FU 120 aufgrund des schnellen Zugriffs zu diesen obersten Rahmen vergrößert wird. SS 504, resident in MEM 112, kann für alle praktischen Zwecke eine unbegrenzte Anzahl von Rahmen aufweisen, so daß MIS 424 und SS 504 einem Benutzer effektiv als unendlich tiefer Stapel erscheinen.
MOS 426 ist vollständig in der FU 120 vorhanden und kann in einer gegenwartigen Ausführungsform des CS 101 eine Kapazität von acht Stapelspeicherrahmen besitzen. Ein Merkmal des CS 101-Betriebs ist, daß sich die CS 101-Mechanismen zur Behandlung gewisser Ereignisse oder Interrupts beim Betrieb nicht auf solche Abschnitte des CS 101 stützen sollten, deren Betrieb zu solchen Fehlern oder Interrupts geführt hat. Unter den vom CS 101-Monitormikrocode behandelten Ereignisse befinden sich beispielsweise MEM 112-Seitenfehler. Ein MEM 112-Seitenfehler erscheint immer dann, wenn die FU 120 auf Daten im MEM 112 Bezug nimmt und diese Daten nicht im MEM 112 enthalten sind. Aufgrund dieser und ähnlicher Operationen ist MOS 426 vollständig in der FU 120 resident und stützt sich daher nicht auf Informationen im MEM 112.
Wie oben beschrieben wurde, residieren GRs 508, MIS 424 und MOS 426 jeweils in gewissen zugeordneten Abschnitten des GRF 506. Dies ermöglicht Flexibilität bei der durch Erfahrung angezeigten Veränderung der Kapazität der GRs 508, des MIS 424 und des MOS 426 oder bei der Änderung eines individuellen CS 101 für besondere Anwendungszwecke.
Schließlich wird auf EU 122 Bezug genommen. EUS 512 ist ein funktioneller Teil eines Prozeß-SS 504. Wie oben erläutert wurde, führt die EU 122 als Antwort auf SINs arithmetische Operationen durch, kann aber durch die FU 120 unterbrochen werden, um gewisse FU 120-Operationen zu unterstützen. EUS 512 ermöglicht das Stapeln von Unterbrechungen. Beispielsweise könnte FU 120 zunächst eine arithmetische SOP unterbrechen, um die EU 122 aufzufordern, bei der Berechnung eines Namenstabelleneintrags zu helfen. Bevor dieser erste Interrupt vollendet ist, könnte FU 120 erneut unterbrechen usw.
Der SOP-Stapelspeicher 514 ist ein einzelner Rahmenstapelspeicher zum Speichern des momentanen Zustands der EU 122, wenn ein Interrupt die Ausführung einer arithmetischen SOP unterbricht. Ein unterbrochener SOP-Status wird in den SOP-Stapelspeicher 514 übertragen, und die Unterbrechung startet die Ausführung in EUS 512. Nach dem Erscheinen eines zweiten Interrupts (bevor der erste Interrupt vollendet ist) wird der erste Interrupt-Status vom EUS 512 zu einem Stapelspeicherrahmen im SS 504 übertragen und in EUS 512 mit der Ausführung des dritten Interrupts begonnen usw. EUS 512 und SS 504 sehen somit einen scheinbar unendlich tiefen Mikrostapelspeicher für EU 122 vor. Angenommen, daß der dritte Interrupt vollendet ist, wird der Status des zweiten Interrupts von SS 504 nach EUS 512 übertragen und die Ausführung des zweiten Interrupts wieder aufgenommen. Nach Vollendung des zweiten Interrupts, wird der Zustand des ersten Interrupts von SS 504 nach EUS 512 übertragen und vollendet. Nach der Vollendung des ersten Interrupts, wird der Status des Ursprungs-SOP vom SOP-Stapelspeicher 514 nach EUS 512 übertragen und die Ausführung dieses SOP wieder aufgenommen.

C. Prozeduren-Prozesse und virtuelle Prozessoren (Fig. 6)

In Fig. 6 ist eine schematische Darstellung von Prozeduren, Prozessen und virtuellen Prozessoren gezeigt. Wie oben beschrieben wurde, wird ein auszuführendes Anwenderprogramm durch Kompilieren in eine Prozedur 602 überführt. Eine Prozedur 602 beinhaltet ein Prozeduren-Objekt 604 des Anwenders, das die SOPs des Anwenderprogramms und eine Namenstabelle mit Einträgen für Operandennamen des Anwenderprogramms enthält, sowie einen statischen Datenbereich 606. Eine Prozedur 602 kann außerdem andere Prozeduren-Objekte 608 enthalten, beispielsweise Dienstprogramme, die für viele Anwender gemeinsam verfügbar sind. Tatsächlich enthält eine Prozedur 602 die Befehle (Prozeduren) und Daten eines Anwenderprogramms.
Ein Prozeß 610 enthält, wie oben beschrieben wurde, einen Makrostapelspeicher (MAS) 502, der den Ausführungsstatus einer Anwender-Prozedur 602 auf dem SOP-Niveau speichert, und einen Sicherungs-Stapelspeicher (SS) 504, der den Ausführungsstatus einer Anwender-Prozedur 602 auf dem Mikrocodeniveau speichert. Einem Prozeß 610 wird eine Anwender-Prozedur 602 durch die oben beschriebenen ABPs zugeordnet, die im MAS 502 des Prozesses 610 gespeichert sind. In ähnlicher Weise sind der MAS 502 und der SS 504 eines Prozesses 610 durch die oben beschriebenen, nicht-architektonischen Zeiger zugeordnet. Tatsächlich ist ein Prozeß 602 ein Informationskörper, der die Ressourcen, Hardware, Mikrocodes und Software des CS 101 mit einer Anwender-Prozedur 602 verbindet. Tatsächlich macht ein Prozeß 610 die Ressourcen des CS 101 für eine Anwender-Prozedur 602 verfügbar, um diese Prozedur 602 auszuführen. CS 101 ist eine Mehrprogramm-Maschine, die in der Lage ist, gleichzeitig bis zu beispielsweise 128 Prozesse 610 aufzunehmen. Die Zahl der Prozesse 610, die gleichzeitig ausgeführt werden können, ist festgelegt durch die Anzahl von virtuellen Prozessoren 612 des CS 101. Es können beispielsweise bis zu 16 virtuelle Prozessoren 612 vorhanden sein.
Nach Fig. 6 enthält ein virtueller Prozessor 612 einen virtuellen Prozessor-Statusblock (VPSB) 614, der dem SS 504 eines Prozesses 612 zugeordnet ist. Tatsächlich ist ein VPSB 614 ein Informationskörper, der für das Betriebssystem des CS 101 zugänglich ist und durch den das CS 101-Betriebssystem durch den SS 504 eines Prozesses 610 über diesen Prozeß 610 informiert und mit Zugriff auf diesen Prozeß 610 versehen wird. Ein VPSB 614 wird dadurch einem speziellen Prozeß 610 zugeordnet, daß Informationen betreffend diesen Prozeß 610 in das VPSB 614 eingeschrieben werden. Das CS 101- Betriebssystem kann dadurch, daß es durch einen zugeordneten VPSB 614 Zugriff zu einem Prozeß 610 erhält, Informationen, beispielsweise ABP-Informationen, von diesem Prozeß 610 zur FU 120 lesen, wodurch dieser Prozeß 610 an die FU 120 zur Ausführung übergeben wird. Es wird gesagt, daß ein virtueller Prozessor 612 dadurch einen Prozeß 610 ausführt; ein virtueller Prozessor 612 kann daher als ein Prozessor angesehen werden, der eine "virtuelle" oder potentielle Existenz besitzt, die "real" wird, wenn sein zugeordneter Prozeß 610 in die FU 120 eingelagert wird. Im CS 101 kann, wie in Fig. 6 angedeutet ist, nur ein virtueller Prozessor 612 zu irgendeiner Zeit in der FU 120 ausführen, und das Betriebssystem wählt aus, welcher virtuelle Prozessor 612 zu irgendeiner Zeit in der FU 120 ausführt. Außerdem wählt das CS 101-Betriebssystem aus, welche Prozesse 610 den verfügbaren virtuellen Prozessoren 612 zugeordnet werden.
Nachdem kurz gewisse individuelle Struktur- und Betriebsmerkmale des CS 101 beschrieben wurden, wird die Gesamtbetriebsweise des CS 101 nachfolgend anhand dieser einzelnen Merkmale in weiteren Einzelheiten beschrieben.

D. CS 101-Gesamtstruktur und -Betrieb (Fig. 7, 8, 9, 10, 11, 12, 13,14, 15)

1. Einführung (Fig. 7)

Wie in Fig. 7 angedeutet ist, ist der CS 101 ein Mehrfach-Niveau-System, in dem Operationen in irgendeinem Niveau im allgemeinen transparent für höhere Niveaus sind. Ein Anwender 701 sieht nicht die S-Sprache, die Adressierung und die Schutzmechanismen, die auf dem Architekturniveau 708 definiert sind. Statt dessen sieht der Anwender die Schnittstelle 709, die durch Compiler 702, Programmverknüpfer 703 und das erweiterte (auf hohem Niveau befindliche) Betriebssystem (EOS) 704 definiert ist. Die Compiler 702 übersetzen höhere Sprachcodes in SINs und Binder 703 übersetzen symbolische Namen und Programme in UID-Offset-Adressen.
Wie Fig. 7 zeigt, ist das Architekturniveau 708 nicht durch die FU 120-Schnittstelle 711 definiert. Statt dessen werden die architektonischen Ressourcenniveaus durch mit der S- Sprache interpretierte SINs erzeugt, wenn ein Programm ausgeführt wird; ein Namensinterpreter 715 arbeitet unter der Steuerung eines S-Sprache-Interpreters 705 und übersetzt Namen in logische Beschreiber. Im CS 101 werden sowohl der S-Sprache-Interpreter 705 als auch der Namens-Interpreter 715 als Mikrocode implementiert, der in FU 120 ausführt. S-Sprache-Interpreter 705 können außerdem EU 122 benutzen, um Rechnungen durchzuführen. Ein Kernbetriebssystem (KOS) versorgt CS 101 mit UID-Abstand- Adressierungen, Objekten, Zugriffsprüfung, Prozessen und virtuellen Prozessoren, wie weiter unten beschrieben wird. KOS hat drei Arten von Komponenten: KOS-Mikrocode 710, KOS-Software 706 und KOS-Tabellen in MEM 112. Die KOS 710-Komponenten sind Mikrocodeprogramme, die FU 120 bei der Durchführung gewisser geforderter Operationen unterstützen. Wie andere Hochsprachenprogramme enthalten die KOS 706- Komponenten SINs, die durch den S-Interpreter-Mikrocode 705 interpretiert werden. Viele KOS-Hochsprachenprogramme 706 werden durch spezielle KOS-Prozesse ausgeführt; andere können durch irgendeinen Prozeß ausgeführt werden. Sowohl die höheren KOS-Sprachprogramme 706 als auch die KOS-Mikrocodes 710 manipulieren die KOS- Tabellen in MEM 112.
Das FU 120-Interface 711 ist nur für KOS und den S-Interpreter-Mikrocode 705 sichtbar. Für die Zwecke dieser Beschreibung kann FU 120 als Prozessor angesehen werden, der die folgenden Hauptelemente enthält: - einen Steuermechanismus 725, der in einem schreibbaren Steuerspeicher 713 gespeicherten Mikrocode ausführt und FU 120-Geräte manipuliert, wie durch diesen Mikrocode angewiesen.
- ein GRF 506 mit Registern, in denen Daten gespeichert werden können.
- eine Verarbeitungseinheit 715.
Alle Mikrocode, die auf FU 120 ausführen, benutzen diese Geräte; zusätzlich gibt es eine Gruppe von Geräten zur Durchführung spezieller Funktionen; diese Geräte werden nur durch mit diesen Funktionen verbundene Mikrocode benutzt. Die Mikrocode, die speziellen Geräte und manchmal Tabellen in MEM 112 bilden logische Maschinen zur Durchführung gewisser Funktionen. Diese Maschinen werden im einzelnen weiter unten beschrieben.
Im folgenden werden die in Fig. 7 dargestellten Niveaus nacheinander erläutert. Zunächst werden die Komponenten am Anwender-Interface 709 untersucht, um zu sehen, wie sie Anwenderprogramme und Anforderungen in Formen übersetzen, die vom CS 101 verwertet werden können. Danach werden die Komponenten unterhalb des Anwender- Interface 709 untersucht, um zu sehen, wie sie logische Maschinen zur Durchführung von CS 101-Operationen erzeugen.

2. Compiler 702 (Fig. 7)

Compiler 702 übersetzen Dateien, die den höhersprachigen Code enthalten, der durch den Anwender 701 in die Prozeduren-Objekte 608 geschrieben worden ist. Zwei Komponenten eines Prozedurenobjekts 608 sind Codes (SOPs) und Namen, wie oben beschrieben ist. SOPs repräsentieren Operationen, während die Namen Daten repräsentieren. Ein einzelnes SIN spezifiziert somit eine Operation, die mit den durch die Namen repräsentierten Daten durchgeführt werden sollen.

3. Programmverknüpfer 703 (Fig. 7)

In manchen Fällen kann der Compiler 702 Orte nicht als Abstände von einem ABP definieren. Wenn beispielsweise eine Prozedur eine Prozedur aufruft, die in einem anderen Prozedurenobjekt enthalten ist, kann der Ort, zu dem der Aufruf die Steuerung überträgt, nicht als ein Abstand von einem PBP definiert werden, der von der rufenden Prozedur benutzt wird. In diesen Fällen verwendet der Compiler symbolische Namen, um die Orte zu definieren. Der Binder 703 ist ein Hilfsprogramm, das symbolische Namen in UID-Abstand-Adressen übersetzt. Er macht dies auf zwei Arten: durch Kombination eines separaten Prozeduren-Ojekts 608 in ein einziges großes Prozeduren-Objekt 608 und dann durch Neudefinition symbolischer Namen als Abstände von ABPs von diesem Prozeduren- Objekt 608 oder durch Übersetzung symbolischer Namen, wenn das Programm ausgeführt wird. Im zweiten Fall fordert der Binder 703 die Unterstützung von EOS 704.

4. EOS 704 (Fig. 7)

EOS 704 verwaltet die Ressourcen, die der Anwender 701 benötigt, um seine Programme auszuführen. Vom Standpunkt des Anwenders 701 aus sind dabei die wichtigsten Ressourcen die Dateien und Prozesse. EOS 704 erzeugt Dateien, indem es KOS auffordert, ein Objekt zu erzeugen, und dann die Datei auf das Objekt abbildet. Wenn ein Anwender 701 eine Operation an einer Datei durchführt, übersetzt EOS 704 die Dateioperation in eine Operation an einem Objekt. KOS erzeugt diese auf Anforderung von EOS 704 und macht sie EOS 704 verfügbar, was sie wiederum für den Anwender 701 verfügbar macht. EOS 704 verursacht die Ausführung eines Prozesses, indem es diesen einem virtuellen Prozessor 612 zuordnet. Legisch gesehen ist ein virtueller Prozessor 612 ein Mittel, das KOS an EOS 704 liefert, um Prozesse 610 auszuführen. In CS 101 können offenbar so viele Prozesse gleichzeitig ausgeführt werden, wie dort virtuelle Prozessoren 612 vorgesehen sind. Die Illusion einer gleichzeitigen Ausführung wird durch Multiplexen von JP 114 zwischen den virtuellen Prozessoren erzeugt; die Art, in der die Prozesse 610 und virtuellen Prozessoren 612 implementiert werden, wird weiter unten im einzelnen erklärt.

5. KOS und Architektur-Schnittstelle 708 (Fig. 7)

S-Interpreter-Mikrocode 710 und Namens-Interpreter-Mikrocode 715 erfordern zur Ausführung von SINs eine Umgebung, die durch KOS-Mikrocode 710 und KOS-Software 706 vorgesehen wird. Wie oben erläutert wurde, werden beispielsweise Namen und Programmorte in Termen von ABPs definiert, deren Werte sich während der Ausführung des Programms ändern. Die KOS-Umgebung liefert Werte für die ABPs und macht es dadurch möglich, Namen und Programmorte als Orte in MEM 112 zu interpretieren. In ähnlicher Weise ist die Hilfe von KOS erforderlich, um logische Beschreiber in Referenzen für MEM 112 zu übertragen und Schutzprüfungen auszuführen.
Die von KOS vorgesehene Umgebung hat folgende Elemente:
- Einen Prozeß 610, der den Status einer Ausführung eines Programms für einen gegebenen Anwender 701 enthält.
- Einen virtuellen Prozessor 612, der dem Prozeß 610 Zugang zum JP 114 gibt.
- Ein Objekt-Management-System, das UIDs in Werte übersetzt, die innerhalb von JP 114 verwendbar sind.
- Ein Schutzsystem, das überprüft, ob ein Prozeß 610 das Recht hat, an einem Objekt eine Operation durchzuführen.
- Ein virtuelles Speicher-Management-System, das solche Abschnitte von Objekten von der Außenwelt in das MEM 112 bewegt, auf die ein Prozeß 610 tatsächlich Bezug nimmt und logische Beschreiber in physikalische Beschreiber übersetzt.
Nachfolgend werden die logischen Eigenschaften dieser Umgebung und die Art erläutert, in der ein Programm ausgeführt wird.

6. Prozesse 610 und virtuelle Prozessoren 612 (Fig. 8)

Prozesse 610 und virtuelle Prozessoren 612 wurden bereits in logischen Ausdrücken beschrieben; Fig. 8 gibt einen auf hohem Niveau liegenden Überblick über ihre physikalische Implementierung.
Fig. 8 zeigt die Beziehung zwischen Prozessen 610, virtuellen Prozessoren 612 und dem JP 114. Physikalisch gesehen ist ein Prozeß 610 ein Bereich von MEM 112, das den gegenwärtigen Zustand einer Anwender-Ausführung eines Programms enthält. Ein Beispiel für einen solchen Status sind die momentanen Werte der ABPs und ein Programmzähler (PC). Ist der momentane Wert des PBP und des PC gegeben, kann die nächste SOP im Programm ausgeführt werden; in ähnlicher Weise können, wenn die momentanen Werte der SDP und FP gegeben sind, die Programmnamen korrekt aufgelöst werden. Da der Prozeß 610 den momentanen Status der Ausführung eines Programms enthält, kann die physikalische Ausführung des Programms gestoppt und an jeder Stelle wieder aufgenommen werden. Es ist dadurch möglich, mittels des Prozesses 610 die Ausführung des Programms zu steuern.
Wie schon erwähnt wurde, schreitet die Ausführung eines Prozesses 610 nur fort, wenn er von KOS an einen virtuellen Prozessor 612 gebunden worden ist, d. h. an einen Bereich von MEM 112, der den erforderlichen Status enthält, um Mikrobefehle in der JP 114- Hardware auszuführen. Die Operation des Anbindens ist einfach eine Übertragung des Zustands des Prozesses 610 vom Prozeß 610-Bereich des MEM 112 zu einem Bereich eines virtuellen Prozessors 612 im MEM 112. Da das Anbinden und Entbinden zu jeder Zeit stattfinden kann, kann das EOS 704 Prozesse 610 auf virtuelle Prozessore 612 aufteilen. In Fig. 8 sind mehr Prozesse 610 als virtuelle Prozessoren 612. Die physikalische Ausführung eines Prozesses 610 in JP 114 findet nur statt, wenn der virtuelle Prozessor 612 des Prozesses 610 an JP 114 angebunden ist, d. h. wenn der Zustand von einem Bereich des virtuellen Prozessors 612 des MEM 112 zu den JP 114-Registern übertragen ist. Ebenso wie EOS 704 virtuelle Prozessoren 612 auf Prozesse 610 aufteilt, teilt KOS den JP 114 auf virtuelle Prozessoren 612 auf. In Fig. 8 wird nur ein Prozeß 610 gerade physikalisch ausgeführt. Die Mittel, durch die JP 114 auf die virtuellen Prozessoren 612 aufgeteilt wird, werden weiter unten im einzelnen beschrieben.

7. Prozesse 610 und Stapelspeicher (Fig. 9)

In CS 101-Systemen besteht ein Prozeß 610 aus sechs Objekten: einem Prozeßobjekt 901 und fünf Stapelspeicherobjekten 902 bis 906. Fig. 9 zeigt einen Prozeß 610. Das Prozeß- Objekt 901 enthält die Information, die EOS 704 benötigt, um den Prozeß 610 zu verwalten. EOS 704 hat keinen direkten Zugang zum Prozeß-Objekt 901, sondern erhält statt dessen die Information, die es benötigt, mit Hilfe von Funktionen, die ihm durch KOS 706, 710 geliefert werden. Eingeschlossen in die Information sind die UIDs der Stapelspeicher-Objekte 902 bis 906. Die Stapelspeicher-Objekte 902 bis 906 enthalten den Prozeß 610-Status.
Die Stapelspeicher-Objekte 902 bis 905 werden vom Bereichsschutzverfahren des CS 101 benötigt und enthalten den Prozeß 610-MAS 502. Eine Domäne wird teilweise durch Operationen festgelegt, die ausgeführt werden, wenn ein System in dieser Domäne arbeitet. Beispielsweise befindet sich das System in der EOS 704-Domäne, wenn es EOS 704-Operationen ausführt, und in der KOS 706, 710-Domäne, wenn es KOS 706, 710- Operationen ausführt. Ein Prozeß 610 muß einen Stapelspeicher für jede Domäne, in die er eintritt, haben. Beim gegenwärtigen Ausführungsbeispiel ist die Zahl der Domänen auf vier festgelegt, doch kann bei anderen Ausführungsbeispielen jede Zahl von Domänen und entsprechend jede Zahl von Stapel-Speicher-Objekten vorgesehen sein. Das Stapel- Speicher-Objekt 906 enthält den Prozeß 610-Sicherungs-Stapelspeicher 504 und ist erforderlich, um einen Status zu speichern, der nur durch KOS 706, 710 manipuliert werden könnte.
Jede durch einen Prozeß 610 gemachte Invokation resultiert in der Addition von Rahmen zum Sicherungs-Stapelspeicher 504 und zum Makro-Stapelspeicher 502. Der im Rahmen des Sicherungs-Stapelspeichers 504 gespeicherte Zustand enthält den Makro-Zustand für die Invokation, d. h. den Zustand, der erforderlich ist, um den Prozeß 610 an einen virtuellen Prozessor 612 anzubinden. Der zum Makro-Stapelspeicher 502 addierte Rahmen wird in einem der Stapelspeicher-Objekte 902 bis 905 plaziert. Welches Stapelspeicher- Objekt 902 bis 905 den Rahmen erhält, wird durch den aufgerufenen Ausführungsbereich der Prozedur festgelegt.
Fig. 9 zeigt den Zustand des MAS 502 und des Sicherungs-Stapelspeichers 504 eines Prozesses 610, nachdem der Prozeß 610 vier Invokationen ausgeführt hat. Der Sicherungs- Stapelspeicher 504 weist einen Rahmen für jede Invokation auf; die Rahmen des MAS 502 des Prozesses 610 finden sich in den Stapelspeicher-Objekten 902,904 und 905. Wie durch ihre Orte offenbart wird, ist der Rahmen 1 für eine Invokation einer Routine mit einer KOS 706, 710-Domäne der Ausführung, Rahmen 2 für eine Invokation einer Routine mit der EOS 704-Domäne der Ausführung und die Rahmen 3 und 4 für Invokationen von Routinen mit der Anwender-Domäne der Ausführung. Der Prozeß 610 hat noch keine Routine mit der Domäne des Daten-Basis-Verwaltungs-Systems (DBMS) der Ausführung aufgerufen. Die Rahmen in den Stapelspeicher-Objekten 902 bis 905 sind miteinander verbunden, und jedesmal, wenn ein Rahmen zu den Stapelspeicher-Objekten 902 bis 905 hinzugefügt wird, wird ein Stapelspeicher dem Sicherungs-Stapelspeicher 504 hinzugefügt oder entnommen. MAS 502 und Sicherungs-Stapelspeicher 504 funktionieren dadurch als ein einziger logischer Stapelspeicher, selbst wenn sie logisch in fünf separaten Objekten enthalten sind.

8. Prozesse 610 und Aufrufe (Fig. 10, 11)

Im CS 101 werden die Aufrufe und die Rückkehren durch KOS 706, 710 durchgeführt. Wenn KOS 706, 710 einen Aufruf für einen Prozeß durchführt, so macht er folgendes:
- Er speichert den Makrozustand der aufrufenden Invokation in dem oberen Bereich des Sicherheits-Stapelspeichers 504 (Fig. 9).
- Er lokalisiert die Prozedur, deren Name im Aufruf enthalten ist. Die Stelle des ersten SIN in der Prozedur wird zum neuen PBP.
- Indem KOS 706,710 die Informationen auswertet, die in der gerufenen Prozedur enthalten sind, erzeugt er einen neuen MAS 502-Bereich in dem Ruhestapelspeicher- Objekt 902 bis 905 und einen neuen Sicherheits-Stapelspeicherbereich 504 im Sicherheits- Stapelspeicher 504. FP wird geändert, so daß er zum neuen MAS 502 zeigt. Falls nötig, wird SDP ebenso geändert.
Sobald die Werte der ABPs einmal geändert sind, ist PC definiert, die Namen können gelöscht werden und die Ausführung der aufgerufenen Routine kann beginnen. Nach einer Rückkehr aus der Unterroutine zu der rufenden Routine werden die Stack-Bereiche gelöscht und die ABPs werden auf die Werte gesetzt, die im Makrozustand der rufenden Routine gespeichert sind. Die aufrufende Routine setzt dann die Ausführungen fort an dem Punkt, der dem Aufruf folgt.
Ein Prozeß 610 kann im Detail illustriert werden, indem man die FORTRAN-Anweisung A + B in eine FORTRAN-Routine namens EXAMPLE steckt und indem man sie aufruft von einer anderen FORTRAN-Routine namens CALLER. Um das Beispiel zu vereinfachen, sei angenommen, daß CALLER und EXAMPLE denselben Ausführungsbereich besitzen. Die Bereiche von EXAMPLE, die von Interesse sind, sehen folgendermaßen aus:
SUBROUTINE EXAMPLE (C)
INTEGER X, C
INTEGER A, B
. . .
A = B
. . .
RETURN
END.
Die neuen Elemente sind formale Argumente C und eine neue lokale Variable X. Ein formales Argument ist eine Variable, die ihren Wert von einer Variable in der rufenden Routine bekommt. Der Wert des formalen Arguments variiert auf diese Weise von Aufruf zu Aufruf. Die Bereiche von INVOKER, die von Interesse sind, sehen folgendermaßen aus:
SUBROUTINE INVOKER
INTEGER Z
. . .
CALL EXAMPLE (Z)
. . .
END.
Die CALL-Anweisung in INVOKER spezifiziert den Namen der Unterroutine, die aufgerufen wird und die aktuellen Argumente für die formalen Argumente in der Subroutine. Während der Ausführung des Unterprogrammes nehmen die formalen Argumente des Unterprogrammes die Werte der aktuellen Argumente an. So wird das formale Argument C während der Ausführungen des Unterprogrammes, die in der CALL-Anweisung spezifiziert wird, den Wert bekommen, den die Variable Z in INVOKER hatte.
Wenn INVOKER compiliert wird, erzeugt der Compiler ein CALL SIN entsprechend der CALL-Anweisung. Der CALL SIN enthält einen Namen, der einen Zeiger auf den Anfang der Speicherstelle der gerufenen Routine im Objekt der Prozedur repräsentiert und eine Liste von Namen, die die aktuellen Argumente des Aufrufs repräsentieren. Wenn CALL ausgeführt wird, werden die Namen interpretiert, um die Namen des SINs aufzulösen, wie oben beschrieben, und um den KOS 710 Mikrocode aufzulösen, um MAS 502 und Sicherheits-Stapelspeicher 504-Operationen durchzuführen.
Fig. 10 verdeutlicht die Art und Weise, in welcher der KOS 710-Aufrufmikrocode den MAS 502 und den Sicherheits-Stapelspeicher 504 manipuliert. Bild 10 umfaßt folgende Elemente:
- Aufrufmikrocode 1001, enthalten im FU 120-Schreibkontrollspeicher 1014.
- PC-Gerät 1002, das Teil des Makrozustandes enthält, der zur Ausführung von INVOKER gehört, der die CALL-Anweisung ausführt.
- Register in den FU-Registern 1014. Registerinhalte 1004 beinhalten den Rest des Makrozustands und die Beschreiber, die den Namen für die Stelle von EXAMPLE und dem aktuellen Argument Z entsprechen.
- Prozedurobjekt 1006 enthält die Eingänge für INVOKER und EXAMPLE, ihre Namenstabellen und ihren Code.
- Makrostapelspeicher-Objekt 1008 (MAS 502) und Sicherheits-Stapelspeicher-Objekt 1010 (Sicherheits-Stapelspeicher 504) enthalten die Stapelspeicherrahmen für die Ausführung von INVOKER und EXAMPLE, die hier diskutiert wurden. Der Rahmen von EXAMPLE ist im selben Makrostapelspeicher-Objekt wie der Rahmen von INVOKER, weil beide Routinen sich in demselben Prozedur-Objekt 1006 befinden und daher denselben Ausführungsbereich besitzen.
KOS-Aufrufmikrocode 1001 speichert zuerst den Makrozustand von INVOKER's Ausführung im Sicherheits-Stapelspeicher 504. Wie später diskutiert werden wird, benutzt KOS 706 Aufrufmikrocode 1001, wenn der Zustand abgespeichert wird, einen anderen KOS 706 Mikrocode, um die Lokationsinformation, die sich im Makrozustand befinden, in die Art von Zeigern zu übersetzen, die in MEM 112 benutzt werden. Darauf benutzt Mikrocode 1001 den Beschreiber des Namens der Routine, um den Zeiger auf den Eingang von EXAMPLE im Prozedurobjekt 1006 zu positionieren. Vom Eingang positioniert er Zeiger zu der Namenstabelle von EXAMPLE und zum Anfang von EXAMPLE's Code. Mikrocode 1001 nimmt diese Zeiger, benutzt einen anderen KOS 706 Mikrocode, um sie in Beschreiber zu übersetzen, und plaziert diese Beschreiber in die Lokationen in den Registern 1004, die für die Werte von PBP und NTP reserviert sind. Es ändert dann die Werte des PC-Gerätes 1002, so daß, wenn der Aufruf beendet ist, der nächste SIN, der ausgeführt werden soll, der erste SIN in EXAMPLE ist.
CALL Mikrocode 1001 konstruiert dann die Rahmen für EXAMPLE auf dem Sicherheits- Stapelspeicher 504 und dem Makrostapelspeicher 502. Diese Diskussion betrifft nur den Rahmen 1102 auf dem Makrostapelspeicher 502. Fig. 11 verdeutlicht den Rahmen 1102 von EXAMPLE. Die Größe vom Rahmen 1102 wird bestimmt durch die lokalen Variablen X, A und B von EXAMPLE und seinem formalen Argument C. Am unteren Ende von Rahmen 1102 ist der Kopf 1104. Der Kopf 1104 enthält Information, die von KOS 706,710 benutzt wird, um den Stapelspeicher zu organisieren. Als nächstes kommt der Zeiger 1106 zu der Speicherstelle, die den Wert, der durch das Argument C repräsentiert wird, enthält. Während der Ausführung ist der aktuelle Wert für C der der lokalen Variablen Z in INVOKER. Wie bei allen anderen lokalen Variablen ist der Speicherbereich, der durch Z repräsentiert wird, im Stapelspeicherrahmen enthalten, der zur Ausführung von INVOKER gehört. Wenn ein Namensinterpreter den Namen von C auflöst, so plaziert er den Beschreiber in einem Register. Aufrufmikrocode 1001 nimmt diesen Beschreiber, konvertiert ihn in einen Zeiger und speichert den Zeiger über dem Kopf 1104.
Weil der FP ABP zu der Stelle zeigt, die dem letzten Zeiger zu einem aktuellen Argument folgt, kann Aufrufmikrocode 1001 nun diese Stelle berechnen, sie in einen Beschreiber umwandeln und diesen in ein FU-Register 1004 plazieren, welches für FP reserviert ist. Der nächste Schritt besteht darin, Speicherplatz für die lokalen Variablen von EXAMPLE bereitzustellen. Das Prozedurobjekt 1006 von EXAMPLE enthält die Größe des benötigten Speichers für die lokalen Variablen. Daher erhält Aufrufmikrocode 1001 diese Information vom Prozedurobjekt 1006 und fügt dementsprechend Speicherplatz zu dem Rahmen 1102 dazu. Indem er den neuen Wert von FP und die Information, die in den Eingängen der Namenstabelle für die lokalen Daten enthalten ist, benutzt, kann der Namensinterpreter 715 nun Beschreiber für die lokalen Daten konstruieren. Zum Beispiel spezifizierte A's Eingang in der Namenstabelle einen Offset von 32 Bit von FP und daß es 32 Bits lang war. So fällt seine Speicherung zwischen die Speicherplätze von X und von B in Fig. 11.

9. Speicherreferenzen und virtuelles Speichermanagement-System (Fig. 12, 13)

Wie bereits erklärt, enthält ein logischer Beschreiber ein AON-Feld, ein Offsetfeld und ein Längenfeld. Fig. 12 beschreibt einen physikalischen Beschreiber. Der physikalische Beschreiber 1202 enthält ein Rahmennummernfeld (FN), ein Verschiebungsfeld (D) und ein Längenfeld (L). Das Rahmennummernfeld spezifiziert zusammen mit dem Verschiebungsfeld die Lokation im MEM 112, welches die Daten enthält, und das Längenfeld spezifiziert die Länge der Daten.
Wie aus dem Vorhergegangenen klar wurde, muß das virtuelle Speichermanagement- System die AON-Offsetlokation, die im logischen Beschreiber 1204 enthalten ist, in eine Rahmennummer-Verschiebungslokation übersetzen. Es tut dies, indem es logische Seiten mit dem MEM 112-Rahmen in Zusammenhang bringt. (Anmerkung: MEM 112-Rahmen sind nicht zu verwechseln mit Stapelspeicherrahmen.) Fig. 13 stellt dar, wie Makrostack 502 Objekt 1302 in logische Seiten 1304 im Sekundärspeicher unterteilt wird und wie die logischen Seiten 1304 auf die Rahmen 1306 in MEM 112 geschoben werden. Ein Rahmen 1306 ist eine zusammenhängende Fläche fester Größe des MEM 112. Wenn das virtuelle Speichermanagement-System Daten in MEM 112 bringt, bewerkstelligt es dies in Abschnitten in Rahmengröße, den sogenannten logischen Seiten 1308. Daher ist aus der Sicht des virtuellen Speichersystems jedes Objekt unterteilt in logische Seiten 1308 und die Datenadresse auf einer Seite besteht aus dem AON des Objektes der Daten, der Anzahl der Seiten im Objekt und seiner Verschiebung auf der Seite. In Fig. 13 wird die Stelle der lokalen Variablen B von EXAMPLE gezeigt, wie sie vom virtuellen Speichersystem definiert ist. B's Stelle ist ein UID und ein Offset, oder innerhalb von JP 114 ein AON und ein Offset. Wie vom virtuellen Speichersystem definiert, ist B's Lokation das AON, die Seitennummer 1308 und eine Verschiebung innerhalb der Seite. Wenn ein Prozeß auf die Variable B Bezug nimmt, schiebt das virtuelle Speichermanagement-System alles der logischen Seite 1308 in einen MEM 112-Rahmen 1306. B's Verschiebung bleibt die gleiche und das virtuelle Speichersystem übersetzt seine logische Seite Nummer 1308 in die Rahmennummer 1306 in MEM 112, welches die Seite beinhaltet.
Das virtuelle Speichermanagement-System muß daher zwei Arten von Übersetzungen durchführen: (1) AON-Offset-Adressen in AON-Seitennummern-Verschiebungsadressen und (2) AON-Seitennummer in Rahmennummer.

10. Zugangskontrolle (Fig. 14)

Jedes Mal, wenn zu einem Objekt Bezug genommen wird, überprüft KOS 706, 710, ob die Bezugnahme legal ist. Die folgende Diskussion wird zuerst die logische Struktur der Zugangskontrolle in CS 101 präsentieren und dann den Mikrocode und die Geräte diskutieren, die sie implementieren.
CS 101 definiert Zugang in Subjekten, Zugangsarten und Objektgröße. Ein Prozeß kann auf einen Datenausdruck Bezug nehmen, der in einem Objekt lokalisiert ist, wenn drei Bedingungen erfüllt sind:
1. Falls das Subjekt des Prozesses Zugang zum Objekt besitzt.
2. Falls die Zugangsarten, die für das Subjekt spezifiziert sind, die einschließen, die verlangt sind, um die beabsichtigte Operation durchzuführen.
3. Falls der Datenausdruck vollständig im Objekt enthalten ist, d. h. falls die Länge des Datenausdrucks plus der Anfangspunkt des Datenausdrucks die Anzahl der Bits im Objekt nicht übersteigt.
Die Subjekte, die Zugang zum Objekt haben, und die Zugriffsarten, die sie zum Objekt haben, werden durch eine Datenstruktur spezifiziert, die mit dem Objekt assoziiert ist und Zugangskontroll-Liste (ACL) heißt. Die Größe eines Objekts ist eine seiner Attribute. Weder die Größe eines Objekts noch seine ACL ist im Objekt enthalten. Beide sind in Systemtabellen enthalten und sind zu erreichen durch die UID des Objekts.
Fig. 14 zeigt die logische Struktur der Zugangskontrolle in CS 101. Subjekt 1408 hat vier Komponenten: Prinzipal 1404, Prozeß 1405, Bereich 1406 und Kennzeichen 1407. Kennzeichen 1407 ist nicht in einer vorhandenen Verkörperung von CS 101 implementiert. Daher behandelt die folgende Beschreibung nur Prinzipal 1404, Prozeß 1405 und Bereich 1406.
- Prinzipal 1404 spezifiziert den Benutzer, für den der Prozeß, der Bezug nimmt, kreiert wurde.
- Prozeß 1405 spezifiziert den Prozeß, der Bezug nimmt, und
- Bereich 1406 spezifiziert den Bereich der Ausführung der Prozedur, die der Prozeß ausführt, wenn die Bezugnahme stattfindet.
Jede Komponente des Subjekts 1408 wird durch eine UID repräsentiert. Falls die UID eine Null-UID ist, unterliegt die Komponente des Subjekt keiner Zugangskontrolle. Nicht Null-UIDs sind die UIDs eines Objekts, die Information über die Komponenten des Subjekts enthalten. Das Prinzipal 1404 enthält die Information über die Identifikation und die Anmeldung der Systembenutzer, Prozeßobjekt 1405 enthält die Prozeßmanagement- Information und Bereichsobjekt 1406 enthält die Information über bereichsspezifische Fehlerbehandlungen.
Zu einem Objekt 1410 kann es drei verschiedene Zugangsarten geben: Lesen, Schreiben und Ausführen. Lesen und Schreiben erklären sich selbst. Ausführen ist ein Zugang, der einem Subjekt erlaubt, die in einem Objekt enthaltenen Befehle auszuführen.
Die Zugangskontroll-Listen (ACLs) 1412 werden von den Eingängen 1414 gemacht. Jeder Eingang hat zwei Komponenten: die Subjektschablone 1416 und den Artenspezifizierer 1418. Subjektschablone 1416 spezifiziert eine Gruppe von Subjekten, die auf das Objekt Bezug nehmen können, und Artenspezifizierer 1418 spezifiziert die Zugangsarten, die diese Subjekte zu dem Objekt haben können. Legisch gesprochen überprüft die ACL 1412 jedesmal, wenn ein Prozeß auf ein Objekt 1410 Bezug nimmt. Die Bezugnahme ist nur dann erfolgreich, wenn das aktuelle Subjekt 1408 eines von jenen Subjekten ist, die in der ACL 1412 des Objekts 1410 vorhanden sind und falls die Arten im ACL-Eingang 1414 für das Subjekt 1408 die Zugriffsart erlauben, die der Prozeß wünscht auszuführen.

11. Virtuelle Prozessoren and virtuelle Prozessor-Ein- und Auslagerung (Fig. 15)

Wie im Vorhergehenden erwähnt, kann die Ausführung eines Programmes durch einen Prozeß 610 nur dann stattfinden, wenn EOS 704 den Prozeß 610 an einen virtuellen Prozessor 612 gebunden hat. Die physikalische Ausführung des Prozesses 610 findet nur dann statt, solange der virtuelle Prozessor 612 des Prozesses an JP 114 gebunden ist. Die folgende Diskussion behandelt die Datenbasen, die zu dem virtuellen Prozessor 612 gehören, und die Mittel, durch die der virtuelle Prozessor 612 an JP 114 gebunden ist und von ihm entfernt wird.
Fig. 15 verdeutlicht die Geräte und Tabellen, die KOS 706, 710 benutzt, um den virtuellen Prozessor 612 zu implementieren. FU 120 WCS enthält KOS Mikrocode 706, um die virtuellen Prozessoren 612 an JP 114 zu binden und von ihm zu lösen. Die Zeitschalter 1502 und die Unterbrechungslinie 1504 sind Hardware-Geräte, die Signale produzieren, die die Ausführung des KOS Mikrocode 706 verursachen. Die Zeitschalter 1502 enthalten zwei Zeitgeräte: Intervallzeitschalter 1506, der durch KOS 706, 710 eingeschaltet werden kann, wenn eine bestimmte Zeit erreicht ist, und der Eieruhrschalter 1508, der garantiert, daß es eine maximale Zeitspanne gibt, in der der virtuelle Prozessor 612 an JP 114 gebunden ist, bevor er den KOS Mikrocode 706 ausführt. Die Unterbrechungslinie 1504 wird aktiv, wenn JP 114 eine Nachricht von IOS 116 bekommt, z. B. wenn IOS 116 das Laden einer logischen Seite in MEM 112 beendet hat.
Die FU 120-Register 508 enthalten den Zustand, der zum virtuellen Prozessor 612 gehört, der momentan an JP 114 gebunden ist. Hier wird dieser virtuelle Prozessor 612 virtueller Prozessor A genannt. Zusätzlich enthalten die Register 508 Register, die für die Ausführung des Mikrocode 1510 reserviert sind zur Aus- und Einlagerung des VP. ALU 1942 (Teil von FU 120) wird dazu benötigt, um die Beschreiber- zu Zeiger- und Zeiger- zu Beschreiberumwandlungen zu führen, wenn ein virtueller Prozessor 612 von einer JP 114 gelöst wird oder ein anderer an JP 114 gebunden wird. MEM 112 enthält Datenbasen für den virtuellen Prozessor 612 und Datenbasen, die von KOS 706, 710 benötigt werden, um die virtuellen Prozessoren 612 zu verwalten. KOS 706, 710 stellt eine feste Anzahl von virtuellen Prozessoren 612 für CS 101 bereit. Jeder virtuelle Prozessor 612 wird repräsentiert durch einen virtuellen Prozessor-Zustandsblock (VPSB) 614. Jeder VPSB 614 enthält Informationen, die von KOS 706, 710 benötigt werden, um den virtuellen Prozessor 612 zu verwalten, und enthält darüber hinaus noch Informationen für die Verbindung des virtuellen Prozessors 612 mit einem Prozeß. Fig. 15 zeigt zwei VPSBs 614, einer gehört zu dem virtuellen Prozessor 612A und der andere zu dem virtuellen Prozessor 612B, der den virtuellen Prozessor 612A auf JP 114 ersetzen wird. Die VPSBs 614 sind im VPSB- Vektor 1512 enthalten. Der Index eines VPSB 614 im VPSB-Vektor 1512 ist die virtuelle Prozessornummer 1514, die zu einem virtuellen Prozessor 612 gehört, repräsentiert durch VPSB 614. Virtuelle Prozessorlisten 1516 sind Listen, die KOS 706, 710 benötigt, um die virtuellen Prozessoren 612 zu verwalten. Wenn ein virtueller Prozessor 612 ausführungsfähig ist, so steht seine virtuelle Prozessornummer 1514 auf einer Liste, die ausführbare Liste genannt wird. Virtuelle Prozessoren 612, die nicht ausführen können, stehen auf anderen Listen, abhängig von der Begründung, warum sie nicht ausführen können. Es wird angenommen, daß die virtuelle Prozessornummer 1514 des virtuellen Prozessors 612B die erste auf der ausfährbaren Liste ist.
Wenn ein Prozeß an einen virtuellen Prozessor 612 gebunden wird, so wird die virtuelle Prozessornummer 1514 in das Prozeßobjekt 901 des Prozessors hineinkopiert und die AONs des Prozeßobjekts 901 des Prozesses und die Stapelspeicher werden in den VPSB 614 des virtuellen Prozessors 612 hineinkopiert. (AONs werden benutzt, weil die Stapelspeicher eines Prozesses solange aktiv geschaltet sind, wie der Prozeß an den virtuellen Prozessor 612 gebunden ist.) Das Binden wird von KOS 706, 710 auf Anforderung von EOS 704 ausgeführt. In Fig. 15 werden zwei Sicherheits-Stapelspeicherobjekte 906 gezeigt, einer gehört zu dem Prozeß, an den der virtuelle Prozessor 612A gebunden ist, und der andere gehört zu dem, an welchen der virtuelle Prozessor 612B gebunden ist.
Nachdem bestimmte allgemeine Betriebsmerkmale des CS 101 beschrieben sind, wird nun eine vorhandene Implementierung einer CS 101-Struktur beschrieben.

E. Die strukturelle Implementierung von CS 101 (Fig. 16, 17, 18, 19, 20)

1. (IOS) 116 (Fig. 16, 17)

Mit Bezug auf Fig. 16 wird ein Ausschnittsblockdiagramm des IOS 116 gezeigt. Die Hauptelemente eines IOS 116 beinhalten einen ECLIPSE Burst-Multiplexerkanal (BMC) 1614 und einen NOVA Datenkanal (NDC) 1616, einen Ein- und Ausgabe-Controller (IOC) 1618 und einen Datenbeweger (DM) 1610. Die Datenkanalgeräte des IOS 116, beispielsweise BMC 1614 und NDC 1616, umfassen die Schnittstelle von IOS 116 zur Außenwelt. Informationen und Adressen von externen Geräten werden empfangen, wie z. B. Festplattenlaufwerke, Kommunikationsarten oder andere Computersysteme, durch die Datenkanalgeräte des IOS 116 und werden zu DM 1610, wie weiter unten beschrieben, transferiert, um in MEM 112 geschrieben zu werden. In ähnlicher Weise wird die Information, die von MEM 112 gelesen wird, durch DM 1610 für die Datenkanalgeräte des IOS 116 bereitgestellt und auf diese Weise für die oben beschriebenen externen Geräte. Die externen Geräte sind Teil des Adreßraumes von CS 101 und können adressiert werden durch UID-Adressen.
IOC 1618 ist eine allgemeine CPU, z. B. ein ECLIPSE-Computer, der von der Data General Corporation verfügbar ist. Eine Hauptfunktion des IOC 1618 ist die Kontrolle des Datentransfers durch IOS 116. Darüber hinaus erzeugt IOC 1618 individuelle Karten für jedes Datenkanalgerät, um externe Geräteadressen in physikalische Adressen innerhalb von MEM 112 zu übersetzen. Wie angezeigt in Fig. 16, enthält jedes Datenkanalgerät eine individuelle Adressenübersetzungskarte (MAP) 1632 und 1636. Dies erlaubt dem IOS 116, individuelle Flächen des physikalischen Adreßraumes von MEM 112 jedem Datenkanalgerät zuzuordnen. Dieses Merkmal sorgt für Sicherheit gegen das Schreiben oder Lesen von Information, die zu einem anderen Datenkanalgerät gehört. Zusätzlich kann IOC 1618 überlappende Adreßübersetzungskarten für zwei oder mehrere Datenkanalgeräte erzeugen, um es diesen Datenkanalgeräten zu ermöglichen, eine gemeinsame Fläche im physikalischen Adreßraum von MEM 112 zu teilen.
Der Datentransfer zwischen den Datenkanalgeräten von IOS 116 und MEM 112 geschieht durch DM 1610, welches einen Pufferspeicher (BUF) 1641 enthält. BUF 1641 erlaubt MEM 112 und IOS 116 asynchronen Betrieb. DM 1610 schließt auch einen Ringberechtigungserzeuger (RGG) 1644 ein, welcher die Zugangskontrolle der verschiedenen Datenkanalgeräte zu MEM 112 durchführt. RGG 1644 ist flexibel ausgelegt, um den Zugang zu MEM 112 unter den Datenkanalgeräten des IOS 116, je nach Auslastung der verschiedenen Datenkanalgeräte aufzuteilen. Zusätzlich sorgt RGG 1644 dafür, daß nicht ein einzelner oder eine Gruppe von Datenkanalgeräten den Zugang zum MEM 112 für sich allein beanspruchen kann.
Fig. 17 zeigt diagrammartig den Betrieb des RGG 1644. Wie später in einer folgenden Beschreibung beschrieben werden wird, kann RGG 1644 betrachtet werden als ein Vertauscher, der eine Reihe von Anschlußpunkten absucht, die den verschiedenen Kanalgeräten zugeordnet sind. Zum Beispiel werden die Anschlußpunkte A, C, E und G dem BMC 1614 zugeordnet, die Anschlußpunkte B und F zu NDC 1616 und die Anschlußpunkte D und H zu einem anderen Datenkanalgerät. RGG 1644 wird jeden dieser Anschlußpunkte immer wieder lesen und wenn das Datenkanalgerät, welches mit dem speziellen Anschlußpunkt verbunden ist, Zugang sucht zu MEM 112, so wird er ihm im Datenkanalgerät zu MEM 112 Zugang gewähren. Wenn keine Anforderung vorliegt an einem gegebenen Anschlußpunkt, so wird RGG 1644 sofort zum nächsten Anschlußpunkt weitergehen. Jedem Datenkanalgerät, dem ein oder mehrere Anschlußpunkte zugeordnet sind, wird auf diese Weise Gelegenheit zum Zugang zu MEM 112 verschafft. Nicht gebrauchte Anschlußpunkte, z. B. die Datenkanalgeräte, die momentan nicht in den Informationstransfer eingreifen, werden einfach übergangen, so daß der Zugang zu MEM 112 dynamisch verändert wird, je nach Belastung der Informationstransfers der einzelnen Datenkanalgeräte. Die Anschlußpunkte des RGG 1644 können unter den verschiedenen Datenkanalgeräten des IOS 116 neu zugeordnet werden, wenn es nötig wäre, den Bedarf eines bestimmten CS 101-Systems zu decken. Falls z. B. eine bestimmte CS 101 mehr den NDC 1616 benutzt als den BMC 1614, so würden den NDC 1616 dieser CS 101 mehr Anschlußpunkte zugeordnet werden, und den BMC 1614 der CS 101 würden weniger Anschlußpunkte zugeordnet werden.

2. Speicher (MEM) 112 (Fig. 18)

In Fig. 18 wird ein Ausschnitt aus einem Blockdiagramm des MEM 112 gezeigt. Die wichtigsten Elemente des MEM 112 sind die Hauptspeicherbank (MSB) 1810, der Bank- Controller (BC) 1814, ein Zwischenspeicher (MC) 1816, eine Feldschnittstelleneinheit (FIU) 1820 und ein Speicherschnittstellen-Controller (MIC) 1822. Die Verbindungen dieser Elemente mit den Input- und Output-Bussen des MEM 112 zu IOS 116 und JP 114 werden angezeigt.
MEM 112 ist ein intelligenter, Prioritäten vergebender Speicher, der einen Anschlußpunkt zu IOS 116 besitzt, umfaßt vom IOM-Bus 130, MIO-Bus 129 und IOMC-Bus 131, und zwei Anschlußpunkten zu JP 114. Ein erster JP 114-Anschlußpunkt ist angeschlossen an MOD-Bus 140 und PD-Bus 146. Ein zweiter Anschlußpunkt ist angeschlossen an JPD-Bus 142 und PD-Bus 146. Grundsätzlich bestehen alle Datentransfers von und zu MEM 112 durch IOS 116 und JP 114 aus einzelnen 32-Bit-Worten. IOM-Bus 130, MIO-Bus 129, MOD-Bus 140 und JPD-Bus 142 sind jeweils 32 Bit breit. CS 101 jedoch ist eine Maschine, die Worte unterschiedlicher Länge verarbeiten kann, wobei die aktuelle physikalische Breite der Datenbusse dem Benutzer nicht erscheinen. Zum Beispiel bezieht sich ein Bezeichner in einem Benutzerprogramm auf einen Operanden, der 97 Datenbits enthält. Für den Benutzer würde dieser 97-Bit-Datenausdruck von MEM 112 zu JP 114 scheinbar in einer einzelnen Operation gelesen werden. Tatsächlich würde JP 114 diesen Operanden von MEM 112 in einer Serie von Leseoperationen als Zeichenkettentransfer lesen. In diesem Beispiel würde der Zeichenkettentransfer drei 32-Bit-Lesetransfers und einen Einzelbit-Lesetransfer umfassen. Der letzte Einzelbittransfer, der das einzelne Datenbit enthält, würde aus einem 32-Bit-Wort bestehen, worin ein Bit ein Datum ist und 31 Bits nur Füller sind. Schreibvorgänge auf MEM 112 können auf die gleiche Weise ausgeführt werden. Falls eine einzelne Lese- oder Schreibanforderung an MEM 112 einen Datenausdruck spezifiziert, der weniger als 32 Datenbits enthält, würde dieser Transfer auf die gleiche Art und Weise vollführt werden wie der letzte Transfer, der oben beschrieben wurde. Das heißt, ein einzelnes 32-Bit-Wort würde transferiert werden, worin nicht signifikante Bits Füllbits sind.
Die Speicherung einer großen Menge von Daten in MEM 112 ist in MSB 1810 vorgesehen, der aus ein oder mehreren Speichervektorkarten (MAs) 1812 besteht. Der Datenpfad in und aus MA 1812 geht durch BC 1814, der alle steuerungs- und zeitkritischen Funktionen für MAs 1812 durchführt. Der Funktionsumfang von BC 1814 schließt die Adressierung, den Datentransfer, die Steuerung, ob ein Lese- oder Schreibvorgang durchgeführt wird, und Codeoperationen für Refresh, Sniffing und die Fehlerkorrektur ein. Alle Lese- und Schreibvorgänge von und zu MAs 1812 durch BC 1814 geschehen in Blocks von vier 32-Bit-Wörtern.
Die verschiedenen MAs 1812, die MSB 1810 umfaßt, müssen nicht notwendigerweise die gleiche Datenspeicherkapazität besitzen. Zum Beispiel könnten bestimmte MAs 1812 eine Speicherkapazität von 256 Kilobit besitzen, während andere MAs 1812 eine von 512 Kilobit besitzen könnten.
Die Adressierung der MAs 1812 in MSB 1810 wird automatisch an die verschiedenen MA 1812-Konfigurationen angepaßt. Wie in Fig. 18 angezeigt, enthält jeder MA 1812 eine Adreßleitung (A), die einen Input von dem nächsttieferen MA 1812 erhält, der die höchste Adresse in diesem nächsttieferen MA 1812 anzeigt. Die A-Leitung bei einem MA 1812 empfängt auch einen Input von diesem MA 1812, der den gesamten Adreßraum dieses MA 1812 anzeigt. Die A-Leitung dieses MA 1812 fügt den höchsten Adresseninput vom nächsttieferen MA 1812 zu seinem eigenen Input dazu, der seine eigene Kapazität repräsentiert, und erzeugt für den nächsten MA 1812 einen Output, der seine eigene höchste Adresse anzeigt. Alle MAs 1812 des MSB 1810 werden parallel adressiert von BC 1814. Jeder MA 1812 vergleicht solche Adressen mit seinem Input vom nächsttieferen MA 1812, der die höchste Adresse von diesem nächsttieferen MA 1812 repräsentiert, und seinem eigenen Output, der die höchste eigene Adresse repräsentiert, um zu bestimmen, ob eine spezielle Adresse, die für BC 1814 vorgesehen ist, im Adreßbereich jenes speziellen MA 1812 enthalten ist. Jener MA 1812, dessen Adreßraum diese Adresse beinhaltet, wird dann antworten, indem er die Lese- oder Schreibanforderung von BC 1814 akzeptiert.
MC 1816 ist der Datenpfad für den Transfer von Daten zwischen BC 1814 und IOS 116 und JP 114. MC 1816 enthält einen Hochgeschwindigkeitszwischenspeicher, der Daten von MSB 1810 speichert, der gerade entweder von IOS 116 oder JP 114 benutzt wird. MSB 1810 stattet MEM 112 dadurch mit einer großen Speicherkapazität aus, während MC 1816 einen Hochgeschwindigkeitsspeicher bereitstellt. Zusätzlich zum Zwischenspeicherbetrieb beinhaltet MC 1816 einen Umgehungsschreibpfad, der es IOS 116 erlaubt, Blocks von vier 32-Bit-Worten direkt in MSB 1810 über BC 1814 zu schreiben. Darüber hinaus beinhaltet MC 1816 einen Zwischenspeicher-Zurückschreibpfad, der erlaubt, Daten aus dem Zwischenspeicher von MC 1816 herauszutransferieren und zu speichern, während weitere Daten in den Zwischenspeicher von MC 1816 hineintransferiert werden. Daten, die aus dem Zwischenspeicher von MC 1816 entfernt worden sind, können dann zu einem späteren, besser passenden Zeitpunkt in MSB 1810 zurückgeschrieben werden. Dieser Zurückschreibpfad steigert die Betriebsgeschwindigkeit des MC 1816, indem es Zeitverzögerungen vermeidet, die auftreten, wenn Daten vom MC 1816 zum MSB 1810 transferiert werden, bevor neue Daten in MC 1816 geschrieben werden können.
Die FIU 1820 des MEM 112 erlaubt die Manipulation von Datenformaten in Lese- und Schreibvorgängen an MEM 112 durch JP 114 und IOS 116. Zum Beispiel könnte FIU 1820 ungepackte dezimale Daten zu gepackten dezimalen Daten umwandeln und umgekehrt. Darüber hinaus erlaubt FIU 1820 es dem MEM 112, bitweise adressiert zu werden. Zum Beispiel bestehen, wie beschrieben, alle Datentransfers von und zu MEM 112 aus 32-Bit-Worten. Wenn ein Datentransfer mit weniger als 32 Bits angefordert wird, kann das 32-Bit-Wort, welches diese Daten enthält von MC 1816 zu FIU 1820 gelesen werden und dort selbst manipuliert werden, um die geforderten Datenbits zu extrahieren. FIU 1820 erzeugt dann ein 32-Bit-Wort, welches die geforderten Datenbits enthält, plus Füllbits und stellt dieses neue 32-Bit-Wort JP 114 oder IOS 116 zur Verfügung. Beim Schreiben in MEM 112 von IOS 116 über FIU 1820 werden Daten auf dem IOM-Bus 130 transferiert, in FIU 1820 gelesen, dort weiterverarbeitet, auf MOD Bus 140 transferiert und weiter transferiert vom MOD-Bus 140 zu MC 1816. Bei Lesevorgängen von MEM 112 zu IOS 116 werden die Daten von MC 1816 zum MOD-Bus 140 transferiert, in FIU 1820 hineingeschrieben und dort weiterverarbeitet und auf den MIO-Bus 129 transferiert zu IOS 116. Bei einem Datenlesen von MEM 112 zu JP 114 werden die Daten von MC 1816 auf den MOD-Bus 140 transferiert, von dort transferiert in FIU 1820 und dort selbst weiterverarbeitet und weitertransferiert auf MOD-Bus 140 zu JP 114. Bei Schreiboperationen von JP 114 nach MEM 112 werden Daten auf den JPD-Bus 142 transferiert und von dort in FIU 1820 transferiert und dort selbst weiterverarbeitet und dann auf den MOD-Bus 140 transferiert zu MC 1816. MOD-Bus 140 wird dabei als ein interner Bus in MEM 112 für Operationen in FIU 1820 benutzt.
Schließlich stellt MIC 1822 die Hauptsteuerung des BC 1814, MC 1816 und FIU 1820 zur Verfügung. MIC 1822 empfängt Steuerungseingaben von und macht Steuerungsausgaben zum PD-Bus 146 und dem IOMC-Bus 131. MIC 1822 enthält die hauptsächliche Mikrocodesteuerung für MEM 112, aber BC 1814, MC 186 und FIU 1820 beinhalten jeweils interne Mikrocodesteuerung. Unabhängige interne Mikrocodesteuerungen erlauben es BC 1814, MC 1816 und FIU 1820, unabhängig von MIC 1822 zu operieren, nachdem ihre Operationen einmal initiiert worden sind durch MIC 1822. Dies erlaubt BC 1814 und MSD 1810, MC 1816 und FIU 1820 unabhängig und asynchron zu operieren. Die Effektivität und die Geschwindigkeit des Betriebs von MEM 112 werden dadurch gesteigert, indem es den MEM 112-Operationen das sogenannte Pipelining erlaubt.

3. Zugriffseinheit (FU) 120 (Fig. 19)

Die Hauptfunktion der FU 120 ist, SINs auszuführen. Dabei ruft FU 120 Befehle und Daten ab (SOPs und Bezeichner), und zwar von MEM 112, gibt die Operationsergebnisse an MEM 112 zurück, dirigiert den Betrieb von EU 122, führt Befehle vom Benutzerprogramm aus und führt verschiedene Funktionen des Betriebssystems vom CS 101 aus. Als Teil dieser Funktionen erzeugt und manipuliert FU 120 logische Adressen und Beschreiber und ist dazu imstande, als normale CPU zu operieren.
Wie aus Fig. 19 hervorgeht, ist ein Hauptelement von FU 120 der Beschreiberprozessor (DESP) 1910. DESP 1910 beinhaltet die allgemeine Registerdatei (GRF) 506. GRF 506 ist ein großer Registervektor, der vertikal in drei Teile unterteilt ist, die parallel adressiert werden. Ein erster Teil AONGRF 1932 speichert AON-Felder von logischen Adressen und Beschreibern. Ein zweiter Teil OFFGRF 1934 speichert Offsetfelder von logischen Adressen und Beschreibern und wird als ein 32 Bit breiter, allgemeiner Registervektor benutzt. Ein dritter Bereich GRF 506, LENGRF 1936, ist ein 32 Bit breiter Registervektor für die Speicherung von Längenfeldern und logischen Beschreibern und als allgemeines Register um Daten zu speichern. Der Hauptdatenpfad von MEM 112 zu FU 120 geht über MOD-Bus 140, der den Input für OFFGRF 1934 bereitstellt. Wie in Fig. 19 gezeigt, können Daten von OFFGRF 1934 zu den Inputs von AONGRF 1932 und LENGRF 1936 über verschiedene Verbindungen transferiert werden. In ähnlicher Weise können Outputs von LENGRF 1936 und AONGRF 1932 zu Inputs von AONGRF 1932, OFFGRF 1934 und LENGRF 1936 transferiert werden.
Der Output von OFFGRF 1934 wird mit den Eingaben von DESPs 1910 arithmetischer und logischer Einheit (ALU) 1942 verbunden. ALU 1942 ist ein allgemeiner 32 Bit-ALU, der dazu benutzt werden kann, um logische Adressen und Bezeichner zu erzeugen und zu manipulieren im Unterschied zu allgemeinen arithmetischen und logischen Operanden, die von MUX 1940 ausgeführt werden. Der Output von ALU 1942 wird mit dem JPD-Bus 142 verbunden, um es den Ergebnissen der arithmetischen und logischen Operationen zu erlauben, zu MEM 112 oder EU 122 transferiert zu werden.
Auch der Beschreiber-Multiplexer (MUX) 1940 ist an den Output von OFFGRF 1934 angeschlossen. Ein Output von MUX 1940 ist vorgesehen für einen Input für ALU 1942. MUX 1940 ist ein 32 Bit-ALU mit einem Akkumulator für Datenmanipulationsvorgänge. MUX 1940 und ALU 1942 erlauben es DESP 1910, 32 Bit arithmetische und logische Operationen durchzuführen. MUX 1940 und ALU 1942 können arithmetische und logische Operationen mit Operanden, die größer als 32 Bit sind, erlauben, indem sie aufeinander folgende Operationen auf aufeinander folgenden 32-Bit-Worten von längeren Operanden durchführen.
Logische Beschreiber oder Adressen, die erzeugt werden oder vorgesehen sind für DESP 1910, werden dem logischen Beschreiber-Bus (LD) 1902 zur Verfügung gestellt. LD-Bus 1902 wiederum ist verbunden mit dem Input einer Adressen-Übersetzungseinheit (ATU) 1928. ATU 1928 ist ein Zwischenspeichermechanismus, um logische Beschreiber in physikalische Beschreiber für MEM 112 umzuwandeln.
Der LD-Bus 1902 ist auch mit dem Schreibeingang des Namenzwischenspeichers (NC) 1926 verbunden. NC 1926 ist ein Zwischenspeichermechanismus, um logische Beschreiber zu speichern, die Operandennamen entsprechen, die gerade in Benutzerprogrammen benutzt werden. Wie oben beschrieben, werden die Eingänge von Namenstabellen, die den Operanden, die gerade in Benutzerprogrammen benutzt werden, entsprechend in MEM 112 gespeichert. Bestimmte Namenstabelleneingänge für Operanden eines Benutzerprogramms, welches gerade ausgeführt wird, werden von den Namenstabellen in MEM 112 zu FU 120 transferiert und hier ausgewertet, um die entsprechenden logischen Beschreiber zu erzeugen. Diese logischen Beschreiber werden dann in NC 1926 gespeichert. Wie weiter unten beschrieben werden wird, wird der Befehlsstrom eines Benutzerprogramms in den Befehlspuffer (IB) 1962 der FU 120 über den MOD-Bus 140 geleitet. Der Parser (P) 1964 sortiert die Namen oder analysiert die Namen von IB 1962 und stellt die Namen als Adreßeingaben für NC 1924 dar. NC 1924 hingegen stellt Aufgaben in Form von losen Beschreibern für den LD-Bus 1902 dar und damit als Eingabe für ATU 1928. Der Input von LD-Bus 1902 in NC 1926 erlaubt es, daß die logischen Beschreiber, die aus der Auswertung der Eingänge der Namenstabelle resultieren, in NC 1926 geschrieben werden können. Der Schutzzwischenspeicher (PC) 1934 der FU 120 ist ein Zwischenspeichermechanismus, der einen Input vom LD-Bus 1902 besitzt und Informationen bereitstellt, wie weiter unten beschrieben werden wird, die Schutzaspekte beim Zugriff auf Daten im MEM 112 durch Benutzerprogramme betreffen. NC 1926, ATU 1928 und PC 1934 sind dabei Beschleunigungsmechanismen von CS 101-Namensspeicheradressierung, logischer bis physikalischer Adressenstruktur und Schutzmechanismen.
Sich wieder auf DESP 1910 beziehend, schließt DESP 1910 BIAS 1952 ein, der mit dem Output von LENGRF 1936 verbunden ist. Wie oben beschrieben wurde, werden Operanden, die mehr als 32 Datenbits groß sind, zwischen MEM 112 und JP 114 mit den Mitteln des Zeichenkettentransfers transferiert. Um Zeichenkettentransfers durchführen zu können, muß FU 120 eine entsprechende Folge von logischen Beschreibern generieren, wobei die Feldlänge dieser logischen Beschreiber nicht größer als 5 sein darf; das bedeutet, Längen zu spezifizieren, die nicht größer als 32 Datenbits sind.
Ein logischer Beschreiber, der einen Datenausdruck beschreibt, der mit Hilfe des Zeichenkettentransfers transferiert werden soll, wird in GRF 506 abgespeichert. Das AON-Feld des logischen Beschreibers wird Platz finden in AONGRF 1932, das O-Feld in OFFGRF 1934 und das L-Feld in LENGRF 1936. Bei jedem nachfolgenden Transfer eines 32 Bit- Worts im Zeichenkettentransfer wird das O-Feld des ursprünglichen logischen Beschreibers um die Anzahl der Datenbits, die transferiert worden sind, inkrementiert, während das 1-Feld entsprechend dekrementiert wird. Der logische Beschreiber in GRF 506 wird daher bei jedem nachfolgenden Transfer des Zeichenkettentransfers jenen Anteil des Datenausdrucks beschreiben, der noch zu transferieren ist. Das O-Feld in OFFGRF 1934 wird daher immer größer werdende Abstände in diesen Datenausdruck anzeigen, während das L-Feld immer kleinere Längen anzeigen wird. Das AON- und das O-Feld des logischen Beschreibers in GRF 506 kann direkt als AON- und O-Feld des darauf folgenden logischen Beschreibers des Zeichenkettentransfers benutzt werden. Das 1-Feld des logischen Beschreibers in LENGRF 1936 jedoch kann nicht als 1-Feld des logischen Beschreibers des darauf folgenden Zeichenkettentransfers benutzt werden, weil dieses 1- Feld die noch verbleibende Länge des Datenausdrucks, der noch zu transferieren ist, anzeigt. Statt dessen erzeugt BIAS 1952 die fünf Bit 1-Felder des logischen Beschreibers des darauf folgenden Zeichenkettentransfers, während er entsprechend das 1-Feld des logischen Beschreibers in LENGRF 1936 herunterzählt. Während jeden Transfers erzeugt BIAS 1952 das 1-Feld des logischen Beschreibers des nächsten Zeichenkettentransfers, während er gleichermaßen das L-Feld des logischen Beschreibers des aktuellen Zeichenkettentransfers zur Verfügung stellt. Auf diese Weise erhöht BIAS 1952 dadurch die Ausführungsgeschwindigkeit von Zeichenkettentransfers, indem er pipelined 1-Feld- Operationen durchführt. BIAS 1952 erlaubt es daher CS 101, dem Benutzer als eine Maschine mit variabler Wortlänge zu erscheinen, indem es automatisch Zeichenkettentransfers durchführt. Dieser Mechanismus wird für jeden Transfer von Datenausdrücken benutzt, die größer als 32 Bit sind, z. B. für Gleitkommazahlen doppelter Genauigkeit.
Schließlich enthält FU 120 Mikrocodeschaltungsaufbau, um alle oben beschriebenen Operationen von FU 120 zu steuern. Im besonderen enthält FU 120 einen Steuerspeicher für Mikrobefehlsfolgen 1920, in dem die Abfolgen von Mikrobefehlen gespeichert werden, um schrittweise die Ausführung aller FU 120-Operationen zu steuern. Allgemein gesprochen unterscheidet man bei den FU 120-Operationen zwei Klassen. Eine erste Klasse beinhaltet jene Abfolgen von Mikrobefehlen, die direkt mit der Ausführung der SOPs des Benutzerprogramms verbunden sind. Die zweite Klasse beinhaltet Abfolgen von Mikrobefehlen, die mit dem Betriebssystem des CS 101 verbunden sind und bestimmte automatische interne FU 120-Funktionen wie z. B. die Auswertung der Eingänge der Namenstabellen.
Wie früher beschrieben, ist die CS 101 eine Mehrfach-S-Sprachenmaschine. Zum Beispiel könnte MC 1920 Abfolgen von Mikroinstruktionen zur Ausführung von Benutzer-SOPs in mindestens vier verschiedenen Dialekten beinhalten. MC 1920 umfaßt beschreibbaren Steuerspeicher, und verschiedene Sätze von Mikrobefehlabfolgen für verschiedene Dialekte können in und aus MC 1920 transferiert werden, so wie es erforderlich ist für die Ausführung von verschiedenen Benutzerprogrammen. Dadurch, daß man Sätze von Mikrobefehlsabfolgen für mehr als einen Dialekt in MC 1920 abspeichern kann, ist es für Benutzerprogramme möglich, in einer Mischung aus Benutzersprachen geschrieben zu werden. Zum Beispiel könnte ein spezielles Benutzerprogramm hauptsächlich in FORTRAN geschrieben sein, aber könnte bestimmte COBOL-Routinen aufrufen. Diese COBOL-Routinen werden entsprechend in SOPs mit COBOL-Dialekt übersetzt und durch Mikrobefehlsabfolgen in COBOL ausgeführt, die in MC 1920 gespeichert sind.
Der Befehlsstrom, der von MEM 112 für FU 120 vorgesehen ist, ist weiter oben beschrieben in Bild 3. Die SOPs und Namen dieses Befehlsstroms werden vom MOD-Bus 140 in den in 1962 transferiert in dem Maße, in dem sie von MEM 112 zur Verfügung gestellt werden. IB 1962 enthält zwei 32 Bit (Einwort) Register. IB 1962 enthält auch Vorgriffsschaltlogik, um SOPs und Namen des Befehlsstroms von MEM 112 zu lesen, und zwar so, daß in 1962 immer mindestens ein SOP oder einen Namen enthält. FU 120 enthält (P) 1964, der die SOPs und Namen von in 1962 liest und trennt oder analysiert. Wie früher beschrieben, stellt P 1964 jene Namen NC 1926 zur Verfügung, welcher in entsprechender Weise die logischen Beschreiber ATU 1928 zur Verfügung stellt, also das Lesen der entsprechenden Operanden von MEM 112. Die SOPs, die durch P 1964 analysiert werden, werden als Input zur Zugriffseinheiten-Zuteilungstabelle (FUDT) 1904 und für die Ausführungseinheiten-Zuteilungstabelle (EUDT) 1966 zur Verfügung gestellt. Zuerst auf FUDT 1904 eingehend ist FUDT 1904 tatsächlich eine Tabelle für die Übersetzung von SOPs in Startadressen in MC 1912 der entsprechenden Mikrobefehlsabfolgen. Diese zwischenzeitliche Übersetzung von SOPs zu MC 1912-Adressen erlaubt effektives Packen von Mikrobefehlsabfolgen innerhalb von MC 1912. Das bedeutet, daß bestimmte Mikrobefehlsabfolgen gleichermaßen zu zwei oder mehreren S-Sprachen- Dialekten gehören können. Solche Mikrobefehlsabfolgen können daher in MC 1912 geschrieben werden und die Bezugnahme auf sie kann erfolgen durch verschiedene SOPs von verschiedenen S-Sprachen-Dialekten.
EUDT 1966 führt eine ähnliche Funktion wie EU 122 durch. Wie weiter unten beschrieben werden wird, enthält EU 122 einen MC, ähnlich dem MC 1912, der durch EUDT 1966 adressiert wird durch EU 122-Operationen, die SOPs spezifizieren. Zusätzlich kann FU 120 solche Adressen MC 1912 zur Verfügung stellen, um EU 122-Operationen zu initiieren, wie es erforderlich ist, um bestimmte FU 120-Operationen zu unterstützen. Beispiele von solchen Operationen, die von FU 120 angefordert werden können, beinhalten Rechnungen, die bei der Auswertung von Namenstabelleneingängen erforderlich sind, um die logischen Beschreiber zur Verfügung zu stellen, die in NC 1926 geladen werden sollen.
Mit FUDT 1904 und EUDT 1966 werden die Dialekt (D) Register 1905 und 1967 in Verbindung gebracht. Die D-Register 1905 und 1967 speichern die Information ab, die den speziellen S-Sprachen-Dialekt anzeigt, der gerade bei der Ausführung des Benutzerprogramms benutzt wird. Die Outputs der D-Register 1905 und 1967 werden als Teil von Adressen-Inputs für MC 1912 und EU 122's MC gebraucht.

4. Ausführungseinheit (EU) 122 (Fig. 20)

Wie weiter oben beschrieben, ist EU 122 eine arithmetische und logische Einheit, die dafür vorgesehen ist, FU 120 von bestimmten arithmetischen Operationen zu entlasten. EU 122 ist imstande, Additions-, Subtraktions-, Multiplikations- und Divisionsoperationen mit ganzen Zahlen, gepackten und ungepackten Dezimalzahlen und Gleitkomma-Operanden von einfacher und doppelter Genauigkeit durchzuführen. EU 122 ist eine unabhängig operierende mikrocodegesteuerte Maschine, die Mikrocodesteuerung (MC) 2010 enthält, die, wie oben beschrieben, von EUDT 1966 adressiert wird, um EU 122-Operationen zu initiieren. MC 2010 enthält auch Logik, um gegenseitige Unterbrechungen zwischen FU 120 und EU 122 zu bewerkstelligen. Das heißt, FU 120 kann aktuelle EU 122-Operationen unterbrechen, indem es EU 122 aufruft, bei einer FU 120-Operation unterstützend tätig zu werden. Zum Beispiel kann FU 120 eine arithmetische Operation, die augenblicklich von EU 122 ausgeführt wird, unterbrechen, um EU 122 dazu aufzufordern, bei der Erzeugung eines logischen Beschreibers von einem Namenstabelleneingang zu unterstützen. In ähnlicher Weise kann EU 122 aktuelle FU 120-Operationen unterbrechen, wenn EU 122 die Hilfe von FU 120 benötigt, um eine aktuelle arithmetische Operation auszuführen. Beispielsweise kann EU 122 eine aktuelle FU 120-Operation unterbrechen, falls EU 122 einen Befehl und Operanden empfängt, die EU 122 erforderlich machen, um eine Division durch Null auszuführen.
In Fig. 20 wird ein Ausschnitt aus einem Blockdiagramm von EU 122 gezeigt. EU 122 enthält zwei arithmetische und logische Einheiten. Eine erste arithmetische und logische Einheit (MULT) 2014 wird dazu benötigt, um Additions-, Subtraktions-, Multiplikations- und Divisionsoperationen mit ganzzahligen und Dezimaloperanden und mit Mantissenfeldern von Gleitkommazahlen einfacher oder doppelter Genauigkeit durchzuführen. Die zweite ALU (EXP) 2016 wird dazu benötigt, wenn der Operandenexponent eine Gleitkommazahl von einfacher oder doppelter Genauigkeit ist, und zwar parallel zu Operationen, die an Gleitkomma-Mantissenfeldern durch MULT 2014 durchgeführt werden. Sowohl MULT 2014 als auch EXP 2016 enthalten eine arithmetische und logische Einheit respektive MALU 2074 und EXPALU 2084. MULT 2014 und EXP 2016 enthalten auch Registerdateien MRF 2050 respektive ERF 2080, die parallel arbeiten und parallel adressiert werden in ähnlicher Weise zu AONGRF 1932, OFFGRF 1984 und LENGRF 1936.
Die Operanden, mit denen EU 122 operieren soll, werden von MEM 112 durch den MOD-Bus 140 zur Verfügung gestellt und werden in den Operandenpuffer (OPB) 2022 transferiert. Zusätzlich zu seiner Funktion als Eingabepuffer führt OPB 2022 bestimmte Datenformat-Manipulationsoperationen aus, um die Eingabeoperanden in Formate zu transferieren, mit denen EU 122 am effektivsten arbeiten kann. Insbesondere EU 122 und MULT 2014 sind so ausgelegt, daß sie am effektivsten mit gepackten Dezimaloperanden arbeiten können. OPB 2022 kann ungepackte Dezimaloperanden in gepackte Dezimaloperanden transformieren. Ungepackte Dezimaloperanden sind in der Form ASCII- Zeichen, worin vier Bits jedes Zeichens Binärcode sind, um einen Dezimalwert zu spezifizieren zwischen Null und Neun. Die anderen Bits jedes Zeichens sind Zonenfelder und enthalten normalerweise Informationen, die bestimmte ASCII-Zeichen identifizieren. Zum Beispiel können die Bits des Zonenfeldes spezifizieren, ob ein bestimmtes ASCII- Zeichen eine Zahl, ein Buchstabe oder ein Punktuationszeichen ist. Gepackte Dezimaloperanden bestehen aus einer Reihe von vier Bitfeldern, worin jedes Feld eine Binärzahl enthält, die einen Dezimalwert zwischen Null und Neun spezifiziert. OPB 2022 konvertiert ungepackte Dezimaloperanden zu gepackten Dezimaloperanden, indem es die Zonenfeldbits extrahiert und die vier Bits numerischen Werts jedes Zeichens in die vier Bitfelder einer gepackten Dezimalzahl packt.
EU 122 ist auch dazu imstande, die Resultate von arithmetischen Operanden, die z. B. im gepackten Dezimalformat sind, in ungepacktes Dezimalformat zu transformieren für einen Transfer zurück zu MEM 112 oder FU 120. In diesem Fall wird ein gepacktes Dezimalresultat, welches als Output von MALU 2074 erscheint, in MRF 2050 geschrieben mit Hilfe eines Multiplexers, der in Fig. 20 nicht gezeigt ist, der die vier Bit numerische Codefelder des gepackten Dezimalergebnisses in die entsprechenden Bits von ungepackten Zeichen von Dezimaloperanden überführt und Leerzeichen in die Zonenfeldbits von jenen ungepackten Dezimalzeichen zwingt. Die Ergebnisse von dieser Operation werden dann von MRF 2050 zu MALU 2074 gelesen und Zonenfeldbits für jene ungepackten Dezimalzeichen werden vom konstanten Speicher (CST) 2060 zu MALU 2074 gelesen. Diese Eingaben von MRF 2050 und CST 2060 werden von MALU 2074 addiert, um das Endergebnis als Ausgabe im ungepackten Dezimalformat zu erzeugen. Diese Endresultate können dann über den JPD-Bus 142 durch den Output-Multiplexer (OM) 2024 transferiert werden.
Wenn wir erst Gleitkommaoperationen betrachten, so ist es bei der Addition oder der Subtraktion von Gleitkommaoperanden notwendig, die Werte der Exponentenfelder der Gleitkommaoperanden zu glätten. Darunter verstehen wir vor Ausrichtung. Bei Gleitkommaoperationen werden die Exponentenfelder der beiden Operanden in EXPALU 2034 transferiert und verglichen, um die Differenz zwischen den Exponentenfeldern zu bestimmen. Eine Ausgabe, welche die Differenz zwischen den Exponentenfeldern repräsentiert, wird von EXPALU 2034 der Gleitkammersteuerung (FPC) 2002 als Eingabe zur Verfügung gestellt. FPC 2002 wiederum stellt Steuerungsausgaben MALU 2074 zur Verfügung, welcher die Mantissenfelder der beiden Operanden empfangen hat. MALU 2074, welcher unter der Leitung von FPC 2002 arbeitet, verschiebt das Mantissenfeld eines Operanden nach rechts oder nach links, um das Exponentenfeld jenes Operanden an dem Exponentenfeld des anderen Operanden am besten auszurichten. Dann kann die Addition oder Subtraktion der Mantissenfelder der Operanden vor sich gehen.
EXPALU 2034 führt auch die Addition oder die Subtraktion von Exponentenfeldern von Gleitkommaoperanden während der Multiplikations- oder Divisionsoperationen durch, während MALU 2074 die Multiplikation und Division der Mantissenfelder der Operanden durchführt. Die Multiplikation und Division der Mantissenfelder des Gleitkommaoperanden durch MALU 2074 wird durch aufeinanderfolgendes Verschieben eines Operanden durchgeführt, was der Erzeugung von Teilprodukten des anderen Operanden entspricht und der sukzessiven Addition und Subtraktion von diesen Teilprodukten.
Schließlich führt EU 122 die Normalisierung der Ergebnisse der Gleitkommaoperandenoperationen durch, indem es das Mantissenfeld des Endresultats nach links verschiebt, um die führenden Nullen im Mantissenfeld des Endresultats zu eliminieren und gleichermaßen Verschiebung der Exponentenfelder des Endresultats. Die Normalisierung der Gleitkommaoperationsergebnisse werden gesteuert durch FPC 2002. FPC 2002 untersucht ein nicht normalisiertes Gleitkommaergebnis als Ausgabe von MALU 2074, um zu entdecken, ob welche der führenden Zeichen Nullen sind. FPC 2002 stellt dann entsprechend Kontrollausgaben EXPALU 2034 und MALU 2074 zur Verfügung, um die Exponenten- und Mantissenfelder von jenen Ergebnissen zu verschieben, um führende Nullen aus den Mantissenfeldern zu eliminieren. Normalisierte Felder von Mantisse und Exponent der Gleitkommaergebnisse können dann von MALU 2074 und EXPALU 2034 über JPD-Bus 142 durch OM 2024 transferiert werden.
Wie oben beschrieben, führt EU 122 auch Additions-, Multiplikations-, Subtraktions- und Divisionsoperationen an Operanden durch. In diesem Zusammenhang benutzt EU 122 einen Detektor für führende Nullen in FPC 2002, um in effektiver Weise Multiplikations- und Divisionsoperationen durchzuführen. Der führende Nullen-Detektor von FPC 2002 untersucht die Zeichen oder Bits der beiden Operanden, die multipliziert oder dividiert werden sollen, indem es mit dem höchsten anfängt, um zu bestimmen, welche, wenn überhaupt, Nullen enthalten, um eine Multiplikation oder Division gar nicht erst erforderlich zu machen. FPC 2002 links verschiebt die Operanden, um wirkungsvoll jene Zeichen oder Bits zu eleminieren, und reduziert so die Anzahl von Operationen, die Operanden miteinander zu multiplizieren oder zu dividieren, und reduziert in entsprechender Weise die Zeit, in der an beiden Operanden gearbeitet wird.
Schließlich benutzt EU 122 eine einzigartige Methode - mit der entsprechenden Hardware -, um arithmetische Operationen an Dezimaloperanden auszuführen, indem es Schaltungen benutzt, die sonst konventionellerweise nur dazu benutzt werden, um Operationen an Gleitkommaoperanden durchzuführen. Wie oben beschrieben, ist MULT 2074 dafür ausgelegt, mit gepackten Dezimaloperanden zu operieren, das sind Operanden in der Form von aufeinanderfolgenden Vier-Bitblocks, wobei jeder Vier-Bitblock einen Binärcode enthält, der numerische Werte zwischen Null und Neun repräsentiert. Gleitkommaoperanden sind in ähnlicher Weise in der Form von aufeinanderfolgenden Vier- Bitblocks. Jeder Vier-Bitblock eines Gleitkommaoperanden jedoch enthält eine Binärzahl, die einen hexadezimalen Wert repräsentiert zwischen Null und Fünfzehn. Als erster Schritt mit dem Operieren mit gepackten Dezimaloperanden werden jene Operanden geladen, einer zu einem Zeitpunkt in MALU 2074 und es wird mit jedem solchen Operanden eine Zahl in MALU 2074 von CST 2060 geladen, die alle hexadezimalen Sechsen umfaßt. Diese CST 2060-Zahl wird zu jedem gepackten Dezimaloperanden addiert, um in effektiver Weise jene gepackten Dezimaloperanden in hexadezimale Operanden zu konvertieren, in welchen die Vier-Bitblocks numerische Werte zwischen Sechs und Fünfzehn enthalten, nicht wie im Originalbereich zwischen Null und Neun. MULT 2014 führt dann arithmetische Operationen an jenen transformierten Operanden durch und entdeckt und speichert Information darüber ab, welche vier Bitzeichen dieser Operanden durch Übertrag während der arithmetischen Operationen entstanden sind. In einem letzten Schritt wird das Zwischenergebnis, welches resultiert aus der Vollendung jener arithmetischen Operationen auf jenen transformierten Operanden zu gepacktem Dezimalformat zurückkonvertiert, indem die hexadezimalen Sechsen von jenen Zeichen abgezogen werden, die durch Übertrag entstanden sind. EU 122 konvertiert praktisch gepackte Dezimaloperanden in Übertrag-Sechs-Operanden, führt arithmetische Operationen an jenen Übertrag-Sechs-Operanden aus und verwandelt die Übertrag-Sechs-Ergebnisse von solchen Operationen zurück in gepacktes Dezimalformat.
Letztlich steuert FU 120, wie vorher beschrieben, den Transfer der arithmetischen Ergebnisse von EU 122 zu MEM 112. Dabei generiert FU 120 einen logischen Beschreiber, der die Größe des MEM 112-Adreßraums beschreibt, oder erzeugt einen Container, in den jenes Ergebnis transferiert werden soll. Bei bestimmten arithmetischen Operationen, z. B. Ganzzahloperationen, kann ein arithmetisches Ergebnis größer sein als angenommen und mehr Bits enthalten als der MEM 112-Container. Die Ablauflogik der Prüfung der Containergröße (CSC) 2052 vergleicht die aktuelle Größe des arithmetischen Ergebnisses und die L-Felder des logischen Beschreibers des MEM 112-Containers. CSC 2052 erzeugt einen Output, der anzeigt, ob der MEM 112-Container kleiner ist als ein arithmetisches Ergebnis.
Nachdem nun in Kürze bestimmte Eigenschaften der Struktur und des Betriebs von CS 101 im obigen Überblick beschrieben worden sind, werden diese und andere Eigenschaften des CS 101 nun eingehender beschrieben in einer detaillierteren Einführung zur Struktur und zum Betrieb des CS 101. Dann werden in weiteren Beschreibungen diese und andere Eigenschaften des Betriebs und der Struktur des CS 101 in größerer Tiefe beschrieben werden.

1. Einführung (Fig. 101 bis 110)

A. Allgemeine Struktur und Betrieb (Fig. 101)

a) Allgemeine Struktur

In Fig. 101 wird ein Ausschnittblockdiagramm des Computersystems (CS) 10110 gezeigt. Die Hauptelemente von CS 10110 sind der Zweikanalspeicher (MEM) 10112, der Jobprozessor (JP) 10114, das Input-Output-System (IOS) 10116 und der Diagnoseprozessor (DP) 10118. JP 10114 beinhaltet eine Zugriffseinheit (FU) 10120 und eine Ausführungseinheit (EU) 10122.
Betrachten wir zunächst IOS 10116, so ist IOS 10116 verbunden mit den externen Geräten (ED) 10124 durch den Input-Output (I/O) Bus 10126. ED 10124 kann z. B. andere Computersysteme, Tastatur- oder Bildschirmeinheiten oder Festplattenspeicher enthalten. IOS 10116 ist verbunden mit dem Speicher Input-Output (MIO)-Kanal 10128 von MEM 10112 durch den Speicher Input-Output-Bus 10130 und den Speicher Input-Output (MIO)- Bus 10129 und mit FU 10120 über den Eingabe/Ausgabe-Jobprozessor (IOJP)-Bus 10132. DP 10118 ist verbunden z. B. mit externen Tastatur-CRP oder Bildschirmeinheiten (DU) 10134 durch den Diagnoseprozessor Input-Output-Bus (DPIO) 10136. DP 10118 ist mit IOS 10116 verbunden, MEM 10112, FU 10120 und EU 10122 durch den Diagnoseprozessor (DP)-Bus 10138.
Der Speicherkanal zum Jobprozessor (MJP) 10140 des Speichers 10112 ist mit FU 10120 und EU 10122 über den Jobprozessor-Datenbus (JPD) 10142 verbunden. Eine Ausgabe von MJP 10140 ist verbunden mit den Eingaben von FU 10120 und EU 10122 über den Speicher-Ausgabedaten-Bus (MOD) 10144. Eine Ausgabe des FU 10120 ist mit einer Eingabe an MJP 10140 über den physikalischen Beschreiberbus (PD) 10146 verbunden. FU 10120 und EU 10122 sind miteinander verbunden über den Zugriffs- und Ausführungsbus (F/E) 10148.

b) Allgemeiner Betrieb

Wie weiter unten besprochen werden wird, operieren IOS 10116 und MEM 10112 unabhängig unter der allgemeinen Kontrolle von JP 10114 bei der Ausführung von vierlei Benutzerprogrammen. In dieser Hinsicht ist MEM 10112 ein intelligenter, prioritisierender Speicher, der getrennte und unabhängige Kanäle MIO 10128 und MJP 10140 zu IOS 10116 respektive JP 10114 besitzt. MEM 10112 ist der Hauptpfad für Informationstransfer zwischen den externen Geräten 10124 (über IOS 10116) und JP 10114. MEM 10112 arbeitet daher sowohl als Puffer für das Empfangen und Speichern verschiedener individueller Benutzerprogramme (z. B. Daten, Befehle und Ergebnisse von Programmausführungen) und als Hauptspeicher für JP 10114.
Eine Hauptfunktion des IOS 10116 ist, Eingabe/Ausgabe-Puffer zwischen CS 10110 und ED 10124 zu sein. Daten und Befehle werden von ED 10124 zu IOS 10116 über den I/O- Bus 10126 transferiert in einer Weise und einem Format, welches kompatibel ist zu ED 10124. IOS 10116 erhält und speichert diese Information und bringt die Information in Formate, die geeignet sind für den Transfer zu MEM 10112. Darauf zeigt IOS 10116 MEM 10112 an, daß neue Information für den Transfer zu MEM 10112 verfügbar ist. Über die Bestätigung von MEM 10112 wird diese Information nach MEM 10112 über den IOM-Bus 10130 und den MIO-Kanal 10128 transferiert. MEM 10112 speichert die Information in gewählten Bereichen des physikalischen Adreßraums von MEM 10112. Jetzt macht IOS 10116 JP 10114 darauf aufmerksam, daß neue Information in MEM 10112 vorhanden ist, indem es ein "semaphore"-Signal zu FU 10120 über den IOJP-Bus 10132 bereit stellt. Wie später beschrieben werden wird, bringt CS 10110 die Daten und Befehle, die in mEM 10112 gespeichert sind, in bestimmte Informationsstrukturen, die in laufenden Benutzerprogrammen benutzt werden. Unter diesen Strukturen sind bestimmte Strukturen, die später besprochen werden, die von CS 10110 benutzt werden, um den Fluß und die Ausführung von Benutzerprogrammen zu organisieren und zu steuern.
FU 10120 und EU 10122 sind unabhängig operierende mikrocodegesteuerte "Maschinen", die beide die CS 10110 Mikromaschine umfassen, um Benutzerprogramme auszuführen, die in MEM 10112 gespeichert sind. Unter den Hauptfunktionen von FU 10120 sind (1) Zugreifen und Interpretieren auf Instruktionen und Daten von MEM 10112 für den Gebrauch von FU 10120 und EU 10122; (2) die Organisation und Steuerung des Flusses von Benutzerprogrammen; (3) das Initiieren von EU 10122-Operationen; (4) arithmetische und logische Operationen auf Daten auszuführen; (5) den Datentransfer von FU 10120 und EU 10122 nach MEM 10112 zu steuern; und (6) die Aufrechterhaltung von bestimmten Stapelspeichern und Registermechanismen, die weiter unten beschrieben werden. Die Zwischenspeichermechanismen von FU 120120, die auch weiter unten beschrieben werden, sollen die Betriebsgeschwindigkeit von JP 10114 steigern. Diese Zwischenspeichermechanismen enthalten Beschleunigungsschaltlogik und teilweise Hochgeschwindigkeitsspeicher, um Kopien von ausgewählter Information, die in MEM 10112 gespeichert war, zu speichern. Die Information, die in dieser Beschleunigungsschaltlogik gespeichert ist, ist daher schneller für W 10114 verfügbar. EU 10122 ist eine arithmetische Einheit, die imstande ist, Ganzzahl, Dezimal- oder Gleitkommazahl arithmetische Operationen auszuführen. Die Hauptfunktion von EU 10122 ist es, FU 10120 von bestimmten extensiven arithmetischen Operationen zu entbinden, um so die Effektivität von CS 10110 zu steigern.
Allgemein werden Operationen in JP 10114 auf Speicher zur Speicherbasis durchgeführt; Daten werden gelesen von MEM 10112, sie werden manipuliert und die Ergebnisse werden zu MEM 10112 zurückgebracht. In dieser Hinsicht arbeiten bestimmte Stapelspeicher- und Zwischenspeichermechanismen in JP 10114 (später beschrieben) als Erweiterungen für den Adreßraum von 10112.
Während des Betriebes liest FU 10120 Daten und Befehle von MEM 10112, indem es physikalische Adressen MEM 10112 über den PA-Bus 10146 und MJP-Kanal 10140 zur Verfügung stellt. Die Befehle und Daten werden zu FU 10120 transferiert und zu EU 10122 über den MJP-Kanal 10140 und MOD-Bus 10144. Die Befehle werden von der FU 10120 Mikrocodeschaltlogik interpretiert, was nicht in Fig. 101 gezeigt wird, aber weiter unten beschrieben, und falls notwendig, werden die MikrotodebefehIe EU 10122 von FU 10120's Mikrocodesteuerung über den FE-Bus 10148 oder über den JPD-Bus 10142 zur Verfügung gestellt.
Wie oben festgestellt, arbeiten FU 10120 und EU 10122 asynchron mit gegenseitiger Rücksichtnahme auf die jeweiligen Funktionen. Ein Mikrobefehl der FU 10120 Mikrocodeschaltlogik zu EU 10122 kann eine ausgewählte Operation von EU 10122 initiieren. EU 10122 kann dann daran gehen, diese ausgewählte Operation unabhängig auszufahren. FU 10120 kann weiterarbeiten, um gleichzeitig andere Operationen durchzuführen, während EU 10122 die gewählte arithmetische Operation vollendet. Wenn diese zu Ende ist, signalisiert EU 10122 der FU 10120, daß das Operationsergebnis verfügbar ist, und zwar mittels eines "Händeschüttelsignals" über den FE-Bus 10148. FU 10120 kann dann die Ergebnisse der arithmetischen Operationen für weitere Verarbeitung oder, wie momentan besprochen, kann die Resultate der arithmetischen Operation direkt zu MEM 10112 transferieren. Wie weiter unten beschrieben, erlaubt ein Befehlsspeicher, der als Warteschlange zwischen FU 10120 und EU 10122 bezeichnet wird, erlaubt FU 10120 eine Abfolge von arithmetischen Operationen, die von EU 10122 ausgeführt werden sollen, zuzuordnen.
Die Information wie z. B. Ergebnisse einer Befehlsabarbeitung werden von FU 10120 oder EU 10122 nach MEM 10112 geschrieben über den JPD-Bus 10142. FU 10120 stellt MEM 10112 über den PA-Bus 10146 und den MJP-Kanal 10140 ein "physikalisches Schreibadressen"-Signal zur Verfügung. Gleichzeitig wird die Information, die nach MEM 10112 geschrieben werden soll, auf den JPD-Bus 10142 gesetzt und wird darauf folgend in MEM 10112 geschrieben an den Stellen, die durch die physikalischen Schreibadressen gewählt wurden.
FU 10120 gibt ein semaphore-Signal an IOJP-Bus 10132, um IOS 10116 zu signalisieren, daß die Information wie z. B. die Ergebnisse der Ausführung eines Benutzerprogrammes zur Verfügung stehen, um aus CS 10110 gelesen zu werden. IOS 10116 kann dann die Information von MEM 10112 zu IOS 10116 über MJO-Kanal 10128 und IOM-Bus 10130 transferieren. Die Information, die in IOS 10116 gespeichert ist, wird dann nach ED 10124 über den I/O-Bus 10126 transferiert.
Während der Ausführung eines Benutzerprogrammes kann eine bestimmte Information, die von JP 10116 benötigt wird, nicht in MEM 10112 verfügbar sein. In solchen Fällen kann, wie in der folgenden Diskussion weiter beschrieben wird, JP 10114 eine Informationsanforderung an MEM 10112 schicken und IOS 10116 über den IOJP-Bus 10132 mitteilen, daß eine solche Anforderung gemacht wurde. IOS 10116 wird dann die Anforderung lesen und die gewünschte Information von ED 10124 über IOS 10116 nach MEM 10112 in der oben beschriebenen Weise transferieren. Bei solchen Operationen arbeiten IOS 10116 und JP 10114 als Speichermanager zusammen, wobei der von JP 10114 adressierbare Speicherplatz virtueller Speicherplatz genannt wird, und er schließt den MEM 101 12-Speicherplatz und auch alle externen Geräte ein, zu denen IOS 10116 Zugang besitzt.
Wie früher beschrieben, stellt DP 10118 eine zweite Schnittstelle zwischen Computersystem 10110 und der externen Welt über den DPIO-Bus 10136 zur Verfügung. DP 10118 erlaubt es DU 10134, z. B. ein CRT oder eine Tastatureinheit oder ein Fernschreiber, alle Funktionen, die normalerweise von einer Konsole (d. h. mit Schaltern und Lämpchen) zur Verfügung gestellt werden, auszuführen. Zum Beispiel erlaubt es DP 10118 der DU 10134 für Zwecke wie Systeminitialisierung und Start, Ausführung von diagnostischen Prozessen und Fehlerüberwachung und Fehleridentifizierung, die Kontrolle auszuüben. DP 10118 hat Schreib- und Lesezugang zu den meisten Speicherbereichen innerhalb von IOS 10116, MEM 10112, FU 10120 und EU 10122 über den DP-Bus 10138. Die Speicher und Register in CS 10110 können daher direkt während des Systemstarts geladen oder initialisiert werden und können direkt gelesen oder geladen werden mit Test- oder Diagnosesignalen für die Fehlerüberwachung und Fehleridentifizierung. Wie weiter unten beschrieben wird, können Mikrobefehle in JP 10114's Mikrocodeschaltlogik beim Systemstart oder wie angefordert geladen werden.
Nachdem nun die allgemeine Struktur und der allgemeine Betrieb des Computersystems 10110 beschrieben worden sind, werden nun bestimmte Merkmale des Computersystems 10110 im folgenden kurz beschrieben werden, um beim Verständnis für die folgenden, ins Genauere gehenden Beschreibungen dieser oder anderer Merkmale des Computersystems 10110 behilflich zu sein.

c) Definition von bestimmten Ausdrücken

In der folgenden Diskussion werden bestimmte Ausdrücke benutzt, die sich auf die Struktur und den Betrieb des CS 10110 beziehen. Manche dieser Ausdrücke werden zuerst besprochen und definiert werden, um für das Verständnis der folgenden Beschreibungen behilflich zu sein. Andere Ausdrücke werden dann eingeführt, wenn sie für die folgende Beschreibung gebraucht werden.
Eine Prozedur ist eine Folge von Arbeitsschritten oder Befehlen, die ausgeführt werden, um eine bestimmte Operation durchzuführen. Eine Prozedur kann die Daten, mit denen während der Durchführung der Operation gearbeitet werden, mit einschließen.
Ein Programm ist eine statische Gruppe von einer oder mehreren Prozeduren. Allgemein kann man Programme klassifizieren in Benutzerprogramme, Utility-Programme und Betriebssystemprogramme. Ein Benutzerprogramm ist eine Gruppe von Prozeduren, die von einem bestimmten Benutzer einer Benutzergruppe erzeugt wurden und ihm angehören, kommunizierend mit CS 10110. Utility-Programme sind normalerweise allen Benutzern verfügbar; z. B. umfaßt ein Compiler eine Menge von Prozeduren, um ein Programm in einer Benutzersprache in ein Programm in einer S-Sprache zu kompilieren. Die Betriebssystemprogramme sind Gruppen von Prozeduren innerhalb CS 10110 für die Allocation und Steuerung der CS 10110-Ressourcen. Betriebssystemprogramme definieren auch Schnittstellen innerhalb CS 10110. Zum Beispiel werden, wie weiter unten beschrieben werden wird, alle Operanden in einem Programm mit "NAME" bezeichnet. Ein Betriebssystemprogramm übersetzt den Operandenname in die physikalischen Stellen der Operanden in MEM 10112. Das Übersetzungsprogramm für NAME definiert so die Schnittstelle zwischen dem Operandenname (Platzadresse von NAME) und den physikalischen Adressen von MEM 10112.
Ein Prozeß ist ein unabhängiger Steuerungsort, der sich durch physikalische, logische oder virtuelle Adreßräume bewegt oder insbesondere ein Ausführungspfad durch eine Reihe von Programmen (d. h. Prozeduren). Ein Prozeß wird im allgemeinen ein Benutzerprogramm und Daten beinhalten, dazu ein oder mehrere Utility-Programme (d. h. ein Compiler) und Betriebssystemprogramme, die nötig sind, um das Benutzerprogramm durchzuführen.
Ein Objekt ist ein eindeutig identifizierbarer Bereich des "Datenraums", zu dem CS 10110 Zugang hat. Ein Objekt kann als Behälter für Informationen angesehen werden oder kann Daten oder Prozedurinformationen oder beides enthalten. Ein Objekt kann z. B. ein vollständiges Programm enthalten oder einen Satz von Prozeduren oder ein einziges Datenbit. Die Objekte müssen nicht zusammenhängend im Datenraum, der CS 10110 zur Verfügung steht, lokalisiert werden und die Information, die in einem Objekt enthalten ist, muß nicht zusammenhängend in diesem Objekt plaziert sein.
Ein Bereich ist ein Betriebszustand von CS 10110 für die Anwendungsfalle von CS 10110's Schutzmechanismen. Jeder Bereich wird definiert durch einen Satz von Prozeduren, die für ihre Ausführung Zugang haben zu Objekten innerhalb dieses Bereichs. Jedes Objekt hat einen einzigen Ausführungsbereich, in dem es ausgeführt wird, falls es ein Prozedurobjekt ist, oder genutzt wird, falls es ein Datenobjekt ist. Man sagt, CS 10110 operiert in einem bestimmten Bereich, wenn es eine Prozedur ausführt, die diesen Ausführungsbereich hat. Jedes Objekt kann zu einem oder mehreren Bereichen gehören; ein Objekt gehört zu einem Bereich, wenn eine Prozedur, die in diesem Bereich ausführt, möglicherweise Zugang zu diesem Objekt hat. CS 10110 kann z. B. vier Bereiche haben: Benutzerbereich, Datenbankmanagementsystem (DBMS)-bereich, erweiterter Betriebssystembereich (EOS) und den Bereich des Betriebssystemkerns (KOS). Der Benutzerbereich ist der Bereich der Ausführung aller dem Benutzer zur Verfügung gestellten Prozeduren wie Benutzer- oder Utility-Prozeduren. Der DBMS-Bereich ist der Bereich der Ausführung für Betriebssystemprozeduren, die Daten speichern, nach ihnen suchen oder verwalten. Der EOS-Bereich ist der Bereich der Ausführung von Betriebssystemprozeduren, der die Schnittstelle mit CS 10110 auf Benutzerebene definiert und gestaltet wie z. B. Prozeduren zur Steuerung und Ausführung von Dateien, Prozessen und Eingabe/Ausgabeoperationen. Der KOS-Bereich ist der Bereich der Ausführung des Sicherheitsbetriebssystems auf unterer Ebene, der die physikalischen Ressourcen von CS 10110 verwaltet und steuert. Andere Verkörperungen von CS 10110 können weniger oder mehr Bereiche haben als eben beschrieben wurde. Zum Beispiel können DBMS-Prozeduren in den EOS- Bereich inkorporiert sein oder der EOS-Bereich kann dadurch, daß er Ein- und Ausgabeprozeduren beinhaltet, unterteilt sein in Ein- und Ausgabebereich. Es gibt keine Hardwarebegrenzung für die Anzahl von Grenzen zwischen Bereichen in CS 10110. Bestimmte CS 10110-Hardwarefunktionen und Strukturen sind jedoch abhängig von Bereichen.
Ein Subjekt wird für die Anwendungsfälle der CS 10110-Schutzmechanismen definiert als Kombination der gegenwärtigen Betriebsart (Benutzer), des gerade ausgeführten Prozesses und des Bereichs, in dem der Prozeß gerade ausgeführt wird. Zusätzlich zur Betriebsart Prozeß und Bereich, die durch UIDs identifiziert werden, kann das Subjekt ein Kennzeichen enthalten, welches ein einem Benutzer zugeordneter Identifikationscode ist und dort benötigt wird, wo zusätzliche Sicherheit verlangt ist. Bei einem gegebenen Prozeß bleiben Betriebsart und Prozeß konstant, aber der Bereich wird durch die Prozedur bestimmt, die gegenwärtig ausgeführt wird. Ein Subjekt, welches mit einem Prozeß assoziiert ist, ist daher variabel längs des Ausführungspfades des Prozesses.
Nachdem wir die oberen Ausdrücke besprochen und definiert haben, werden nun bestimmte Merkmale von CS 10110 kurz beschrieben.

d) Mehrprogrammbetrieb

CS 10110 ist dazu imstande, gleichzeitig zwei oder mehr Programme auszuführen und die Abfolge der Programmausführung so zu wählen, daß die Ressourcen von CS 10110 optimal ausgenutzt werden. Dies bezeichnen wir als Mehrfachprogrammierung. In dieser Hinsicht kann CS 10110 zeitweise die Ausführung eines Programmes stoppen, z. B. wenn eine Ressource oder eine bestimmte Information, die für jenes Programm erforderlich ist, nicht sofort verfügbar ist, und kann damit fortfahren, ein anderes Programm auszuführen, solange, bis die angeforderte Ressource oder Information verfügbar ist. Zum Beispiel sei eine bestimmte Information, die von einem ersten Programm angefordert wird, in MEM 10112 nicht verfügbar, wenn sie aufgerufen wird. JP 10114 kann, wie weiter beschrieben werden wird, die Ausführung dieses ersten Programmes stoppen, eine Anforderung für diese Information an IOS 10116 transferieren und damit fortfahren, ein zweites Programm aufzurufen und auszuführen. IOS 10116 würde auf die angeforderte Information von ED 10124 zugreifen und sie zu MEM 10112 transferieren. Einige Zeit, nachdem IOS 10116 JP 10114 signalisiert hat, daß die angeforderte Information verfügbar ist in MEM 10112, könnte JP 10114 die Ausführung des zweiten Programmes stoppen und die Ausführung des ersten Programmes wieder aufnehmen.

e) Mehrsprachenbetrieb

Wie früher beschrieben, ist CS 10110 eine Mehrsprachenmaschine. Jedes Programm, welches in einer Benutzersprache einer höheren Ebene geschrieben ist wie COBOL oder FORTRAN wird in ein entsprechendes Soft (S)-Sprachenprogramm kompiliert. Das bedeutet, daß bei konventionellen Computersystemen jede höhere Sprache eine entsprechende Maschinensprache besitzt, die klassisch definiert ist als Assembler-Sprache. Im Gegensatz zu klassischen Assembler-Sprachen sind S-Sprachen Sprachen mittlerer Ebene, in denen jeder Befehl der höheren Programmiersprache durch zwei oder drei S-Sprachen- Instruktionen ersetzt wird, die wir bezeichnen als SINs. Bestimmte SINs können von zwei oder mehr höheren Programmiersprachen gleichermaßen benutzt werden. CS 10110 stellt für jede S-Sprache, wie in den folgenden Diskussionen besprochen werden wird, einen Satz oder Dialekt von Mikrocodeinstruktionen (S-Interpretern) zur Verfügung. Die S- Interpreter interpretieren die SINs und stellen entsprechende Abfolgen von Mikroinstruktionen für die detaillierte Steuerung des CS 10110 zur Verfügung. Der Befehlsschatz und Betrieb von CS 10110 kann daher auf jedes Benutzerprogramm zugeschnitten werden, ohne Rücksicht auf eine spezielle Benutzersprache, so daß es am effizientesten das Benutzerprogramm ausführen kann. Das Computersystem 10110 kann z. B. FORTRAN- und COBOL-Programme mit vergleichbarer Effizienz ausführen. Darüber hinaus kann ein Benutzer ein Programm in mehr als einer höheren Programmiersprache schreiben, ohne dabei an Effizienz zu verlieren. Zum Beispiel kann ein Benutzer einen Teil seines Programmes in COBOL schreiben, aber er möchte bestimmte Bereiche des Programmes in FORTRAN schreiben. In solchen Fällen würden die COBOL-Bereiche in COBOL-SINs kompiliert werden und mit dem COBOL-Dialekt-S-Interpreter ausgeführt werden. Die FORTRAN-Bereiche würden in FORTRAN-SINs kompiliert werden und mit dem FORTRAN-Dialekt-S-Interpreter ausgeführt werden. Die gegenwärtige Verkörperung von CS 10110 benutzt ein einheitliches Format für alle SINs. Dieses Merkmal erlaubt einfachere S-Interpreter-Strukturen und steigert die Effektivität der SIN-Interpretation, weil es nicht notwendig ist, daß für jeden Dialekt extra Mittel zu seiner Interpretation zur Verfügung gestellt werden müssen.

f) Adressierungsstrukturen

Jedem Objekt, das für den Gebrauch in oder von einer CS 10110-Operation erzeugt wurde, wird permanent ein eindeutiger Identifizierer (UID) zugeordnet. Die UID eines Objekts erlaubt, daß jenes Objekt jederzeit eindeutig identifiziert und lokalisiert werden kann, unabhängig davon, von welcher speziellen CS 10110 es erzeugt wurde oder wo es darauf hinplaziert wurde. So wird jedesmal, wenn ein neues Objekt definiert wird, eine neue und eindeutige UID allokiert sowie Sozialversicherungsnummern den Individuen zugeordnet werden. Eine bestimmte Teilinformation, die in einem Objekt enthalten ist, kann durch eine logische Adresse lokalisiert werden, die die UID des Objektes, den Abstand vom Anfang des Objektes zu dem ersten Bit des Segmentes und die Länge (Anzahl der Bits) des Informationssegmentes umfaßt. Daten innerhalb eines Objektes können daher mit Bit-Genauigkeit adressiert werden. Wie in den folgenden Diskussionen weiter beschrieben werden wird, werden die UIDs innerhalb CS 10110 als logische Adressen benutzt und z. B. als Zeiger. Logisch gesehen sind alle Adressen und Zeiger in CS 10110 UID-Adressen und -Zeiger. Wie schon früher und auch weiter unten beschrieben, werden kurze zeitweise eindeutige Identifizierer, die nur innerhalb JP 10114 Gültigkeit besitzen und die wir als aktive Objektnummern bezeichnen, innerhalb JP 10114 benutzt, um die Adreßbusbreite und den Umfang der zu verwaltenden Adreßinformationen zu reduzieren.
Ein Objekt wird in CS 10110 aktiv, wenn es vom Zusatzspeicher CED 10124 zu MEM 10112 transferiert wird, um einen Prozeß auszuführen. Zu dieser Zeit wird jedem solchen Objekt eine aktive Objektnummer (AON) zugeordnet. Die AONs sind kurze eindeutige Identifizierer und beziehen sich auf die UID eines Objekts über bestimmte CS 10110- Informationsstrukturen, die unten beschrieben werden. Die AONs werden nur innerhalb JP 10114 benutzt und werden dort statt UIDs benutzt, um die erforderliche Adreßbusbreite von JP 10114 und den Adreßdatenumfang, mit denen JP 10114 umgeht, zu reduzieren. So wie bei logischen Adressen von UIDs, kann ein Datenstück in einem Objekt adressiert werden durch eine Bit-genaue, AON-logische Adresse, die die AON des Objektes, den Abstand vom Beginn des Objekts zum ersten Bit des Datenstückes und die Länge des Datenstückes umfaßt.
Der Transfer von logischen Adressen, z. B. Zeigern zwischen MEM 10112 (UIDA) und JP 10114 (AONs), erfordert während der Ausführung eines Prozesses Übersetzungen zwischen UIDs und AONs. Wie später besprochen werden wird, erfolgt diese Übersetzung teilweise durch die Informationsstrukturen, die oben erwähnt wurden. In ähnlicher Weise erfolgt die Übersetzung von logischen Adressen zu physikalischen Adressen in MEM 10112 zur physikalischen Zugangsinformation, die in MEM 10112 gespeichert ist, durch CS 10110-Informationsstrukturen, die die logischen Adressen der AONs auf physikalische Adressen von MEM 10112 beziehen.
Jedem Operanden, der in einem Programm auftaucht, wird, wenn das Programm kompiliert wird, ein Name zugeordnet. Danach geschieht jede Bezugnahme auf diese Operanden über die zugeordneten Namen. Wie später genauer beschrieben werden wird, enthält die Adressierungsstruktur von CS 10110 einen Mechanismus, die Namen zu erkennen, wie sie im Befehlsstrom erscheinen, und Namenstabellen, die Anleitungen enthalten, um Namen zu AON-logischen Adressen aufzulösen. Die AON-logischen Adressen können dann ausgewertet werden, z. B. übersetzt werden in MEM 10112's physikalische Adressen, um aktuelle Operanden zur Verfügung zu stellen. Der Gebrauch von Namen, um Operanden im Befehlsstrom (Prozeß) zu identifizieren, erlaubt, (1) daß eine komplizierte Adresse durch eine einfache Referenz einheitlichen Formats ersetzt wird, (2) erfordert nicht, daß eine Operation direkt vom Datentyp im Befehlsstrom definiert wird, (3) erlaubt, daß wiederholte Referenzen zu einem Operanden in einem Befehlsstrom gemacht werden können, indem man nur den Namen des Operanden wiederholt, und (4) erlaubt, daß teilweise fertiggestellte Namen nach Adresse-Übersetzungen in einem Zwischenspeicher abgespeichert werden können, um die Operandenreferenzen zu beschleunigen. Der Gebrauch von Namen reduziert dabei das benötigte Informationsvolumen im Befehlsstrom für die Operandenreferenzen beträchtlich und erhöht die Geschwindigkeit und Wirksamkeit des CS 10110, indem es die Operandenreferenzen durch einen zugrunde liegenden parallel arbeitenden Mechanismus ausführt.
Schließlich enthält die CS 10110 Adressenstruktur einen Satz von architektonischen Basiszeigern (ABPs) für jeden Prozeß. Die ABPs stellen ein Adressierungsrahmenwerk zur Verfügung, um Daten und Prozedurinformationen, die zu einem Prozeß gehören und z. B. dazu benutzt werden, Namen zu AON-logischen Adressen aufzulösen, zu lokalisieren.

g) Schutzmechanismen

Der Schutzmechanismus von CS 10110 ist konstruiert, um einen Benutzer daran zu hindern (1) Zugang zu dem Prozeß eines anderen Benutzers zu erlangen oder ihn zu stören, einschließlich der Daten, und (2) den Betrieb des CS 10110 zu stören oder zu unterminieren. Die Zugangsrechte zu jedem speziellen aktiven Objekt werden dynamisch als eine Funktion des gegenwärtigen aktiven Subjekts zugeteilt. Ein Subjekt ist definiert als eine Kombination des gegenwärtigen Betriebszustandes (Benutzer), des gegenwärtigen gerade ausgeführten Prozesses und des Bereichs, in dem der Prozeß gegenwärtig ausgeführt wird. Zusätzlich zu Betriebsart, Prozeß und Bereich kann das Subjekt ein Kennzeichen enthalten, das ein Identifikationscode ist, der dem Benutzer zugeordnet ist, wo zusätzliche Sicherheit erforderlich ist. Bei einem gegebenen Prozeß sind die Betriebsart und der Prozeß konstant, aber der Bereich wird von der gerade ausgeführten Prozedur bestimmt. Das mit dem Prozeß assoziierte Subjekt ist daher variabel entlang des Ausführungspfades des Prozesses.
In einer gegenwärtigen Verkörperung des CS 10110 haben Prozeduren, die einen KOS- Bereich besitzen, Zugang zu Objekten in KOS, EOS, DBMS und den User-Bereichen. Prozeduren, die einen EOS-Ausführungsbereich haben, haben Zugang-zu Objekten in EOS, DBMS und User-Bereichen. Prozeduren, die einen DBMS-Ausführungsbereich haben, haben Zugang zu Objekten in DBMS und User-Bereichen. Prozeduren, die einen Benutzer-Ausführungsbereich besitzen, haben Zugang nur zu Objekten im User-Bereich. Ein Benutzer kann daher nicht Zugang zu Objekten gewinnen, die im KOS-Ausführungsbereich liegen und kann nicht Einfluß nehmen auf das Sicherheitsbetriebssystem niedriger Ebene von CS 10110. Der Prozeß des Benutzers kann jedoch eine Prozedur zur Ausführung rufen, die einen KOS-Ausführungsbereich hat. An diesem Punkt ist das Subjekt des Prozesses im KOS-Bereich und die Prozedur wird Zugang haben zu bestimmten Objekten im KOS-Bereich.
In einer gegenwärtigen Verkörperung des CS 10110, die auch in weiteren Diskussionen beschrieben wird, hat jedes Objekt eine Zugangskontroll-Liste (ACL), die mit ihm assoziiert ist. Eine ACL enthält für jedes Subjekt, welches Zugang zu diesem Objekt hat, einen Zugangskontrolleingang (ACE). Die ACEs spezifizieren für jedes Subjekt die Zugangsrechte, die ein Subjekt bezüglich jenes Objektes besitzt.
Es gibt normalerweise keine Beziehungen zwischen Subjekten und Objekten, die anders definiert sind als die in der ACL eines Objekts. CS 10110 unterstützt jedoch Objekte erweiterten Typs, die erweiterte ACLs besitzen, in denen ein Benutzer spezifisch definieren kann, welche Subjekte welche Zugangsrechte zu dem Objekt besitzen.
In einer anderen Verkörperung von CS 10110, die in der folgenden Diskussion beschrieben wird, werden die Zugangsrechte auf einer dynamischen Basis zugeteilt. Bei der Ausführung eines Prozesses kann eine Prozedur eine zweite Prozedur aufrufen und ein Argument zu dieser gerufenen Prozedur übergeben. Die aufrufende Prozedur kann auch ausgewählte Zugangsrechte für dieses Argument der gerufenen Prozedur übergeben. Die übergebenen Zugangsrechte existieren nur für die Dauer des Aufrufs.
In der Verkörperung des dynamischen Zugriffs werden Zugangsrechte nur dann zugeteilt, wenn es erforderlich ist. In der ACL-Verkörperung werden Zugangsrechte auf die Generierung von Objekten oder auf bestimmte Anforderungen zugeteilt. In jeder Verkörperung hat jede Prozedur, zu der Argumente in einem bereichsübergreifenden Aufruf übergeben werden können, einen Zugangsinformationsvektor (AIA), der mit ihr verbunden ist. Der AIA einer Prozedur stellt fest, welche Zugangsrechte eine rufende Prozedur (Subjekt) haben muß, bevor die gerufene Prozedur mit den übergebenen Argumenten arbeiten kann. Die Schutzmechanismen von CS 10110 vergleichen die Zugangsrechte der rufenden Prozedur mit den Zugangsrechten, die erforderlich sind, die gerufene Prozedur auszuführen. Dies garantiert, daß eine rufende Prozedur eine gerufene Prozedur nicht beauftragen darf etwas zu tun, was der rufenden Prozedur nicht erlaubt ist zu tun. Eine rufende Prozedur kann praktisch an die gerufene Prozedur nur die Zugangsrechte übergeben, die sie selbst besitzt. Nachdem die allgemeine Struktur und der Betrieb und bestimmte Merkmale des CS 10110 beschrieben sind, werden nun jene und andere Merkmale des Betriebs von CS 10110 mehr im Detail besprochen werden.

B. Die Informationsstrukturen und Mechanismen des Computersystems 10110 (Fig. 102, 103, 194, 105)

CS 10110 enthält bestimmte Informationsstrukturen und Mechanismen, die bei der effizienten Ausführung von Prozessen behilflich sind. Diese Strukturen und Mechanismen kann man in drei allgemeine Typen einteilen. Der erste Typ betrifft die Prozesse selbst, d. h. Prozedur und Datenobjekte, die den Benutzerprozeß umfassen oder direkt mit der Ausführung eines Benutzerprozesses verbunden sind. Der zweite Typ steht für Management, Kontrolle und Ausführung von Prozessen. Diese Strukturen sind allgemeiner Weise allen in CS 10110 aktiven Prozessen gemeinsam. Der dritte Typ sind CS 10110-Mikromaschinen-Informationsstrukturen und -mechanismen. Diese Strukturen steuern den internen Betrieb der CS 10110 Mikromaschine und sind ihr eigen.

a) Einführung (Fig. 102)

In Fig. 102 wird eine bildliche Darstellung des CS 10110 (MEM 10112, FU 10120 und EU 10122) gezeigt, in der bestimmte Informationsstrukturen und Mechanismen dargestellt werden. Es sollte verstanden werden, daß diese Informationsstrukturen und Mechanismen über die Grenzen zwischen MEM 10112, FU 10120, EU 10122 und IOS 10116 hinwegschreiten. Die Prozeßstrukturen 10210 im oberen Bereich von Fig. 103 enthalten jene Informationsstrukturen und Mechanismen, die in sehr engem Kontakt mit den Individualprozessen des ersten und dritten Typs von Informationsstrukturen, die oben beschrieben sind, stehen. Die Prozeßstrukturen 10210 sind in MEM 10112 angesiedelt und die virtuellen Prozesse 10212 beinhalten die virtuellen Prozesse (VP) 1 bis N. Die virtuellen Prozesse 10212 können in einer gegenwärtigen Verkörperung von CS 10110 bis zu 256 VPs enthalten. Wie früher beschrieben, enthält jedes VP bestimmte Objekte, die für einen einzelnen Benutzerprozeß spezifisch sind, z. B. Stapelspeicherobjekte, die früher beschrieben wurden und im folgenden weiter beschrieben werden. Jedes VP enthält auch ein Prozeßobjekt, welches bestimmte Informationen enthält, die erforderlich sind, um den Prozeß auszuführen, z. B. Zeiger auf andere Prozeßinformationen.
Die virtuellen Prozessorzustandsblöcke (VPSBs) 10218 beinhalten VPSBs, die bestimmte Tabellen und Mechanismen enthalten, die die Ausführung von VPs verwalten, die von CS 10110 für die Ausführung ausgewählt wurden.
Ein spezieller VP wird in CS 10110 hineingebunden, wenn ein virtueller Prozeßverteiler, der in einer folgenden Diskussion beschrieben wird, jenes VP als für die Ausführung berechtigt auswählt. Das Prozeßobjekt des ausgewählten VP wird, wie vorher beschrieben, in eine VPSB hinübergespeichert. Die VPSBs 10218 können z. B. 16 oder 32 Zustandsblöcke enthalten, so daß CS 10110 gleichzeitig 16 bis 32 VPs ausführen kann. Wenn ein einem VPSB zugeordnetes VP ausgeführt werden soll, so wird der VP auf die Informationsstrukturen und Mechanismen, die in FU 10120 und EU 10122 gezeigt sind, getauscht. Die FU-Register und Stapelspeichermechanismen (FURSM) 10214 und EU-Register und Stapelspeichermechanismen (EURSM) 10216, die in FU 10120 und EU 10122 respektive gezeigt sind, beinhalten Register und Stapelspeichermechanismen, die zur Ausführung von VPs gebraucht werden, die an CS 10110 gebunden sind. Diese Register und Stapelspeichermechanismen werden auch, wie weiter unten diskutiert wird, für bestimmte CS 101 10-Prozeßmanagementfunktionen gebraucht. Die Prozedurobjekte (POs) 10213 enthalten Prozedurobjekte (POs) 1 bis N der Prozesse, die in CS 10110 ausgeführt werden.
Die Adressierungsmechanismen (AM) 10220 sind Teil des CS 10110's Prozeßmanagementsystems und werden allgemeiner Weise mit den Adressierungsfunktionen des Computersystems 10110 assoziiert, wie in der folgenden Diskussion beschrieben wird. Die UID/AON-Tabellen 10222 sind eine Struktur, um UIDs und AONs wie früher beschrieben aufeinander zu beziehen. Die Speichermanagementtabellen 10224 beinhalten Strukturen, um (1) AON-logische Adressen auf MEM 10112-physikalische Adressen zu beziehen; (2) den physikalischen Adreßraum von MEM 10112 zu verwalten; (3) den Informationstransfer zwischen MEM 10112 und CS 10110's Hilfsspeicher (ED 10124) zu verwalten, (4) um Objekte in CS 10110 hineinzuaktivieren; der Namenszwischenspeicher (NC) 10226 und der Adreßübersetzungszwischenspeicher (ATC) 10228 sind Beschleunigungsmechanismen für die Speicherung von Adressierungsinformation, die zu dem VP gehört, welches gerade an CS 10110 gebunden ist. NC 10226, welches weiter unten beschrieben wird, enthält Informationen über die Beziehung zwischen Operandennamen und AON-Adressen. ATC 10228, das auch weiter unten beschrieben wird, enthält Information über die Beziehung zwischen AON-Adressen und MEM 10112-physikalischen Adressen.
Die Schutzmechanismen 10230, die unter AM 10220 gezeichnet sind, beinhalten Schutztabellen 10232 und Schutzzwischenspeicher (PC) 10234. Die Schutztabellen 10232 enthalten Informationen über die Zugangsrechte eines jeden aktiven Objekts in CS 10110.
PC 10234 enthält Schutzinformation über bestimmte Objekte des VP, der gerade an CS 10110 gebunden ist.
Die Mikrobefehlsmechanismen 10236, die unter PM 10230 dargestellt sind, beinhalten Mikrocode (M Code)-Speicher 10238, FU (Mikrocode) M Code-Struktur 10240 und EU Mikrocode (M Code)-Struktur 10242. Diese Strukturen enthalten Mikrobefehlsmechanismen und Tabellen, um SINs zu interpretieren und den genauen Betrieb des CS 10110 zu steuern. Die Mikrobefehlsmechanismen 10232 stellen auch Mikrocodetabellen und Mechanismen zur Verfügung, die teilweise beim Betrieb des Sicherheitsbetriebssystems auf unterer Ebene benötigt werden, welches die physikalischen Ressourcen des CS 10110 steuert.
Nachdem nun bestimmte Informationsstrukturen und Mechanismen des CS 10110 mit Hilfe von Fig. 102 beschrieben wurden, sollen nun in der oben erwähnten Reihenfolge jene Informationsstrukturen und Mechanismen genauer beschrieben werden. Bei diesen Beschreibungen sei angemerkt, daß beim MEM 10112, wie er in Fig. 102 und in anderen Figuren der folgenden Diskussion dargestellt ist, der adressierbare Speicherplatz dargestellt ist. Bestimmte Bereiche des Adreßraums von MEM 10112 wurden so bezeichnet, daß sie bestimmte Informationsstrukturen und Mechanismen enthalten. Diese Strukturen und Mechanismen existieren reell physikalisch in MEM 10112, aber können sowohl an unterschiedlicher Stelle im Adreßraum von MEM 10112 stehen als auch unterschiedliches Volumen besitzen. Indem man diesen Strukturen und Mechanismen die Position eines einzigen großen Speichers zuschreibt, können diese Strukturen und Mechanismen rekonfiguriert werden, so wie es für den effektiven Betrieb des CS 10110 erforderlich ist. In einer alternativen Verkörperung werden physikalisch getrennte Speicher benutzt, um die Strukturen und Mechanismen, die in MEM 10112 abgebildet sind, aufzunehmen, im Gegensatz zu den zugewiesenen Bereichen eines einzelnen Speichers.

b) Prozeßstrukturen 10210 (Fig. 103, 104, 105)

In Fig. 103 wird ein Ausschnitt aus einer schematischen Darstellung von Prozeßstrukturen 10210 gezeigt. Insbesondere zeigt Fig. 103 einen Prozeß (P) 10310, der zur Ausführung selektiert ist, und seine assoziierten Prozedurobjekte (POs) in Prozeßobjekten (POs) 10213. P 10310 ist in Fig. 103 dargestellt, so daß er vier Prozedurobjekte in POs 10213 enthält. Dies soll so verstanden werden, daß diese typische Anordnung der Klarheit der Darstellung dient; ein spezieller P 10310 kann jede beliebige Anzahl von Prozedurobjekten enthalten. Auch der Übersichtlichkeit halber ist EURSM 10216 nicht gezeigt, weil EURSM 10216 ähnlich wie FURSM 10214 ist. EURSM 10216 wird in der folgenden Diskussion der Struktur und des Betriebs von CS 10110 genauer beschrieben werden.
Wie vorher besprochen, enthält jeder Prozeß bestimmte Daten und Prozedurobjekte. Wie in Fig. 103 für P 10310 dargestellt, sitzen die Prozedurobjekte in POs 10213. Die Datenobjekte enthalten statische Datenflächen und Stapelspeichermechanismen in P 10310. Die POs, wie z. B. das Prozedurobjekt von KOS (KOSPO) 10318, enthalten die verschiedenen Prozeduren des Prozesses, wobei jede Prozedur eine Abfolge von SINs ist, die eine Operation, die während der Ausführung des Prozesses ausgeführt werden soll, definiert. Wie weiter unten beschrieben wird, enthalten die Prozedurobjekte auch bestimmte Informationen, die bei der Ausführung der Prozeduren benötigt werden und in ihnen enthalten sind. Statische Datenflächen (SDAs) sind Datenobjekte, die im allgemeinen zur Speicherung von Daten reserviert sind, und die während der Lebensdauer des Prozesses existieren. Die Stapelspeichermechanismen von P 10310 erlauben das Stapeln von Prozeduren für Prozeduraufrufe und Rückgaben und für das Austauschen von Prozessen in und aus JP 10114. Makrostapelspeicher (MAS) 10328 bis 10334 werden normalerweise dazu benötigt, automatische Daten zu speichern (Daten, die während der Ausführung einer Prozedur generiert werden, und die nur so lange leben, wie die Prozedur ausgeführt wird). Obwohl sie als von den Stapelspeichern in P 10310 getrennt dargestellt sind, können die SDAs auch innerhalb der MAS 10328 bis 10334 liegen. Der Sicherheitsstapelspeicher (SS) 10336 speichert allgemeiner Weise den Zustand der CS 10110-Mikromaschine für jede Prozedur. Die Information, die in SS 10336 abgespeichert ist, erlaubt es, den Zustand der Maschine bei der Rückkehr von einer gerufenen Prozedur oder beim Hineinbinden (Austauschen) eines VPs in CS 10110 wieder herzustellen.
Wie in P 10310 gezeigt, ist jeder Prozeß auf Bereichsbasis strukturiert. Ein P 10310 kann daher für jeden Bereich ein oder mehrere Prozedurobjekte beinhalten, die Prozeduren enthalten, die jenen Bereich als ihren Ausführungsbereich besitzen, einen SDA und ein MAS. Zum Beispiel enthält der KOS-Bereich von P 10310 KOSPO 10318, KOSSDA 10326 und KOSMAS 10334. Der SS 10336 von P 10310 liegt in keinem Bereich von P 10310 sondern ist ein Stapelspeichermechanismus, der zur CS 10110 Mikromaschine gehört.
Nachdem nun die allgemeine Struktur des P 10310 beschrieben ist, werden im folgenden die individuellen Informationsstrukturen und -mechanismen eines P 10310 genauer beschrieben werden.

1. Prozedurobjekte (Fig. 103)

KOSPO 10318 ist ein typisches CS 10110-Prozedurobjekt, und wir werden deshalb zur Verdeutlichung in der folgenden Diskussion auf es Bezug nehmen. Die Hauptkomponenten von KOSPO 10318 sind der Kopf 10338, die externe Eingangsbeschreiberfläche (EED) 10340, die interne Eingangsbeschreiberfläche (IED) 10342, die S-Op-Codefläche 10344, der Prozedurumgebungsbeschreiber (PED) 10348, die Namenstabelle (NT) 10350 und die Zugangsinformationsvektorfläche (AIA) 10352.
Der Kopf 10338 enthält bestimmte Informationen, die PO 10318 identifizieren und die Anzahl der Eingänge in die EED-Fläche 10340 anzeigen, die momentan diskutiert wird.
Die EED-Fläche 10340 und die IED-Fläche 10342 enthalten zusammen einen Eingangsbeschreiber (ED) für jede Prozedur in KOSPO 10318. KOSPO 10318 enthält laut Darstellung die Prozeduren 1, 2 und 11, wobei Prozedur 11 in der gegenwärtigen Diskussion als ein Beispiel benutzt werden wird. Die EDs umfassen praktisch einen Index, über den alle Informationen in KOSPO 10318 lokalisiert werden können. Die IEDs bilden einen Index für alle KOSPO 10318-Prozeduren, die nur von anderen Prozeduren, die in KOSPO 10318 enthalten sind, aufgerufen werden können. Die EEDs bilden einen Index für alle Prozeduren von KOSPO 10318, die von Prozeduren, die außerhalb von KOSPO 10318 stehen, aufgerufen werden können. Von außen aufrufbare Prozeduren sind eine hervorragende Hilfe, wie im folgenden bei der Diskussion der CS 10110-Schutzmechanismen besprochen wird, bei der Bestätigung der Zugangsrechte von außerhalb rufenden Prozeduren.
Innerhalb von ED 11 - ED für Prozedur 11 - werden drei Felder gezeigt. Das Abstandsfeld des Prozedurenumgebungsbeschreibers (PEDO) gibt den Beginn des PED von Prozedur 11 in der PED-Fläche 10348 relativ zum Beginn von KOSPO 10318 an. Wie weiter unten besprochen wird, enthält der PED einer Prozedur einen Satz von Zeigern, um die Information, die für die Ausführung dieser Prozedur benötigt wird, zu lokalisieren. Die PED-Fläche 10348 enthält ein PED für jede Prozedur, die in 10318 enthalten ist. In der gegenwärtigen Verkörperung von CS 10110 kann ein einzelnes PED von zwei oder mehreren Prozeduren geteilt werden. Das Codeeingangspunktfeld (CEP) zeigt den Beginn des SIN-Codes von Prozedur 11 und der SIN-Codefläche 10344 relativ zum Prozedurbasiszeiger (PBP), der später diskutiert werden wird, an. Schließlich zeigt das initiale Rahmengrößenfeld (IFS) von ED 11 die benötigte Anfangsrahmengröße des Rahmens von KOSMAS 10334 an, wo die automatischen Daten der Prozedur 11 gespeichert werden.
PED 11, d. h. der PED von Prozedur 11 in der PED-Fläche 10348, enthält einen Satz von Zeigern, um die Information, die in der Ausführung von Prozedur 11 benötigt wird, zu lokalisieren. Der erste Eingang in PED 11 ist ein Kopf, der Informationen zur Identifikation von PED 11 enthält. Der Basiszeigereingang (PBP) der Prozedur von PED 11 ist ein Zeiger, der eine bestimmte Adresse zur Verfügung stellt, von der aus andere Informationen in PO 10318 lokalisiert werden können. Bei einem bestimmten Beispiel zeigt der CEP von Prozedur 11 den Ort des Beginns des S-Op-Codes in der S-Op-Codefläche 10344 relativ zu PBP an. Wie weiter unten beschrieben werden wird, ist PBP ein architektonischer Basiszeiger (ABP) von CS 10110. Die ABPs von CS 10110 sind ein Satz von architektonischen Zeigern, die in CS 10110 dazu benutzt werden, die Adressierung von CS 10110's Adreßraum zu erleichtern. Der Eingang der statischen Datenzeiger (SDP) von PED 11 zeigt auf Daten in PO 10318, die bestimmte Parameter von KOSSDA 10326 von P 10310 spezifizieren. Der Eingang des Namenstabellenzeigers (NTP) ist ein Zeiger, der die Stelle in NT 10350 anzeigt, wo die Namenstabelleneingänge (NTEs) für die Operanden von Prozedur 11 liegen. NT 10350 und die NTEs werden in der folgenden Diskussion der Adressierungsstruktur des Computersystems 10110 näher beschrieben werden. Der Eingang des S-Interpreterzeigers von PED 11 (SIP) ist ein Zeiger, der näher in einer folgenden Diskussion von CS 10110's Mikrocodestruktur beschrieben werden wird, der auf den speziellen S-Interpreter (SINT) zeigt, der dazu benutzt wird, den SIN-Code der Prozedur 11 zu interpretieren.
AIA 10352 enthält, wie gezeigt und oben besprochen, Informationen, die die Zugangsrechte betreffen, die für jede externe Prozedur, die eine 10318-Prozedur aufruft, erforderlich sind. Es gibt einen AIA 10352-Eingang für jede PO 10318-Prozedur, die von einer externen Prozedur aufgerufen werden kann. Ein bestimmter AIA-Eingang kann von einer oder mehreren Prozeduren, die ein ED in der EED-Fläche 10340 besitzen, geteilt werden. Jedes EED enthält bestimmte Informationen, die aus Übersichtlichkeitsgründen nicht gezeigt werden, die anzeigen, daß auf den entsprechenden AIA-Eingang jener Prozedur Bezug genommen werden muß, und daß die Zugangsrechte der rufenden Prozedur bestätigt werden müssen, wann immer jene Prozedur gerufen wird.

2. Stapelspeichermechanismen (Fig. 104, 105)

Wie oben beschrieben, enthalten die Stapelspeichermechanismen von P 10310 SS 10336, der dazu benutzt wird, um den Maschinenzustand zu speichern, und die MAS 10328 bis 10334, die dazu benutzt werden, die lokalen Daten, die während der Ausführung der P 10310-Prozeduren generiert werden, zu speichern. P 10310 ist so dargestellt, daß es für jeden CS 10110-Bereich ein MAS enthält. In einer anderen Verkörperung von CS 10110 wird ein spezielles P 10310-MAS nur jene Bereiche enthalten, in denen P 10310 eine Prozedur ausführt.
Bezogen auf die MAS 10328 bis 10334 und SS 10336 wird P 10310 so dargestellt, daß es elf Prozeduraufrufe hatte. Prozedur 0 hat Prozedur 1 aufgerufen, Prozedur 1 hat Prozedur 2 aufgerufen, und so weiter. Jedesmal, wenn eine Prozedur aufgerufen wurde, wird ein entsprechender Stapelspeicherrahmen auf den MAS des Bereichs konstruiert, in dem die gerufene Prozedur ausgeführt wird. Zum Beispiel führen die Prozeduren 1, 2 und 11 im KOS-Bereich aus; die MAS-Rahmen für die Prozeduren 1, 2 und 11 sind daher in KOSMAS 10334 plaziert. In ähnlicher Weise führen die Prozeduren 3 und 9 im EOS- Bereich aus, so daß ihre Stapelspeicherrahmen in EOSMAS 10332 plaziert sind. Die Prozeduren 5 und 6 führen im DBMS-Bereich aus, so daß deren Stapelspeicherrahmen im DBMSMAS 10330 plaziert sind. Die Prozeduren 4, 7, 8 und 10 führen im Benutzerbereich aus und ihre Stapelspeicherrahmen liegen im USERMAS 10328. Die Prozedur 11 ist die zuletzt aufgerufene Prozedur und daher ist der Stapelspeicherrahmen auf KOSMAS 10334 der aktuelle Rahmen. Die Prozedur 11 ist die Prozedur, die momentan ausgeführt wird, wenn VP 10310 an CS 10110 gebunden wird.
SS 10336, der ein Stapelspeichermechanismus der CS 10110-Mikromaschine ist, enthält einen Rahmen für jede der Prozeduren 1 bis 11. Jeder SS 10336-Rahmen enthält teilweise den Betriebszustand von CS 10110 für seine entsprechende Prozedur.
In Fig. 104 wird eine schematische Darstellung eines typischen MAS, z. B. KOSMAS 10334, gezeigt. KOSMAS 10334 enthält einen Stapelspeicherkopf 10410 und einen Rahmen 10412 für jede Prozedur auf KOSMAS 10334. Jeder Rahmen 10412 enthält einen Rahmenkopf 10414 und kann einen Verkettungszeigerblock 10416, einen lokalen Zeigerblock 10418 und einen lokalen (automatischen) Datenblock 10420 enthalten.
Der Stapelspeicherkopf 10410 von KOSMAS 10334 enthält mindestens folgende Informationen:
(1) einen Abstand relativ zum Stapelspeicherkopf 10410, der die Lokation des Rahmenkopfes 10414 des ersten Rahmens auf KOSMAS 10334 anzeigt;
(2) den Stapelspeicherspitzenabstand (STO), der die Spitze von KOSMAS 10334 relativ zum Beginn von KOSMAS 10334 anzeigt; die Spitze von KOSMAS 10334 wird durch den Zeiger STO angezeigt, der auf die Spitze des letzten Eingangs des lokalen Datenblocks 10420 des Rahmens 10412 der Prozedur 11 anzeigt;
(3) einen Abstand relativ zum Beginn von KOSMAS 10334, der die Lokation des Rahmenkopfes 10414 des gegenwärtig obersten Rahmens von KOSMAS 10334 anzeigt; in Fig. 104 ist dieser Abstand durch den Rahmenzeiger (FP) angedeutet, ein ABP wird weiter unten beschrieben;
(4) die UID des VP 10310;
(5) ein UID-Zeiger, der die Lokation von bestimmten Informationen der Bereichsumgebung anzeigt, die weiter in einer folgenden Diskussion beschrieben werden;
(6) ein Signalzeiger, der die Lokation von bestimmten Routinen anzeigt, die bestimmte CS 10110-Betriebssystemsfehler verwalten;
(7) ein UID-Zeiger, der die Lokation von KOSSDA 10326 anzeigt; und
(8) ein Ablaufsteuerer für die Rahmenkennzeichen, der Zeiger auf die Köpfe von Rahmen in anderen Bereichen enthält; diese Zeiger werden für die Ausführung von nicht lokalen go-to-Operationen benötigt.
Der Stapelspeicherkopf 10410 von KOSMAS 10334 enthält daher Informationen, um bestimmte wichtige Punkte in der Struktur von KOSMAS 10334 zu lokalisieren und um bestimmte Informationen zu lokalisieren, die zu ausführenden Prozeduren im KOS-Bereich gehören.
Jeder Rahmenkopf 10414 enthält mindestens die folgenden Informationen:
(1) Abstände relativ zum Rahmenkopf 10414, die die Lokationen der Rahmenköpfe 10414 von den vorhergehenden und den nachfolgenden Rahmen von KOSMAS 10334 anzeigen;
(2) einen Abstand relativ zu dem Rahmenkopf 10414, der die Lokation der Spitze jenes Rahmens 10412 anzeigt;
(3) Informationen, die die Anzahl der übergebenen Argumente anzeigen, die in jenem Rahmen 10412 enthalten sind;
(4) einen dynamischen Rückwärtszeiger im UID/Abstandsformat, der auf den vorhergehenden Rahmen 10412 zeigt, falls jener vorhergehende Rahmen 10412 in einem anderen Bereich residiert;
(5) ein UID-Abstandszeiger auf den Umgebungsbeschreiber der Prozedur, die jene Prozedur aufruft;
(6) eine Abfolge von Rahmenkennzeichen, die Informationen über die Lokationen anderer Rahmenköpfe 10414 in KOSMAS 10334 anzeigen; diese Information wird gebraucht, um andere Rahmen in KOSMAS 10334 zu lokalisieren zum Zwecke der Ausführung lokaler go-to-Operationen. Die Rahmenköpfe 10414 enthalten dadurch Informationen, um bestimmte wichtige Punkte in der Struktur von KOSMAS 10334 und bestimmte Daten, die relevant sind für die Ausführung der damit verbundenen Prozeduren, zu lokalisieren. Zusätzlich enthalten die Rahmenköpfe 10414 Informationen in Kombination mit dem Stapelspeicherkopf 10410, die für das Zusammenfügen der Aktivierungssätze jedes VP 10310 MAS und für das Zusammenfügen der Aktivierungssätze jedes individuellen MAS dienlich sind.
Die Verkettungszeigerblöcke 10416 enthalten Zeiger auf Argumente, die von der rufenden Prozedur an die gerufene Prozedur übergeben werden. Zum Beispiel enthält der Verkettungszeigerblock 10416 des Rahmens 10412 der Prozedur 11 Zeiger auf Argumente, die von Prozedur 10 nach Prozedur 11 übergeben werden. Der Gebrauch der Verkettungszeiger in CS 10110's Adressierungsstruktur wird später diskutiert werden, wenn die Adressierungsstruktur von CS 10110 besprochen wird. Die lokalen Datenzeigerblöcke 10418 enthalten Zeiger auf bestimmte lokale Daten der damit verbundenen Prozedur. In Fig. 104 wird ein Zeiger gezeigt, ein Rahmenzeiger (FP), der den Verkettungszeigerblock 10416 des höchsten Rahmens 10412 und den lokalen Datenzeigerblock 10418 verkettet. FP, der weiter unten besprochen wird, ist ein ABP zum MAS-Rahmen 10412 der gegenwärtigen Prozedur des Prozesses.
Jeder lokale (automatische) Datenblock 10420 des Rahmens 10412 enthält bestimmte automatische Daten der damit verbundenen Prozedur.
Wie oben beschrieben, wird bei jedem Prozeduraufruf ein MAS-Rahmen an der Spitze des MAS des Bereichs erzeugt, in dem die gerufene Prozedur ausgeführt wird. Wenn z. B. Prozedur 10 die Prozedur 11 aufruft, wird ein Rahmenkopf 10414 für Prozedur 11 konstruiert und in KOSMAS 10334 plaziert. Dann werden die Verkettungszeiger von Prozedur 11 erzeugt und in Prozedur 11's Verkettungszeigerblock 10416 abgelegt. Die nächsten lokalen Zeiger der Prozedur 11 werden erzeugt und in dem lokalen Zeigerblock 10418 von Prozedur 11 abgelegt. Schließlich werden die lokalen Daten von Prozedur 11 in dem lokalen Datenblock 10420 von Prozedur 11 abgelegt. Während dieser Operation wird die Reihenfolge der Rahmenkennzeichen von USERMAS 10328 auf den neuesten Stand gebracht, damit sie einen Eingangspunkt für den Rahmenkopf 10414 der Prozedur 11 beinhaltet. Der Stapelspeicherkopf 10410 von KOSMAS 10334 wird mit Rücksicht auf STO zu der neuen Spitze von KOSMAS 10334 aktualisiert. Der Rahmenkopf 10414 von Prozedur 2 wird mit Rücksicht auf den Abstand zum Rahmenkopf 10414 des Rahmens 10412 von Prozedur 11 und mit Rücksicht auf die Reihenfolge der Rahmenkennzeichen aktualisiert, die die Lokation des Rahmenkopfs 10414 der Prozedur 11 anzeigen. Sobald Prozedur 11 die gegenwärtige Prozedur ist, wird FP aktualisiert, so daß er zwischen dem Verkettungszeigerblock 10416 und dem lokalen Zeigerblock 10418 des Rahmens 10412 der Prozedur 11 verkettet. Es wird auch, wie später besprochen wird, ein neuer Rahmen auf SS 10336 oder Prozedur 11 konstruiert. Dann wird CS 10110 damit fortfahren, Prozedur 11 auszuführen. Während der Ausführung der Prozedur 11 können weitere lokale Daten, die erzeugt werden, auf der Spitze des lokalen Datenblocks 10420 von Prozedur 11 abgelegt werden. Die Spitze der Stapelspeicherabstandsinformation in Prozedur 11's Rahmenkopf 10414 und im Stapelspeicherkopf 10410 von KOSMAS 10334 wird in entsprechender Weise aktualisiert.
Die MAS 10328 bis 10334 stellen dadurch einen bereichsbezogenen Stapelspeichermechanismus zur Verfügung, um Daten abzuspeichern, die zu individuellen Prozeduren gehören, und erlauben daher das Stapeln von Prozeduren, ohne diese Daten zu verlieren. Obwohl sie auf Bereichsbasis strukturiert sind, umfassen die MAS 10328 bis 10334 eine einheitliche logische Stapelspeicherstruktur, die miteinander durch Information verknüpft ist, die in MAS-Stapelspeicher und -Rahmenköpfen gespeichert sind.
Wie oben und vorher beschrieben, ist SS 10336 eine CS 10110-Mikromaschinen-Stapelspeicherstruktur für das teilweise Abspeichern des Zustands der CS 10110-Mikromaschine für jede gestapelte VP 10310-Prozedur. In Fig. 105 wird ein Teilausschnitt einer schematischen Darstellung des Stapelspeicherrahmens 10510 von SS 10336 gezeigt. Der SS 10336- Stapelspeicherkopf 10512 und die Rahmenköpfe 10514 enthalten Informationen, die jenen in den MAS-Stapelspeicherköpfen 10410 und den Rahmenköpfen 10414 ähneln. Wiederum lokalisiert die hierin enthaltene Information bestimmte Punkte innerhalb SS 10336-Struktur und verbindet SS 10336 mit den MAS 10328 bis 10334.
Der Stapelspeicherrahmen 10510 von SS 10336 enthält bestimmte Informationen, die von der CS 10110-Mikromaschine bei der Ausführung der VP 10212-Prozedur, mit der dieser Rahmen assoziiert ist, benötigt werden. Der Prozedurenzeigerblock 10516 enthält bestimmte Zeiger einschließlich ABPs, die von der CS 10110-Mikromaschine dazu benutzt werden, Informationen innerhalb der Informationsstrukturen von VP 10310 zu lokalisieren. Die Mikroprogrammrahmen (MRFs) 10518 umfassen zusammen den Mikroprogramm-Stapelspeicher (MRS) 10520 innerhalb jedes SS 10336-Stapelspeicherrahmens 10510. Der MRS-Stapelspeicher 10520 ist mit dem internen Betrieb der CS 10110- Mikroprogramme verbunden, die während der Ausführung der VP 10212-Prozedur, die mit dem Stapelspeicherrahmen 10510 verbunden ist, ausgeführt werden. SS 10336 hat daher einen CS 10110-Mikromaschinen-Stapelspeicher doppelter Funktion. Die Eingänge des Zeigerblocks 10516 definieren praktisch eine Schnittstelle zwischen der CS 10110- Mikromaschine und der gegenwärtigen Prozedur des gegenwärtigen Prozesses. MRS 10520 umfaßt einen Stapelspeichermechanismus für die internen Operationen der CS 10110-Mikromaschine.
Nachdem nun kurz die virtuellen Prozesse 10212 beschrieben sind, wird als nächstes FURSM 10214 beschrieben. Wie oben festgestellt, ist EURSM 10216 im Betrieb dem FURSM 10214 ähnlich und wird in den folgenden genaueren Beschreibungen der CS 10110-Struktur und des CS 10110-Betriebs näher beschrieben werden.

3. FURSM 10214 (Fig. 103)

In Fig. 103 enthält FURSM 10214 die CS 10110-Mikromaschinen-Informationsstrukturen, die innerhalb der CS 10110-Mikromaschine bei der Ausführung von Prozeduren eines P 10310 benötigt werden. Wenn ein VP, z. B. P 10310, ausgeführt werden soll, werden bestimmte Informationen bezüglich jenes VP von den virtuellen Prozessen 10212 zu FURSM 10214 transferiert, weil sie bei der Ausführung jener Prozedur benötigt werden. In dieser Hinsicht kann FURSM 10214 als Beschleunigermechanismus für den gegenwärtigen virtuellen Prozeß 10212 betrachtet werden.
FURSM 10214 enthält eine allgemeine Registerdatei (GRF) 10354, einen Registermechanismus für Mikrostapelspeicherzeiger (MISPR) 10356 und einen Stapelspeicher für die Rückgabesteuerungsworte (RCWS) 10358. GRF 10354 enthält globale Register (GRs) 10360 und Stapelspeicherregister (SRs) 10362. Die GRs 10360 enthalten architektonische Basisregister (ABRs) 10364 und Mikrosteuerungsregister (MCRs) 10366. Die Stapelspeicherregister 10362 enthalten Mikrostapelspeicher (MIS) 10368 und einen Überwachungsstapelspeicher (MOS) 10370.
Indem wir erst auf GRF 10354 Bezug nehmen und weiter annehmen, daß z. B. die Prozedur 11 von P 10310 gerade ausgeführt wird, so enthält GRF 10354 hauptsächlich bestimmte Zeiger auf P 10310-Daten, die bei der Ausführung der Prozedur 11 benötigt werden. Wie vorher besprochen, enthält die CS 10110-Adressierungsstruktur bestimmte architektonische Basiszeiger (ABPs) für jede Prozedur. Die ABPs stellen ein Grundgerüst zur Überschreitung des Adreßraums von CS 10110 zur Verfügung. Die ABPs jeder Prozedur enthalten einen Rahmenzeiger (FP), einen Prozedurbasiszeiger (PBP) und einen statischen Datenzeiger (STP). Wie oben bezüglich KOSPO 10318 besprochen, sitzen diese ABPs in den PEDs der Prozedur. Wenn eine Prozedur gerufen wird, werden die ABPs von den PED jener Prozedur zu den ABRs 10364 transferiert und bleiben dort für die Dauer jener Prozedur. Wie in Fig. 103 angezeigt, verkettet FP zwischen dem Verkettungszeigerblock 10416 und den lokalen Zeigerblöcken 10418 des Rahmens 10412 von Prozedur 11 auf KOSMAS 10334. PBP zeigt auf den Referenzpunkt, von dem die Elemente von KOSPO 10318 lokalisiert werden. SDP zeigt auf KOSSDA 10326. Wenn Prozedur 11 z. B. eine Prozedur 12 aufruft, so werden die ABPs von Prozedur 11 auf den Prozedurenzeigerblock 10516 von SS 10336's Stapelspeicherrahmen für Prozedur 11 transferiert. Bei der Rückkehr zu Prozedur 11 werden die ABPs von Prozedur 11 vom Prozedurenzeigerblock 10516 zu den ABRs 10364 transferiert und die Ausführung von Prozedur 11 wird wieder aufgenommen.
Die MCRs 10336 enthalten bestimmte Zeiger, die von der CS 1011 10-Mikromaschine bei der Ausführung von Prozedur 11 benutzt werden. Die CS 10110-Mikromaschinenzeiger, die in Fig. 103 angezeigt werden, enthalten einen Programmzähler (PC), einen Namenstabellenzeiger (NTP), einen S-Interpreter-Zeiger (SIP), einen Sicherheitsstapelspeicherzeiger (SSP) und einen Spitzenabstand des Sicherheitsstapelspeichers (SSTO). NTP und SIP wurden vorher bezüglich KOSPO 10318 beschrieben und sitzen in KOSPO 10318. NTP und SIP werden beim Beginn der Ausführung von Prozedur 11 in die MCRs 10366 transferiert. PC ist ein Zeiger, wie angezeigt in Fig. 103, auf den SIN von Prozedur 11, der gegenwärtig von CS 10110 ausgeführt wird. PC wird anfangs vom PBP und CEP von Prozedur 11 generiert und wird danach von der CS 10110-Mikromaschine in dem Maße inkrementiert, wie die SIN-Sequenzen von Prozedur 11 ausgeführt werden. SSP und SSTO werden, wie im folgenden besprochen wird, von einer Information erzeugt, die im Stapelspeicherkopf 10512 des SS 10336 und in den Rahmenköpfen 10514 enthalten sind. Wie in Fig. 103 gezeigt, zeigt SSP auf den Anfang von SS 10336, während SSTO den gegenwärtig obersten Rahmen auf SS 10336 anzeigt, indem es einen Abstand relativ zu SSP anzeigt zur Unterscheidung zwischen einem Prozedurenzeigerblock 10516 oder einem MRF 10518 von MRS 10520. Falls die Prozedur 11 eine nachfolgende Prozedur aufruft, so werden die Inhalte von 10366 von MCR in den Prozedurenzeigerblock 10516 auf SS 10336 transferiert und werden bei der Rückkehr zu Prozedur 11 den MCRs 10366 zurückgegeben.
Die Register 10360 enthalten weitere Zeiger, die in der folgenden detaillierten Diskussion des Betriebs von CS 10110 besprochen werden, und bestimmte Register, die dazu benutzt werden können, die lokalen Daten der gegenwärtigen Prozedur aufzunehmen.
Bezogen auf die Stapelspeicherregister 10362 ist MIS 10368 eine Aufwärtserweiterung oder Beschleunigung des MRS 10520 der gegenwärtigen Prozedur. Wie vorher festgestellt, wird MRS 10520 von der CS 10110-Mikromaschine bei der Ausführung bestimmter Mikroprogramme während der Ausführung einer speziellen Prozedur benutzt. MJS 10368 verstärkt die Wirksamkeit der CS 10110-Mikromaschine bei der Ausführung dieser Mikroprogramme, indem es bestimmte letzte MRFs 10518 des MRS 10520 von jener Prozedur in FU 10120 hinein beschleunigt. MIS 10368 kann z. B. die letzten acht MRFs 10518 der MRS 10520 der gegenwärtigen Prozedur enthalten. So wie verschiedene Mikroprogramme von MRS 10520 gerufen oder zurückgegeben werden, werden entsprechend die MRFs 10518 zwischen SS 10336 und MIS 10368 transferiert, so daß MIS 10368 immer mindestens den obersten MRF 10518 von MRS 10520 enthält und höchstens acht MRFs 10518 von MRS 10520. MISPR 10356 ist ein CS 10110-Mikromaschinenmechanismus zur Verwaltung von MIS 10368. MISPR 10356 enthält einen aktuellen Zeiger, einen vorherigen Zeiger und einen unteren Zeiger. Der aktuelle Zeiger zeigt auf den obersten MRF 10518 auf MIS 10368. Der vorherige Zeiger zeigt auf den vorherigen MRF 10518 auf MIS 10368 und der untere Zeiger zeigt auf den untersten MRF 10518 auf MIS 10368. Der aktuelle, vorherige und untere Zeiger von MISPR 10356 werden in dem Maße aktualisiert, wie die MRFs 10518 zwischen SS 10336 und MIS 10368 transferiert werden. Wenn Prozedur 11 eine nachfolgende Prozedur aufruft, werden alle MRFs 10518 von Prozedur 11 von MIS 10368 zu den MRS 10520 auf SS 10336 der Prozedur 11 transferiert. Bei der Rückkehr zur Prozedur 11 werden bis zu sieben MRFs 10518-Rahmen von Prozedur 11 von SS 10336 zu MIS 10368 zurückgegeben.
MOS 10370 ist ein Stapelspeichermechanismus, der von der CS 10110-Mikromaschine für bestimmte Mikroprogramme zur Fehlerbehandlung oder Fehlerbedingungen benutzt wird. Diese Mikroprogramme werden immer zu Ende geführt, so daß MOS 10370 vollständig in FM 10120 sitzt und keine Erweiterung eines Stapelspeichers in einem P 10310 in MEM 10112 ist. MOS 10370 kann z. B. acht Rahmen enthalten. Falls mehr als acht aufeinanderfolgende Fehler oder Error-Bedingungen auftreten, so wird dieses als eine größere Störung des CS 10110 betrachtet. Die Steuerung von CS 10110 kann dann nach DP 10118 transferiert werden. Wie im folgenden beschrieben werden wird, können dann Diagnoseprogramme in DP 10118 dazu benutzt werden, die Fehler oder Irrtümer des CS 10110 zu diagnostizieren und zu lokalisieren. In anderen Verkörperungen des CS 10110 kann MOS 10370 mehr oder weniger Stapelspeicherrahmen enthalten, je nach Grad der Selbstdiagnose und Selbstkorrekturfähigkeit, die für CS 10110 gewünscht ist.
RCWS 10358 ist ein zweiteiliger Stapelspeichermechanismus. Ein erster Teil operiert parallel mit MIS 10368 und ein zweiter Teil operiert parallel mit MOS 10370. Wie vorher beschrieben, ist CS 10110 ein mikrocodegesteuertes System. RCWS ist ein Stapelspeicher, um die gegenwärtigen Mikrobefehle zu speichern, die von der CS 10110-Mikromaschine ausgeführt werden, wenn die aktuelle Prozedur durch eine Fehler- oder Error-Bedingung unterbrochen wird oder wenn eine nachfolgende Prozedur aufgerufen wird. Der Teil von RCWS 10358, der mit MIS 10368 assoziiert ist, enthält einen Eingang für jeden MRF 10518, der in MIS 10368 sitzt. Diese RCWS 10358-Eingaben werden zwischen SS 10336 und MIS 10368 transferiert, und zwar parallel mit den ihnen verbundenen MRFs 10518. Wenn sie in SS 10336 liegen, werden diese RCWS 10358-Eingaben innerhalb der mit ihnen verbundenen MRFs 10518 gespeichert. Jener Bereich der RCWS 10358, der mit MOS 10370 verbunden ist, operiert in ähnlicher Weise parallel mit MOS 10370 und ist wie MOS 10370 keine Erweiterung eines Stapelspeichers in MEM 10112.
Zusammenfassend gesehen existiert jeder Prozeß, der in CS 10110 aktiv ist, als eine separate, vollständige und in sich selbst befindliche Einheit oder ein virtueller Prozeß und ist strukturell auf Bereichsbasis organisiert. Jeder virtuelle Prozeß enthält neben Prozedur- und Datenobjekten einen Satz von MAS, um lokale Daten der Prozeduren dieser Prozesse zu speichern. Jeder virtuelle Prozeß enthält auch einen CS 101 10-Mikromaschinen- Stapelspeicher, SS 10336, der den CS 10110-Mikromaschinenzustand zu jeder gestapelten Prozedur des virtuellen Prozesses abspeichert. Die CS 10110-Mikromaschine enthält einen Satz von Informationsstrukturen, Register 10360, MIS 10368, MOS 10370 und RCWS 10358, die von der CS 10110-Mikromaschine zur Ausführung der Prozeduren des virtuellen Prozesses benutzt werden. Bestimmte dieser Informationsstrukturen von CS 10110 werden mit dem aktuell ausgeführten Prozeß geteilt und sind daher praktisch Beschleunigermechanismen für den aktuellen virtuellen Prozeß, während andere vollständig intern in CS 10110's Mikromaschine bleiben.
Ein Hauptmerkmal von CS 10110 ist, daß die Maktostapelspeicher und Sicherheitsstapelspeicher eines jeden Prozesses in MEM 10112 sitzen. Der Makrostapelspeicher von CS 10110 und die Sicherheitsstapelspeicher sind daher praktisch in ihrer Tiefe unbegrenzt.
Noch ein anderes Merkmal der CS 10110-Mikromaschine ist der Gebrauch des GRF 10354. GRF 10354 ist in einer Verkörperung von CS 10110 ein einheitlicher Registervektor, der z. B. 256 Register enthält. Bestimmte Bereiche oder Adreßlokationen von GRF 10354 werden den GR 10360, den MIS 10368 und MOS 10370 gewidmet. Die Kapazitäten von GR 10360, MIS 10368 und MOS 10370 können daher durch eine Neuaufteilung des Adreßraums von GRF 10354 angepaßt werden, wie es erforderlich ist für die optimale Effektivität von CS 10110. In anderen Verkörperungen von CS 10110 können die GRs 10360, MIS 10368 und MOS 10370 als funktional getrennte Registervektoren implementiert werden.
Nachdem nun die Struktur und der Betrieb der Prozeßstrukturen 10210 kurz beschrieben sind, wird im folgenden der VP-Zustandsbock 10218 beschrieben werden.

C. Virtuelle Prozessorzustandsblöcke und virtuelle Prozeßerzeugung (Fig. 102)

Wie in Fig. 102 dargestellt, werden die VP-Zustandsblöcke 10218 zur Verwaltung und Steuerung von Prozessen benutzt. Die VP-Zustandsblöcke 10218 enthalten je einen VP- Zustandsblock für jeden virtuellen Prozeß (VP), der von CS 10110 zur Ausführung bestimmt wurde. Jeder dieser VP-Zustandsblöcke enthält mindestens die folgenden Informationen:
(1) den Zustand oder die Identifikationsnummer eines VP;
(2) Eingänge, die die jeweilige Betriebsart und den jeweiligen Prozeß des VP identifizieren;
(3) einen AON-Zeiger zum Sicherheitsstapelspeicher jenes VPs (d. h. SS 10336);
(4) die AONs der MAS-Stapelspeicherobjekte jenes VPs (d. h. MAS's 10328 bis 10334); und
(5) bestimmte Informationen, die von CS 10110's VP-Verwaltungssystem benötigt werden.
Die Informationen, die in jedem VP-Zustandsblock enthalten sind, definieren dadurch den aktuellen Zustand des assoziierten VP.
Ein Prozeß wird in CS 10110 geladen, indem ein einfacher Zugangssatz gebildet wird; das Laden dieses Zugangssatzes in CS 10110 erscheint als ein bereits existierender VP. Ein VP wird kreiert durch die Kreation eines Prozeßobjektes, welches Zeiger auf Makro- und Sicherheitsstapelspeicherobjekte, die für diesen VP kreiert sind, Mikromaschinen-Zustandseingaben, und einen Zeiger auf das Benutzerprogramm beinhalten. Der KOS von CS 10110 generiert dann Makro- und Sicherheitsstapelspeicherobjekte mit Köpfen für jenen Prozeß und, wie vorher beschrieben, lädt Schutzinformationen für diese Prozeßobjekte in die Schutzstrukturen 10230. Der KOS von CS 10110 kopiert dann diesen einfachen Maschinenzustandssatz in ein leeres VPSB, der von CS 10110's VP-Verwalter selektiert wurde, und bindet so den neu kreierten VP in CS 10110. Zu dieser Zeit vollendet eine KOS-Intitialisierprozedur die Erzeugung des VP, z. B., indem es ein Benutzerprogramm durch einen Compiler aufruft. Der frisch erzeugte VP kann dann durch CS 10110 ausgeführt werden.
Nachdem die VP-Zustandsblöcke 10218 und die Erzeugung eines VP kurz beschrieben sind, werden die Adressierungsstrukturen 10220 des CS 10110 im folgenden beschrieben.

D. Adressierstrukturen 10220 (Fig. 103, 106, 107, 108)

1. Objekte, UIDs, AONs, Namen und physikalische Adressen (Fig. 106)

Wie vorher beschrieben, ist der CS 10110 zugängliche Datenraum in Segmente oder Behälter aufgeteilt, die wir als Objekte bezeichnen. In einer Verkörperung von CS 10110 hat der adressierbare Datenraum eines jeden Objekts eine Kapazität von 2³²-Informationsbits und ist strukturiert in 2¹&sup8;-Seiten, wobei jede Seite 2¹&sup4;-Informationsbits enthält.
In Fig. 106a wird eine schematische Darstellung der Adressierungsstruktur des CS 10110 gezeigt. Jedem Objekt, das für den Gebrauch in oder durch den Betrieb von CS 10110 kreiert wurde, wird permanent ein einheitlicher Identifizierer (UID) zugeordnet. Die UID eines Objekts erlaubt es, daß ein Objekt zu jedem zukünftigen Zeitpunkt eindeutig identifiziert und lokalisiert werden kann. Jede UID ist eine 80-Bit-Zahl, so daß der gesamte Adreßraum aller CS 10110's 2&sup8;&sup0; Objekte enthält, wobei jedes Objekt bis zu 2³² Informationsbits enthalten kann. Wie in Fig. 106 angezeigt, umfaßt jede 80-Bit-UID einen logischen Allokationseinheitenidentifizierer (LAUID) von 32 Bit und eine Objektseriennummer (OSN) von 48 Bit. Die LAUIDs sind mit individuellen CS 10110-Systemen assoziiert. Die LAUIDs identifizieren das jeweilige CS 10110-System, welches das jeweilige Objekt generiert. Jede LAUID umfaßt eine logische Allokationseinheiten- Gruppennummer (LAUGN) und eine logische Allokationseinheiten-Seriennummer (LAUSN). Die LAUGNs werden individuellen CS 10110-Systemen zugeordnet und sind garantiert dem jeweiligen System eigen. Einem speziellen System kann jedoch mehr als eine LAUGN zugeordnet werden, so daß es eine zeitvariable Zuordnung zwischen LAUGNs und CS 10110-Systemen geben kann. Die LAUSNs werden innerhalb eines speziellen Systems zugewiesen und während die LAUSNs eindeutig sind innerhalb eines bestimmten Systems, müssen sie es nicht sein zwischen verschiedenen Systemen und müssen nicht auf die physikalische Struktur des jeweiligen Systems passen.
Die OSNs werden mit den individuellen Objekten, die von einer LAU kreiert wurden, verbunden und werden in jeder CS 10110 durch eine architektonische Uhr generiert. Die architektonische Uhr ist definiert als eine 64-Bit-Binärzahl, die die wachsende Zeit darstellt. Das am wenigsten signifikante Bit der architektonischen Uhr stellt ein Inkrement von 600 Picosekunden dar, das signifikanteste Bit repräsentiert ein Inkrement von 127 Jahren. In der gegenwärtigen Verkörperung des CS 10110 werden bestimmte am meisten signifikante und bestimmte am wenigsten signifikante Bits der architektonischen Uhrzeit nicht beachtet, weil sie in der Praxis nicht benötigt werden. Die Zeit, die von der architektonischen Uhr angezeigt wird, wird relativ zu einem willkürlich gewählten fixen Punkt in der Zeit bestimmt. Dieser Zeitpunkt ist derselbe für alle CS 10110's, die je gebaut werden. Alle CS 10110, die je gebaut werden, werden daher dieselbe architektonische Uhrzeit anzeigen, und alle UIDs, die generiert werden, werden eine gemeinsame Basis besitzen. Der Gebrauch einer architektonischen Uhr zur Erzeugung von OSNs ist dafür von Vorteil, daß es die Möglichkeit ausschließt, daß es zu einer zufälligen Übereinstimmung zweier OSNs kommt, falls ein CS 10110 eine Störung hat und daraufhin reinitialisiert wird.
Wie oben festgestellt, wird jedes Objekt, das von einer CS 10110 erzeugt wurde oder für den Gebrauch in einer CS 10110 bestimmt ist, eindeutig identifiziert durch seine assoziierte UID. Indem man eine Abstands- (O) und Längen- (L) Information an die UID eines Objektes anfügt, wird die UID-logische Adresse generiert, die dazu benutzt werden kann, bestimmte Datensegmente, die in einem bestimmten Objekt liegen, zu lokalisieren. Wie in Fig. 106 angezeigt, bestehen die O- und die L-Felder einer UID-logischen Adresse aus 32 Bits. Die O- und L-Felder können daher in einem Objekt jedes beliebige Bit von 2³²-1 anzeigen und erlauben so eine Bit-genaue Adressierung von Information in den Objekten.
Wie in Fig. 106 angezeigt und auch früher erwähnt wurde, wird jedem aktiven Objekt in CS 10110 ein kurzer, zeitweise eindeutiger Identifizierer zugeordnet, der nur innerhalb von W 10114 Gültigkeit besitzt und den wir als aktive Objektnummer (AON) bezeichnen. Weil auch weniger Objekte in einer CS 10110 aktiv sein können als maximal im CS 10110-Adreßraum möglich sind, sind die AONs in der gegenwärtigen Verkörperung des CS 10110 14 Bit lang. Eine bestimmte CS 10110 kann daher bis zu 2¹&sup4; aktive Objekte enthalten. Die AON eines Objekts wird innerhalb JP 10114 anstelle der UID des Objekts benutzt. Zum Beispiel zeigt, wie oben im Zusammenhang mit Prozeßstrukturen 10210 besprochen, der FP einer Prozedur an den Anfang des Rahmens jener Prozedur auf den MAS seines Prozesses. Wenn jener FP in SS 10336 sitzt, so wird er als UID ausgedrückt. Wenn jene Prozedur ausgeführt werden soll, so wird FP von SS 10336 zu ABRs 10364 transferiert und in die entsprechende AON übersetzt.
In ähnlicher Weise wird FP, wenn jene Prozedur gestapelt wird, zu SS 10336 zurückgegeben und auf diese Weise in die entsprechende UID übersetzt. Wieder kann ein bestimmtes Datensegment in einem Objekt mit Hilfe einer AON-logischen Adresse adressiert werden, welche die AON des Objekts und zusätzlich die 32 Bit-Abstands- und Längenfelder umfaßt.
Jedem Operanden, der in einem Prozeß auftaucht, wird ein Name zugewiesen, und jede Bezugnahme zu Operanden in einem Prozeß geschieht durch jene zugeordneten Namen. Wie in Fig. 106b angezeigt, ist in der gegenwärtigen Verkörperung des CS 10110 jeder Name eine 8-, 12- oder 16-Bitzahl. Alle Namen innerhalb eines bestimmten Prozesses werden die gleiche Länge besitzen. Wie in einer folgenden Diskussion besprochen werden wird, können die Namen, die während der Ausführung eines Prozesses auftauchen, durch die Namenstabelle 10350 der Prozedur oder durch den Namenszwischenspeicher 10226 zu einer AON-logischen Adresse aufgelöst werden. Wie unten beschrieben, kann eine AON- logische Adresse, die einem Operandennamen entspricht, darauf zu einer MEM 10112- physikalischen Adresse ausgewertet werden, um den Operanden, auf den man Bezug nimmt, zu finden.
Die Auswertung der AON-logischen Adressen zu MEM 10112-physikalischen Adressen wird in Fig. 106c gezeigt. Das L-Feld einer AON-logischen Adresse ist von der Auswertung von AON-logischen Adressen zu physikalischen Adressen nicht betroffen und wird aus Übersichtlichkeitsgründen in Fig. 106c nicht dargestellt. Das L-Feld einer AON- logischen Adresse sollte man sich als an die Adressen darangehängt denken - bei den verschiedenen Schritten der Auswerteprozedur, die in Fig. 106c gezeigt ist.
Wie oben beschrieben, bestehen die Objekte aus 2³² Bits, die in 2¹&sup8; Seiten strukturiert sind, wobei jede Seite 2¹&sup4; Datenbits enthält. MEM 10112 ist physikalisch ähnlich in Rahmen aufgeteilt, wobei in der gegenwärtigen Verkörperung des CS 10110 jeder Rahmen 2¹&sup4; Datenbits enthält. In anderen Verkörperungen von CS 10110 können sowohl Seiten als auch Rahmen von verschiedener Größe sein, aber die Übersetzung von AON-logischen Adressen nach MEM 10112-physikalischen Adressen würde denen ähnlich sein, die wir momentan beschreiben.
Das O-Feld einer AON-logischen Adresse wurde vorher beschrieben als eine 32-Bitzahl, die den Anfang des adressierten Datensegments innerhalb des Objekts relativ zum Beginn des Objekts anzeigt. Die 18 signifikantesten Bits des O-Feldes repräsentieren die Nummer (P) der Seite innerhalb des Objekts, auf dem das erste Bit der adressierten Daten sitzt. Die 14 am wenigsten signifikanten Bits des O-Feldes repräsentieren den Abstand (Op) des ersten Bits der adressierten Daten innerhalb der Seite relativ zum Anfang der Seite. Das O-Feld einer AON-logischen Adresse kann daher wie in Fig. 106 unterteilt werden in ein 18 Bit Seitenfeld (P) und ein 14 Bit Abstandsfeld innerhalb der Seite (Op). Da, wie oben beschrieben, die physikalische Rahmengröße des MEM 10112 gleichgroß wie die Seitengröße des Objekts ist, kann das Op-Feld der AON-logischen Adresse direkt als ein Abstandsfeld der physikalischen Adresse innerhalb des Rahmens (Of) benutzt werden. Wie weiter unten beschrieben wird, können die AON- und P-Felder einer AON-logischen Adresse durch die Adressiermechanismen 10220 dann auf die Rahmennummer (FN) des MEM 10112-Rahmens, in dem sich die Seite befindet, bezogen werden.
Nachdem nun kurz die Beziehungen zwischen UIDs, UID-logischen Adressen, Namen, AONs, AON-logischen Adressen und MEM 10112-physikalischen Adressen beschrieben worden sind, werden im folgenden die Adressiermechanismen 10220 beschrieben.

2. Adressiermechanismen 10220 (Fig. 107)

In Fig. 107 wird eine schematische Darstellung der Adressierungsmechanismen 10220 des Computersystems 10110 gezeigt. Wie vorher beschrieben, umfassen die Adressierungsmechanismen 10220 UID/AON-Tabellen 10222, Speicherverwaltungstabellen 10224, Namenszwischenspeicher 10226 und die Adressenübersetzungseinheit 10228.
Die UID/AON-Tabellen 10222 beziehen die UID eines jeden Objekts auf seine AON und beinhalten eine AOT-Aufteilungstabelle (AOTHT) 10710, eine Tabelle der aktiven Objekte (AOT) 10712 und einen Tabellenanhang für diese Tabelle (AOTA) 10714.
Eine AON, die einer bestimmten UID entspricht, wird durch AOTHT 10710 bestimmt. Die UID ist aufgeteilt, um einen UID-Index in AOTHT 10710 hinein zur Verfügung zu stellen, der dann die entsprechende AON zur Verfügung stellt. AOTHT 10710 ist praktisch ein Beschleunigermechanismus für AOT 10712, um, wie eben beschrieben, eine schnelle Übersetzung von UIDs in AONs zu gewährleisten. Die AONs werden als Indizes in AOT 10712 gebraucht, der einen entsprechenden AOT-Eingang (AOTE) zur Verfügung stellt. Ein AOTE besteht, wie im folgenden bei der Diskussion des CS 10110 näher beschrieben wird, neben anderen Informationen aus der UID, die dem AON entspricht, der den AOTE indiziert. Zusätzlich zur Übersetzung von AONs in UIDs kann die UID eines AOTE mit der Original-UID verglichen werden, um die Richtigkeit einer AON von AOTHT 10710 zu bestimmen.
AOTA 10714 ist mit AOT 10712 assoziiert. AOTA 10714 ist eine Erweiterung von AOT 10712 und enthält bestimmte Informationen, die zu aktiven Objekten gehören, z. B. den Ausführungsbereich eines jeden aktiven Prozedurobjekts.
Nachdem die CS 10110-Mechanismen für die Beziehung zwischen UIDs und AONs kurz beschrieben worden sind, werden nun im folgenden die CS 10110-Mechanismen zur Auflösung von Operandennamen in AON-logische Adressen beschrieben.

3. Namensauflösung (Fig. 103, 108)

Indem wir uns zuerst auf Fig. 103 beziehen, wurde jedes Prozedurobjekt in einem VP, z. B. KOSPO 10318 in VP 10310, als eine Namenstabelle (NT) 10350 enthaltend beschrieben. Jede NT 10350 enthält für jeden Operanden, dessen Name in einer Prozedur auftaucht, einen Namenstabelleneingang (NTE). Jeder NTE enthält eine Beschreibung, aus der hervorgeht, wie der entsprechende Name zu einer AON-logischen Adresse aufzulösen ist und enthält Zugriffsinformationen, die Datentypinformationen, die zu jenem Namen gehören, und Informationen über die Länge des Datensegmentes, auf das sich bezogen wird.
In Fig. 108 wird eine Darstellung eines NTE gezeigt. Wie gezeigt, enthält dieses NTE sieben Informationsfelder: Kennzeichen, Basis (B), Vorverschiebung (PR), Länge (L), Verschiebung (D), Index (E) und Zwischenelement-Abstand (IES). Das Kennzeichenfeld enthält zum Teil Informationen, die beschreiben, wie die restlichen Felder des NTE zu interpretieren sind, die Typinformationen, auf die sich NTE bezieht, und wie jene Information verwaltet werden soll, wenn MEM 10112 auf sie zugreift. Das L-Feld zeigt, wie oben beschrieben, die Länge oder Anzahl der Bits im Datensegment an. Die Funktionen der anderen NTE-Felder werden während der folgenden Diskussionen beschrieben werden.
In einer vorliegenden Verkörperung des CS 10110 gibt es fünf NTE-Typen: (1) die Basis B ist nicht ein Name und die Adreßauflösung ist nicht indirekt; (2) B ist nicht ein Name und die Adreßauflösung ist indirekt; (3) B ist ein Name und die Adreßauflösung ist indirekt; (4) B ist ein Name und die Adreßauflösung ist indirekt. Der fünfte Typ ist ein NTE, der ein bestimmtes Element aus einem Vektor von Elementen auswählt. Diese fünf NTE-Typen und deren Auflösung werden unten in der oben beschriebenen Reihenfolge besprochen.
Im ersten Typ ist B nicht ein Name und die Adreßauflösung ist nicht indirekt, das B-Feld spezifiziert ein ABR 10364, der einen AON plus Abstand (AON/O)-Zeiger enthält. Die Inhalte des D-Feldes werden zum O-Feld dieses Zeigers addiert und das Ergebnis ist die AON-logische Adresse des Operanden. Im zweiten Typ ist B nicht ein Name und die Adreßauflösung ist indirekt. Das B-Feld spezifiziert wiederum ein ABR 10364, der einen AON/O-Zeiger enthält. Die Inhalte des PR-Feldes werden zum O-Feld des AON/O- Zeigers addiert, um die AON-logische Adresse eines Basiszeigers zur Verfügung zu stellen. Die AON-logische Adresse des Basiszeigers wird ausgewertet, wie unten beschrieben, und der Basiszeiger wird von MEM 10112 geholt. Die Inhalte des D-Feldes werden zum O-Feld des Basiszeigers addiert und das Ergebnis ist die AON-logische Adresse des Operanden.
Die NTE-Typen 3 und 4 entsprechen den NTE-Typen 1 respektive 2 und werden in der gleichen Weise aufgelöst, außer wenn das B-Feld einen Namen enthält. Der B-Feld-Name wird durch ein anderes NTE aufgelöst, um einen AON/O-Zeiger zu erhalten, der anstelle des ABR 10364-Zeigers, den wir in der Diskussion der Typen 1 und 2 besprochen haben, gebraucht wird.
Der fünfte Typ des NTE wird beim Referenzieren von Vektorelementen benutzt. Diese Vektor-NTEs werden in der gleichen Weise wie die NTE-Typen 1 bis 4 von oben aufgelöst, um die AON-logische Adresse des Anfangs des Vektors zur Verfügung zu stellen. Das I- und das IES-Feld stellen zusätzliche Informationen zur Verfügung, um ein bestimmtes Element im Vektor zu lokalisieren. Das I-Feld ist immer ein Name, der aufgelöst wird, um den Wert des Operanden zu erhalten, der das spezielle Vektorelement repräsentiert. Das IES-Feld enthält Information über den Abstand zwischen den Vektorelementen, d. h. die Anzahl von Bits zwischen nebeneinander liegenden Vektorelementen. Das IES-Feld kann den aktuellen IES-Wert enthalten oder aber einen Namen, der zu einer AON-logischen Adresse aufgelöst wird, die zum Wert des Zwischenelementabstandes führt. Die I- und IES-Werte, die man durch die eben beschriebene Auflösung der I- und IES-Felder enthält, werden miteinander multipliziert, um den Abstand des bestimmten Elements, auf das sich NTE bezieht, zum Beginn des Vektors zu bestimmen. Dieser vektorinterne Abstand wird zum O-Feld der AON-logischen Adresse des Anfangs des Vektors addiert, um die AON-logische Adresse des Elements zur Verfügung zu stellen.
In der gegenwärtigen Verkörperung des CS 10110 enthalten bestimmte NTE-Felder, z. B. B, D und das Kennzeichenfeld, immer Direktoperanden. Bestimmte andere Felder, z. B. IES, D, PRE und das L-Feld, können entweder Direktoperanden oder Namen, die aufzulösen sind, enthalten. Noch andere Felder, z. B. das I-Feld, enthalten immer Namen, die aufgelöst werden müssen.
Die Übergabe von Argumenten von einer rufenden Prozedur an eine gerufene Prozedur wurde oben mit Bezug auf virtuelle Prozesse 10212 besprochen und noch spezieller in Hinsicht auf die MAS 10328 bis 10334 des VP 10310. Die Übergabe von Argumenten wird durch die Namenstabellen 10350 der rufenden und der gerufenen Prozedur vollendet. Zur Erläuterung möge die Prozedur W (a, b, c) die Argumente a, b und c an die Prozedur X (u, v, w) übergeben, wobei die Argumente u, v und w den Argumenten a, b und c entsprechen sollen. Beim Kompilieren werden NTEs für die Argumente a, b und c im Prozedurobjekt von W erzeugt und NTEs werden für die Argumente u, v und w im Prozedurobjekt von Prozedur X erzeugt. Die NTEs von Prozedur X für u, v und w werden so konstruiert, daß sie auf Zeiger im Verkettungszeigerblock 10416 im Rahmen 10412 von Prozedur X im MAS zeigen. Um die Argumente a, b und c von Prozedur W zu Prozedur X zu übergeben, werden die NTEs der Argumente a, b und c zu AON- logischen Adressen (d. h. AON/O-Gestalt) aufgelöst. Die AON-logischen Adressen der Argumente a, b und c werden dann in die entsprechenden UID-Adressen übersetzt, die dann an jene Stellen des Verkettungszeigerblocks 10416 von Prozedur X plaziert werden, auf die die NTEs für u, v und w von Prozedur X zeigen. Wenn Prozedur X ausgeführt wird, werden die NTEs von Prozedur X für u, v und w aufgelöst, um die Zeiger auf die Argumente a, b und c im Verkettungszeigerblock 10416 von Prozedur X zu lokalisieren.
Wenn die Argumente in dieser Weise übergeben werden, werden die Informationen über den Datentyp und die Länge von den NTEs der gerufenen Prozedur erhalten und nicht von den NETs der rufenden Prozedur. Dies erlaubt der rufenden Prozedur, nur einen Teil z. B. der Argumente a, b oder c, der gerufenen Prozedur zu übergeben, und das kann als Merkmal der CS 10110-Schutzmechanismen angesehen werden.
Nachdem nun die Auflösung von Namen zu AON/Abstandsadressen und die Übersetzung von UID-Adressen in AON-Adressen kurz beschrieben worden ist, wird im folgenden die Auswertung von AON-Adressen in MEM 10112-physikalische Adressen beschrieben werden.

4. Die Auswertung von AON-Adressen zu physikalischen Adressen (Fig. 107)

In Fig. 107 wird ein Ausschnitt aus einer schematischen Darstellung der CS 10110- Speicherverwaltungstabelle 10224 gezeigt. Die Speicheraufteilungstabelle (MHT) 10716 und die Speicherrahmentabelle (MFT) 10718 sind von der Übersetzung von AON- Adressen in MEM 10112-physikalische Adressen betroffen und werden daher zuerst diskutiert. Die Arbeitssatzmatrix (WSM) 10720 und die Anforderungswarteschlange des virtuellen Speichermanagers (VMMRQ) 10722 sind mit der Verwaltung des in MEM 10112 verfügbaren physikalischen Adreßraums beauftragt und werden an zweiter Stelle diskutiert. Die Anforderungswarteschlange der aktiven Objekte (AORQ) 10728 und das logische Allokierungseinheitsverzeichnis (LAUD) 10730 haben damit zu tun, inaktive Objekte zu lokalisieren; die Verwaltung der aktiven Objekte in CS 10110 wird am Ende besprochen.
Die Übersetzung von AON/O-logischen Adressen in MEM 10112-physikalische Adressen wurde oben mit Bezug auf Fig. 106c diskutiert. Wie dort besprochen, sind die Objekte in Seiten unterteilt. In entsprechender Weise ist das O-Feld einer AON/O-logischen Adresse in ein 18 Bit-Seitennummernfeld (P) und ein 14 Bit-Feld (Op) für den Abstand innerhalb einer Seite unterteilt. MEM 10112 ist in Rahmen aufgeteilt, die in der gegenwärtigen Verkörperung von CS 10110 gleich groß wie die Seite eines Objekts sind. Das Op-Feld einer AON/O-Adresse kann daher direkt als ein Abstand innerhalb des Rahmens (Of) der entsprechenden physikalischen Adresse benutzt werden. Die AON- und P-Felder einer AON-Adresse müssen jedoch in einen MEM 10112-Rahmen, der durch eine entsprechende Rahmennummer (FN) dargestellt wird, übersetzt werden.
In Fig. 107 werden die AON- und P-Felder einer AON-Adresse "gehashed", um einen MHT-Index zu erzeugen, der als Index in MHT 10716 benutzt wird. Kurz umrissen versteht man unter "hashing" eine Methode, um Information in einer Tabelle zu indizieren oder zu lokalisieren, wobei die Indizes auf eine Information von der Information selbst über eine "hashing"-Funktion gebildet werden. Eine hashing-Funktion bildet jedes Informationsstück auf den von ihr generierten Index über die hashing-Funktion ab. MHT 10716 stellt dann die entsprechende FN des MEM 10112-Rahmens zur Verfügung, in dem die Seite gespeichert ist. Die FNs werden als Indizes in MFG 10718 benutzt, die für jedes FN einen Eingang enthalten, der die in jenem Rahmen gespeicherte Seite beschreibt. Diese Information beinhaltet die AON und P der Seite, die in jenem MEM 10112-Rahmen gespeichert sind. Ein FN kann daher von MHT 10716 als ein Index in MFT 10718 gebraucht werden und das resultierende AON/P des MFT 10718 kann mit dem Original- AON/P verglichen werden, um die Korrektheit des FN, der von MHT 10716 erhalten wird, zu bestätigen. MHT 10716 ist ein effektiver Beschleunigermechanismus von MFT 10718, um eine schnelle Übersetzung von AON-Adressen in MEM 10112-physikalische Adressen zur Verfügung zu stellen.
MFT 10718 speichert auch "benötigte" und "veränderte" Informationen für jede Seite in MEM 10112 ab. Diese Information zeigt an, welche Seitenrahmen darin schon benutzt wurden und welche schon verändert wurden. Diese Information wird von CS 10110 benötigt, wenn es bestimmen soll, welche Rahmen von MEM 10112 gelöscht werden können oder frei sind, wenn Seiten vom Zusatzspeicher (ED) 10124 in MEM 10112 geschrieben werden sollen. Wenn z. B. das Modifizierbit einer Seite anzeigt, daß auch diese Seite nicht geschrieben wurde, so ist es nicht nötig, diese Seite zurück in den Zusatzspeicher zu schreiben, wenn es von MEM 10112 gelöscht wird. Statt dessen kann die Seite einfach gelöscht werden.
ATU 10228 schließlich ist ein Beschleunigermechanismus für MHT 10716. Die AON/O- Adressen werden direkt - ohne hashing - als Indizes in ATU 10228 benutzt und ATU 10228 stellt die entsprechenden FN- und O-Ausgaben korrekt zur Verfügung. Ein CS 10110-Mechanismus, der in der folgenden genaueren Beschreibung des CS 10110-Betriebs näher beschrieben wird, aktualisiert die Inhalte von ATU 10228 kontinuierlich so, daß ATU 10228 die FNs und Op (Of) der Seiten enthält, auf die der gegenwärtige Prozeß am häufigsten zugreift. Falls ATU 10228 keinen entsprechenden Eingang für eine gegebene AON-Eingabe enthält, so entsteht ein ATU-Fehler und die FN- und O-Information kann direkt aus MHT 10716 erhalten werden.
WSM 10720 und VMMRQ 10722 sind, wie oben festgestellt, Mechanismen, die mit der Verwaltung des MEM 10112 zur Verfügung stehenden Adreßraums beauftragt sind. Wenn z. B. MHT 10716 und MFT 10718 keinen Eingang für eine Seite enthalten, auf die die gegenwärtige Prozedur zugreift, passiert ein MHT/MFT-Fehler und die entsprechende Seite muß vom Zusatzspeicher (ED) 10124 geholt und in MEM 10112 gelesen werden. WSM 10720 enthält einen Eingang für jede in MEM 10112 befindliche Seite. Auf diese Eingänge wird durch Indizes zugegriffen, die die virtuelle Prozessornummer (VPN) des virtuellen Prozesses enthalten, der auf die Seite zugreift, und das P der Seite, auf die zugegriffen wird, umfaßt. Jeder WSM 10720-Eingang enthält zwei Bits, die anzeigen, ob eine bestimmte Seite Teil eines VP-Arbeitssets ist, d. h. von diesem VP benutzt wird, und ob auf jene Seite von jenem VP Bezug genommen wird. Diese und die Information, die in den oben beschriebenen MFT 10718-Eingängen enthalten sind, werden von CS 10110's virtuellem Speichermanager (VMM) beim Transfer von Seiten in und aus MEM 10112 heraus benutzt.
CS 10110's VMM pflegt VMMRQ 10722, das von VMM dazu benutzt wird, den Seitentransfer in MEM 10112 hinein und aus ihm heraus zu steuern. VMMRQ 10722 beinhaltet den virtuellen Speicheranforderungszähler (VMRC) 10724 und eine Warteschlange von virtuellen Speicheranforderungseingängen (VMREs) 10726. Wie jetzt diskutiert werden soll, verfolgt VMRC 10724 die Anzahl der gegenwärtig anstehenden Seitenanforderungen. Jedes VMRE 10726 beschreibt eine bestimmte Seite, für die eine Anforderung vorliegt. Bei einem MHT/MFT-(oder Seiten-)Fehler wird VMRC 10724 inkrementiert, was den Betrieb des CS 10110's VMM initiiert und ein VMRE 10726 wird in die Warteschlange gestellt. Jedes VMRE 10726 umfaßt das VPN des Prozesses, der die Seite anfordert, und das AON/O der angeforderten Seite. Zu diesem Zeitpunkt wird der VP, der die Anforderung macht, aus JP 10114 herausgetauscht und ein anderer VP wird an JP 10114 gebunden. VMM allokiert einen MEM 10112-Rahmen zur Aufnahme der angeforderten Seite, indem er die eben beschriebene Information in MFT 10718 und WSM 10720 dazu benutzt, diesen Rahmen auszuwählen. Auf diese Weise kann VMM eine Seite, die momentan z. B. in MEM 10112 residiert, ausrangieren, weil sie die älteste Seite ist, oder weil sie nicht benutzt wird, oder weil sie eine unveränderte Seite ist, die nicht in den Zusatzspeicher zurückgeschrieben werden muß. VMM erfordert dann eine Eingabe/Ausgabe-Operation, um die angeforderte Seite in den Rahmen zu transferieren, der von VMM ausgewählt worden ist. Während dieser Ein-/Ausgabe-Operation erzeugt VMM neue Eingänge in MHT 10716 und MFT 10718 für die angeforderte Seite, säubert den Rahmen in MEm 10112, der von jener Seite besetzt werden soll, und stoppt den Betrieb. IOS 10116 fährt damit fort, die Ein-/Ausgabe-Operation auszuführen und schreibt die angeforderte Seite direkt in MEM 10112 in den Rahmen, der von VMM spezifiziert worden ist. IOS 10116 signalisiert dann CS 10110's VMM, daß die Seite nun im Speicher residiert und referenziert werden kann. Einige Zeit später wird jener VP, der die Seite angefordert hat, die Ausführung wieder aufnehmen und jene Bezugnahme wiederholen. Wenn er zuerst zu ATU 10228 geht, würde VP einen ATU 10228-Fehler verursachen, weil VP 10212 noch nicht aktualisiert wurde, um die Seite aufnehmen zu können. Der VP würde dann nach MHT 10716 und MFT 10718 wegen der angeforderten Information gehen und gleichzeitig würden WSM 10720 und ATU 10228 aktualisiert werden.
Bezüglich der obigen Operationen wird jedem in CS 10110 aktiven VP ein Seitenfehlerhäufigkeits-Zeitfaktor (PFFT) zugeordnet, der von CS 10110's VMM dazu benutzt wird, den Arbeitssatz jenes VP so anzugleichen, daß das Intervall zwischen zwei aufeinander folgenden Seitenfehlern für den VP in einem optimalen Zeitbereich liegt. Dies trägt dazu bei, daß VMM von CS 10110 äußerst wirksam arbeiten kann, und erlaubt es, das VMM von CS 10110 nach Belieben zu tunen.
Die obigen Diskussionen sind von der Annahme ausgegangen, daß die Seite, auf die Bezug genommen wird, sei es von einer UID/O-Adresse oder einer AON/O-Adresse oder von einem Namen, in einem in CS 10110 aktiven Objekt residiert. Während ein Objekt nicht gezwungenermaßen eine Seite in MEM 10112 haben muß, um aktiv zu sein, muß das Objekt aktiv sein, um eine Seite in MEM 10112 zu haben. Ein VP hingegen kann eine Seite in einem nicht aktiven Objekt in CS 10110 referenzieren. Falls eine solche Bezugnahme gemacht wird, muß das Objekt in CS 10110 aktiv gemacht werden, bevor die Seite nach MEM 10112 gebracht werden kann. Das Ergebnis ist eine Operation ähnlich wie die Seitenfehleroperation, die oben beschrieben wurde. CS 10110 betreibt einen Manager für aktive Objekte (AOM), der eine Anforderungswarteschlange für aktive Objekte (AORQ) 10728 beinhaltet, die ähnlich arbeitet wie CS 10110's VMM und VMMRQ 10722. Das AOM und AORQ 10728 von CS 10110 arbeiten in Verbindung mit AOTHT 10710 und AOT 10712, um inaktive Objekte zu lokalisieren und sie aktiv zu machen, indem sie innen AONs zuordnen und ihnen Eingänge in AOTHT 10710, AOT 10712 und AOTA 10714 zu erzeugen.
Bevor ein bestimmtes Objekt in CS 10110 aktiv gemacht werden kann, muß es zuvor im Zusatzspeicher (ED) 10124 lokalisiert werden. Alle Objekte im Zusatzspeicher werden durch ein logisches Allokationseinheitsverzeichnis (LAUD) 10730 lokalisiert, das im Zusatzspeicher residiert. Ein LAUD 10730 enthält für jedes Objekt, zu dem ein bestimmtes CS 10110 Zugang besitzt, Eingänge. Jeder LAUD 10730-Eingang enthält die notwendigen Informationen, um einen AOT 10712-Eingang für jenes Objekt zu erzeugen. Auf ein LAUD 10730 wird durch eine UID/O-Adresse, die in CS 10110's VMM enthalten ist, zugegriffen. Eine Bezugnahme zu LAUD 10730 resultiert in MEM 10112-Rahmen, die jenem LAUD 10730 zugewiesen werden, und darin, daß LAUD 10730 nach MEM 10112 transferiert wird. Falls ein LAUD 10730-Eingang für das referenzierte inaktive Objekt existiert, wird der LAUD 10730-Eingang in AOT 10712 transferiert. Bei der nächsten Bezugnahme auf eine Seite in dem Objekt würde AOT 10712 die AON für jenes Objekt zur Verfügung stellen, aber es würde zu einem Seitenfehler kommen, weil die Seite noch nicht in MEM 10112 transferiert worden ist. Dieser Seitenfehler würde, wie oben beschrieben, behandelt werden und die referenzierte Seite würde nach MEM 10112 transferiert werden.
Nachdem nun in kurzer Weise die Struktur und der Betrieb der Adressierungsstruktur von CS 10110 einschließlich der Beziehung zwischen UIDs, Namen, AONs und physikalischen Adressen und den Mechanismen, mit Hilfe derer CS 10110 den MEM 10112 verfügbaren Adreßraum verwaltet, beschrieben wurde, werden im folgenden die Schutzstrukturen von CS 10110 beschrieben.

E. Die Schutzmechanismen von CS 10110 (Fig. 109)

In Fig. 109 wird eine schematische Darstellung des Schutzmechanismus 10230 gezeigt. Die Schutztabellen 10232 enthalten die Zugangsmatrix für aktive Elemente (APAM) 10910, die Aufteilungstabelle für die aktiven Subjektnummern (ASNHT) 10912 und die Tabelle der aktiven Subjekte (AST) 10914. Die Bereiche der Schutzmechanismen 10230, die in FU 10120 liegen, beinhalten ASN-Register 10916 und Schutzzwischenspeicher (PC) 10234.
Wie früher beschrieben, werden die Zugangsrechte zu Objekten auf der Basis der Subjekte gehandelt. Ein Subjekt war definiert worden als eine spezielle Kombination aus Betriebsart, Prozeß und Bereich (PPD), wobei alle durch entsprechende UIDs identifiziert werden. Jedes Objekt besitzt eine Zugangskontroll-Liste (ACL) 10918, die mit ihm verbunden ist, und für jedes Subjekt, welches Zugang zu jenem Objekt besitzt, einen ACL-Eingang (ACLE).
Wenn ein Objekt in CS 10110 aktiv wird (d. h. es wird ihm eine AON zugewiesen), so wird jene ACLE in der ACL 10918 von jenem Objekt in APAM 10910 geschrieben. Gleichzeitig wird jedem Subjekt, das zu jenem Objekt Zugang besitzt und für welches es ein ACLE in der ACL 10918 jenes Objekts gibt, eine aktive Subjektnummer (ASN) zugewiesen. Diese ASNs werden in ASNHT 10912 geschrieben, und ihre entsprechenden PPDs werden in AST 10914 geschrieben. Anschließend erhält man die ASN eines jeden Subjekts, das zu jenem Objekt Zugang fordert, durch "hashing" der PPD von jenem Subjekt, um einen PPD-Index in ASNHT 10912 zu erhalten. ASNHT 10912 wiederum würde eine entsprechende ASN zur Verfügung stellen. Ein ASN kann als ein Index in AST 10914 genutzt werden. AST 10914 würde eine entsprechende PPD zur Verfügung stellen, die mit der Original-PPD verglichen werden kann, um die Genauigkeit der ASN zu bestätigen.
Wie oben beschrieben, erhält APAM 10910 eine ACL 10918 für jedes in CS 10110 aktive Objekt. Die Zugangsrechte eines jeden bestimmten aktiven Subjekts auf ein spezielles aktives Objekt werden durch die Benutzung der ASN jenes Subjekts und der AON jenes Objekts als Indizes in APAM 10910 bestimmt. APAM 10910 wiederum stellt ein vier Bit- Output zur Verfügung, in dem definiert wird, ob jenes Subjekt Leserechte (R), Schreibrechte (W) oder Ausführungsrechte (E) bezüglich jenes Objektes hat und ob jener bestimmte Eingang gültig (V) ist.
Die ASN-Register 10916 und PC 10234 sind praktisch Beschleunigermechanismen der Schutztabellen 10232. Das ASN-Register 10916 speichert die ASN eines gerade aktiven Subjekts, während PC 10234 bestimmte Zugangsrechtsinformationen für Objekte, die von dem gegenwärtigen Prozeß benutzt werden, speichert. Die PC 10234-Eingänge werden mittels ASNs vom ASN-Register 10916 und durch ein Betriebsarten-Input von JP 10114 indiziert. Der Betriebsarten-Input definiert, ob die aktuelle Prozedur beabsichtigt, ein bestimmtes Objekt, das einen Eingang in PC 10234 hat, zu lesen, zu schreiben oder auszuführen. Beim Empfang der ASN und der Betriebsarten-Inputs stellt PC 10234 ein "okay/nicht okay-Output" zur Verfügung, der anzeigt, ob jenes Subjekt die erforderlichen Rechte besitzt, die beabsichtigte Operation an jenem Objekt zu verrichten.
Zusätzlich zum obigen Mechanismus besitzt jede Prozedur, an die in einem bereichsübergreifenden Aufruf Argumente übergeben werden können, mit sich selbst verbunden ein Zugangsinformationenvektor (AIA) 10352, wie wir im Zusammenhang mit virtuellen Prozessen 10212 bereits besprochen haben. Der AIA 10352 einer Prozedur stellt fest, welche Zugangsrechte eine rufende Prozedur (Subjekt) auf ein bestimmtes Objekt (Argument) haben muß, bevor die gerufene Prozedur mit den übergebenen Argumenten arbeiten kann. Die CS 10110-Schutzmechanismen vergleichen die Zugangsrechte der rufenden Prozedur mit den Rechten, die von der gerufenen Prozedur gefordert werden. Dies stellt sicher, daß die rufende Prozedur die gerufene Prozedur nicht dazu auffordern kann, etwas zu tun, wofür die rufende Prozedur nicht die Erlaubnis besitzt. Eine rufende Prozedur kann der gerufenen Prozedur praktisch nur die Zugangsrechte geben, die sie selbst besitzt.
Schließlich werden PC 10234-, APAM 10910- oder AST 10914-Fehler (d. h. Mängel) in der gleichen Weise behandelt wie oben beschrieben für die Seitenfehler in der Diskussion der Adressierungsmechanismen 10220 von CS 10110. Als solche wird die Behandlung der Schutzmängel an dieser Stelle nicht weitergeführt.
Nachdem nun kurz die Struktur und der Betrieb der Schutzmechanismen 10230 des CS 10110 beschrieben wurden, werden im folgenden nun die CS 10110-Mikrobefehlsmechanismen 10236 beschrieben werden.

F. Mikrobefehlsmechanismen der CS 10110 (Fig. 110)

Wie früher beschrieben, ist CS 10110 eine Mehrsprachenmaschine. Jedes in einer höheren Programmiersprache geschriebenes Programm wird in ein entsprechendes S-Sprachen- Programm kompiliert, welches die Befehle in Form von SINs enthält. CS 10110 stellt einen Satz oder Dialekt von Mikrocodebefehlen zur Verfügung, die wir als S-Interpreter (SINTs) für jede S-Sprache bezeichnen. Die SINTs interpretieren SINs und stellen entsprechende Mikrobefehlsabfolgen für die genauere Steuerung des CS 10110 zur Verfügung.
In Fig. 110 wird ein Teilausschnitt aus einer schematischen Darstellung der Mikrobefehlsmechanismen 10236 von CS 10110 gezeigt. Bei der Systeminitialisierung wird der ganze CS 10110-Mikrocode einschließlich SINTs und sämtlichen Maschinenunterstützungsmikrocodes vom Zusatzspeicher zum Mikrocodesteuerspeicher (mCCS) 10238 in MEM 10112 transferiert. Der Mikrocode wird dann von mCCS 10238 zu FU-Mikrocodestruktur (FUmC) 10240 und EU-Mikrocodestruktur (EUmC) 10242 transferiert. EUmC 10242 ist in Struktur und Betrieb ähnlich wie FUmC 10240 und wird daher in der folgenden genaueren Beschreibung der Struktur und des Betriebs von CS 10110 näher beschrieben werden. In ähnlicher Weise wird der CS 10110-Maschinenunterstützungsmikrocode im folgenden genauer beschrieben werden. Die gegenwärtige Diskussion betrifft die CS 10110-S-Interpreter-Mechanismen.
Die CS 10110-S-Interpreter (SINTs) werden in die S-Interpreter-Tabelle (SITT) 11012 geladen, die in Fig. 110 als die, S-Interpreter von 1 bis N enthaltend, dargestellt ist. Jedes SIT enthält eine oder mehrere Mikrocodesequenzen; jede Mikrocodesequenz entspricht einem speziellen SIN in jenem S-Sprachen-Dialekt. Die S-Interpreter-Verteilertabelle (SDT) 11010 enthält S-Interpreter-Verteiler (SDs) 1 bis N. In SITT 11012 gibt es für jeden SINT ein SD und so ein SD für jeden S-Sprachen-Dialekt. Jeder SD umfaßt einen Satz von Zeigern. Jeder Zeiger in einem speziellen SD entspricht einer bestimmten SIN jenes SD-Dialekts und zeigt auf die entsprechende Abfolge von Mikrobefehlen, um jene SIN im SITT 11012 im SIT jenes Dialekts zu interpretieren. Das SIP für jene Prozedur wird in eines der mCRs 10366 transferiert, wie vorher bei der Diskussion über die Ausführung einer bestimmten Prozedur verdeutlicht wurde. Jener SIP zeigt auf den Anfang des SD des SIT, der bei der Interpretation der SINs jener Prozedur benutzt werden soll. In Fig. 110 zeigt SIP in mCRs 10366, wie abgebildet, auf den Anfang von SD2. Jedes S-Op, welches während der Ausführung jener Prozedur auftaucht, ist ein Abstand relativ zum Anfang des ausgewählten SD, der auf einen entsprechenden SD- Zeiger zeigt. Dieser SD-Zeiger wiederum zeigt auf die entsprechende Mikrobefehlsabfolge für die Interpretation jenes SIN im entsprechenden SIT im SITT 11012. Wie in der folgenden Diskussion beschrieben wird, fährt die CS 10110-Mikromaschine damit fort, die Mikrobefehle jener Sequenz von SITT 11012 nach der Reihe abzuarbeiten und jene Mikrobefehle für die Steuerung des Betriebs des CS 10110 zu benutzen, sobald der Beginn einer Mikrocodeabfolge für die Interpretation eines SIN ausgewählt worden ist.

G. Zusammenfassung über bestimmte CS 10110-Merkmale und alternative Verkörperungen

Der obige einführende Überblick hat die Gesamtstruktur und den Betrieb und bestimmte Merkmale des CS 101, d. h. CS 10110, beschrieben. Die obige Einführung hat weiterhin die Struktur und den Betrieb und weitere Merkmale des CS 10110 und insbesondere die physikalische Implementierung und den Betrieb der Informationssteuerungs- und Adressierungsmechanismen des CS 10110 beschrieben. Bestimmte dieser CS 10110-Merkmale werden im folgenden zusammengefaßt, um kurz die Grundkonzepte dieser Merkmale, wie sie in CS 10110 implementiert sind, festzustellen. Darüber hinaus werden andere mögliche Verkörperungen bestimmter dieser Konzepte beschrieben.
Zunächst umfaßt CS 10110 eine Vielzahl von unabhängig operierenden Prozessoren, wobei jeder Prozessor eine separate Mikrobefehlssteuerung besitzt. In der vorliegenden Verkörperung des CS 10110 beinhalten diese Prozessoren FU 10120, EU 10122, MEM 10112 und IOS 10116. Andere solche unabhängig arbeitenden Prozessoren, z. B. spezielle arithmetische Prozessoren wie Vektorprozessoren oder Mehrfach-FU's 10120, können zu der vorliegenden CS 10110-Konfiguration zugefügt werden.
In dieser Hinsicht ist MEM 10112 ein Vielkanalprozessor, der einen oder mehrere separate und unabhängige Kanäle für jeden Prozessor in CS 10110 besitzt. Jede Kommunikation zwischen den Prozessoren von CS 10110 geschieht über MEM 10112, so daß MEM 10112 als der zentrale Kommunikationsknoten von CS 10110 arbeitet und gleichermaßen Speicheroperationen durchführt. Weitere separate und unabhängige Kanäle können an MEM 10112 angefügt werden, genauso wie weitere Prozessoren an CS 10110 angefügt werden können. CS 10110 kann daher beschrieben werden als eine Vielzahl von separaten unabhängigen Prozessoren umfassend, von denen jeder eine separate Mikrobefehlssteuerung enthält und jeder einen separaten und unabhängigen Kanal zu einem zentralen Kommunikations- und Speicherknoten hat, der als solches ein unabhängiger Prozessor mit separater und unabhängiger Mikrobefehlssteuerung ist. Wie in einer folgenden genaueren Beschreibung des MEM 10112 näher beschrieben werden wird, umfaßt MEM 10112 selbst eine Vielzahl von unabhängig arbeitenden Prozessoren, von denen jeder speicherbezogene Operationen durchführt und jeder eine separate Mikrobefehlssteuerung besitzt. Die Koordination der Operationen zwischen den Prozessoren des CS 10110 wird durch die Übergabe von "Nachrichten" zwischen den Prozessoren erreicht, z. B. SOPs und Beschreiber.
Die Adressiermechanismen von CS 10110 basieren vor allem auf der UID-Adressierung von Objekten. Das heißt, jede Information, die für den Gebrauch in oder durch den Betrieb einer CS 10110 erzeugt wird, z. B. Daten und Prozeduren, ist in Objekte strukturiert und jedem Objekt wird eine permanente UID zugeordnet. Jede UID ist innerhalb eines speziellen CS 10110 und auch zwischen allen CS 10110's eindeutig und wird andauernd mit einem speziellen Objekt in Verbindung gebracht. Der Gebrauch der UID- Adressierung stellt ein permanentes, eindeutiges Adressierungsmittel zur Verfügung, das allen CS 10110 und anderen Computersystemen, die CS 10110's UID-Adressierung benutzen, gemeinsam ist.
UID-Adressierung bedeutet praktisch, daß der Adreß- (oder Speicher-) Raum einer speziellen CS 10110 den Adreßraum aller Systeme, z. B. Festplattenlaufwerke oder andere CS 10110's, zu denen jene bestimmte CS 10110 Zugang hat, beinhaltet. UID-Adressierung erlaubt, daß jeder Prozeß in jeder CS 10110 Zugang zu jedem Objekt in jeder CS 10110, zu der sie physikalischen Zugang hat, z. B. zu einer anderen CS 10110 auf der anderen Seite der Welt, Zugang gewinnt. Dieser Zugang wird nur durch die CS 10110- Schutzmechanismen eingeschränkt. In alternativen Verkörperungen des CS 10110 können bestimmte UIDs separat nur für den Gebrauch innerhalb einer bestimmten CS 10110 abgestellt werden und sind dann nur innerhalb dieser bestimmten CS 10110 eindeutig. Diese UIDs würden jedoch eine begrenzte Gruppe bilden, die allen CS 10110-Systemen als nicht eindeutig zwischen Systemen bekannt sind, so daß die Fähigkeit zur eindeutigen Objektadressierung der CS 10110-UID-Adressierung gewährleistet ist.
Wie vorher festgestellt, werden AONs und physikalische Beschreiber gegenwartig für die Adressierung innerhalb CS 10110 benutzt, praktisch als abgekürzte UIDs. In anderen Verkörperungen von CS 10110 können andere Formen von AONs genutzt werden oder die AONs können gänzlich verworfen werden und die UIDs zur Adressierung innerhalb als auch zwischen CS 10110's benutzt werden.
Die Adressiermechanismen von CS 10110 basieren auch auf dem Gebrauch von Deskriptoren innerhalb und zwischen CS 10110's. Jeder Beschreiber enthält ein AON- oder UID-Feld, um ein bestimmtes Objekt zu identifizieren, ein Abstandsfeld, um einen Bitgenauen Abstand innerhalb des Objekts zu spezifizieren und ein Längenfeld, um eine bestimmte Anzahl von Bits zu spezifizieren, beginnend am spezifizierten Abstand. Deskriptoren können auch Typ- oder Formatfelder enthalten, die ein bestimmtes Format der Daten identifizieren, auf die der Deskriptor Bezug nimmt. Physikalische Deskriptoren werden für die Adressierung von MEM 10112 benutzt und in diesem Fall werden die AON- oder UID-Felder durch ein Rahmennummernfeld ersetzt, welches sich auf eine physikalische Lokation in MEM 10112 bezieht.
Wie oben festgestellt, werden Deskriptoren zur Adressierung innerhalb und zwischen den separaten unabhängigen Prozessoren (FU 10120, EU 10122, MEM 10112 und IOS 10116), die CS 10110 umfaßt, benutzt, und es wird auf diese Weise eine gemeinsame systemweite Bit-genaue Adressierungsmöglichkeit inklusive Formatinformation zur Verfügung gestellt. Im Besonderen antwortet MEM 10112 auf die Typinformationsfelder der Beschreiber, indem es Formatoperationen durchführt, um anfordernden Elementen Daten in dem Format zur Verfügung zu stellen, das das anfordernde Element im Beschreiber spezifiziert hat. MEM 10112 akzeptiert auch Daten in einem deskriptorspezifizierten Format und formatiert jene Daten in ein Format um, das von MEM 10112 am effektivsten zur Speicherung der Daten genutzt werden kann.
Wie vorher beschrieben, findet der Bezug zu allen Operanden in CS 10110 durch Namen statt, wobei alle Namen innerhalb eines speziellen S-Sprachen-Dialekts von einheitlicher, fester Größe und Format sind. Ein K-Wert, der die Namensgröße spezifiziert, wird FU 10120 bei jedem Wechsel des S-Sprachen-Dialekts zur Verfügung gestellt und wird von FU 10120 dazu benutzt, die Namen vom Befehlsstrom zu analysieren. In einer anderen Verkörperung des CS 10110 haben die Namen dieselbe Größe in allen S-Sprachen- Dialekten, so daß K-Werte und die damit verbundene Ablauflogik in FU 10120's Analysator nicht erforderlich sind.
Schließlich wurde bei den Beschreibungen, wie CS 10110 die SOPs benutzt, die Mikrobefehlsablauflogik von FU 10120 als Speicherung von einem oder mehreren S-Interpretern beschrieben. Die S-Interpreter sind Mikrobefehlsabfolgesätze für die Interpretation von SOPs der verschiedenen S-Sprachen-Dialekte und stellen entsprechende Mikrobefehlssequenzen zur Verfügung, um CS 10110 zu steuern. In einer anderen Verkörperung von CS 10110 würden diese S-Interpreter (SITT) 11012 in MEM 10112 gespeichert werden. FU 10120 würde die SOPs von dem Befehlsstrom empfangen und würde die SITT 11012, die in MEM 10112 gespeichert sind, adressieren, indem sie einen oder mehrere S- Interpreter-Basiszeiger benutzt (d. h. architektonische Basiszeiger, die auf SITT 11012 in MEM 10112 zeigen). MEM 10112 würde darauf reagieren, indem es Mikrobefehlsabfolgen von SITT 11012 in MEM 10112 zur Verfügung stellt, die direkt zur Steuerung des CS 10110 benutzt werden können. Als Alternative könnte SITT 11012 in MEM 10112 konventionelle Befehle, die von einer konventionellen CPU genutzt werden können, zur Verfügung stellen, z. B. FORTRAN oder Maschinensprachenbefehle. Dies z. B. würde es FU 10120 erlauben, durch eine konventionelle CPU, wie z. B. Data General Corporation Eclipse, ersetzt zu werden.
Nachdem nun bestimmte Merkmale des CS 10110 und alternative Verkörperungen von bestimmten dieser Merkmale kurz zusammengefaßt worden sind, wird im folgenden die Struktur und der Betrieb der CS 10110 genauer beschrieben werden.

2. Genaue Beschreibung der wichtigsten Subsysteme von CS 10110 (Fig. 201 bis 206. 207 bis 274)

Nachdem im Vorangegangenen die Gesamtstruktur und der Betrieb des CS 10110 beschrieben worden sind, wird nun die Struktur und der Betrieb der wichtigsten Subsysteme von CS 10110 individuell und präziser beschrieben werden. Wie vorher besprochen, sind die wichtigsten Subsysteme von CS 10110 in der Reihenfolge, in der sie beschrieben werden, MEM 10112, FU 10120, EU 10122, IOS 10116 und DP 10118. Individuelle Blockdiagramme von MEM 10112, FU 10120, EU 10122, IOS 10116 und DP 10118 werden in den Fig. 201 bis respektive 205 gezeigt. Die Fig. 201 bis 205 können, wie in Fig. 206 gezeigt, so zusammengestellt werden, daß sie ein detaillierteres Blockdiagramm von CS 10110 ergeben, was dem entspricht, das in Fig. 101 gezeigt wurde. Für die Zwecke der folgenden Beschreibungen sei angenommen, daß die Fig. 201 bis 205, wie in Fig. 206 gezeigt, zusammengestellt sind, um ein solches Blockdiagramm zu bilden. Es werden weitere Diagramme in den folgenden Beschreibungen vorgestellt werden, je nachdem, wie es erforderlich ist, einem gewöhnlichen Fachmann auf dem Gebiet die Struktur und den Betrieb von CS 10110 klar zu machen.
Wie vorher beschrieben, ist MEM 10112 ein intelligenter, Prioritäten setzender Speicherbaustein, der separate und unabhängige Kanäle MIO 10128 und MJP 10140 nach IOS 10116 respektive JP 10114 hat. MEM 10112 wird von JP 10114 und IOS 10116 geteilt, ist ihnen beiden zugängig und ist der Hauptspeicher von CS 10110. Darüber hinaus ist MEM 10112 der Hauptpfad für den Informationstransfer zwischen der externen Welt (über IOS 10116) und JP 10114.
Wie weiter beschrieben werden wird, ist MEM 10112 ein Zwei-Ebenen-Speicher, der schnellen Zugang zu den Daten, die in ihm gespeichert sind, ermöglicht. Die erste Ebene von MEM 10112 umfaßt einen großen Satz Vektoren freien Zugriffs, und die zweite Ebene von MEM 10112 umfaßt einen Hochgeschwindigkeits-Zwischenspeicher, dessen Betrieb im allgemeinen den Speichernutzern, d. h. JP 10114 und IOS 10116, bekannt ist. Informationen, die in MEM 10112 gespeichert sind, erscheinen auf beiden Ebenen sowohl JP 10114 als auch IOS 10116 bitweise adressierbar. Darüber hinaus stellt MEM 10112 einfache Schnittstellen JP 10114 und IOS 10116 zur Verfügung. Aufgrund hochgradigem Pipelinings (gleichzeitige und überlappende Speicheroperationen) erscheinen die Schnittstellen von MEM 10112 zu JP 10114 und IOS 10116 so, als ob JP 10114 und IOS 10116 beide vollen Zugang zu MEM 10112 besitzen würden. Dieses Merkmal erlaubt Datentransferraten von z. B. 63,6 Megabytes pro Sekunde von MEM 10112 und 50 Megabytes pro Sekunde zu MEM 10112.
In den folgenden Beschreibungen wird eine bestimmte Terminologie benutzt, die zuerst vorgestellt werden soll, danach wird die physikalische Organisation von MEM 10112 beschrieben. Darauf werden die Kanalstrukturen von MEM 10112 beschrieben, und danach folgen Beschreibungen der Steuerungsorganisation und des Steuerungsflusses von MEM 10112. Danach werden die Schnittstellen von MEM 10112 zu JP 10114 und IOS 10116 beschrieben. Nach diesen allgemeinen Beschreibungen werden die hauptsächlichen logischen Strukturen von MEM 10112 individuell beschrieben, beginnend mit den MEM 10112-Schnittstellen zu JP 10114 und IOS 10116, und einwärts fortschreitend zu MEM 10112's erster Ebene (Massenebene) der gespeicherten Daten. Schließlich werden bestimmte Merkmale der Mikrocodesteuerungsstruktur von MEM 10112 beschrieben.

A. MEM 10112 (Fig. 201, 206, 207-237)

a. Terminologie

Bestimmte Ausdrücke werden durchgängig in den folgenden Beschreibungen benutzt und hier definiert, damit der Leser darauf Bezug nehmen kann:
Ein Wort sind 32 Datenbits.
Ein Byte sind 8 Datenbits.
Ein Block sind 128 Datenbits (d. h. vier Wörter).
Ein Block ist immer an einer Blockgrenze positioniert, d. h. die sieben am wenigsten signifikanten Bits der logischen oder physikalischen Adressen sind Null (siehe auch Kapitel 1, Abschnitte A.f und D., Beschreibung der der Adressierung von CS 10110).
Der Ausdruck "ausgerichtet" bezieht sich auf die Anfangsbitadresse eines Datenausdrucks relativ zu bestimmten Adreßgrenzen. Eine Anfangsbitadresse ist Block-ausgerichtet, wenn die sieben niedrigsten Bits der Anfangsbitadresse Null sind, d. h. die Anfangsbitadresse fällt auf eine Grenze zwischen zwei nebeneinander liegenden Blöcken. Eine Wortausgerichtete Anfangsbitadresse bedeutet, daß die niedrigsten fünf Bits der Anfangsbitadresse Null sind, und die Anfangsbitadresse zeigt auf eine Grenze zwischen zwei nebeneinander liegenden Worten. Ein Byte-ausgerichtete Anfangsbitadresse bedeutet, daß die niedrigsten drei Bits der Anfangsbitadresse Null sind, und die Anfangsbitadresse auf eine Grenze zwischen zwei benachbarten Bytes zeigt.
Bit-genaue Daten haben eine Anfangsbitadresse, die innerhalb eines Bytes fällt, aber nicht auf eine Bytegrenze, oder aber die Adresse ist an einer Bytegrenze ausgerichtet, aber die Länge der Daten ist Bit-genau, d. h. sie ist nicht ein Vielfaches von acht Bits.

b. Die physikalische Struktur von MEM 10112 (Fig. 201)

In Fig. 201 wird ein Ausschnitt aus einem Blockdiagramm von MEM 10112 gezeigt. Die wichtigsten funktionalen Einheiten von MEM 10112 sind die Hauptspeicherbank (MSB) 20110, die die Speichervektoren (MAs) 20112, den Bankcontroller (BC) 20114 und den Speicherzwischenspeicher (MC) 20116 umfaßt, der wiederum die Umgehungsschreibdatei (BYF) 20118, die Feldisolationseinheit (FIU) 20120 und den Speicherschnittstellencontroller (MIC) 20122 umfaßt.
MSB 20110 umfaßt MEM 10112's ersten oder Massenspeicher. MSB 20110 kann zwischen einem und z. B. 16 MA 20112's umfassen. Jeder MA 20112 kann eine Speicherkapazität von z. B. 256 Kilobyte, 512 Kilobyte, 1 Megabyte oder 2 Megabyte haben. Wie weiter unten beschrieben wird, können MA 20112's verschiedener Speicherkapazitäten zusammen in MSB 20110 benutzt werden. Jeder MA 20112 hat einen Dateneingang, der parallel mit dem Schreibdatenbus (WD) 20124 verbunden ist, und einen Datenausgang, der parallel mit dem Lesedatenbus (RD) 20126 verbunden ist. Die MA's 20112 haben auch Steuerungs- und Adreßkanäle, die parallel mit dem Adreß- und Steuerungsbus (ADCTL) 20128 verbunden sind. Insbesondere sind die Dateneingänge 20124 der Speichervektoren 20112 parallel mit dem Schreibdatenbus (WD) 20126 verbunden, und die Datenausgänge 20128 der Speichervektoren 20112 sind parallel mit dem Lesedatenbus (RD) 20130 verbunden. Die Steuerungsadreßkanäle 20132 der Speichervektoren 20112 sind parallel mit dem Adreß- und Steuerungsbus (ADCTL) 20134 verbunden.
Der Datenausgang 20136 des Bankcontrollers 20114 ist mit dem WD-Bus 20126 verbunden, und der Dateneingang 20138 des BC 20114 ist mit dem RD-Bus 20130 verbunden. Der Steuerungs- und Adreßkanal 20140 von BD 20114 ist mit dem ADCTL-Bus 20134 verbunden. Der Dateneingang 20142 von BC 20114 ist mit MC 20116's Datenausgang 20144 über den Rückspeicherdatenbus (SBD) 20146 verbunden. Der Rückspeicheradresseneingang 20148 von BC 20114 ist mit dem Rückspeicheradressenausgang 20150 von MC 20116 über den Rückspeicheradressenbus (SBA) 20152 verbunden. Der Datenleseausgang 20154 von BC 20114 ist mit dem Datenleseeingang von MC 20116 über den Datenauslesebus (RDO) 20158 verbunden. Der Steuerungskanal 20160 von BC 20114 ist mit dem Speichersteuerungsbus (MCNTL) 20164 verbunden.
MC 20116 hat einen Ausgang 20166, der mit dem MIO-Bus 10131 über den MIO-Kanal 10128 verbunden ist, und der Kanal 20168 ist mit dem MOD-Bus 10144 über den MJP- Kanal 10140 verbunden. Der Steuerungskanal 20170 von MC 20116 ist mit dem MCNTL- Bus 20164 verbunden. Der Eingang 20172 von BYF 20118 ist mit dem IOM-Bus 10130 über den MIO-Kanal 10128 verbunden und der Ausgang 20176 ist mit dem SBD-Bus 20146 über den Umgehungseinschreibebus (BWI) 20178 verbunden.
Schließlich besitzt FIU 20120 einen Ausgang 20180 und einen Eingang 20182, die mit MIO-Bus 10129 respektive IOM-Bus 10130 jeweils über MIO-Kanal 10128 verbunden sind. Der Eingang 20184 und der Kanal 20186 sind mit JPD-Bus 10142 respektive MOD- Bus 10144 jeweils über MJP-Kanal 10140 verbunden. Der Steuerungskanal 20188 ist mit dem MCNTL-Bus 20164 verbunden. Schließlich Bezug nehmend auf MIC 20122, so hat MIC 20122 einen Steuerungskanal 20190 und einen Eingang 20122, die mit IOMC-Bus 10131 respektive IOM-Bus 10130 jeweils über MIO-Kanal 10128 verbunden sind. Der Steuerungskanal 20194 und der Eingang 20196 sind mit JPMC-Bus 10147 respektive dem physikalischen Beschreiber-Bus (PD) 10146 jeweils über MJP-Kanal 10140 verbunden. Der Steuerungskanal 20198 ist mit MCNTL-Bus 20164 verbunden.

c. Der allgemeine Betrieb von MEM 10112

Zuerst auf die Schnittstelle von MEM 10112 mit IOS 10116 Bezug nehmend, beinhaltet diese den MIO-Bus 10129, den IOM-Bus 10130 und den IOMC-Bus 10131. Lese- und Schreibadressen und Daten, die in MEM 10112 geschrieben werden sollen, werden von IOS 10116 nach MEM 10112 über den IOM-Bus 10130 transferiert. Daten, die aus MEM 10112 gelesen werden sollen, werden nach IOS 10116 über den MIO-Bus 10129 transferiert. IOMC 10131 ist ein bidirektionaler Steuerungsbus zwischen MEM 10112 und IOS 10116 und überträgt, wie später beschrieben wird, Steuerungssignale zwischen MEM 10112 und IOS 10116, um den Datentransfer zwischen MEM 10112 und IOS 10116 zu steuern.
Die Schnittstelle von MEM 10112 zu JP 10114 ist der MJP-Kanal 10140, und beinhaltet den JPD-Bus 10142, den MOD-Bus 10144, den PD-Bus 10146 und JPMC-Bus 10147. Die physikalischen Beschreiber, d. h. die physikalischen Lese- und Schreibadressen von MEM 10112 werden von JP 10114 zu MEM 10112 über den PD-Bus 10146 transferiert. SOPs, d. h. Abfolgen von S-Befehlen und Operandennamen, werden von MEM 10112 nach JP 10114 über den MOD-Bus 10144 transferiert, während Daten, die von JP 10114 nach MEM 10112 geschrieben werden sollen, von JP 10114 nach MEM 10112 über den JPD- Bus 10142 transferiert werden. Der JPMC-Bus 10147 ist ein bidirektionaler Steuerungsbus, um Befehls- und Steuerungssignale zwischen MEM 10112 und JP 10114 zu übertragen zur Kontrolle des Datentransfers zwischen MEM 10112 und JP 10114. Wie weiter unten beschrieben wird, sind MJP-Kanal 10140 und insbesondere MOD-Bus 10144 und PD-Bus 10146 generell physikalisch wie ein Einzelkanal organisiert, der als Doppelkanal arbeitet. In einem ersten Fall arbeitet MJP-Kanal 10140 als ein Job-Prozessor-Befehlskanal (JI) für die Übertragung von SOPs von MEM 10112 nach JP 10114. In einem zweiten Fall arbeiten MOD 10144 und PD 10146 als ein Job-Prozessor-Operandenkanal (JO) für den Operandentransfer von MEM 10112 nach JP 10114, während JPD-Bus 10142 und PD-Bus Operanden von JP 10114 nach MEM 10112 transferieren.
Auf MSB 20110 Bezug nehmend, enthält MSB 20110 die erste oder Massenebene der Speicherkapazität von MEM 10112. MSB 20110 kann von einem bis z. B. 16 MAs 20112 enthalten. Jeder MA 20112 enthält einen dynamischen Speichervektor freien Zugriffs und kann eine Speicherkapazität von z. B. 246 Kilobyte, 512 Kilobyte, 1 Megabyte oder 2 Megabyte besitzen. MEM 10112 kann daher eine physikalische Kapazität von bis zu z. B. 16 Megabyte Massenspeicher besitzen. Wie weiter unten beschrieben wird, können in MSB 20110 MA 20112's verschiedener Speicherkapazität zusammen benutzt werden, z. B. vier 2 Megabyte MA 20112's und vier 1 Megabyte MA 20112's.
BC 20114 steuert den Betrieb der MAs 20112 und ist der Datentransferpfad von und zu den MAs 20112. Darüber hinaus führt BC 20114 die Fehlerentdeckung und Korrektur bei Daten durch, die in die MAs 20112 oder aus ihnen heraus transferiert werden, aktualisiert Daten, die in den MAs 20112 gespeichert sind, und führt Fehlerentdeckung und Korrektur von Daten, die in den MAs 20112 gespeichert sind, aus, während es Datenaktualisierungsoperationen durchführt.
MC 20116 umfaßt die Speicherkapazität der zweiten Ebene oder Zwischenspeicher und beinhaltet z. B. 8 Kilobyte Hochgeschwindigkeitsspeicher. MC 20116, der BYF 20118 beinhaltet, ist auch der Datentransferpfad zwischen MSB 20110 (über BC 20114) und JP 10114 und IOS 10116. Im allgemeinen geschehen alle Lese- und Schreiboperationen zwischen JP 10114 und IOS 10116 über MC 20116. IOS 10116 kann jedoch Lese- und Schreiboperationen von ganzen Blöcken durchführen, indem es MC 20116 umgeht. Blockschreibevorgänge von IOS 10116 werden über BYF 20118 durchgeführt, während Blocklesevorgänge über einen Datentransferpfad, der innerhalb von MC 20116 verläuft, durchgeführt und weiter unten gezeigt und beschrieben werden. Alle Lese- und Schreiboperationen zwischen MEM 10112 und JP 10114 müssen jedoch über den MC 20116 internen Zwischenspeicher durchgeführt werden, wie weiter unten gezeigt und beschrieben wird.
Wie unten auch gezeigt und beschrieben, beinhaltet FIU 20120 Schreibdatenregister, um Daten zu empfangen, die von JP 10114 und IOS 10116 nach MEM 10112 geschrieben werden sollen, und eine Ablauflogik, um Daten zu manipulieren, die von MSB 20110 gelesen werden sollen, so daß MEM 10112 als bitadressierbarer Speicher erscheint. FIU 20120 führt zusätzlich zur Bereitstellung der Bitadressierbarkeit von MEM 10112 Rechts- und Linsksausrichtung von Daten durch, füllt Daten mit Nullen auf, führt Operationen der Vorzeichenerweiterung und andere Operationen der Datenmanipulation, die weiter unten beschrieben werden, durch. Bei der Ausführung dieser Operationen der Datenmanipulation auf Daten, die von MEM 10112 nach JP 10114 gelesen werden sollen, wird der MOD- Bus 10144 als ein MEM 10112-interner Datenpfad für den Datentransfer von MC 20116 nach FIU 20120, und von FIU 20120 zu MC 20116, benutzt. Das heißt Daten, die nach JP 10114 transferiert werden sollen, werden von MC 20116 gelesen, über den MOD-Bus 10144 nach FIU 20120 transferiert, von FIU 20120 manipuliert und von FIU 20120 nach JP 10114 über den MOD-Bus 10144 transferiert.
MIC 20122 enthält Ablauflogik, die den Betrieb von MEM 10112 steuert und insbesondere die Schnittstelle von MEM 10112 mit JP 10114 und IOS 10116 kontrolliert. MIC 20122 empfängt Lese- und Schreibanforderungen von MEM 10112, d. h. Lese- und Schreibadressen über den PD-Bus 10146 und den IOM-Bus 10130, und Kontrollsignale über den JPMC-Bus 10147 und IOMC-Bus 10131, und stellt Kontrollsignale BC 20114, MC 20116 und FIU 20120 über den MCNTL-Bus 20164 zur Verfügung.
Nachdem die Gesamtstruktur und der Betrieb von MEM 10112 beschrieben worden sind, werden nun die Struktur und der Betrieb von MEM 10112's Kanälen, MIO-Kanal 10128 und MJP-Kanal 10140 beschrieben, anschließend werden die Steuerungsstruktur und die Steuerung und der Fluß der Lese- und Schreibanforderungen an MEM 10112 beschrieben.

d. Die Kanalstruktur von MEM 10112

Die Kanalstruktur von MEM 10112 ist so ausgearbeitet, daß sie eine einfache Schnittstelle zu JP 10114 und IOS 10116 zur Verfügung stellt. Sie sorgt für einen schnellen und flexiblen Betrieb bei der Unterstützung von MEM 10112's Lese- und Schreibanforderungen von JP 10114 und IOS 10116. In dieser Hinsicht kann MEM 10112 - wie weiter unten beschrieben werden wird - bis zu vier Lese- und Schreibanforderungen gleichzeitig verwalten, bei einer Datenübertragungsrate von z. B. 63,6 Megabyte pro Sekunde. Darüber hinaus ist MEM 10112 dazu imstande, Bit-genaue Adressierung, blockweise Lese- und Schreibvorgänge und Datenmanipulationen wie z. B. Ausrichtung und Füllung durchzuführen, um JP 10114 und IOS 10116 einen möglichst optimalen Betrieb zu ermöglichen. MEM 10112 bedient Anforderungen praktisch von drei Kanälen aus. Diese Kanäle sind der MIO-Kanal 10128 nach IOS 10116, von nun an als IO-Kanal bezeichnet, und die JI- und JO-Kanäle, die oben beschrieben wurden, nach JP 10114. Diese drei Kanäle teilen sich den gesamten Adreßraum von MEM 10112, aber IOS 10116 z. B. kann in seiner Nutzung des vollen MEM 10112's Adreßraums begrenzt werden. Jeder Kanal hat einen verschiedenen Satz von erlaubten Operationen. Zum Beispiel kann der JO-Kanal Bitgenaue Adressen benutzen, kann aber bei jeder Anforderung nur 32 Datenbits referenzieren. Der JI-Kanal kann Leseanforderungen nur nach Wort-ausgerichteten 32 Bitdatenausdrücken machen. Der IO-Kanal kann Bit-genaue Daten referenzieren und, wie weiter unten beschrieben wird, bei jeder Lese- oder Schreibauforderung bis zu 16 Byte lesen oder schreiben. Die Kennzeichen jeder dieser Kanäle werden im folgenden beschrieben.

1. Die Kennzeichen des IO-Kanals

IOS 10116 kann zu MEM 10112 in zwei Betriebsarten Zugang haben. Die erste Betriebsart sind Blocktransfers durch den Zwischenspeicher in MC 20116 oder ihn umgehend, und die zweite Betriebsart sind Nichtblocktransfers über den Zwischenspeicher und MC 20116.
Blockumgehungen können sowohl bei Lese- als auch bei Schreiboperationen geschehen. Eine Lese- oder Schreiboperation ist Block-Bypass-berechtigt, falls die Daten auf Blockgrenzen liegen und 16 Bytes lang sind, und die Lese- oder Schreibanforderung nicht von einem Steuersignal begleitet ist, die anzeigt, daß eine Encache-Operation (ein Laden in den Zwischenspeicher von MC 20116) durchgeführt werden soll. Eine Bypass-Operation findet nur dann statt, wenn die Blockadresse, d. h. die physikalische Adresse des Blocks in MEM 10112, nicht einen gegenwärtig encacheden Block adressiert, d. h. der Block befindet sich augenblicklich nicht in MC 20116's Zwischenspeicher. Falls der Block in MC 20116's Zwischenspeicher encached ist, so geht der Lese- oder Schreibtransfer zu MC 20116's Zwischenspeicher.
Partielle Blockreferenzen, d. h. nicht volle Blocktransfers, gehen durch MC 20116's Zwischenspeicher. Falls ein Zwischenspeicherfehler auftritt, d. h. die referenzierten Daten befinden sich nicht im Zwischenspeicher von MC 20116, so transferieren die Steuerstrukturen von MEM 10112 die Daten nach oder von MSB 20110 und aktualisieren den Zwischenspeicher von MC 20116. Es sei angemerkt, daß partielle Blocks ein Byte kurz oder 15 Bytes lang sein können. Eine Anfangsbyteadresse kann irgendwo innerhalb eines Blockes liegen, aber die Länge des partiellen Blocks darf nicht eine Blockgrenze überschreiten.
Bitweise Transfers, d. h. Transfers von Datenausdrücken, die eine Länge von ein bis 16 Bits besitzen und nicht ein Vielfaches eines Bytes sind, oder wo die Adresse nicht auf einer Bytegrenze liegt, gehen durch den Zwischenspeicher von MC 20116. Diese Operationen können Byte-, Wort- oder Blockgrenzen überqueren, aber dürfen nicht Seitengrenzen überqueren. Diese spezifischen Operationen, die vom IO-Kanal angefordert werden, bestimmen, ob eine Lese- oder Schreibanforderung ein partieller Blocktransfer oder ein Bitlängentransfer ist.

2. Die Kennzeichen des JO-Kanals

Alle Lese- oder Schreibanforderungen vom JO-Kanal müssen durch den Zwischenspeicher von MC 20116 gehen; Bypass-Operationen können nicht durchgeführt werden. Die Daten, die zwischen MEM 10112 und JP 10114 transferiert werden, sind immer 32 Bits lang, aber von den 32 übertragenen Bits können Null bis 32 gültige Daten sein. JP 10114 bestimmt die Lokation der gültigen Daten innerhalb der 32 Bits, indem es sich auf bestimmte FIU-Spezifikationsbits bezieht, die als Teil einer Lese- oder Schreibanforderung zur Verfügung gestellt werden. Wie weiter unten beschrieben wird, werden die FIU- Spezifikationsbits und andere Steuerbits MIC 20122 durch JP 10114 über JPMC-Bus 10147 zur Verfügung gestellt, wenn jeweils eine Lese- oder Schreibanforderung gemacht wird.
Während MEM 10112 keine Block-Bypass-Operationen an JP 10114 durchführt, kann MEM 10112 eine Zwischenspeicher-Durchleseoperation ausführen. Solche Operationen treten bei einer JP 10114-Leseanforderung auf, wenn die angeforderten Daten nicht im Zwischenspeicher von MC 20116 vorhanden sind. Falls die JP 10114-Leseanforderung nach einem vollen Wort ist, das Wort-ausgerichtet ist, so transferiert MEM 10112's Lademanager, wie unten beschrieben, die angeforderten Daten direkt zu JP 10114, während er gleichzeitig die angeforderten Daten in den Zwischenspeicher von MC 20116 lädt. Diese Operation sei als bedienungsfreie Operation bezeichnet. Diese Operationen können auch vom IO-Kanal für 16 Bit-Halbwörter durchgeführt werden, die am rechten Halbwort eines 32 Bit-Worts ausgerichtet sind, oder wenn ein voller Block links ausgerichtet und in den Zwischenspeicher von MC 20116 geladen wird.

3. Die Kennzeichen des JI-Kanals

Alle JI-Kanalanforderungen werden durch den Zwischenspeicher von MC 20116 befriedigt; MEM 10112 führt keine Bypass-Operationen zum JI-Kanal aus. JI-Kanalanforderungen sind immer Leseanforderungen nach Ganzwort-ausgerichteten Worten und sind im obigen Sinne bedienungsfrei, falls ein Zwischenspeicherfehler auftritt. Bei den meisten anderen Aspekten sind JI-Kanalanforderungen JO-Kanalanforderungen ähnlich.
Nachdem die Gesamtstruktur und der Betrieb von MEM 10112, einschließlich seiner Ein- und Ausgabekanäle zu JP 10114 und IOS 10116 beschrieben wurde, wird im folgenden die Steuerungsstruktur von MEM 10112 beschrieben werden.

e. Die Steuerungsstruktur und der Betrieb von MEM 10112 (Fig. 207)

In Fig. 207 wird ein genaueres Blockdiagramm von MIC 20116 gezeigt. Es wird in der folgenden Diskussion der Steuerungsstruktur von MEM 10112 in Verbindung mit Fig. 201 Bezug genommen.

1. Die Steuerungsstruktur von MEM 10112

In Fig. 207 ist der MCNTL-Bus 20164 dargestellt, der den MCNTL-BC-Bus 20164A, den MCTL-MC-Bus 20164B und den MCNTL-FIU-Bus 20164C enthält. Die Busse 20164A, 20164B und 20164C sind Arme des MCNTL-Busses 20164, die jeweils mit BC 20114, MC 20116 und FIU 20120 verbunden sind. Ebenfalls in Fig. 207 dargestellt sind der PD- Bus 10146 und der JPMC-Bus 10147 nach JP 10114, und der IOM-Bus 10130 und IOMC- Bus 10131 nach IOS 10116.
Das JO-Kanal-Adreßregister (JPAR) 20710 und das JI-Kanal-Adreßregister (JIPAR) 20712 haben Eingänge, die mit dem PD-Bus 10146 verbunden sind. Das IO-Kanal-Adreßregister (IOPAR) 20714 hat einen Eingang, der mit dem IOM-Bus 10130 verbunden ist. Die Kanalsteuerungslogik (PC) 20716 hat bidirektionale Ein- und Ausgänge, die mit JPC 10147 und IOMC-Bus 10131 verbunden sind. Die Bypass-Lese/Schreibe-Steuerungslogik (BR/WC) 20718 hat einen bidirektionalen Ein-/Ausgang, der mit IOMC-Bus 10131 verbunden ist.
Die Ausgänge von JOPAR 20710, JIPAR 20712 und IOPAR 20714 sind mit den Eingängen des Kanalanforderungsmultiplexers (PRMUX) 20720 jeweils über die Busse 20732, 20734 und 20736 verbunden. Der Ausgang von PRMUX 20720 wiederum ist mit dem Bus 20738 verbunden. Die Arme des Busses 20738 sind mit den Eingängen der Ladezeiger (LP) 20724, der Fehlersteuerung (MISSC) 20726, dem Anforderungsmanager (RM) 20722 und mit den Bussen MCNTL-MC 20164B und MCNTL-FIU 20164C verbunden.
Die Ausgänge des PC 20716 sind mit den Eingängen von JOPAR 20710, JIPAR 20712, IOPAR 20714, PRMUX 20720 und LP 20724 über den Bus 207 38 verbunden. Der Bus 20740 verbindet die Ein-/Ausgänge des PC 20716 mit den Ein-/Ausgängen von RM 20722.
Ein Ausgang von BR/WC 20718 ist mit dem MCNTL-MC-Bus 20164B über den Bus 20742 verbunden. Die Eingänge von BR/WC 20718 sind mit den Ausgängen von RM 20722 und der Leseschlange (RU) 20728 jeweils über die Busse 20744 und 20746 verbunden.
RM 20722 hat Ausgänge, die mit dem MCNTL-BC-Bus 20164A, dem MCNTL-FIU-Bus 20164C und dem Eingang von MISSC 20726 und einen Eingang von LP 20724 jeweils über die Busse 20748, 20750, 20752 und 20754. Der Ausgang von MISSC 20726 ist mit dem MCNTL-BC-Bus 20164A verbunden. Die Ausgänge von LP 20724 sind mit dem MCNTL-MC-Bus 20164B und mit einem Eingang von LM 20730 jeweils über die Busse 20756 und 20758 verbunden. Der Eingang von RQ 20728 ist mit dem MCNTL-MC-Bus 20164B über den Bus 20760 verbunden, und RQ 20728 hat Ausgänge, die mit einem Eingang von LP 20724 über den Bus 20762, und wie oben beschrieben, mit einem Input von BR/WC 20718 über den Bus 20746 verbunden sind. Schließlich ist der Ausgang von LM 20730 mit dem MCNTL-MC-Bus 20164B über den Bus 20764 verbunden.
Nachdem die Struktur von MIC 20716 mit Bezug auf Fig. 207 beschrieben wurde, und nachdem schon oben die Struktur von MEM 10112 mit Bezug auf Fig. 201 beschrieben worden war, wird im folgenden der Betrieb der Steuerungsstruktur von MEM 10112 mit Bezug auf die Fig. 201 und 207 beschrieben werden.

2. Der Steuerungsbetrieb von MEM 10112

Wie oben in Fig. 207 beschrieben, sind JOPAR 20710, JIPAR 20712 und IOPAR 20714 mit PD-Bus 10146 von JP 10114 und IOM-Bus 10130 von IOS 10116 verbunden. WAR 20710, JIPAR 20712 und IOPAR 10714 empfangen Lese- und Schreibanforderungsadressen von JP 10114 und IOS 10116 und speichern diese Adressen für den nachfolgenden Service durch MEM 10112. Wie weiter unten beschrieben wird, enthalten diese Adreßeingänge von JP 10114 und IOS 10116 FIU-Information, die spezifiziert, welche Datenmanipulationsoperationen von FIU 20120 durchgeführt werden müssen, bevor die angeforderten Daten zum Anforderer transferiert werden oder in MEM 10112 geschrieben werden; sie enthalten weitere Informationen, die das Ziel betreffen, das den Daten zur Verfügung gestellt werden muß, die aus MEM 10112 gelesen werden; sie enthalten Informationen, die die Betriebsart, die von MEM 10112 durchgeführt werden soll, betreffen, und Informationen über die Operandenlänge. Die Informationen über die Anforderungsadressen, die in JOPAR 20710, JIPAR 20712 und IOPAR 20714 empfangen und gespeichert werden, werden dort so lange zurückgehalten, bis MEM 10112 die Bedienung der entsprechenden Anforderungen begonnen hat. MEM 10112 wird weitere Anforderungsadreßinformationen in ein bestimmtes Kanalregister nur akzeptieren, nachdem eine vorherige Anforderung in jenen Kanal bedient worden oder abgebrochen worden ist. Die Adreßinformationsausgaben von JOPAR 20710, JIPAR 20712 und IOPAR 20714 werden über PRMUX 20720 zum Bus 20738 und von dort zu RM 20722, MC 20116 und FIU 20120 transferiert, wenn die Bedienung von individuellen Anforderungen begonnen hat. Wie unten beschrieben wird, wird diese Adreßinformation über PRMUX 20720 und den Bus 20738 zu LP 20724 transferiert, um einen Zwischenspeicherfehler bedienen zu können, wenn ein MC 20116-Fehler auftritt.
PC 20716 empfängt Befehls- und Steuerungssignale, die zur jeweiligen angeforderten Speicheroperation gehören, von JP 10114 und IOS 10116 über den JPMC-Bus 10147 und den IOSC-Bus 10131. PC 20716 enthält Anforderungsentscheidungslogik und Kanalzustandslogik. Die Anforderungsentscheidungslogik bestimmt die Abfolge, in der die IO-, JI- und JO-Kanäle bedient werden, und wann jeder Kanal bedient werden muß. Bei der Bestimmung der Abfolge der Kanalbedienung benutzt die Anforderungsentscheidungslogik die gegenwärtige Kanalzustandsinformation für jeden Kanal von der Kanalzustandslogik, sie benutzt die Informationen von JPMC-Bus 10147 und IOMC-Bus 10131, die jede ankommende Anforderung betreffen, und sie benutzt Information von RM 20722 über den aktuellen Betriebszustand von MEM 10112. Die Kanalzustandslogik wählt jeden bestimmten Kanal aus, der bedient werden soll, und ermöglicht durch Steuerungssignale über den Bus 20738 den Transfer von Anforderungsadreßinformationen eines jeden Kanals von JOPAR 20710, JIPAR 20712 und IOPAR 20714 über PRMUX 20720 zum Bus 20738 für die Benutzung durch den Rest der Steuerungslogik von MEM 10112 bei der Bedienung des ausgewählten Kanals. Zusätzlich zur Anforderungsinformation, die von JP 10114 und IOS 10116 über den JPMC-Bus 10147 und den IOMC-Bus 10131 empfangen wird, benutzt die Kanalzustandslogik Informationen von RM 20722 und beim Auftreten eines Zwischenspeicherfehlers von LM 20730 (aus Übersichtlichkeitsgründen ist diese Verbindung nicht in Fig. 207 dargestellt). Die Kanalzustandslogik steuert auch verschiedene Kanalzustandskennzeichensignale, z. B. Kanalverfügbarkeitssignale, Signale, die gültige Anforderungen anzeigen, und Signale, die anzeigen, daß verschiedene Kanäle auf Bedienung warten.
RM 20722 steuert die Ausführung der Bedienung für jede Anforderung. RM 20722 ist eine mikrocodegesteuerte "Mikromaschine", die Programme ausführt, die von den angeforderten MEM 10112-Operationen aufgerufen werden. Die Eingaben von RM 20722 beinhalten Anforderungsadreßinformationen von IOPAR 20714, JIPAR 20212 und JOPAR 20210, die Informationen bezüglich des Typs der MEM 10112-Operation, die bei der Bedienung einer bestimmten Anforderung ausgeführt werden sollen, betreffen, sie beinhalten Unterbrechungssignale von anderen MEM 10112-Steuerelementen und z. B. Anfangssignale von PC 20716's Anforderungsentscheidungslogik. RM 20722 stellt Steuersignale FIU 20120, MC 20116 und den meisten anderen Teilen der Steuerungsstruktur von MEM 10112 zur Verfügung.
Mit Bezug auf Fig. 201 ist der Zwischenspeicher von MC 20116 z. B. ein 8 Kilobyte, vier Satz Assoziativ-Zwischenspeicher, der dazu benutzt wird, schnellen Zugang zu einer Untermenge von Daten, die in MSB 20110 gespeichert sind, zu verschaffen. Die Untermenge von MSB 20110-Daten, die im Zwischenspeicher von MC 20116 gespeichert sind, sind immer die Daten, die von JP 10114 oder IOS 10116 zum Schluß benutzt wurden. MC 20116's Zwischenspeicher, der weiter unten beschrieben wird, enthält Kennzeichnungsspeicher-Vergleichslogik zur Bestimmung der Adressen, die in den Zwischenspeicher transferiert wurden, einen Datenspeicher, der die entsprechenden Daten, die in den Zwischenspeicher transferiert wurden, enthält und Register und Logik, die nötig ist, um die Zwischenspeicherinhalte zu aktualisieren, wenn ein Zwischenspeicherfehler auftritt. Die Register und die Legik zur Bedienung von Zwischenspeicherfehlern enthält Logik zur Bestimmung des letzten aktuellen Zwischenspeichereingangs und Register für die Ergreifung und Speicherung der Informationen, die fehlende Zwischenspeicherreferenzen betreffen, z. B. Modifizierbits und Ersatzseitennummern. Eingaben zu MC 20116 werden von RM 20722, LM 20730 (wird später besprochen), FIU 20120, MSB 20110 (über BC 20114), LP 20724 (wird weiter unten besprochen) zur Verfügung gestellt, die Adresseninformation wird voll PRMUX 20720 zur Verfügung gestellt. Die Ausgaben von MC 20116 beinhalten Daten und gehen zu FIU 20120 (über den MOD-Bus 10144), den Datenanforderern (JP 10114 und IOS 10116) und einer MC 20116-Zurückschreibdatei (weiter unten beschrieben).
Wie oben beschrieben, enthält FIU 20120 eine Logik, die notwendig ist, MEM 10112 Bitadressierbar erscheinen zu lassen. Darüber hinaus enthält FIU 20120 Logik, um bestimmte Datenmanipulationsoperationen durchzuführen, wie sie von den Anforderern (JP 10114 oder IOS 10116) verlangt werden. Daten werden in FIU 20120 von MC 20116 durch jenen Bereich des MOD-Busses 10144 transferiert, der innerhalb MEM 10112 liegt, werden wie verlangt manipuliert und dann zum Anforderer über den MOD-Bus 10144 oder MIO-Bus 10129 transferiert. Im Falle von Schreibvorgängen, die einen Lese- Veränder-Schreib-Vorgang von Daten, die sich im Zwischenspeicher befinden, erfordern, werden die Daten nach der Manipulation zurück zu MC 20116 über den MOD-Bus 10144 transferiert. Allgemein beinhalten Datenmanipulationsoperationen die Lokalisierung der angeforderten Daten auf den ausgewählten MOD-Bus 10144- oder MIO-Bus 10139-Linien und das Auffüllen unbenutzter Buslinien, wie es vom Anforderer spezifiziert wird. Die Dateneingaben zu FIU 20120 können von MC 20116 oder JP 10114 über den MOD-Bus 10144 oder von IOS 10116 über den IOM-Bus 10130 zur Verfügung gestellt werden. Die Datenausgaben von FIU 20120 können MC 20116, JP 10114 oder IOS 10116 über dieselben Busse zur Verfügung gestellt werden. Die Steuerungsinformation wird FIU 20120 von RM 20722 über den Bus 20748 und den MCNTL-FIU-Bus 20164C zur Verfügung gestellt. Adreßinformation kann FIU 20120 von JOPAR 20710, JIPAR 20712 oder IOPAR 20714 über PRMUX 20720, Bus 20738 und den MCNTL-FIU-Bus 20164C zur Verfügung gestellt werden.
Wie wieder in Fig. 207 dargestellt, wird MISSC 20726 zur Behandlung von MC 20116- Fehlern benutzt. Wenn eine Datenanforderung nach Daten, die nicht im Zwischenspeicher von MC 20116 liegen, geschieht, so speichert MISSC 20726 die Blockadresse der Referenz und den Operationstyp, der ausgeführt werden soll, wobei diese Informationen von einem Adreßregister in MC 20116 und von RM 20722 zur Verfügung gestellt werden. MISSC 20726 benutzt diese Informationen und erzeugt über den MCNTL-BC-Bus 20164A einen Befehl für BC 20114 für einen Datenlesevorgang von MSB 20110, um die referenzierten Daten zu erhalten. BC 20114 plaziert diesen Befehl in eine Warteschlange oder ein Register und führt daraufhin die befohlene Leseoperation durch. MISSC 20726 erzeugt auch einen Eingang in RQ 20728 (weiter unten beschrieben), der den Operationstyp anzeigt, der ausgeführt werden soll, wenn die referenzierten Daten nachfolgend von MSB 20110 gelesen werden.
RQ 20728 ist z. B. eine drei Ebenen tiefe Warteschlange, in der Informationen gespeichert werden, die die Operationen kennzeichnen, die mit den Daten, die von MSB 20110 gelesen werden, assoziiert sind. Zwei Arten von Operationen können angezeigt werden: Block-Bypass-Lesen und Zwischenspeicherladen. Wenn Zwischenspeicherladen spezifiziert wird, d. h. ein Lesen und Speichern des Zwischenspeichers von MC 20116 angezeigt wird, so wird RM 20722 unterbrochen und dazu gezwungen, andere MEM 10112- Operationen in Leerlaufposition zu bringen bis das Zwischenspeicherladen vollendet ist. Eine Block-Bypass-Leseoperaation resultiert in einer Bypass-Lesesteuerung (unten beschrieben), bei der die Datensteuerung von MSB 20110 vorausgesetzt wird. Eingaben nach RQ 20728 sind Steuersignale von RM 20752, MISSC 20726 und BC 20114. RQ 20728 stellt Steuerausgaben LP 20724 (unten beschrieben), LM 20730 (unten beschrieben), RM 20722 und Bypass-Lesesteuerung (unten beschrieben) zur Verfügung.
LP 20724 ist ein Registersatz für die Speicherung von Information, die notwendig ist, die MC 20116-Fehler zu bedienen, die sich daraus ergeben, wenn MC 20116's Kennzeichenspeicher geladen wird. LM 20730 benutzt diese Informationen, wenn Daten über BC 20114 verfügbar werden, die in MSB 20110 gespeichert sind und von MSB 20110 gelesen werden, um einen MC 20116-Zwischenspeicher-Fehler zu bedienen. Die Eingaben für LP 20724 beinhalten die Adresse der fehlenden Referenz, die von JOPAR 20710, JIPAR 20712 oder IOPAR 20714 über PRMUX 20720 und Bus 20738 zur Verfügung gestellt werden, und Befehle von RM 20722 und Steuersignale von RQ 20728. Die Ausgaben von LP 20724 beinhalten Adressen von fehlenden Referenzen für MC 20116 über die Busse 20756 und MCNTL-MC 20164B und Befehlssignale für LM 20730 und BR/WC 20718.
LM 20730, auf den wir uns oben bezogen haben, steuert das Laden des Zwischenspeichers von MC 20116 mit Daten von MSB 20110, nachdem ein Zwischenspeicherfehler aufgetreten ist. RQ 20728, auf das wir uns oben bezogen haben, zeigt für jeden Datenlesevorgang von MSB 20110 an, ob der Datenlesevorgang das Resultat eines MC 20116- Zwischenspeicherfehlers ist. Wenn die Daten von MSB 20110 als Resultat eines Zwischenspeicherfehlers gelesen werden, fährt LM 20730 fort, indem er eine Abfolge von Steuersignalen veranlaßt, um die Daten von MSB 20110 und ihren assoziierten Adressen in den Zwischenspeicher von MC 20116 zu laden. Diese Daten werden in den Datenspeicher des Zwischenspeichers von MC 20116 transferiert, während die Blockadressen von LP 20724 in den Kennzeichenspeicher (in der folgenden Diskussion beschrieben) des Zwischenspeichers von MC 20116 transferiert werden. Wenn der Datentransfer in MC 20116's Zwischenspeicher Daten ersetzt, die vorher in jenem Zwischenspeicher residierten, und diese Daten "schmutzig" sind, d. h. die Daten wurden hineingeschrieben, weil sie sich von einer Originalkopie der Daten, die in MSB 20110 gespeichert sind, unterschieden, so müssen die modifizierten Daten, die in MC 20116's Zwischenspeicher residieren, nach MSB 20110 zurückgeschrieben werden. Diese Operation wird durch eine Zurückschreibedatei ausgeführt, die in MC 20116 enthalten ist und unten beschrieben wird. Bei einer solchen Operation initiiert LM 20730 eine Zurückschreibeoperation durch MC 20116 und BC 20114, was auch unten beschrieben wird.
Wie in einer weiteren Beschreibung beschrieben wird, sind alle MC 201 16-Zwischenspeicher-Ladeoperationen volle Vier-Wort-Blöcke. Eine Anforderung, aus der ein MC 20116-Zwischenspeicherfehler resultiert, kann in einem "hand-off" resultieren, das ist eine Leseoperation von vier ganzen Wortblöcken. Hand-off-Operationen können auch aus einzelnen 32 Bit-Worten bestehen, in denen ein Wort, was an einem 32 Bit-Wort ausgerichtet ist, von JP 10114 transferiert wird, oder aus einem 16 Bit-Operanden, der an einem rechten Halbwort ausgerichtet ist, von IOS 10116 transferiert werden. Bei einer solchen Hand-off-Operation sendet LM 20730 ein gültiges Anforderungssignal zu dem anfordernden Kanal, und eine Hand-off-Operation wird ausgeführt. Im anderen Fall wird ein Wartesignal zu dem nachfragenden Kanal ausgesendet und die Anforderung wird wieder in die Prioritätswarteschlange von PC 20716 eingereiht, um nachfolgend ausgeführt zu werden. Um diese Operationen zu vollführen, empfängt LM 20730 Eingaben von RQ 20728 (aus Übersichtlichkeitsgründen nicht in Fig. 207 gezeigt) und von LP 20724. LM 20730 stellt Ausgaben der Kanalzustandslogik von PC 20716, MC 20116, MC 20116's Rückschreibdatei und MC 20116-Rückschreibadreßregister und BC 20114 zur Verfügung.
Laut Fig. 201 kann IOS 20116, wie oben besprochen, eine Ganzblockschreiboperation direkt von MSB 20110 aufordern. Eine solche Bypass-Schreibanforderung kann berücksichtigt werden, wenn der zu transferierende Block nicht in den Zwischenspeicher von MC 20116 geladen ist. In einem solchen Fall initiiert RM 20722 den Transfer, indem er die Bypass-Schreibsteuerungslogik in BR/WC 20718 zum Betrieb vorbereitet, und kann dann die Steuerung der Operation der Bypass-Schreibsteuerungslogik von BR/WC 20718 zur Vollendung übergeben. Die Bypass-Schreibsteuerung kann dann den verbleibenden Teil des Datenblocks von IOS 10116 annehmen, indem sie geeignete Übergangssignale über IOMC-Bus 10131 erzeugt, und den Datenblock in BYF 20118 und MC 20116 lädt.
MISSC 20726 stellt dann über MNCTL-PC-Bus 20164A einen Bypass-Schreibbefehl für BC 20114 zur Verfügung. BC 20114 transferiert dann den Datenblock von BYF 20118 in MAs 20112 und MSB 20110.
Wie oben besprochen, empfängt BYF 20118 von IOM-Bus 10130 Daten und stellt Datenausgabe BC 20114 über den BWY-Bus 20178 und den SBD-Bus 20146 zur Verfügung. BYF 20118 ist dazu imstande, gleichzeitig Daten vom IOM-Bus 10130 zu empfangen, während er Daten nach BC 20114 ausliest. Die Steuerung für das Schreiben der Daten in BYF 20118 wird von der Bypass-Schreibkontroll-Logik von BR/WC 20718 zur Verfügung gestellt.
IOS 10116 kann, wie oben beschrieben, eine Ganzblock-Leseoperation anfordern und dabei den Zwischenspeicher von MC 20116 umgehen. In einem solchen Fall verwaltet BR/WC 20718's Bypass-Lesesteuerung den Datentransfer nach IOS 10116 und erzeugt die erforderlichen Übergabesignale für IOS 10116 über den IOMC-Bus 10131. Der Datenpfad für Bypass-Leseoperationen geht über einen MC 20116-internen Datenpfad und nicht durch BYF 20118. Dieser interne Datenpfad ist der RDO-Bus 20158 nach MIO-Bus 10129.
Wie oben beschrieben, verwaltet BC 20114 alle Datentransfers zu und von den MAs 20112 in MSB 20110. BC 20114 empfängt Anforderungen nach Datentransfers von RM 20722 in einem internen Warteschlangenregister. Alle Datentransfers zu und von MSB 20110 sind Ganzblocktransfers mit Block-ausgerichteten Adressen. Bei Datenschreiboperationen empfängt BC 20114 Daten von BWF 20118 oder von MC 20116-Zurückschreibdatei und transferiert die Daten in die MAs 20112. Während der Leseoperationen holt BC 20114 den Datenblock von den MAs 20112 und plaziert den Datenblock auf den RDO-Bus 20158, während es MIC 20122 signalisiert, daß die Daten zur Verfügung stehen. Wie oben beschrieben, verfolgt und steuert MIC 20122 den Datentransfer und BYF 20118, MC 20116 und MC 20116-Zurückschreibdatei, und leitet die Daten, die von MSB 20110 gelesen werden, zur geeigneten Richtung, nämlich MC 20116's Datenspeicher, JP 10114 oder IOS 10116.
Zusätzlich zu den obigen Operationen steuert BC 20114 die Aktualisierung der MAs 20112 und führt Fehlerentdeckung und Korrekturoperationen durch. In dieser Hinsicht führt BC 20114 zwei Fehlerentdeckungs- und Korrekturoperationen durch. Im ersten entdeckt BC 20114 Einzel- und Doppelbitfehler in Daten, die von MSB 20110 gelesen werden, und korrigiert Einzelbitfehler. In dem zweiten liest BC 20114 die Daten, die in den MAs 20112 während der Aktualisierungsoperationen gespeichert sind, und führt Einzelbitfehlerentdeckung durch. Wann auch immer ein Fehler gefunden wird, während einer Lese- oder Aktualisierungsoperation, macht BC 20114 eine Aufnahme von jenem Fehler in einem Fehlerprotokoll, das in BC 20114 (weiter unten in einer folgenden Beschreibung beschrieben) enthalten ist. Sowohl JP 10114 als auch IOS 10116 können das Fehlerprotokoll von BC 20114 lesen, und die Informationen aus dem Fehlerprotokoll von BC 20114 können in einem Wartungsprotokoll von CS 10110 aufgezeichnet werden, um bei der Reparatur und Fehlersuche von CS 10110 zu helfen. Das Fehlerprotokoll von BC 20114 kann direkt durch RM 20722 adressiert werden und Daten von BC 20114's Fehlerprotokoll können zu JP 10114 oder IOS 10116 in der gleichen Weise transferiert werden wie Daten, die in MSB 20110 gespeichert sind.
Indem wir schließlich Bezug nehmen zu den MAs 20112, so enthält jeder MA 20112 einen Vektor aus dynamischen Halbleiterspeichern freien Zugriffs. Jeder MA 20112 kann 256 Kilobyte-, 512 Kilobyte-, 1 Megabyte- oder 2 Megabyte-Datenspeicher enthalten. Die Speicherkapazität eines jeden MA 20112 ist segmentweise organisiert, wobei jedes Segment 256 Kilobytes enthält. Bei der Adressierung eines bestimmten MA 20112 wählt BC 20114 jenen bestimmten MA 20112 aus, wie weiter unten beschrieben wird. BC 20114 wählt gleichzeitig ein Segment innerhalb jenes MA 20112 und einen Block von vier Worten innerhalb jenes Segments. Jedes Wort kann 39 Informationsbits, 32 Datenbits und 7 Bits-Fehlerkorrekturcode beinhalten. Die vollen 39 Bits eines jeden MA 20112-Worts werden jeder Lese- und Schreiboperation zwischen BC 20114 und den MAs 20112 transferiert. Nachdem die allgemeine Struktur und der Betrieb von MEM 10112 beschrieben wurden, werden im folgenden bestimmte Typen von Operationen, die von MEM 10112 ausgeführt werden können, beschrieben.

f. Operationen von MEM 10112

MEM 10112 kann zwei allgemeine Typen von Operationen durchführen. Der erste Typ sind Datentransferoperationen und der zweite Typ sind Speicheraktualisierungsoperationen. Die Datentransferoperationen können Lesen, Schreiben und Lesen und Einstellen beinhalten. Die Speicheraktualisierungsoperationen können das Lesen des Fehlerprotokolls, des Reparaturblocks und des Einbauzwischenspeichers beinhalten. Außer während einer Einbauzwischenspeicheroperation ist die Existenz von MC 20116 und seinem Betrieb für die Anforderer unsichtbar, d. h. für JP 10114 und IOS 10116.
Eine MEM 10112-Leseoperation transferiert Daten von MS 10112 zu einem Anforderer, entweder JP 10114 oder IOS 10116. Ein Datenlesetransfer ist in der Hinsicht asynchron, daß der Anforderer nicht die abgelaufene Zeit zwischen dem Abschicken einer Speicheroperationsauforderung und der Rückkehr der angeforderten Daten vorhersagen kann. Die Operation eines Anforderers in MEM 10112 wird durch ein Signal koordiniert, das aussagt, daß die angeforderten Daten verfügbar sind, und welches von MEM 10112 zu dem Anforderer übersendet wird.
Eine MEM 10112-Schreiboperation transferiert Daten entweder von JP 10114 oder von IOS 10116 nach MEM 10112. Während solcher Operationen muß JP 10114 nicht auf Signal von MEM 10112 warten, das Daten, die von JP 10114 für MEM 10112 vorgesehen sind, angenommen wurden. JP 10114 kann Daten in MEM 10112's JO-Kanal transferieren, wenn immer ein Signal von MEM 10112 vorhanden ist, daß der JO-Kanal verfügbar ist; das Lesen von Daten wird sofort akzeptiert, ohne weitere Handlung oder Wartezeit für JP 10114. Wort-Schreiboperationen von IOS 10116 werden in einer ähnlichen Weise durchgeführt. Bei Block-Schreiboperationen jedoch muß IOS 10116 auf ein Daten-Genommen-Signal von MEM 10112 warten, bevor es die zweiten, dritten oder vierten Worte eines Blocks sendet.
MEM 10112 ist imstande, "Bitverriegelungsoperationen" durchzuführen. Bei solchen Operationen wird ein Bit-genaues Lesen der Daten durchgeführt, und der gesamte Operand wird zum Anforderer geschickt. Zur gleichen Zeit wird das signifikanteste Bit des Operanden, das ist das Verriegelungsbit, in der Kopie der Daten, die in MEM 10112 gespeichert sind, auf Eins gesetzt. In dem Operanden, der zum Anforderer gesendet wird, bleibt das Verriegelungsbit auf seinem ursprünglichen Wert, der Wert vor der gegenwärtigen Lese- und Setzoperation. Prüfungs- und Besetzoperationen werden durchgeführt, indem Lese- und Setzoperationen durchgeführt werden, wobei die Länge des Datenausdrucks auf ein Bit festgelegt wird.
Wie oben beschrieben, führt MEM 10112 bestimmte Verwaltungsoperationen inklusive Fehlerentdeckung aus. MEM 10112's Fehlerprotokoll in BC 20114 ist ein 32 Bitregister, das ein Adressenfeld und ein Fehlercodefeld enthält. Wenn ein erster Fehler geschieht, werden der Fehlertyp und in manchen Fällen, wie z. B. ERCC-Fehler bei einem Lesen von Daten, die in MSB 20110 gespeichert sind, die Adresse der Daten, die den Fehler beinhalten, in BC 20114's Fehlerprotokollregister gespeichert. Es wird ein Unterbrechungssignal herausgegeben, das die Entdeckung eines Fehlers anzeigt, und zur gleichen Zeit wird die Information, die den Fehler betrifft, im Fehlerprotokoll abgespeichert. Falls mehrfache Fehler auftreten, bevor das Fehlerprotokoll gelesen und zurückgesetzt wird, wird die Information, die den ersten Fehler betrifft, zurückgehalten und gültig bleiben. Das Codefeld des Fehlerprotokolls wird hingegen anzeigen, daß mehr als ein Fehler aufgetreten ist.
JP 10114 kann eine Leseoperation des Fehlerprotokolls anfordern, die als "Lesen und Zurücksetzen des Fehlerprotokolls"-Operation bezeichnet wird. Bei dieser Operation liest MEM 10112 den gesamten Inhalt des Fehlerprotokolls nach JP 10114, setzt das Fehlerprotokollregister zurück und setzt das Unterbrechungssignal zurück, welches das Vorhandensein eines Fehlers anzeigt. IOS 10116 ist, wie weiter unten beschrieben, auf das gleichzeitige Lesen von 16 Bits von MEM 10112 begrenzt. Es macht daher zwei Leseoperationen notwendig, um das Fehlerprotokoll zu lesen. Die erste Leseoperation nach IOS 10116 liest die oberen 16 Bits der Fehlerprotokolldaten und setzt das Fehlerprotokoll nicht zurück. Die zweite Leseoperation wird in derselben Weise ausgeführt wie eine JP 10114-Lese- und Rücksetzoperation des Fehlerprotokolls außer daß nur die untersten 16 Bits des Fehlerprotokolls nach IOS 10116 gelesen werden.
MEM 10112 führt Blockreparaturoperationen durch, um die Gleichheit von ERCC-Fehlern in Daten, die in MC 20116's Zwischenspeicher oder in den MAs 20112 gespeichert sind, zu korrigieren. Während einer Blockreparaturprozedur werden die Paritätsbits für Daten, die in MC 20116's Zwischenspeicher gespeichert sind oder die ERCC-Check-Bits von Daten, die in den MAs 20112 gespeichert sind, modifiziert, so daß sie mit den Datenbits der Daten, die darin gespeichert sind, übereinstimmen. In dieser Hinsicht haben reparierte, unkorrigierbare Fehler, wie z. B. zwei Bitfehler von Daten in den MAs 20112, gute ERCC- und Paritätswerte. Solange bis eine Blockreparaturoperation durchgeführt ist, wird jede Leseanforderung, die auf schiechte Daten gerichtet ist, d. h. Daten, die Paritäts- oder ERCC-Check-Bits haben, die ungültige Daten anzeigen, als ungültig gekennzeichnet werden. Blockreparaturoperationen ist es erlaubt, solche Daten als gültig zu lesen, z. B. wenn sie zu einer Datenkorrekturoperation benutzt werden. Fehler in Blockreparaturoperationen werden ignoriert und nicht in BC 20114's Fehlerprotokoll aufgezeichnet. Eine Schreiboperation in eine Speicheffläche, die schlechte Daten enthält, kann durchgeführt werden, wenn MEM 10112's-interner Betrieb keine "Lese- und Aktualisier"-Prozedur erfordert. Indem solche Schreiboperationen durchgeführt werden, ist es daher möglich, schlechte Daten zu überschreiben, indem man von normalen Schreiboperationen Gebrauch macht, vor oder anstelle von Blockreparaturoperationen.
MEM 10112 führt, wenn ein Leistungsfehler vorliegt, d. h. wenn MEM 10112 zum Batteriebetrieb übergeht, eine Zwischenspeicherbereinigungsoperation durch. Bei einem solchen Ereignis bleiben nur die MAs 20112 und BC 20114 unter Leistung. Bevor JP 10114 und IOS 10116 ihre Leistung verlieren, müssen JP 10114 und IOS 10116 alle Daten inklusive den Betriebszustand nach MEM 10112 transferieren, um dort gesichert zu werden. Dies wird durch eine Reihe von normalen Schreiboperationen durchgeführt. Wenn diese Schreiboperationen abgeschlossen sind, übersenden JP 10114 und IOS 10116 eine Anforderung nach MEM 10112, den Zwischenspeicher zu reinigen. Wenn MEM 10112 zwei Anforderungen, den Zwischenspeicher zu reinigen, empfängt, so reinigt er den Zwischenspeicher von MC 20116, so daß alle schmutzigen Daten, die in MC 20116- Zwischenspeicher geladen sind, in die MAs 20112 transferiert werden, bevor die Leistung verlorengeht. Wenn nur JP 10114 oder IOS 10116 arbeitet, entdeckt DP 10118 diese Tatsache und hätte während der Systeminitialisierung schon ein Aktivierungssignal (FLUSHOK) nach MEM 10112 gesendet. FLUSHOK ermächtigt MEM 10112, die Bereinigung des Zwischenspeichers durchzuführen, wenn es eine einzige Anforderung empfängt, den Zwischenspeicher zu reinigen. Nach einer Bereinigungsoperation des Zwischenspeichers sind so lange keine weiteren MEM 10112-Operationen möglich, bis DP 10118 ein Leistungsfehlersperrsignal zurücksetzt, um MEM 10112 es zu ermöglichen, den Normalbetrieb wieder aufzunehmen.
Nachdem die Gesamtstruktur und der Betrieb von MEM 10112 und bestimmte Operationen, die von MEM 10112 ausgeführt werden können, besprochen wurden, werden im folgenden die Schnittstellen von MEM 10112 zu JP 10114 und IOS 10116 beschrieben.

g. Die Schnittstellen von MEM 10112 zu JP 10114 und IOS 10116 (Fig. 209, 210, 211, 204)

Wie oben beschrieben, funktionieren der MJP-Kanal 10140 und MIO-Kanal 10128 logisch gesehen als drei unabhängige Kanäle. Diese Kanäle sind ein IO-Kanal zu IOS 10116, ein JP-Operandenkanal zu JP 10114 und ein JP-Befehlskanal zu JP 10114. In den Fig. 209, 210 und 211 werden diagrammartige Darstellungen von IO-Kanal 20910, JP-Operandenkanal (JPO) 21010 und JP-Befehlskanal (JPI) 21110 gezeigt.
Der IO-Kanal 20910 verwaltet alle Anforderungen von IOS 10116 nach MEM 10112, einschließlich des Transfers von Befehlen und Operanden. Der JPO-Kanal 21010 wird für Lese- und Schreiboperationen von Operanden benutzt, z. B. numerischen Werten, und zwar zu und von JP 10114. Der JPI-Kanal 21110 wird dazu benutzt, SINs, d. h. SOPs und Operandennamen, von MEM 10112 zu JP 10114 zu lesen. Speicherbedienungsauforderungen an einen bestimmten Kanal werden in der Reihenfolge bedient, in der sie dem Kanal zur Verfügung gestellt werden. Zwischen Anforderungen nach verschiedenen Kanälen wird keine serielle Ordnung aufrechterhalten, aber Kanäle können in der Reihenfolge ihrer Priorität bedient werden. In einer Verkörperung der vorliegenden Erfindung wird dem IO- Kanal 20910 die höchste Priorität gewährt, gefolgt von JPO-Kanal 21010 und schließlich von JPI-Kanal 21110, wobei Anforderungen, die augenblicklich in einem Kanal enthalten sind, die Priorität über neu hereinkommenden Anforderungen haben. Wie oben beschrieben und genauer in den folgenden Beschreibungen beschrieben, werden MEM 10112-Operationen "gepipelint". Dieses Pipelining erlaubt Überlappen von Anforderungen von IO-Kanal 20910, JPO-Kanal 21010 und JPI-Kanal 21110 gleichermaßen wie eine überlappende Bedienung der Anforderungen an einen bestimmten Kanal. Unter überlappenden Operationen sei verstanden, daß eine Operation, die einen bestimmten Kanal bedient, beginnt, bevor die vorangegangene Operation, die jenen Kanal bedient, abgeschlossen wurde.

1. Die Betriebskennzeichen des IO-Kanals 20910 (Fig. 209, 204)

Indem wir uns zunächst zu Fig. 209 zuwenden, wird dort eine diagrammartige Darstellung des IO-Kanals 20910 gezeigt. Signale werden zwischen IO-Kanal 20910 und IOS 10116 über den MIO-Bus 10129, IOM-Bus 10130 und IOMC-Bus 10131 übertragen. Der MIO- Bus 10129 ist ein eindirektionaler Bus, der Eingaben von MC 20116 und FIU 20120 erhält und für den Daten- und Befehlstransfer von MEM 10112 nach IOS 10118 ausgelegt ist. Der IOM-Bus 10130 ist gleichermaßen ein eindirektionaler Bus und ist für den Transfer von Leseadressen, Schreibadressen und Daten, die nach MEM 10112 geschrieben werden sollen, zwischen IOS 10118 und MEM 10112 ausgelegt. Der IOM-Bus 10130 stellt Eingaben BYF 20118, FIU 20120 und MIC 20122 zur Verfügung. Der IOMC-Bus 10131 ist eine Menge von zweckbestimmten Signallinien für den Austausch von Steuersignalen zwischen IOS 10118 und MEM 10112.
Indem wir uns zuerst auf MIO-Bus 10129 beziehen, ist MIO-Bus 10129 ein 36 Bit-Bus, der Lesedateneingaben von MC 20116's Zwischenspeicher und von FIU 20120 empfängt. Eine einzelne Leseoperation von MEM 10112 nach IOS 10116 transferiert ein 32 Bit-Wort (oder vier Bytes) von Daten (MIO (0-31)) und vier Bits ungerader Parität (MIOP (0-3)) oder ein Paritätsbit pro Byte.
Nun auf IOM-Bus 10130 Bezug nehmend, beinhaltet ein einzelner Transfer von IOS 10116 nach MEM 10112 36 Informationsbits, die entweder eine Speicheranforderung, die eine physikalische Adresse umfaßt, oder eine wahre Länge oder Befehlsbits enthalten. Diese Speicheranforderungen und Daten werden auf IOM 10130 durch IOS 10116 vervielfacht.
Datentransfers von IOS 10116 nach MEM 10112 umfassen jeweils ein einzelnes 32 Bitdatenwort (IOM (0-31)) und vier Bits ungerader Parität (IOMP (0-3)) oder ein Paritätsbit pro Byte. Solche Datentransfers werden entweder von BYF 20118 oder von FIU 20120 empfangen.
Jede IOS 10116-Speichernnforderung nach MEM 10112 umfaßt, wie oben beschrieben, ein Adressenfeld, ein Längenfeld und ein Operationscodefeld. Die Adreß- und Längenfelder besetzen die 32 Linien des IOM-Bus 10130, der für den Transfer von Daten nach MEM 10112 bei IOS 10116-Schreiboperationen benutzt wird. Das Längenfeld beinhaltet vier Informationsbits, die die Bits 0-3 des IOM-Bus 10130 besetzen, und das Adressenfeld enthält 27 Informationsbits, die die Bits 4-31 des IOM-Bus 10130 besetzen. Zusammen spezifizieren das Adreß- und das Längenfeld eine physikalische Startadresse und wahre Länge eines bestimmten Datenausdrucks, der nach MEM 10112 geschrieben oder von dort gelesen werden soll. Das Operationscodefeld spezifiziert den Typ der Operation, die von MEM 10112 ausgeführt werden soll. Bestimmte Basisoperationscodes umfassen drei Informationsbits, die die Bits 32-36 des IOM-Bus 10130 besetzen, wie oben beschrieben wurde. Dieselben Linien werden für den Transfer der Paritätsbits während der Datentransfers benutzt. Bestimmte Operationen, die von MEM 10112 durch IOS 10116 angefordert werden können, sind, zusammen mit den entsprechenden Befehlscodefeldern, die folgenden:
000 = Lesen
001 = Lesen und Setzen
010 = Schreiben
011 = Fehler
100 = Lies Fehlerprotokoll (erste Hälfte)
101 = Lies Fehlerprotokoll (zweite Hälfte) und Setz zurück
110 = Repariere Block und
111 = Bereinige den Zwischenspeicher.
Zwei weitere Befehlsbits können weitere Operationen spezifizieren, die von MEM 10112 ausgeführt werden sollen. Ein erstes Befehlsbit zeigt MEM 10112 an, ob es während Schreiboperationen wünschenswert ist, Daten, die nach MEM 10112 geschrieben werden sollen, in den Zwischenspeicher von MC 20116 zu laden. IOS 10116 kann dieses Bit auf Null setzen, falls eine Wiederverwendung der Daten unwahrscheinlich ist, und zeigt damit MEM 10112 an, daß MEM 10112 es vermeiden sollte, die Daten zwischenzuspeichern. IOS 10116 kann dieses Bit auf Eins setzen, wenn eine Wiederverwendung dieser Daten wahrscheinlich ist, und zeigt MEM 10112 damit an, daß es wünschenswert ist, diese Daten zwischenzuspeichern. Ein zweites Befehlsbit bezeichnen wir als CYCLE. Das CYCLE-Befehlsbit zeigt MEM 10112 an, ob ein spezieller Datentransfer eine Einfachzyklusoperation ist, d. h. ein Bit-genaues Wort, oder eine Vierzyklusoperation, d. h. ein Block-ausgerichteter Block oder ein Byte-ausgerichteter Teilblock.
IOMC 10131 enthält eine Menge von zweckbestimmten Linien für den Austausch von Steuersignalen zwischen IOS 10116 und MEM 10112, um den Betrieb von IOS 10116 und MEM 10112 zu koordinieren. Ein erstes solches Signal ist der Lade-IO-Anforderer (LIOR) von IOS 10116 nach MEM 10112. Wenn IOS 10116 eine Speicheranforderung in MEM 10112 laden will, so prägt IOS 10116 MEM 10112 LIOR auf. IOS 10116 muß LIOR während desselben Systemzyklusses aufprägen, währenddem die Speicheranforderung, d. h. Adressen, Längen und Befehlscodefehler, gültig sind. Wenn die LIOR- und IO- Kanal-Gültig-Signale, die unten beschrieben werden, während desselben Uhrzyklus aufgeprägt werden, wird MEM 10112's Kanal von IOS 10116 geladen, und IOPA wird umgeschaltet, was anzeigt, daß die Anforderung akzeptiert worden ist. Falls eine Ladeanforderung versucht wird, und IOPA wird nicht aufgeprägt, erfährt MEM 10112 nichts von dieser Anforderung, LIOR bleibt aktiv, und die Anforderung muß dann wiederholt werden, wenn IOPA aufgeprägt wird.
IOPA ist ein Signal von MEM 10112 zu IOS 10116, das von MEM 10112 aufgeprägt wird, wenn MEM 10112 dazu bereit ist, eine neue Anforderung-von IOS 10116 zu akzeptieren. IOPA kann aufgeprägt werden, während eine vorhergehende Anforderung von IOS 10116 ihren Betrieb vollendet, falls die Adressen, Längen und Operationscodefelder dieser vorangegangenen Anforderung nicht mehr länger von MEM 10112 benötigt werden, z. B. dazu, Bypass-Operationen zu bedienen.
IO-Daten-Genommen (TIOMD) ist ein Signal von MEM 10112 zu IOS 10116, das anzeigt, daß MEM 10112 Daten von IOS 10116 empfangen hat. IOS 10116 plaziert ein erstes Datenwort auf IOM-Bus 10130 beim nächsten Systemtaktzyklus, nachdem eine Schreibanforderung geladen wurde; d. h. LIOR wurde aufgeprägt, eine Speicheranforderung präsentiert und IOPA umgeschaltet. MEM 10112 nimmt dann das Datenwort am Taktanfang des nächsten Systemzyklusses. An diesem Punkt prägt MEM 10112 TIOMD auf, um anzuzeigen, daß die Daten akzeptiert worden sind. Bei einer Einzelwortoperation wird TIOMD nicht von IOS 10116 benutzt, weil das erste Datenwort immer von MEM 10112 akzeptiert wird, wenn der IO-Kanal 20910 verfügbar war. Bei Blockoperationen wird das erste Datenwort immer genommen, aber eine Verzögerung kann zwischen dem Empfangen des ersten und des zweiten Worts auftreten. IOS 10116 muß das zweite Wort auf IOM-Bus 101130 gültig halten, bis MEM 10112 mit TIOMD antwortet, um anzuzeigen, daß die Blockoperation fortschreiten kann.
Daten-Verfügbar für IO (DAVIO) ist ein Signal, was von MEM 10112 IOS 10116 aufgeprägt wird, das anzeigt, daß die Daten, die von IOS 10116 angefordert wurden, verfügbar sind. DAVIO wird von MEM 10112 während des Systemtaktes aufgeprägt, indem MEM 10112 die angeforderten Daten auf den MIO-Bus 10129 plaziert. Bei jedem einzelnen Worttypentransfer ist DAVIO aktiv für ein Einzelsystemtakttransfer. Bei blockähnlichen Transfers ist DAVIO normalerweise für vier aufeinander folgende Systemtakte aktiv. Beim Auftreten einer Einzelzyklus-"Blase", als Ergebnis einer ERCC- Fehlerentdeckung und -korrektur von BC 20114, bleibt DAVIO für vier nicht aufeinander folgende Systemtaktzyklen hoch und bleibt mit einer Einzelzyklusblase, einer Nichtaufprägung in DAVIO, was einer Fehlerentdeckung und Fehlerkorrektur entspricht.
IO-Speicherunterbrechung (IMINT) ist ein Signal, das von MEM 10112 IOS 10116 aufgeprägt wird, wenn VC 20114 einen Satz eines entdeckten Zählers in BC 20114's Fehlerprotokoll schreibt, wie oben beschrieben wurde.
Vorhergehender MIO-Transfer-ungültig (PMIOI)-Signal ist ein ähnliches Signal, das von MEM 10112 IOS 10116 aufgeprägt wird, das Fehler beim Datenlesen von MEM 10112 nach IOS 10116 betrifft. Wenn ein unkorrigierbarer Fehler bei solchen Daten auftaucht, d. h. ein Fehler in zwei oder mehr Datenbits, so werden die inkorrekten Daten nach IOS 10116 gelesen und das PMIOI-Signal von MEM 10112 aufgeprägt. Korrigierbare oder Einzelbitfehler in Daten ergeben keine Aufprägung eines PMIOI. MEM 10112 prägt PMIOI IOS 10116 beim nächsten Systemtakt auf, der MEM 10112's DAVIO-Aufprägung folgt.
Nachdem MEM 10112's Schnittstelle zu IOS 10116, und bestimmte Operationen, die IOS 10116 von MEM 10112 abfordern kann, beschrieben wurden, werden im folgenden bestimmte MEM 10112-Operationen innerhalb der Einsetzbarkeit der Schnittstelle beschrieben werden. Erstens können Operandentransfers, z. B. von numerischen Daten, zwischen MEM 10112 und IOS 10116 Bit-genau sein mit jeder Länge zwischen ein und sechzehn Bits. Die Operandentransfers können Grenzen innerhalb einer Seite überschreiten, dürfen aber keine physikalischen Seitengrenzen überschreiten. Wie oben beschrieben, sind MIO-Bus 10129 und IOM-Bus 10130 dazu imstande, 32 Datenbits auf einmal zu transferieren. Die am wenigsten signifikanten 16 Bits dieser Busse, d. h. die Bits 16 bis 31, enthalten während der Operandentransfers rechts ausgerichtete Daten. Der Inhalt der 16 höchstsignifikanten Bits dieser Busse ist im allgemeinen nicht definiert, weil im allgemeinen MEM 10112 keine Fülloperationen bei Leseoperationen nach IO-Kanal 20910 durchführt, und IOS 10116 während Schreiboperationen auch keine ungenutzten Bits auffüllt. Während einer Lese- oder Schreiboperation sind nur jene Datenbits, die vom Längenfeld in der entsprechenden Speicheranforderung indiziert werden, von Bedeutung. In allen Fällen jedoch muß die Parität für alle 32 Bits des MIO-Bus 10129 und IOM-Bus 10130 gültig sein.
Mit Bezug auf Fig. 204 enthält IOS 10116 Datenkanäle 20410 und 20412, die beide weiter in einer folgenden genauen Beschreibung von IOS 10116 beschrieben werden. Die Datenkanäle 20410 und 20412 besitzen beide spezielle Charakteristiken, die bestimmte IO- Kanal 20910-Operationen definieren. Der Datenkanal 20410 arbeitet mit vollen und partiellen Blöcken, die Schreib-/Leseblock-ausgerichtet sind. Ganze Blöcke haben blockausgerichtete Adressen und die Länge von 16 Bytes. Teilblöcke haben Byte-ausgerichtete Adressen eine Länge zwischen einem und 15 Bytes; ein Teilblocktransfer muß innerhalb eines Blockes sein, d. h. darf nicht Blockgrenzen überqueren. Ein ganzer Vier- Wort-Block wird zwischen IOS 10116 und MEM 10112 in beiden Fällen transferiert, aber nur jene Blöcke, die durch das Längenfeld in einer entsprechenden MEM 10112-Anforderung indiziert werden, sind von aktueller Bedeutung bei einer Schreiboperation. Nicht adressierte Bytes können bei solchen Operationen jede Information enthalten, so lange wie die Parität für den gesamten Datentransfer gültig ist. Der Datenkanal 20412 liest oder schreibt vorzugsweise 16 Bits gleichzeitig auf Doppelbytegrenzen. Solche sind auf dem MIO-Bus 10129 und dem IOM-Bus 10130 rechts ausgerichtet. Die 16 höchstwertigen Bits dieser Busse können jede Information während solcher Operationen enthalten, so lange wie die Parität für die gesamten 32 Bits Gültigkeit besitzt. Die Operationen des Datenkanals 20412 sind den IOS 10116-Operanden Lese- und Schreiboperationen mit Doppelbyte-ausgerichteten Adressen und Längen von 16 Bits ähnlich. Schließlich werden Befehle, die z. B. den Betrieb von IOS 10116 steuern, von MEM 10112 nach IOS 10116 blockweise gelesen. Solche Operationen sind identisch zu Ganzblockdaten-Leseoperationen.
Nachdem die Betriebskennzeichen von IO-Kanal 20910 beschrieben worden sind, werden im folgenden die Betriebskennzeichen von JPO-Kanal 21010 beschrieben.

2. Die Betriebskennzeichen von JPO-Kanal 21010 (Fig. 210)

In Fig. 210 wird eine diagrammartige Darstellung des JPO-Kanals 21010 gezeigt. Wie oben gezeigt, wird JPO-Kanal 21010 für den Transfer von Operanden benutzt, z. B. numerischen Daten, und zwar zwischen MEM 10112 und JP 10114. Der JPO-Kanal 21010 beinhaltet eine Anforderungseingabe (Adressen, Längen und Operationsinformation) für MIC 20122 vom 36 Bit-PD-Bus 10146, eine Datenschreibeingabe für FIU 20120 vom 32 Bit-JPD-Bus 10142, eine 32 Bit-Lese-Datenausgabe von MC 20116 und FIU 20120 zum 32 Bit-MOD-Bus 10144, und bidirektionale Steuereingaben und -ausgaben zwischen MIC 20122 und JPMC-Bus 10147.
Indem wir uns zuerst auf JPO-Kanal 21010's Datenleseausgabe an MOD-Bus 10144 beziehen, so wird der MOD-Bus 10144 vom JPO-Kanal 21010 dazu benutzt, Daten, z. B. Operanden, zu JP 10114 zu transferieren. Der MOD-Bus 10144 wird auch als MEM 10112-interner bidirektionaler Bus benutzt, um Daten zwischen MC 20116 und FIU 20120 zu transferieren. In dieser Weise können Daten von MC 20116 zu FIU 20120, wo bestimmte Datenformatoperationen auf die Daten angewendet werden, transferiert werden, bevor die Daten über den MOD-Bus 10144 nach JP 10114 transferiert werden. Es können auch Daten dazu benutzt werden, um Daten von FIU 20120 nach MC 20116 zu transferieren, nachdem eine Datenformatoperation bei einer Schreiboperation durchgeführt worden ist. Daten können auch direkt von MC 20116 über den MOD-Bus 10144 zu JP 10114 transferiert werden. Innerhalb von MEM 10112 ist der MOD-Bus 10144 ein 36 Bit- Bus für den gleichzeitigen Transfer von 32 Datenbits, die MOD-Bus 10144-Bits (MOD (0-31)), und vier Bits ungerader Parität, ein Bit pro Byte, die MOD-Bus 10144-Bits (MODP (0-3)). Außerhalb von MEM 10112 ist der MOD-Bus 10144 ein 32 Bit-Bus, der die (MOD (0-31))-Bits umfaßt; Paritätsbits werden von JP 10114 nicht gelesen. Daten werden in MEM 10112 über den JPD-Bus 10142 und FIU 20120 geschrieben. Wie soeben beschrieben, können Datenformatoperationen dann auf diese Daten ausgeführt werden, bevor sie von FIU 20120 über den MOD-Bus 10144 nach MC 20116 transferiert werden. Bei solchen Operationen arbeitet der JPD-Bus 10142 als ein 32 Bit-Bus, der 32 Datenbits, die Bits (JPD (0-31)) ohne Paritätsbits trägt. Der JO-Kanal 21010 erzeugt für JPD-Bus 10142 Daten, die nach MEM 10112 geschrieben werden sollen, Parität, wenn diese Daten nach MEM 10112 transferiert werden.
Es werden auch Speicheranforderungen an MEM 10112 von JP 10114 über den JPD-Bus 10142 übertragen, der in dieser Hinsicht als 40 Bit-Bus operiert. Jede solche Anforderung beinhaltet ein Adressenfeld, ein Längenfeld, ein FIU-Feld, das die Datenformatoperationen, die ausgeführt werden sollen, spezifiziert, ein Operationscodefeld und ein Bestimmungscodefeld, das die Bestimmung der Daten enthält, die von MEM 10112 gelesen werden. Das Adressenfeld enthält ein 13 Bitfeld für die physikalische Seitennummer (JPPN (0-12)), und ein 14 Bitfeld für den physikalischen Seitenabstand (JPPO (0-13)). Das Längenfeld enthält sechs Bits Längeninformation (JLNG (0-5)) und drückt die wahre Länge des Datenausdrucks aus, der nach MEM 10112 geschrieben oder von dort gelesen werden soll. Weil der JPD-Bus 10142 und der MOD-Bus 10144 beide dazu imstande sind, 32 Datenbits in einem einzigen MEM 10112 Lese- oder Schreibzyklus zu transferieren, werden sechs Bits Längeninformation nötig, um die wahre Länge auszudrücken. Wie in einer folgenden Beschreibung beschrieben werden wird, kann JP 10114 den physikalischen Seitenabstand und die Längeninformation direkt MEM 10112 zur Verfügung stehen, führt Übersetzungen zur Umwandlung von logischen Seitennummern in physikalische Seitennummern durch, und kann eine Schutzmechanismus 10230-Überprüfung für die resultierende physikalische Seitennummer durchführen. In einem solchen Fall erwartet MEM 10112 (JPPN (0-12)) später als (JPPO (0-13)) und (JLNG (0-5)). (JPPO (0-13)) und (JLNG (0-5)) sollten jedoch während des Systemzyklusses, in dem eine JP 10114-Speicheranforderung in MEM 10112 geladen wird, gültig sein.
Das Operationscodefeld, das MEM 10112 von JP 10114 zur Verfügung gestellt wird, ist ein drei Bitcode (JMCMD (0-2)), der die Operation spezifiziert, die von MEM 10112 ausgeführt werden soll. Bestimmte Operationen, die JP 10114 von MEM 10112 anfordern kann, und ihre entsprechenden Operationscodes sind:
000 = Lesen
001 = Lesen und Setzen
010 = Schreiben
011 = Fehler
100 = Fehler
101 = Lese Fehlerprotokoll und setz zurück
110 = Repariere Block; und
111 = Reinige den Zwischenspeicher.
Das Zwei-Bit-FIU-Feld (JFIU (0-1)) spezifiziert Datenmanipulationsoperationen, die bei der Ausführung von Lese- oder Schreiboperationen durchgeführt werden sollen. Unter den Datenmanipulationsoperationen, die von JP 10114 angefordert werden können, sind folgende einschließlich ihrer FIU-Felder:
00 = rechts ausgerichtet, mit Nullen gefüllt;
01 = rechts ausgerichtet, mit Vorzeichenerweiterung;
10 = links ausrichten, mit Nullen ausfüllen; und
11 = links ausrichten, mit Leerzeichen füllen.
Für Schreiboperationen kann der JPO-Kanal 21010 nur auf das höchstsignifikante Bit des FIU-Feldes, d. h. das FIU-Feld-Bit, das die Ausrichtung spezifiziert, antworten.
Schließlich ist das Bestimmungsfeld ein zwei Bit-Feld, das eine JP 10114-Bestimmung für Daten spezifiziert, die von MEM 10112 gelesen werden sollen. Dieses Feld wird bei Schreiboperationen nach MEM 10112 ignoriert. Das erste Bit des Bestimmungsfeldes, JPMDST, identifiziert die Bestimmung als FU 10120, und das zweite Feld, EBMDST, spezifiziert EU 10120 als Bestimmung.
Der JPMC-Bus 10147 beinhaltet zweckbestimmte Linien für den Austausch von Steuersignalen zwischen dem JPO-Kanal 21010 und JP 10114. Unter diesen Steuersignalen ist die Lade-JO-Anforderung (LJOR), die von JP 10114 aufgeprägt wird, wenn JP 10114 eine Anforderung in MEM 10112 laden will. LJOR wird gleichzeitig mit der Präsentation der Speicheranforderung an MEM 10112 über den PD-Bus 10146 ausgeprägt. JO-Kanalverfügbar (JOPA) wird von MEM 10112 ausgeprägt, wenn der JPO-Kanal 21010 dazu imstande ist, eine neue Speicheranforderung von JP 10114 zu akzeptieren. Wenn LJOR und JOPA gleichzeitig aufgeprägt werden, akzeptiert MEM 10112 die Speicheranforderung von JP 10114 und MEM 10112 schaltet JOPA herunter, um anzuzeigen, daß die Speicheranforderung akzeptiert worden ist. Wie oben besprochen, kann MEM 10112 JOPA aufprägen, während eine vorherige Anforderung ausgeführt wird und während die PD-Bus 10146-Information, das ist die Speicheranforderung, die-vorher zur Verfügung gestellt wurde, die die vorige Anforderung betrifft, nicht mehr länger benötigt wird.
Wenn JP 10114 eine Speicheranforderung abschickt und JOPA nicht von MEM 10112 aufgeprägt wird, akzeptiert MEM 10112 die Anforderung nicht, und JP 10114 muß jene Anforderung noch einmal abschicken, wenn JOPA aufgeprägt ist. Weil, wie oben beschrieben, das JPPN-Feld der Speicheranforderung von JP 10114 spät im Vergleich zu den anderen Feldern der Anforderung ankommen kann, zögert MEM 10112 das Laden des JPPN-Feldes für eine bestimmte Anforderung bis zum nächsten Systemtaktzyklus, nach dem die Anforderung ursprünglich abgeschickt worden war, heraus. MEM 10112 kann dieses JPPN-Feld auch zur gleichen Zeit erhalten, zu der es in das Kanalregister geladen wird, indem es das Kanalregister umgeht.
JP 10114 kann eine Speicheranforderung abbrechen, indem es JP-Anforderung-abbrechen (ABJR) aufprägt. ABJR wird von MEM 10112 während des Systemtaktes nach dem Empfangen der Speicheranforderung von JP 10114 empfangen, und ABJR wird mit einem Abbruch der angeforderten Operation enden. Eine einzige ABJR-Linie wird sowohl für JPO-Kanal 21010 als auch für JPI-Kanal 21110 zur Verfügung gestellt, weil, wie in einer folgenden Beschreibung erläutert wird, MEM 10112 nur eine einzelne Anforderung von JP 10114, entweder für JPO-Kanal 21010 oder für JPI-Kanal 21110 während eines einzelnen Systemtaktzyklusses empfangen kann.
Bei der Vollendung einer Operanden-Leseoperation, die über JPO-Kanal 21010 angefordert wurde, kann MEM 10112 eines von zwei möglichen Daten-Verfügbar-Signalen JP 10114 aufprägen. Diese Signale sind Daten-verfügbar für FA (DAVFA) und Datenverfügbar für EB (DAVEB). Wie oben erwähnt, enthält ein Teil jeder Leseanforderung von JP 10114 ein Bestimmungsfeld, das die gewünschte Bestimmung der angeforderten Daten enthält. Wie weiter unten beschrieben wird, zeichnet MEM 10112 eine solche Bestimmungsinformation für Leseanforderungen auf und gibt die Bestimmungsinformation mit einer entsprechenden Information in der Form eines DAVFA und DAVEB zurück. DAVFA zeigt eine Bestimmung in FU 10120 an, während DAVEB eine in EU 10122 anzeigt. MEM 10112 kann ebenso das Signal mit Nullen gefüllt (ZFILL) aufprägen, das spezifiziert, ob die zu lesenden Daten für den JPO-Kanal 21010 mit Nullen aufgefüllt sind. ZFILL ist nur dann gültig, wenn DAVEB aufgeprägt ist.
Für eine JPO-Kanal 21010-Schreibanforderung sollte das assoziierte Schreibdatenwort im gleichen Systemtaktzyklus gültig sein wie die Anforderung, oder einen Systemtaktzyklus später. JP 10114 prägt JP-Schreibdatenladen (LJWD) während das Systemtaktzyklusses auf, wenn JP 10114 gültige Schreibdaten auf den JPD-Bus 10142 plaziert.
Wie oben besprochen, plaziert MEM 10112, wenn es eine JP 10114-Anforderung bedient und dabei einen Fehler entdeckt, eine Aufzeichnung dieses Fehlers in MC 20116's Fehlerprotokoll. Wenn ein Eintrag in das Fehlerprotokoll für JPO-Kanal 21010 oder IO- Kanal 20910 eingetragen wird, prägt MEM 10112 ein Unterbrechungskennzeichensignal auf, das anzeigt, daß ein gültiger Fehlerprotokolleintrag vorliegt. DP 10118 entdeckt dieses Kennzeichensignal und kann das Kennzeichensignal entweder zu JP 10114 oder zu IOS 10116 oder zu beiden weiterleiten. IOS 10116 oder JP 10114 können dann, wie von DP 10118 gewählt, das Fehlerprotokoll lesen und zurücksetzen und das Kennzeichen zurücksetzen. Das Unterbrechungskennzeichensignal wird nicht zwangsläufig an den Anforderer, JP 10114 oder IOS 10116, weitergeleitet, aus deren Anforderung der Fehler resultierte. Wenn ein unkorrigierbarer MEM 10112-Fehler, d. h. ein Fehler in zwei oder mehr Bits eines einzelnen Datenworts während einer Leseoperation entdeckt wird, werden die inkorrekten Daten nach JP 10114 gelesen und ein ungültiges Datensignal aufgeprägt. Ein Signal, nämlich vorangegangener MOD-Transfer ungültig (POMDI), wird von MEM 10112 beim nächsten Systemtaktzyklus, der entweder DAVFA oder DAVEB folgt, aufgeprägt. POMDI wird nicht für Einzelbitfehler aufgeprägt, es sei denn, die Daten wurden korrigiert und die korrigierten Daten in JP 10114 eingelesen.
Nachdem die Struktur und die Kennzeichen des JPO-Kanals 21010 beschrieben worden sind, wird im folgenden der JPI-Kanal 21110 beschrieben.

3. Betriebskennzeichen des JPI-Kanal 21110 (Fig. 211)

In Fig. 211 wird eine diagrammartige Darstellung des JPI-Kanal 21110 gezeigt. Der JPI- Kanal 21110 enthält Adreßeingänge vom PD-Bus 10146 nach FIU 20120, Datenausgaben zum MOD-Bus 10144 von MC 20116, und bidirektionale Steuerein- und -ausgaben von MIC 20122 zu JPMC-Bus 10147. Wie oben beschrieben, ist die Hauptfunktion des JPI- Kanals 21110 der Transfer von SOPs und Operandennamen von MEM 10112 zu JP 10114 bei einer Anforderung von JP 10114. Der JPI-Kanal führt dabei nur Leseoperationen durch, wobei jede Leseoperation ein Transfer von einem einzelnen 32 Bit-Wort ist, das eine Wort-ausgerichtete Adresse hat.
Bezug nehmend auf die Eingaben des JPI-Kanals 21110 vom PD-Bus 10146 umfassen die Leseanforderungen an MEM 10112 durch JP 10114 nach SOPs und Operandennamen jeweils eine 22 Bit-Wort-Adresse. Wie oben beschrieben, besteht jede JPI-Kanal 21110- Leseoperation aus einem einzelnen 32 Bit-Wort. Als solche werden die fünf niedrigstsignifikanten Bits der Adresse von MEM 10112 ignoriert. Aus dem gleichen Grund enthält eine JPI-Kanal 21110-Anforderung an MEM 10112 kein Längenfeld, kein Operationscodefeld, kein FIU-Feld oder ein Bestimmungscodefeld. Längen-, Operationscode- und FIU-Codefelder sind nicht erforderlich, weil der JPI-Kanal 21110 nur einen einzigen Typ von Operationen durchführt, und Bestimmungscodefelder sind nicht erforderlich, weil die Bestimmung einer JPI-Kanal 21110-Anforderung inne wohnt.
Die 32 Bit-Worte, die von MEM 10112 als Antwort auf eine JPI-Kanal 21110-Anforderung gelesen werden, werden zu JP 10114 über MC 20116's 32 Bitausgang zum MOD- Bus 10144 transferiert. Wie im Falle der JPO 21010-Leseausgaben nach JP 10114, stellt der JPI-Kanal 21110 keine Paritätsinformationen für JP 10114 zur Verfügung. Der Steuersignalaustausch zwischen JP 10114 und JPI-Kanal 21110 über den JPMC-Bus 10147 beinhaltet die JI-Ladeanforderung (LJIR) und JI-Kanal-verfügbar (JIPA), die in der gleichen Weise arbeiten, wie es im Zusammenhang mit dem JPO-Kanal 21010 besprochen wurde. Wie oben beschrieben, teilen sich der JPO-Kanal 21010 und der JPI-Kanal 21110 einen einzigen Befehl für den Abbruch einer JP-Anforderung (ABJR). In ähnlicher Weise teilen sich JPO-Kanal 21010 und JPI-Kanal 21110 "vorangegangener MOD-Transfer ungültig (PMODI)" von MEM 10112. Wie oben beschrieben, beinhaltet eine JPI-Kanal 21110-Anforderung kein Bestimmungsfeld, weil die Bestimmung implizid klar ist. MEM 10112 stellt jedoch ein Daten-verfügbar-Signal (DAVFI) JP 10114 zur Verfügung, wenn ein Wort, das von MEM 10112 als Antwort auf eine JPI-Kanal 21110-Anforderung gelesen wurde, auf dem MOD-Bus 10144 vorhanden und gültig ist.
Nachdem die Gesamtstruktur und der Betrieb von MEM 10112, und die Struktur und der Betrieb der Schnittstelle von MEM 10112 zu JP 10114 und IOS 10116 beschrieben worden sind, wird im folgenden die Struktur und der Betrieb von MEM 10112's FIU 20120 beschrieben werden.

h. FIU 20120 (Fig. 201, 230, 231)

Wie oben beschrieben, führt FIU 20120 bestimmte Datenmanipulationsoperationen durch, die jene Operationen beinhalten, die notwendig sind, um MEM 10112 Bit-adressierbar zu machen. Datenmanipulationsoperationen können auf Daten ausgeführt werden, die nach MEM 10112 geschrieben werden sollen, z. B. von JP 10114 über JPD-Bus 10142 oder von IOS 10116 über den IOM-Bus 10130. Datenmanipulationsoperationen können auch auf Daten ausgeführt werden, die von MEM 10112 nach JPD 10114 oder IOS 10116 gelesen werden sollen. Wenn Daten nach JP 10114 gelesen werden sollen, wird der MOD-Bus 10144 sowohl als ein MEM 10112-interner Bus, indem er Daten von MC 20116 zu FIU 20120 zur Manipulation transferiert, als auch zum Transfer der manipulierten Daten von MEM 10112 zu JP 10114 benutzt. Wenn Daten zu IOS 10116 gelesen werden sollen, wird der MOD-Bus 10144 wieder als MEM 10112-interner Bus benutzt, um die Daten von MC 20116 nach FIU 20120 für nachfolgende Manipulation zu lesen. Die manipulierten Daten werden dann von FIU 20120 zu IOS 10116 über den MIO-Bus 10129 gelesen. Bestimmte Datenmanipulationsoperationen, die von FIU 20120 durchgeführt werden können, wurden oben beschrieben. Im allgemeinen besteht eine Datenmanipulationsoperation aus vier distingten Operationen, und FIU 20120 kann Daten in jeder möglichen Weise manipulieren, die man durch eine Kombination dieser Operationen erreichen kann. Diese vier möglichen Operationen sind die Auswahl der Daten, die manipuliert werden sollen, Rotation oder Verschieben von jenen Daten, die Maskierung jener Daten und der Transfer jener manipulierten Daten zu einem ausgewählten Ziel. Jede Dateneingabe in FIU 20120 umfaßt ein 32 Bit-Datenwort und kann, wie oben beschrieben, aus den Eingaben, die von JPD-Bus 10142, MOD-Bus 10144 und IOM-Bus 10130 zur Verfügung gestellt werden, ausgewählt werden. In bestimmten Fällen kann eine Dateneingabe in FIU 20120 zwei 32 Bit-Worte umfassen, z. B. wenn eine wortübergreifende Operation ausgeführt wird, die eine Ausgabe erzeugt, die Bits aus zwei verschiedenen 32 Bit-Worten umfaßt. Die Rotation oder das Verschieben von selektierten 32 Bit-Datenworten erlaubt es, daß Bits innerhalb eines ausgewählten Worts mit Rücksicht auf Wortgrenzen neu positioniert werden können. Wenn die Rotation und Verschiebung in Verbindung mit der Maskierungsoperation, die momentan beschrieben wird, benutzt werden, können diese Operationen wiederholt durchgeführt werden, um jede selektierten Bits in einem Wort zu jeder selektierten Lokation in diesem Wort zu transferieren. Wie weiter unten beschrieben wird, erlaubt die Maskierungsoperation, daß jede ausgewählten Bits eines Worts scheinbar gelöscht werden können, und so nur bestimmte andere ausgewählte Bits hinterlassen, oder bestimmte ausgewählte Bits auf vorher festgelegte Werte setzen. Eine Maskierungsoperation kann beispielsweise ausgeführt werden, um Bereiche eines 32 Bit-Wortes mit Nullen aufzufüllen oder um ein Vorzeichen zu erweitern. In Verbindung mit einer Rotations- oder Verschiebungsoperation kann eine Maskierungsoperation z. B. ein Einzelbit eines 32 Bit-Eingabewortes auswählen, jenes Bit an jede beliebige Stelle plazieren und alle anderen Bits jenes Wortes auf Null setzen. Jede Ausgabe von FIU 20120 ist ein 32 Bit- Datenwort und, wie oben beschrieben, kann auf den MOD-Bus 10144 oder auf den MIO- Bus 10129 transferiert werden. Wie weiter unten beschrieben wird, wird die Auswahl einer bestimmten Abfolge der obigen vier Operationen, die auf ein bestimmtes Datenwort ausgeführt werden sollen, durch Steuerungseingaben, die von MIC 20122 zur Verfügung gestellt werden, bestimmt. Diese Steuerungseingaben von MIC 20122 werden von der Mikrobefehlssteuerungslogik, die in FIU 20120 enthalten ist, dekodiert und ausgeführt.
In Fig. 230 wird ein Ausschnitt aus einem Blockdiagramm von FIU 20120 gezeigt. Wie darin gezeigt, enthält FIU 20120 Datenmanipulations-Ablauflogik (DMC) 23010 und FIU- Steuerungsablauflogik (FIUC) 23012. Die Datenmanipulations-Ablauflogik 23010 wiederum enthält die FIUIO-Ablauflogik (FIUIO) 23014, den Datenverschieber (DS) 23016, die Maskenlogik (MSK) 23018 und eine Assembler-Registerlogik (AR) 23020. Die Datenmanipulations-Ablauflogik 23010 wird als erstes beschrieben werden, gefolgt von FIUC 23012. Bei der Beschreibung der Datenmanipulations-Ablauflogik 23010 wird FIUIO 23014 als erstes beschrieben werden, gefolgt von DS 23016, MSK 23018 und AR 23020 in jener Reihenfolge.
Mit Bezug auf FIUIO 23014, so umfaßt FIUIO 23014 die Dateneingangs- und -ausgangs- Ablauflogik von FIU 20120. Das Jobprozessor-Schreibdatenregister (JWDR) 23022, das IO-System-Schreibdatenregister (IWDR) 23024 und das Schreibeingangsdatenregister (RIDR) 23026 sind jeweils mit dem JPD-Bus 10142, IOM-Bus 10130 und MOD-Bus 10144 verbunden, um Datenworteingaben von jeweils JP 10114, IOS 10116 und MC 20116 zu empfangen. JWDR 23022, IWDR 23024 und RIDR 23026 sind jeweils 36 Bitregister, die beispielsweise SN74S374-Register beinhalten. Datenworte, die in IWDR 23024 und RIDR 23026 transferiert werden, bestehen jeweils, wie oben beschrieben, aus einem 32 Bit-Datenwort plus vier Paritätsbits. Dateneingaben von JP 10114 sind jedoch, wie oben beschrieben, 32 Bit-Datenworte ohne Parität. Der Jobprozessor-Paritätsgenerator (JPPG) 23028, der mit JWDR 23022 assoziiert ist, ist mit JPD-Bus 10142 verbunden und erzeugt vier Paritätsbits für jede Dateneingabe nach JWDR 23022. JWDR 23022's 36 Biteingabe umfaßt daher 32 Datenbits direkt vom JPD-Bus 10142, plus die entsprechenden vier Paritätsbits von JPPG 23028.
Datenworte, 32 Datenbits plus vier Paritätsbits, werden in JWDR 23022, IWDR 23024 oder RIDR 23026 transferiert, je nachdem, ob die Eingabe-Aktivierungssignale Lade-JWD (LJWD), Lade-IWD (LIWD) oder Lade-RID (LRID) aufgeprägt sind. LIWD wird von FU 10120 zur Verfügung gestellt, während LIWD und LRID von MIC 20122 zur Verfügung gestellt werden.
Die Datenworte, die in JWDR 23022, IWDR 23024 oder RIDR 23026 residieren, können durch Ausgabe-Aktivierungssignale JWD-Ausgangsaktivierung (JWDEO), IWD-Ausgangsaktivierung (IWDEO) und RID-Ausgangsaktivierung (RIDEO) selektiert und auf den FIU 20120-internen Datenbus (IB) 23030 transferiert werden. JWDEO, IWDEO und RIDEO werden von FIUC 23012, die unten beschrieben wird, zur Verfügung gestellt.
Wie weiter unten beschrieben wird, werden die manipulierten Datenworte von DS 23016 oder AR 23020 auf den Datenverschiebungsausgangsbus (DSO) 23032 respektive den Assemblerregisterausgangsbus (ASYRO) 23034 für nachfolgenden Transfer auf den MOD- Bus 10144 oder den MIO-Bus 10129 transferiert. Jedes manipulierte Datenwort, das im DSO-Bus 23032 oder im ASYRO-Bus 23034 auftaucht, umfaßt 32 Datenbits plus vier Paritätsbits. Die manipulierten Datenworte, die auf dem DSO-Bus 23032 liegen, können auf den MOD-Bus 10144 oder den MIO-Bus 10129 jeweils über den DSO-Bus zum MOD- Bustreiber-Verknüpfungsglied (DSMOD) 23036 oder über den BSO-Bus zum MIO- Bustreiber-Verkuüpfungsglied (DSMIO) 23038 transferiert werden. Die manipulierten Datenworte, die auf dem ASYRO-Bus 23034 liegen, können auf den MOD-Bus 10144 oder den MIO-Bus 10129 jeweils über den ASYRO-Bus zum MOD-Bustreiber-Verknüpfungsglied (ASYMOD) 23040 oder über den ASYRO-Bus zum MIO-Bustreiber- Verknüpfungsglied (ASYMIO) 23042 transferiert werden. DSMOD 23036, DSMIO 23038, ASYMOD 23040 und ASYMIO 23042 umfassen jeweils z. B. SN74S244-Treiber. Ein manipuliertes Datenwort auf dem DSO-Bus 23032 kann über DSMOD 23036 auf den MOD-Bus 10144 transferiert werden, wenn das Treiber-Verknüpfungsglied-Aktivierungssignal Treiber nach MOD verschieben (DRVSHFMOD) DSMOD 23036 aufgeprägt ist. In ähnlicher Weise wird ein manipuliertes Datenwort auf dem DSO-Bus 23032 über DSMIO 23038 zum MIO-Bus 10129 transferiert, wenn das Treiber-Verknüpfungsgleid-Aktivierungssignal Treiber durch MIO-Bus schieben (DRVSHFMIO) DSMIO 23038 aufgeprägt ist. Manipulierte Datenworte, die auf dem ASYRO-Bus 23034 liegen, können auf den MOD-Bus 10144 oder den MIO-Bus 10129 transferiert werden, wenn jeweils das Treiber- Verknüpfungsglied-Aktivierungssignal Schreibe die Anordnung zum MOD-Bus (DRVA- SYMOD) ASYMOD 23040 aufgeprägt ist oder Treibe die Anordnung zum MIO-Bus (DRVASYMIO) ASYMIO 23042 aufgeprägt ist. DRVSHFMOD, DRVSHFMIO, DRVA- SYMOD und DRVASYMIO werden, wie unten beschrieben, von FIUC 23012 zur Verfügung gestellt.
Die Register IARM 23044 und BARMR 23046, die in einer folgenden Beschreibung des DP 10118 näher beschrieben werden, werden von DP 10118 dazu benutzt, um Datenworte auf in 23030 zu schreiben respektive Datenworte von MOD-Bus 10144 zu lesen, z. B. manipulierte Datenworte von FIU 20120. Ein Datenwort, das von DP 10118 in IARMR 23044 geschrieben wurde und 32 Datenbits und vier Paritätsbits enthält, wird auf den IB- Bus 23030 transferiert, wenn die Aktivierungsausgabe für das Registeraktivierungsausgabesignal IARM (IARMEO) von FIUC 23012 aufgeprägt wird. In ähnlicher Weise wird ein Datenwort, das auf dem MOD-Bus 10144 liegt und 32 Datenbits plus vier Paritätsbits enthält, in BARMR 23046 geschrieben, wenn das Ladeaktivierungssignal Lade BARMR (LDBARMR) BARMR 23046 durch MIC 20122 aufgeprägt wird. Ein Datenwort, das vom MOD-Bus 10144 in BARMR 23046 geschrieben wurde, kann dann darauffolgend nach DP 10118 gelesen werden. IARMR 23044 und BARMR 23046 sind JWDR 23022, IWDR 23024 und IRDR 23026 ähnlich und umfassen z. B. SN74S299-Register.
Schließlich Bezug nehmend auf den IO-Paritäts-Überprüfungskreis (IOPC) 23048, so ist IOPC 23048 mit dem in-Bus 23030 verbunden, um jedes Datenwort, das aus 32 Datenbits plus vier Paritätsbits besteht und auf dem in-Bus 23030 erscheint, zu empfangen. IOPC 23048 bestätigt die Parität und die Gültigkeit der Daten jedes Datenworts, das auf dem IB- Bus 23030 erscheint, und es bestimmt insbesondere die Gültigkeit von Parität und Daten von Datenworten, die von IOS 10116 nach FIU 20120 geschrieben werden. IOPC 23048 erzeugt einen Ausgabenparitätsfehler (PER), der oben diskutiert wurde, der einen Paritätsfehler in Datenworten von IOS 10116 anzeigt.
DS 23016 beinhaltet Halbbytelogik (BYNL) 23050, Paritätsrotationslogik (PRL) 23052 und Bit-Skalierungslogik (BSL) 23054. BYNL 23050, PRL 23052 und BSL 23054 können beispielsweise 25S10-Verschieber umfassen. BYNL 23050 ist mit dem IB-Bus 23030 verbunden, um die 32 Datenbits eines selektierten Datenworts zu empfangen und zu verschieben und dann nach IB-Bus 23030 zu transferieren. PRL 23052 ist ein vier Bitregister, das in ähnlicher Weise mit dem IB-Bus 23030 verbunden ist, um die vier Paritätsbits eines selektierten Datenworts zu empfangen, zu verschieben und nach IB-Bus 23030 zu transferieren. Die Ausgänge von BYNL 23050 und PRL 23052 sind beide mit dem DSO-Bus 23032 verbunden, und stellen somit eine 36 Bit FIU 20120-Datenwortausgabe direkt von BYNL 23050 und PRL 23052 zur Verfügung. Die 32 Bit-Datenausgabe von BYNL 23050 ist auch mit dem Eingang von BSL 23054 verbunden. Die 32 Bitausgaben von BSL 23054 werden wiederum MSK 23018 zur Verfügung gestellt.
Wie oben beschrieben, führt DS 23016 Datenmanipulationsoperationen durch, die ein Verschieben von Bits innerhalb eines Datenworts umfassen. Im allgemeinen sind Datenverschiebungsoperationen, die von DS 23016 ausgeführt werden, Rotationen, bei denen die Datenbits nach rechts verschoben werden, wobei die am wenigsten signifikanten Bits eines Datenworts in die Position der höchstsignifikanten Bits verschoben werden und die höchstsignifikanten Bits in Richtung der Positionen für die weniger signifikanten Bits verschoben werden. Die Rotationsoperationen von DS 23016 werden in zwei Schritten durchgeführt. Der erste Schritt wird von BYNL 23050 und PRL 23052 durchgeführt und umfaßt die nach-rechts-Verschiebungen auf Halbbytebasis (ein Halbbyte ist definiert als vier Datenbits). Das heißt, BYNL 23050 verschiebt ein Datenwort um ein ganzzahliges Vielfaches von vier Bit-Inkrementen nach rechts. Eine nach-rechts-Verschiebung eines Halbbytes auf Halbbytebasis kann z. B. ausgeführt werden, wenn RM 20720 FLIPHALF aufprägt, was oben beschrieben wurde. FLIPHALF wird für Halbwort-Leseoperationen für IOS 10116 aufgeprägt, wobei die angeforderten Daten in den höchstsignifikanten 16 Bits eines Datenworts von MC 20116 stehen. BYNL 23050 führt eine Rechtsverschiebung von vier Halbbytes durch, um die gewünschten 16 Datenbits in die 16 niedrigstsignifikanten Bits der Ausgabe von BYNL 23050 zu transferieren. Die resultierende BYNL 23050- Ausgabe würde zusammen mit PRL 23052's Paritätsbitsausgabe über DSO 23032 zu MIO- Bus 10129 transferiert werden. Zusätzlich zur Durchführung von Datenverschiebungsoperationen kann DS 23016 ein Datenwort, d. h. 32 Datenbits direkt zu MSK 23018 transferieren, wenn die Datenmanipulation, die ausgeführt werden soll, es nicht erforderlich macht, Daten zu verschieben, d. h. es können Verschiebungen von 0 Bits durchgeführt werden.
Weil Datenbits von BYNL 23050 auf Halbbytebasis verschoben werden, kann die Beziehung zwischen den 32 Datenbits eines Wortes und den entsprechenden vier Paritätsbits aufrechterhalten werden, wenn die Paritätsbits in ähnlicher Weise um einen Betrag, der der Rechtsrotation der Datenbits entspricht, nach rechts rotiert werden. Diese Beziehung ist wahr, wenn das Datenwort in Vielfachem von zwei Halbbytes, d. h. acht Bits oder einem Byte nach rechts verschoben wird. PRL 23052 verschiebt die vier Paritätsbits eines Datenworts um einen Betrag, der der Rechtsverschiebung der entsprechenden 32 Datenbits in BYNL 23050 entspricht, nach rechts. Die rechts rotierten Ausgaben von BYNL 23050 und PRL 23052 umfassen daher gültige Datenworte, die 32 Datenbits und vier Paritätsbits enthalten, wobei die Paritätsbits in korrekter Weise mit den Datenbits in Verbindung stehen. Eine rechts rotierte Datenwortausgabe von BYNL 23050 und PRL 23052 kann auf den DSO-Bus 23032 für den nachfolgenden Transfer zum MOD- Bus 10144 oder zum MIO-Bus 10129, wie oben beschrieben, transferiert werden. DSO 23032 wird als Datenpfad für Byte-Schreiboperationen und "Rotierleseoperationen" von FIU 20120 benutzt, wobei die erforderliche Manipulation eines bestimmten Datenworts nur eine ganzzahlige Zahl von Rechtsverschiebungen um Bytes erforderlich macht. Der Betrag der Rechtsverschiebung der 32 Datenbits in BYNL 23050 und der vier Paritätsbits in DRL 23052 wird über Eingabesignalverschiebung (SHFT) (0-2) zu BYNL 23050 und PRL 23052 gesteuert. Wie unten beschrieben wird, wird SHFT (0-2) zusammen mit SHFT (3-4), die BSL 23054 steuern, von FIUC 23012 erzeugt. BYNL 23050 und PRL 23052 sind wie BSL 23054, das unten beschrieben wird, Parallelverschiebungslogikchips und die gesamte Rotationsoperation von BYNL 23050 und PRL 23052 oder BSL 23054 kann in einem Systemtaktzyklus durchgeführt werden.
Der zweite Schritt der Rotation wird von BSL 23054 durchgeführt, das, wie oben beschrieben, die 32 Datenbits eines Datenworts von BYNL 23050 erhält. BSL 23054 führt die Rechtsverschiebung bitweise mit einem Verschiebungsbetrag, der wahlweise zwischen 0 und 3 Bits liegen kann. Daher kann BSL 23054 Bits über Halbbytegrenzen hinweg rotieren. BYNL 23050 und BSL 23054 umfassen daher einen Datenverschiebungskreis, der dazu imstande ist, Bit für Bit Rechtsrotation mit einem Verschiebungsbetrag zwischen 1 Bit und 32 Bits durchzuführen.
Wenden wir uns jetzt MSK 23018 zu, so umfaßt MSK 23018 fünf 32 Bitmasken-Wortgeneratoren (MWGs) 23056 bis 23064. MSK 23018 erzeugt eine 32 Bitausgabe nach AR 23020, indem es selektiv die 32 Bitmasken-Wortausgaben der MWGs 23056 bis 23064 kombiniert. Jedes Maskenwort, das von einem der MWGs 23056 bis 23064 erzeugt worden ist, besteht praktisch aus einer Bit für Bit-Kombination aus einem Satz von Aktivierungsbits und einem vorher bestimmten 32 Bitmaskenwort, das von FIUC 23012 und MIC 20122 erzeugt worden ist. Die MWGs 23058 bis 23064 bestehen je aus z. B. NAND-Gattern mit potentialfreiem Ausgang, um diese Funktionen durchzuführen, während MWG 23056 aus einem PROM besteht.
Wie eben beschrieben, sind die MWG's 23056 bis 23064 jeweils Kreise mit potentialfreiem Ausgang, so daß jede gewünschte Kombination von Maskenwortausgaben der MWG's 23056 bis 23064 zusammen geodert werden kann, um die 32 Bitausgabe des MSK 23018 zu umfassen.
Die MWG 23056 bis MWG 23064 erzeugen Maskenwortausgaben: Verriegelungs-Bit- Wort (LBW) (0-31), vorzeichenerweitertes Wort (SEW) (0-31), Datenmaskenwort (DMW) (0-31), Leerzeichenauffüllwort (BWF) (0-31) und Assemblerregisterausgabe (ARO) (0-31). Erst auf MWG 23064 und ARO (0-31) Bezug nehmend, so werden die Inhalte des Assemblerregisters (ASYMR) 23066 in AR 23020 durch MWG 23064 geschleust, wenn das Aktivierungssignal Assembler-Output-Register (ASYMOR) aufgeprägt wird. ARO (0- 31) ist deshalb eine Kopie der Inhalte von ASYMR 23066, und MWG 23064 erlaubt es, daß die Inhalte von ASYMR 23066 mit der ausgewählten Kombination von LBW (0-31), SEW (0-31), DMW (0-31) oder BFW (0-31) geodert werden.
DMW (0-31) von MWG 23060 wird durch eine Und-Verknüpfung der Aktivierungseingabe-Datenmaske (DMSK) (0-31) mit der 32 Bitausgabe von DS 23016 erzeugt. DMSK (0-31) ist ein 32 Bit-Aktivierungswort, das, wie unten beschrieben, von FIUC 23012 erzeugt wird. FIUC 23012 kann vier verschiedene DMSK (0-31)-Muster erzeugen. In Fig. 231 werden die vier DMSKs (0-31), die von FIUC 23012 erzeugt werden können, gezeigt. DMSKA (0-31) wird in Linie A der Fig. 231 gezeigt. In DMSKA (0-31) sind alle Bits links von einem Bit, das als Linksbitadresse (LBA) bezeichnet wird, nicht einschließlich dieses Bits, und alle Bits rechts von einem Bit, das als Rechtsbitadresse (RBA) bezeichnet wird, auch nicht inklusive dieses Bits, 0. Alle Bits dazwischen und einschließlich jener Bits, die als LBA und RBA bezeichnet werden, sind 1. DMSKB (0-31) wird in Linie B der Fig. 231 gezeigt und ist die Umkehrung von DMSKA (0-31). DMSKC (0-31) und DMSKD (0-31) werden in Fig. 231 in der Linie C respektive D gezeigt und bestehen nur aus Nullen respektive nur aus Einsen. Wie oben festgestellt, ist DMSK (0-31) mit der 32 Bitausgabe von DS 23016 Und-verknüpft. Als solches kann DMSKC (0-31) z. B. dazu benutzt werden, die Ausgabe von DS 23016 zu unterdrücken, während DMSKD (0-31) z. B. dazu benutzt werden kann, die Ausgabe von DS 23016 an AR 23020 weiterzuleiten. DMSKA (0-31) und DMSKB (0-31) können z. B. dazu benutzt werden, um ausgewählte Bereiche der Ausgabe von DS 23016 mit AR 23020 logisch zu verknüpfen, wo z. B. die ausgewählten Bereiche der Ausgabe von DS 23016 mit anderen Maskenwortausgaben MSK 23018 geodert werden können.
Sich als nächstes auf MWG 23062 beziehend, generiert MWG 23062 BFW (0-31). BWG (0-31) wird in einer besonderen Operation benutzt, bei der 32 Bitdatenworte erzeugt werden müssen, die 1 bis 4 ASCII-Leerzeichen beinhalten müssen, wobei ein Bit pro Byte eine logische Eins und die restlichen Bits logische Nullen beinhalten. In diesem Fall können die ASCII-Leerzeichen-Bytes logische Einsen in den Bitpositionen 2, 10, 18 und 26 beinhalten.
Wieder Bezug nehmend auf Fig. 231, zeigt die Linie E darin eine rechts ausgerichtete 32 Bitmaske (RMSK) (0-31), die von FIUC 23012 erzeugt werden kann. Im allgemeinsten Fall enthält RMSK Nullen auf allen Bitpositionen links von und einschließlich einer Bitposition, die als RBA bezeichnet wird. In einer Leerzeichenauffülloperation benutzt, können die Bitpositionen 2, 10, 18 und 26 ausgewählt werden, logische Einsen zu enthalten, abhängig von jenen Byte-Positionen, die logische Einsen enthalten, d. h. die in jenen Bytes ASCII-Leerzeichen enthalten; diese Bytes rechts von RBA werden von RMSK (0-31) bestimmt. RMSK (0-31) wird wie BWF (0-31) durch MWG 23062 aktiviert, wenn MWG 23062 durch ein Leerzeichenauffüllen (BLNKHLL) aktiviert wird, wofür FIU 23012 sorgt.
Wie oben beschrieben, sind die MWFGs 23058 bis 23064 und insbesondere die MWGs 23060 und 23062 NAND-Gatteroperationen. Daher sind die Ausgaben der MWGs 23056 bis 23064 aktive L-Signale. Die invertierte Ausgabe von ASYMR 23066 wird als Ausgabe für ASYRO 23034 benutzt, um diese Ausgaben nach aktiv high zu invertieren.
MWG 23058, das SEW (0-31) erzeugt, wird bei der Erzeugung von vorzeichenerweiterten oder gefüllten Worten benutzt. Bei vorzeichenerweiterten Worten werden alle Biträume links vom signifikantesten Bit eines 32 Bit-Datenwortes mit dem Vorzeichenbit des Datums, das darin enthalten ist, aufgefüllt, die am weitesten links stehenden Bits eines 32 Bit-Worts werden mit Einsen oder Nullen aufgefüllt, abhängig davon, ob das Vorzeichenbit jenes Worts anzeigt, daß das Datum, das darin enthalten ist, eine positive oder negative Zahl ist.
Der Vorzeichenwahl-Multiplexer (SIGNSL) 23066 ist so geschaltet, daß er die 32 Datenbits eines auf IB-Bus 23030 vorhandenen Worts empfangen kann. Der Vorzeichenwähler (SGNSFL) (0-4) bis SIGNSEL 23066 wird von SBA (0-4) abgeleitet, d. h. vom SBA-Bus 21226 von PRMUX 20720. Wie oben beschrieben, ist SBA (0-4) die Anfangsbitadresse, die das erste oder signifikanteste Bit eines Datenwortes identifiziert. Wenn ein Datenwort eine vorzeichenbehaftete Zahl enthält, so enthalten die signifikantesten Bits das Vorzeichenbit jener Zahl. Die SGNSEL (0-4)-Eingabe nach SIGNSEL 23066 wird als Auswahleingabe benutzt und wählt, wenn SIGNSEL durch Vorzeichenerweitern (SI- GNEXT) von FIU 23012 aktiviert wird, das Vorzeichenbit auf dem IB-Bus 23030 und stellt dieses Vorzeichenbit als eine Eingabe für MWG 23058 zur Verfügung.
Die Vorzeichenbiteingabe nach MWG 23058 wird mit jedem Bit der links ausgerichteten Maske (LMSK) (0-31) von FIUC 23012 Und-verknüpft. Wieder auf Fig. 231 Bezug nehmend, wird LMSK (0-31) auf Linie F darin gezeigt. LMSK (0-31) enthält rechts von und einschließlich des Bitplatzes, der durch LBA identifiziert wird, nur Nullen und Einsen auf allen Bitplätzen links von jenem Bitplatz, der durch LBA identifiziert wird. SEW (0- 31) enthält daher Vorzeichenbits auf allen Bitplätzen links des signifikantesten Bits des Datenwortes, das auf dem Ausgang von MWG 23058 vorliegt. Das Datenwort auf dem IB-Bus 23030 kann dann durch DS 23016 geschleust werden und einer DMSK-Operation unterworfen werden, bei der alle Bits links des signifikantesten Bits auf Null gesetzt werden. Die SEW (0-31) und DMW (0-31)-Ausgaben der MWGs 23058 und 23060 können dann geodert werden, um die gewünschte vorzeichenerweiterte Wortausgabe zur Verfügung zu stellen.
LBW (0-31), das von MWG 23056 zur Verfügung gestellt wird, wird bei Verriegelungsbitoperationen benutzt, bei denen das signifikanteste Datenbit eines Datenworts in MEM 10112 auf logisch Eins gesetzt wird. SIGNSEL (0-4) ist eine Adreßeingabe nach MWG 23056 und zeigt, wie oben beschrieben, das signifikanteste Datenbit eines Datenworts an, das auf IB-Bus 23030 vorhanden ist. MWG 23056 wird durch Eingabeverriegeln von FIUC 23012 aktiviert, und das resultierende LBW (0-31) enthält eine einzige logische Eins auf dem Bitplatz des signifikantesten Datenbits des Datenworts, das auf IB-Bus 23030 liegt. Das auf in-Bus 23030 vorliegende Datenwort kann dann durch DS 23016 und MWG 23060 geleitet werden, um mit LBW (0-31) geodert zu werden, so daß das signifikanteste Datenbit jenes Datenworts auf logisch Eins gezwungen wird.
Sich wieder auf AR 23020 beziehend, enthält AR 23020 ASYMR 23066, das beispielsweise SN74S 175-Register und einen Assemblerregister-Paritätsgenerator (ASYPG) 23070 enthalten kann. Wie oben beschrieben, ist ASYMR 23066 mit MSK 23018's 32 Bitausgang verbunden. Ein 32 Bit-Wort, das auf MSK 23018's Ausgang anliegt, wird nach ASYMR 23066 transferiert, wenn ASYMR 23066 durch ein Assemblerregisterladen (ASYMLD) von MIC 20122 aktiviert wird. Das 32 Bit-Wort, das über DS 23016 und MSK 23018 erzeugt wurde, ist dann auf dem ASYRO-Bus 23034 vorhanden und kann, wie oben beschrieben, dann auf MOD-Bus 10144 oder MIO-Bus 10129 transferiert werden. ASYPG 23070 ist an den 32 Bitausgang von ASYMR 23066 angeschlossen und generiert vier Paritätsbits für das 32 Bit-Wort, das auf den 32 Datenlinien des ASYRO- Busses 23034 liegt. Die Vier-Bit-Paritätsausgabe von ASYPG 23070 wird auf die vier Paritätsbitlinien des ASYRO-Busses 23034 geleitet und begleitet darauf das 32 Bit- Datenwort.
Nachdem die Struktur und der Betrieb der Datenmanipulationsablauflogik 23010 beschrieben worden ist, wird im folgenden FIUC 23012 beschrieben.
Sich wieder auf Fig. 230 beziehend, stellt FIUC 23012 Pipeline-verarbeitete Mikrobefehlssteuerung für FIU 20120 zur Verfügung. Das heißt, Steuersignale werden von MIC 20122 während eines ersten Systemtaktes empfangen, und bestimmte dieser Steuersignale werden durch die Mikrobefehlslogik dekodiert, um weitere FIUC 23012-Steuersignale zu erzeugen. Während des zweiten Systemtaktes werden die Steuersignale, die während des ersten Systemtaktes empfangen und generiert wurden, DMC 23010 zur Verfügung gestellt, manche von innen werden weiter dekodiert, um noch andere Steuersignale für die Steuerung des Betriebs von FIUC 23012 zur Verfügung zu stellen. FIUC 23012 enthält eine Anfangsdekodierlogik (IDL) 23074, Pipelineregister (PPLR) 23072, eine Schlußdekodierlogik (FDL) 23076 und ein Aktivierungssignal-Pipelineregister (ESPR) 23098 mit Aktivierungssignaldekodierlogik (ESDL) 23099.
IDL 23074 und die Steuerpipelineregister (CPR) 23084 von PPLR 23072 sind mit den Steuerausgängen von MIC 20122 verbunden, um Steuersignale von dort während des ersten Systemtaktes zu empfangen, wie oben beschrieben wurde. IDL 23074 stellt Ausgaben für die Steuerungspipelineregister Rechtsbitadreßregister (RBAR) 23086, Linksbitadreßregister (LBAR) 23088 und Schieberegister (SHFR) 23090 von PPLR 23072 zur Verfügung. CPR 23084 und SHFR 23090 stellen Steuerausgaben DMC 23010 direkt zur Verfügung. Wie oben beschrieben, steuern diese Ausgaben DMC 23010 während des zweiten Systemtaktes.
CPR 23084, RBAR 23086 und LBAR 23088 stellen Ausgaben FDL 23076 während des zweiten Systemtaktes zur Verfügung, und FDL 23076 stellt wiederum bestimmte Ausgaben DMC 23010 direkt zur Verfügung.
ESPR 23098 und ESDL 23099 empfangen Aktivierungs- und Steuersignale von MIC 20122 und stellen wiederum Aktivierungs- und Steuersignale DMC 23010 und bestimmten anderen Bereichen der MEM 10112-Ablauflogik zur Verfügung.
IDL 23074 und FDL 23076 können beispielsweise aus PROMs bestehen. CPR 23084, RBAR 23086, LBAR 23088, SHFR 23090 und ESPR 23098 können beispielsweise aus SN74S194-Registern bestehen. ESDL 23099 kann z. B. aus kompatiblen Dekodern wie z. B. logischen Gattern bestehen.
Zuerst auf IDL 23074 Bezug nehmend, führt IDL 23074 ein erstes Dekodieren der Schaltkreissteuerungssignale von MIC 20122 durch und stellt weitere Steuersignale, die von FIUC 23012 bei der Steuerung von FIU 20120 benutzt werden, zur Verfügung. IDL 23074 umfaßt Nur-Lese-Speichervektoren mit Rechtsbitadressen-Dekodierlogik (RBADL) 23078, Linksbitadressen-Dekodierlogik (LBADL) 23080 und Verschiebungsbetrag- Dekodierlogik (SHFAMTDL) 23082. RBADL 23078 empfängt als Adreßeingaben Ende- Bitadressen (FBA) (0-4), eine Bitlängennummer (BLN) (0-4) und eine Anfangsbitadresse (SBA) (0-4). FBA, BLN und SBA definieren das letzte Bit, die Länge und das Anfangsbit des angeforderten Datenausdrucks, wie oben beschrieben, im Zusammenhang mit PRMUX 20720. RBADL 23078 empfängt auch Chipauswahl-Aktivierungssignale Adressen- Übersetzungschip-Auswählen (ATCS) 00, 01, 02, 03, 04 und 155 von MIC 20122 und insbesondere RM 20722. Wenn FIU 20120 bestimmte MSK 23018-Operationen ausführen soll, so werden von MIC 20122 RBADL 23078 die Eingaben FBA (0-4), BLN (0-4) und SBA (0-4) zusammen mit einer ATCS-Eingabe zur Verfügung gestellt. RBADL 23078 wiederum stellt Ausgaben RBA (Rechtsbitadresse) (0-4) zur Verfügung, was oben beschrieben wurde im Zusammenhang mit DMSK (0-31) und RMSK (0-31). LBADL 23080 ist RBADL 23078 ähnlich und wird mit Eingaben BLN (0-4), FBA (0-4), SBA (0- 4) und ATCS 06, 07, 08, 09 und 05 von MIC 20122 versorgt. LBADL stellt wiederum für bestimmte MSK 23018-Operationen Linksbitadressen (LBA) (0-4) zur Verfügung, die oben im Zusammenhang mit DMSK (0-31) und LMSK (0-31) besprochen wurden.
RBA (0-4) und LBA (0-4) werden beim Beginn des zweiten Systemtaktes durch das Pipeline-Laden-Aktivieren-Signal PIPELD, das von MIC 20122 zur Verfügung gestellt wird, nach RBAR 23086 und LBAR 23088 transferiert. RBAR 23086 und LBAR 23088 stellen wiederum die Ausgaben Register-Rechtsadresse (RRAD) (0-4) und Register- Linksadresse (RLAD) (0-4) als Adreßeingaben für die Rechtsmaskendekodierlogik (RMSKDL) 23092, der Linksmaskendekodierlogik (LMSKDL) 23094 und FDL 23076 beim Beginn des zweiten Systemtaktes zur Verfügung. RRAD (04-) und RLAD (0-4) entsprechend RBA (0-4) respektive LBA (0-4).
RMSKDL 23092 und LMSKDL 23094 sind Nur-Lesespeichervektoren, die wie eben beschrieben, RRAD (0-4) und RLAD (0-4) als Adreßeingaben respektive Maske-Aktivieren (LMSKENBL) von CPR 23084 als Aktivierungseingaben haben. Zusammen erzeugen RMSKDL 23092 und LMSKDL 23094 RMSK (0-31) respektive LMSK (0-31) für MSK 23018. RMSK (0-31) und LMSK (0-31) werden als Eingaben für die Exklusiv-Oder /Exklusive-Nicht-Oder-Verknüpfung (XOR/XNOR) 23096 zur Verfügung gestellt. XOR/XNOR 23096 empfängt auch das Aktivierungs- und Auswahlssignal Maske-heraus OUTMASK von CPR 23084. Die RMSK (0-31) und IMSK (0-31)-Eingaben nach XOR/- XNOR 23096 werden, wie durch OUTMSK von CPR 23084 ausgewählt, dazu benutzt, eine ausgewählte DMSK (0-31), wie in Fig. 231 gezeigt, zu erzeugen. Die DMSK (0-3 1)- Ausgabe von XOR/XNOR 23096 wird, wie oben beschrieben, MSK 23018 zur Verfügung gestellt.
Wieder mit Bezug auf IDL 23074, dekodiert SHFAMTBL 23082 bestimmte Steuereingaben von MIC 20122, um durch SHFR 23090 Steuereingaben SHFT (0-4) und SGNSEL (0-4) für DS 23016 respektive SIGNSEL 23068 und MWG 23056 zu generieren. Die Adreßeingaben für die PROMs, die SHFAMTBL 23082 umfassen, beinhalten FBA (0-4), SBA (0-4) und FLIPHALF (FLIPHALF) von MIC 20122. FBA (0-4) und SBA (0- 4) sind oben beschrieben worden. FLIPHALF ist ein Steuersignal, das anzeigt, daß, wie oben beschrieben, jene 16 Datenbits, die von IOS 10116 angefordert sind, in der oberen Hälfte eines 32 Bit-Datenworts residieren, und bewirkt, daß jene 16 Bits auf die untere Hälfte des Ausgangsdatenworts von FIU 20120 auf den MIO-Bus 10129 transferiert wird. MIC 20122 stellt auch Chipaktivierungssignale ATCS 10, 11, 12, 13 und 14 zur Verfügung. Beim Empfang dieser Steuereingaben von MIC 20122 erzeugt SHFAMTDL 23082 einen Ausgabeverschiebungsbetrag (SHFAMT) (0-4), der zusammen mit SBA (04-) von MIC 20122 beim Beginn des zweiten Systemtaktes nach SHFR 23090 durch PIPELD transferiert wird. SHFR 23090 stellt dann die entsprechenden Ausgaben SHFT (0-4) und SIGNSEL (0-4) zur Verfügung. Wie oben beschrieben, wird SIGNSEL (0-4) SIGNSEL 23068 und MWG 23056 und MSK 23018 zur Verfügung gestellt. SHFT (0-4) wird als SHFT (0-2) und SHFT (3-4) BYNL 23050 respektive BSL 23054 und DS 23016 zur Verfügung gestellt.
Auf CPR 23084 Bezug nehmend, werden bestimmte Steuersignale, wie oben beschrieben, direkt der FIU 20120-Ablauflogik zur Verfügung gestellt, ohne durch IDL 23074 oder FDL 23076 dekodiert zu werden. Die Eingaben für CPR 23084 beinhalten Vorzeichenerweiterung (SIGNEXT) und Verriegelung (LOCK), die anzeigen, daß FIU 20120 durch MWG 23058 eine Vorzeichenerweiterungsoperation bzw. eine Verriegelungs-Bit-Wort- Operation durch MWG 23056 durchführen soll. CPR 23084 stellt MSK 23018 die entsprechenden Ausgaben SIGNEXT und LOCK zur Verfügung, um diese Operationen auszuwählen. Assembler-Ausgaberegister-Eingeben (ASYMOR) und Leerzeichen-auffüllen (BLANKFILL) werden durch CPR 23084 als ASYMOR und BLANKFILL nach MWG 23064 respektive MWG 23062 gebracht, um die Ausgabe von ASYMR 23066 als Maske zu selektieren, oder um anzuzeigen, daß MSK 23018 ein mit Leerzeichen gefülltes Wort durch MWG 23062 generieren soll. Die Eingaben OUTMSK und MSKENBL für CPR 23084 werden, wie oben besprochen, als Aktivierungssignale OUTMSK und MSKENBL für EXOR/ENOR 23096 respektive RMSKDL 23092 und LMSKBL 23094 zur Verfügung gestellt und generieren RMSK (0-31), LMSK (0-31) und DMSK (0-31), wie oben beschrieben wurde.
Indem wir schließlich auf ESPR 23098 und ESDL 23099 Bezug nehmen, so umfassen ESPR 23098 und PPLR 23072 zusammen ein Pipelineregister und eine ESDL-Dekodierlogik, um Aktivierungssignale FIU 20120 und weiterer MEM 10112-Ablauflogik zur Verfügung zu stellen. ESPR 23098 empfängt die Eingaben MOD-Bus-ansteuern DRVMOD (0-1), MIO-Bus-ansteuern (BRVMIO) (0-1) und Register-aktivieren (ENREG) (0-1) von MIC 20120, wie oben beschrieben wurde. DRVMOD (0-1), DRVMIO (0-1) und ENREG (0-1) werden nach ESPR 23098 durch PIPELD transferiert, wie es oben im Zusammenhang mit PPLR 23072 beschrieben wurde. ESPR 23098 stellt die entsprechenden Ausgaben ESDL 23099 zur Verfügung, das wiederum DRVMOD (0-1), DRVMIO (0- 1) und ENREG (0-1) dekodiert, um Aktivierungssignale FIU 20120 und weiterer MEM 10112-Ablauflogik zur Verfügung zu stellen. Die Ausgaben DRVSHFMOD, DRVASYMOD, DRVSHFMIO und DRVASYMIO werden DSMOD 23036, DSMIO 23038, ASYMOD 23040, ASYMIO 23042 und FIUIO 23014 zur Verfügung gestellt, um den Transfer von FIU 20120-manipulierten Datenworten auf dem MOD-Bus 10144 und dem MIO-Bus 10129 zu steuern. Die Ausgaben IARMEO, JWDEO, IWDEO und RIDEO werden als Ausgangsaktivierungssignale IARMR 23044, JWDR 23022, IWDR 23024 und RIDR 23026 zur Verfügung gestellt, um die Inhalte dieser Register auf den IB-Bus 23030, wie es oben beschrieben wurde, zu transferieren. Die Ausgaben DRVCAMOD, DRVAMIO, DRVBYMOD und DRVBYMIO werden MC 20116 zur Steuerung des Informationstransfers auf MOD-Bus 10144 und MIO-Bus 10129 zur Verfügung gestellt.
Nachdem die Struktur und der Betrieb von MEM 10112 oben beschrieben wurde, wird im folgenden die Struktur und der Betrieb von FU 10120 beschrieben werden.

B. Die Zugriffseinheit 10120 (Fig. 202, 206, 101, 103, 104, 238)

Wie oben beschrieben wurde, ist FU 10120 eine unabhängig operierende mikrocodegesteuerte Maschine, die zusammen mit EU 10122 die Mikromaschine von CS 10110 zur Ausführung von Benutzerprogrammen umfaßt. Die Hauptfunktionen von FU 10120 beinhalten: (1) Zugriff auf und Interpretieren von Befehlen, d. h. SINs, die SOPs und Namen umfassen, und auf Daten von MEM 10112 für den Gebrauch von FU 10120 und EU 10122; (2) die Organisation und Steuerung des Flusses und der Ausführung von Benutzerprogrammen; (3) die Initiierung von EU 10122-Operationen; (4) die Ausführung von arithmetischen und logischen Operationen auf Daten; (5) die Steuerung des Datentransfers von FU 10120 und EU 10122 nach MEM 10112; und (6) die Verwaltung von bestimmten Stapelspeicherregistermechanismen. Unter diesen Stapelspeicher- und Registermechanismen sind der Namenszwischenspeicher (NC) 10226, der Adreßübersetzungszwischenspeicher (ATC) 10228, der Schutzzwischenspeicher (PC) 10234, die architektonischen Basisregister (ABRs) 10364, die Mikrosteuerungsregister (mCRs) 10366, der Mikrostapelspeicher (MIS) 10368, der Überwachungsstapelspeicher (MOS) 10370 der allgemeinen Registerdatei (GRF) 10354, der Mikrostapelspeicher-Zeigerregistermechanismus (MISPR) 10356 und der Rückgabesteuerungs-Wortzwischenspeicher (RCWS) 10358. Zusätzlich zur Verwaltung dieser FU 10120-residenten Stapelspeicher- und Registermechanismen, erzeugt und verwaltet FU 10120 ganz oder teilweise bestimmte, in MEM 10112- residente Datenstrukturen. Unter diesen in MEM 10112 residenten Datenstrukturen sind die Speicheraufteilungstabelle (MHT) 10716 und die Speicherrahmenstabelle (MFT) 10718, die Arbeitssatzmatrix (WSM) 10720, die Anforderungswarteschlange des virtuellen Speichermanagements (VMMRQ) 10721, die Tabelle der aktiven Objekte (AOT) 10712, die Tabelle der aktiven Subjekte (AST) 10914 und die virtuellen Prozessorzustandsblöcke (VPSB) 10218. Darüber hinaus ist eine Hauptfunktion von FU 10120 die Erzeugung und Manipulation von logischen Beschreibern, die, wie oben beschrieben, die Basis der CS 10110-internen Adressierungsstruktur sind. Während FU 10120's interne Struktur und Betrieb FU 10120, wie weiter unten beschrieben werden wird, erlaubt, arithmetische und logische Operationen auszuführen, beinhaltet FU 10120's Struktur bestimmte Merkmale, um die Erzeugung und Manipulation von logischen Beschreibern zu beschleunigen.
In Fig. 202 wird ein Ausschnitt aus einem Blockdiagramm von FU 10120 gezeigt. Um die Klarheit der Darstellung zu vergrößern, werden bestimmte Verbindungen innerhalb FU 10120 und zwischen FU 10120 und EU 10122 und MEM 10122 nicht durch Linienverbindungen gezeigt, sondern, wie weiter unten beschrieben, werden auf andere Weise angezeigt, wie z. B. durch gemeinsame Signalnamen. Die hauptsächlichen funktionalen Elemente von FU 10120 beinhalten den Beschreiberprozessor (DESP) 20210, die MEM 10112-Schnittstellenlogik (MEMINT) 20212 und die Zugriffseinheit-Steuerungslogik (FUCTL) 20214. DSP 20210 ist im allgemeinen eine arithmetische und logische Einheit zur Erzeugung und Manipulation von Eingaben für die in MEM 10112 und FU 10120- residenten Stapelspeichermechanismen und Zwischenspeicher, wie es oben beschrieben wurde, und insbesondere für die Erzeugung und Manipulation von logischen Beschreibern. Darüber hinaus ist DSP 20210, wie oben festgestellt wurde, eine für die allgemeine Verwendung bestimmte zentrale Prozessoreinheit (CPU), die imstande ist, bestimmte arithmetische und logische Funktionen durchzuführen.
DESP 20210 beinhaltet den AON-Prozessor (AONP) 20216, den Abstandsprozessor (OFFP) 20218 und den Längenprozessor (LENP) 20220. OFFP 20218 umfaßt eine allgemeine 32 Bit-CPU mit zusätzlicher Struktur, um die Erzeugung und Manipulation von Abstandsfeldern von logischen Beschreibern zu optimieren. AONP 20216 und LENP 20220 umfassen Prozessoren für die Erzeugung und Manipulation von AON- respektive Längenfeldern von logischen Beschreibern, und können in Verbindung mit OFFP 20218 dazu benutzt werden, bestimmte arithmetische und logische Operationen auszuführen.
DESP 20210 beinhaltet GRF 10354, das wiederum die globalen Register (GRs) 10360 und die Stapelspeicherregister (SRs) 10362 umfaßt. Wie oben beschrieben, beinhalten die GRs 10360 die ABRs 10364 und die mCRs 10366, während die SRs 10362 MIS 10368 und MOS 10370 beinhalten. MEMINT 20212 umfaßt die FU 10120-Schnittstelle für MEM 10112, um physikalische Beschreiber (physikalische Adressen) MEM 10112 zur Verfügung zu stellen, um SINs und Daten von MEM 10112 zu lesen und um Daten nach MEM 10112 zu schreiben. ME- MINT 20212 beinhaltet, abgesehen von weiterer Ablauflogik, MC 10226, ATC 10228 und PC 10234.
FUCTL 20214 steuert den Zugriff auf SINs und Daten von MEM 10112 und stellt Mikrobefehlsabfolgen für die Steuerung von FU 10120 und EU 10122 als Antwort auf SOPs zur Verfügung. FUCTL 20214 stellt MC 10226 Namenseingaben für den nachfolgenden Zugriff auf die entsprechenden Daten von MEM 10112 zur Verfügung. FUCTL 20214 beinhaltet teilweise MISPR 10356, RCWS 10358, die Zugriffseinheits-S-Interpreter- Aufteilungstabelle (FUSDT) 11010 und die Zugriffseinheits-S-Interpreter-Tabelle (FUSITT) 11012.
Nachdem die Gesamtstruktur von FU 10120, insbesondere mit Rücksichtnahme auf die vorherigen Beschreibungen in Kapitel 1 dieser Beschreibung, beschrieben wurden, werden im folgenden und in dieser Reihenfolge DESP 20210, MEMINT 20212 und FUCTL 20214 genauer beschrieben werden.

1. Der Beschreibungsprozessor 20210 (Fig. 202, 101, 103, 104, 238, 239)

Wie oben beschrieben, umfaßt DESP 20210 eine 32 Bit-CPU, um alle gewöhnlichen arithmetischen und logischen Operationen auf Daten auszuführen. Darüber hinaus ist eine Hauptfunktion von DESP 20210 die Erzeugung und Manipulation von Eingaben für z. B. Namenstabellen (NTs) 10350, ATC 10228 und PC 10234 und die Erzeugung und Manipulation von logischen Beschreibern. Wie oben im Zusammenhang mit der Adressierungsstruktur von CS 10110 beschrieben, sind logische Beschreiber logische Adressen oder Zeiger auf Daten, die in MEM 10112 gespeichert sind. Logische Beschreiber werden z. B. als architektonische Basiszeiger oder Mikrosteuerungszeiger in den ABRs 10364 und MCRs 10366, wie in Fig. 103 gezeigt, oder als Verkettungs- und lokale Zeiger von Prozedurrahmen 10412, wie es in Fig. 104 gezeigt wird, benutzt. In einem weiteren Beispiel werden logische Beschreiber, die von DESP 20210 erzeugt wurden und bestimmten Operandennamen entsprechen, in MC 10226 gespeichert, wo auf sie nachfolgend von jenen Namen zugegriffen wird, die in SINs auftauchen, die von MEM 10112 geholt werden, um eine schnelle Übersetzung von logischen Namen in die entsprechenden logischen Beschreiber zu gewährleisten.
Wie oben im Zusammenhang mit der Adressierungsstruktur von CS 10110 besprochen wurde, werden die logischen Beschreiber, die ATU 10228 von DESP 20210 und NC 10226 zur Verfügung gestellt werden, durch ATU 10228 in physikalische Beschreiber übersetzt, die aktuelle physikalische Adressen der entsprechenden Daten darstellen, die in MEM 10112 gespeichert sind. Die Daten werden im folgenden JP 10114 und insbesondere FU 10120 oder EU 10122 über den MOD-Bus 10144 zur Verfügung gestellt.
Wie oben im Zusammenhang mit MEM 10112 besprochen wurde, können alle Daten, die von MEM 10112 nach JP 10114 gelesen werden, bis zu 32 Informationsbits enthalten. Wenn ein bestimmter Datenausdruck, der durch einen logischen Beschreiber referenziert wird, mehr als 32 Datenbits enthält, erzeugt DESP 20210, wie weiter unten beschrieben, aufeinander folgende logische Beschreiber, wobei sich jeder logische Beschreiber auf 32 oder weniger Informationsbits bezieht, so lange bis der gesamte Datenausdruck von MEM 10112 gelesen wurde. In dieser Hinsicht sollte bemerkt werden, daß NC 10226 nur logische Beschreiber für Datenausdrücke von 255 oder weniger Bits enthalten kann. Alle Anforderungen an MEM 10112 nach Datenausdrücken, die länger als 32 Bits sind, werden von DESP 20210 erzeugt. Die meisten Datenausdrücke, mit denen CS 10110 operiert, sind jedoch 32 oder weniger Bits lang, so daß NC 10226 dazu imstande ist, die meisten Übersetzungen von Operandennamen nach logischen Beschreibern zu verwalten. Wie oben beschrieben, enthält DESP 20210 AONP 20216, OFFP 20218 und LENP 20220. OFFP 20218 umfaßt eine für die allgemeine Verwendung bestimmte 32 Bit-CPU mit zusätzlichen logischen Schaltkreisen für die Erzeugung und Manipulation von Tabellen und Zwischenspeichereingaben, wie es oben beschrieben wurde, und für die Erzeugung und Manipulation von Abstandsfeldern von AON-Zeigern und logischen Beschreibern. AONP 20216 und LENP 20220 umfassen logische Schaltkreise für die Erzeugung und Manipulation von AON und Längenfeldern von AON-Zeigern respektive logischen Beschreibern. Wie in Fig. 202 gezeigt, ist GRF 10354 vertikal in drei Teile eingeteilt. Ein erster Teil befindet sich in AONP 20216 und enthält zusätzlich zu willkürlichen Daten AON-Felder von logischen Beschreibern. Der zweite und dritte Teil befinden sich in OFFP 20218 respektive in LENP 20220 und beinhalten zusätzlich zu willkürlichen Daten Abstands- respektive Längenfelder von logischen Beschreibern. Die AON-, Abstands- und Längenbereiche von GRF 10354 befinden sich in AONP 20216 respektive OFFP 20218 und LENP 20220, und werden als AONGRF respektive OFFGRF und als LENGRF bezeichnet. Der AONGRF-Bereich von GPF 10354 ist 28 Bits breit, während die OFFGRF- und LENGRF-Bereiche von GRF 10354 32 Bits breit sind. Obwohl es vertikal in drei Teile unterteilt ist, wird GRF 10354 als eine einzige Struktur adressiert und arbeitet als solche. Das heißt, eine bestimmte Adresse, die GRF 10354 zur Verfügung gestellt wird, adressiert die entsprechenden horizontalen Segmente von jedem der drei Sektionen von GRF 10354, die sich in AONP 20216, OFFP 20218 und LENP 20220 befinden.

a. Die Struktur des Abstandsprozessors 20219

Indem wir uns zuerst auf OFFP 20218 beziehen, ist OFFP 20218 zusätzlich zu seiner Funktion als 32 Bit-CPU, die Tabellen und Zwischenspeichereingaben und Abstandsfelder von AON-Zeigern und logischen Beschreibern generiert und manipuliert, der Hauptpfad von DESP 20210 für das Empfangen von Daten von oder für den Transfer von Daten nach MEM 10112. OFFP 20218 beinhaltet einen Abstandseingabenauswahl-Multiplexer (OFFSEL) 20238, OFFGRF 20234, eine Abstandsmultiplexerlogik (OFFMUX) 20240, eine Abstands-ALU (OFFALU) 20242 und einen Abstands-ALU-A-Eingabenmultiplexer (OFFALUSA) 20244.
OFFSEL 20238 hat einen ersten und zweiten 32 Bit-Dateneingang, der mit MOD-Bus 10144 bzw. JPD-Bus 10142 verunden ist. OFFSEL 20238 hat einen dritten 32 Bit- Dateneingang, der mit dem ersten Ausgang von OFFALU 20242 verbunden ist, einen vierten 28 Bit-Dateneingang, der mit dem ersten Ausgang von AONGRF 20232 verbunden ist, und einen fünften 32 Bit-Dateneingang, der mit dem OFFSET-Bus 20228 verbunden ist. OFFSEL 20238 hat einen ersten 32 Bit-Ausgang zum Eingang von OFFGRF 20234 und einen zweiten 32 Bit-Ausgang, der mit dem ersten Eingang von OFFMUX 20240 verbunden ist. OFFMUX 20240 hat einen zweiten und dritten 32 Bit-Dateneingang, die mit dem MOD-Bus 10144 bzw. dem JPD-Bus 10142 verbunden sind. OFFMUX 20240 hat auch einen vierten 5 Bit-Dateneingang, der mit der BIAS-Logik (BIAS) 20246 und LENP 20220 verbunden ist, die weiter unten beschrieben werden, und einen fünften 16 Bit-Dateneingang, der mit dem NAME-Bus 20224 verbunden ist. Der 32 Bit-Datenausgang von OFFGRF 20234 und der erste 32 Bit-Datenausgang von OFFMUX 20240 sind verbunden mit dem ersten bzw. zweiten Dateneingang von OFFALUSA 20244. Der erste 32 Bit-Datenausgang von OFFALUSA 20244 und der zweite 32 Bit-Datenausgang von OFFMUX 20240 sind mit dem ersten bzw. zweiten Dateneingang von OFFAL 20242 verbunden. Ein zweiter 32 Bit-Datenausgang von OFFALSA 20244 ist mit dem OFFSET- Bus 20228 verbunden. Der erste 32 Bit-Datenausgang von OFFALU 20242 ist mit dem JPD-Bus 20142, mit dem ersten Eingang des AON-Eingabeauswahl-Multiplexers (AON- SEL) 20248 und AONP 20216, und wie oben beschrieben, mit einem dritten Eingang von OFFSEL 20238 verbunden. Ein zweiter 32 Bit-Datenausgang von OFFALU 20242 ist mit dem OFFSET-Bus 20228 verbunden und der dritte 16 Bit-Ausgang ist mit dem NAME- Bus 20224 verbunden.

b. Die Struktur des AON-Prozessors 20216

Mit Bezug auf AONP 20216, so ist eine Hauptfunktion von AONP 20216 die, AON- Felder von AON-Zeigern und logischen Beschreibern zu enthalten. Darüber hinaus können jene Bereiche von AONGRF 20232, die sonst nicht von AON-Zeigern und logischen Beschreibern besetzt werden, als 28 Bit breite allgemeine Registerfläche von JP 10114 genutzt werden. Diese Bereiche von AONGRF 20232 können so entweder alleine oder in Verbindung mit den entsprechenden Bereichen von OFFGRF 20234 und LENGRF 20236 benutzt werden. AONP 20216 beinhaltet AONSEL 20248 und AONGRF 20232. Wie oben beschrieben, ist der erste 32 Bit-Dateneingang von AONSEL 20248 mit dem ersten Datenausgang von OFFALU 20242 verbunden. Ein zweiter 28 Bit-Dateneingang von AONSEL 20248 ist mit dem 28 Bit-Ausgang von AONGRF 20232 und dem AON-Bus 20230 verbunden. Ein dritter 28 Bit-Dateneingang von AONSEL 20248 ist mit logischen Nullen verbunden, d. h. ein 28 Bit-Eingang, bei dem jedes Eingangsbit auf logisch Null gesetzt ist. Der 28 Bit-Datenausgang von AONSEL 20248 ist mit dem Dateneingang von AONGRF 20232 verbunden. Wie eben beschrieben, ist der 28 Bit-Datenausgang von AONGRF 20232 mit-dem zweiten Dateneingang von AONSEL 20248 und dem AON-Bus 20230 verbunden.

c. Die Struktur des Längenprozessors 20220

Indem wir uns schließlich auf LENP 20220 beziehen, so ist eine Hauptfunktion von LENP 20220 die Erzeugung und Manipulation von Längenfeldern von AON-Zeigern und physikalischen Beschreibern. Darüber hinaus kann LENGRF 20236 teilweise alleine oder in Verbindung mit den entsprechenden Adreßräumen von AONGRF 20232 und OFFGRF 20234 als allgemeine Register für die Speicherung von Daten benutzt werden. LENP 20220 beinhaltet den Längeneingabenauswahl-Multiplexer (LENSEL) 20250, LFNGRF 20236, BIAS 20246 und die Längen-ALU (LENALU) 20252. LENSEL 20250 hat einen ersten und zweiten Dateneingang, die mit LENGTH-Bus 20226 bzw. dem OFFSET-Bus 20228 verbunden sind. Der LENGTH-Bus 20226 ist ein 8 Bit-Datenbus, der mit Nullen gefüllt ist, während der OFFSET-Bus 20228 ein 32 Datenbit-Bus ist. LENSEL 20250 hat einen dritten 32 Bit-Dateneingang, der mit dem Datenausgang von LENALU 20252 verbunden ist. Der 32 Bit-Datenausgang von LENSEL 20250 ist mit dem Dateneingang von LENGRF 20236 und mit dem ersten Dateneingang von BIAS 20246 verbunden. Der zweite und dritte 32 Bit-Dateneingang von BIAS 20246 ist mit den konstanten bzw. literalen Ausgaben von FUSITT 11012, die weiter unten beschrieben wird, verbunden. Der 32 Bit-Datenausgnag von LENGRF 20236 ist mit dem JPD-Bus 10142, dem Schreiblängeneingaben (WL)-Eingang von MC 10226 und mit dem ersten Eingang von LENALU 20252 verbunden. Der 5 Bit-Ausgang von BIAS 20246 ist mit dem zweiten Eingang von LENALU 20252, dem LENGTH-Bus 20226 und, wie oben beschrieben, mit dem vierten Eingang von OFFMUX 20240 verbunden. Der 32 Bit-Ausgang von LENALU 20252 ist, wie oben festgestellt, mit dem dritten Eingang von LENSEL 20250 verbunden.
Nachdem der Gesamtbetrieb und die Struktur von DESP 20210 beschrieben wurden, wird der Betrieb von DESP 20210 im folgenden genauer beschrieben werden.

d. Der Betrieb des Beschreiberprozessors 20210

a.a. Der Abstandswähler 20238

Indem wir uns auf OFFP 20218 beziehen, beinhaltet GRF 10354 die GRs 10360 und die SRs 10362. Die GRs 10360 wiederum beinhalten die ABRs 10364, die mCRs 10366 und einen Satz von allgemeinen Registern. Die SRs 10362 beinhalten MIS 10368 und MOS 10370. GRF 10354 ist vertikal in drei Teile unterteilt. AONGRF 20232 ist 28 Bit breit und befindet sich in AONP 20216, LENGRF 10354 ist 32 Bits breit und befindet sich in LENP 20220 und OFFGRF 20234 ist 32 Bits breit und befindet sich in OFFP 20218.
AONGRF 20232, OFFGRF 20234 und LENGRF 20236 können aus Fairchild 93422s zusammengesetzt sein.
Zusätzlich zur Speicherung von Abstandsfeldern von AON-Zeigern und logischen Beschreibern, können jene Bereiche von OFFGRF 20234, die nicht für die ABRs 10365, mCRs 10366 und SRs 10362 reserviert sind, als allgemeine Register, allein oder in Verbindung mit den entsprechenden Bereichen AONGRF 20232 und LFNGRF 20236 benutzt werden, wenn OFFP 20218 als 32 Bit-CPU für allgemeine Zwecke benutzt wird. OFFGRF 20234 wird, wie weiter unten beschrieben werden wird, mit AONGRF 20232 und LENGRF 20236 durch Adreßeingaben, die von FUCTL 20214 zur Verfügung gestellt werden, parallel adressiert.
OFFSEL 20238 ist ein Multiplexer, der z. B. aus SN74S244s und SN74S257s bestehen kann für die Selektion von Dateneingängen, die an bestimmte selektierte Adreßlokationen von OFFGRF 20234 geschrieben werden sollen. Der erste Dateneingang von OFFSEL 20238 ist vom MOD-Bus 10144 und ist der Hauptpfad für den Datentransfer zwischen MEM 10112 und DESP 20210. Wie oben beschrieben, sind alle Daten, die von MEM 10112 zu JP 10114 gelesen werden, einzelne 32 Bit-Worte, in denen von 1 bis 32 Bits aktueller Daten enthalten sein können. Wenn ein Datenausdruck, der von MEM 10112 gelesen werden soll, mehr als 32 Datenbits enthält, so werden aufeinanderfolgende Leseoperationen ausgeführt, so lange bis der gesamte Datenausdruck transferiert wurde.
Der zweite Dateneingang von OFFSEL 20238 kommt vom JPD-Bus 10142. Wie weiter unten beschrieben werden wird, ist der JPD-Bus 10142 ein Datentransferpfad, durch den Datenausgaben von FU 10120 und EU 10122 nach MEM 10112 geschrieben werden. OFFSEL 20238's Eingang von JPD-Bus 10142 stellt daher einen Wortumbruchspfad zur Verfügung, durch den Daten, die an den Ausgängen von FU 10120 oder EU 10122 anliegen, zurück nach DESP 20210 für den weiteren Gebrauch transferiert werden können. Zum Beispiel ist, wie oben festgestellt, der erste Ausgang von OFFALU 20242 mit dem JPD-Bus 10142 verbunden, und ermöglicht es damit, daß die Datenausgabe von OFFP 20218 nach OFFP 20218 für weitere Verarbeitung zurückgegeben werden kann, oder nach AONP 20216 oder LENP 20220 transferiert werden kann, wie weiter unten beschrieben wird. Darüber hinaus ist der Ausgang von LENGRF 20236 auch mit dem JPD-Bus 10142 verbunden, so daß die Längenfelder der AON-Zeiger oder der physikalischen Beschreiber, oder Daten von LENGRF 20236 nach OFFP 20218 gelesen werden können. Dieser Pfad kann z. B. benutzt werden, wenn LENGRF 20236 gerade als allgemeines Register für die Datenspeicherung order für die Speicherung von Zwischenergebnissen von arithmetischen oder logischen Operationen benutzt wird.
OFFSEL 20230's dritter Eingang wird von OFFALU 20242's Ausgang bedient. Dieser Datenpfad stellt dadurch einen Wortumbruchspfad zur Verfügung, wobei mit den Abstandsfeldern oder den Daten, die sich in OFFGRF 20234 befinden, gearbeitet werden kann, oder sie an OFFGRF 20234 zurückgegeben werden können, und zwar entweder an die gleiche Adreßlokation, von der sie ursprünglich gelesen wurden, oder zu einer anderen Adreßlokation. OFFP 20218's Wortumbruchspfad von OFFALU 20242's Ausgang nach OFFSEL 20238's drittem Eingang, und daher nach OFFGRF 20234, kann z. B. zum Lesen eines Datenausdrucks von MEM 10112, der mehr als 32 Datenbits enthält, benutzt werden. Wie oben beschrieben, besteht jede Leseoperation von MEM 10112 nach JP 10114 aus einem 32 Bit-Wort, das zwischen 1 und 32 Bits aktueller Daten enthalten kann. Der Transfer eines Datenworts, das mehr als 32 Bits enthält, wird erreicht, indem man aufeinander folgende Leseoperationen von MEM 10112 nach JP 10114 durchführt. Wenn z. B. ein angeforderter Datenausdruck 70 Datenbits enthält, so wird jener Datenausdruck in drei aufeinander folgende Leseoperationen transferiert. Die erste und zweite Leseoperation transferiert je 32 Datenbits, und die letzte Leseoperation transferiert die übrigen 6 Datenbits. Um einen Datenausdruck, der größer als 32 Bits ist, von MEM 10112 zu lesen, muß DESP 20210 daher eine Abfolge von logischen Beschreibern erzeugen, von denen jeder ein aufeinander folgendes 32 Bitsegment von jenem Datenausdruck definiert. Der letzte logische Beschreiber dieser Abfolge kann ein Segment von weniger als 32 Bits definieren, wie z. B. 6 Bits in dem eben erwähnten Beispiel. In jedem aufeinander folgenden physikalischen Beschreiber muß das Abstandsfeld um den Wert inkrementiert werden, der in dem Längenfeld des vorangegangenen physikalischen Beschreibers steht, um die Startadressen der aufeinander folgenden Datenausdruckssegmente transferieren zu können. Das Längenfeld von aufeinander folgenden physikalischen Beschreibern bleibt im allgemeinen konstant bei 32 Bits, ausgenommen beim letzten Transfer, der weniger als 32 Bits betragen kann. Das Abstandsfeld wird daher gewöhnlich um 32 Bits bei jedem Transfer inkrementiert bis zum Schlußtransfer. OFFP 20218's Wortumbruchsdatenpfad von OFFALU 20242's Ausgang zum dritten Eingang von OFFSEL 20238 kann, wie oben festgestellt, bei solchen sequentiellen Datentransferoperationen dazu benutzt werden, das inkrementierte oder dekrementierte Abstandsfeld eines gegenwärtigen physikalischen Beschreibers zurück nach OFFGRF 20234 zu schreiben, um dort das Abstandsfeld des nächsten nachfolgenden physikalischen Beschreibers zu sein.
In einem weiteren Beispiel kann OFFP 20218's Wortumbruchspfad von OFFALU 20242's Ausgang zu dem dritten Eingang von OFFSEL 20238 dazu benutzt werden, um Eingänge in Namenstabellen 10350 aufzulösen, was Namenserkennung bedeutet. Bei Namenserkennungen werden, wie oben beschrieben, die Abstandsfelder von AON-Zeigern, z. B. Verkettungszeigern 10416, sukzessive addiert und subtrahiert, um den letzten AON-Zeiger auf den gewünschten Datenausdruck zur Verfügung zu stellen.
Der vierte Eingang von OFFSEL 20238 von AONGRF 20232's Ausgang kann dazu benutzt werden, Daten oder AON-Felder von AONGRF 20232 nach OFFGRF 20234 oder OFFMUX 20240 zu transferieren. Dieser Datenpfad kann z. B. benutzt werden, wenn OFFP 20218 dazu benutzt wird, AON-Felder oder AON-Zeiger oder physikalische Beschreiber zu erzeugen, oder Namensauswertungen durchzuführen.
Schließlich erlaubt es der fünfte Dateneingang von OFFSEL 20238 vom OFFSET-Bus 20228, daß Abstandsfelder auf dem OFFSET-Bus 20228 in OFFGRF 20234 geschrieben werden, oder in OFFMUX 20240 transferiert werden können. Dieser Datenpfad kann z. B. benutzt werden, um Abstandsfelder nach OFFGRF 20234 zu kopieren, wenn JP 10114 eine Namensauswertung durchführt.
Indem wir jetzt Bezug nehmen auf OFFMUX 20240, beinhaltet OFFMUX 20240 logische Schaltkreise zur Manipulation individueller Bits von 32 Bit-Worten. OFFMUX 20240 kann beispielsweise dazu benutzt werden, Abstandsfelder um Längenfelder zu inkrementieren oder zu dekrementieren, wenn Zeichenkettentransfers durchgeführt werden, und um Eingaben für z. B. MHT 10716 und MFT 10718 zu erzeugen. OFFMUX 20240 kann auch zur Unterstützung bei der Erzeugung und Manipulation von AON-, OFFSET- und LENGTH-Feldern von physikalischen Beschreibern und AON-Zeigern benutzt werden.

b.b. Die detaillierte Struktur des Abstandsmultiplexers 20240 (Fig. 238)

In Fig. 238 wird ein detaillierterer Ausschnitt aus einem Blockdiagramm von OFFMUX 20240 gezeigt. OFFMUX 20240 beinhaltet den Abstandsmultiplexer-Eingabenselektor (OFFMFIFIS) 23810, der z. B. auf SN74S373s und SN74S244s und Abstandsmultiplexerregister (OFFMUXR) 23812, der z. B. aus SN74S374s bestehen kann, umfassen. OFF- MUX 20240 beinhaltet auch einen Feldentnahmeschaltkreis (FEXT) 23814, der z. B. aus SN74S257s, und einen Abstandsmultiplexerfeldselektor (OFFMUXFS) 23816, der z. B. aus SN74S257s und SN74S374s bestehen kann. Schließlich beinhaltet OFFMUX 20240 einen Abstandsskalierer (OFFSCALE) 23818, der z. B. aus AMD 25S10s bestehen kann, einen Abstandszwischenelements-Raumverschlüsseler (OFFIESENC) 23820, der z. B. aus Fairchild 93427s bestehen kann, und aus einem Abstandsmultiplexer-Ausgangsselektor (OFFMUXOS) 23822, der z. B. AMD 25Ss, Fairchild 93427s und SN74S244s umfassen kann.
Indem wir uns zuerst auf die Verbindungen von OFFMUX 20240 zu anderen Bereichen des OFFP 20218 beziehen, so ist OFFMUX 20240's erster Dateneingang von OFFSEL 20238 mit einem ersten Eingang von OFFMUXIS 23810 verbunden. Der zweite Eingang von OFFMUX 20240, von MOD-Bus 10144, ist mit dem zweiten Eingang von OFF- MUXIS 23810 verbunden. Der dritte Eingang von OFFMUX 20240, vom JPD-Bus 10142, ist mit dem ersten Eingang von OFFMUXFS 23816 verbunden, während OFF- MUX 20240's vierter Eingang, von BIAS 20246, mit dem ersten Eingang von OFF- MUXOS 23822 verbunden ist. OFFMUX 20240's fünfter Eingang, vom NAME-Bus 20224, ist mit dem zweiten Eingang von OFFMUXFS 23816 verbunden. Der erste Ausgang von OFFMUX 20240 nach OFFALUSA 20244 ist mit dem Ausgang von OFFMUXR 23812 verbunden, während der zweite Ausgang von OFFMUX 20240 nach OFFALU 20242 mit dem Ausgang von OFFMUXOS 23822 verbunden ist.
Indem wir uns auf die internen Schaltwege von OFFMUX 20240 beziehen, so ist der 32 Bitausgang von OFFMUXIS 23810 mit dem Eingang von OFFMUXR 23812 verbunden, und der 32 Bitausgang von OFFMUXR 23812 ist, wie oben beschrieben, als erster Ausgang von OFFMUX 20240 und als dritter Eingang von OFFMUXFS 23816 verschaltet. Der 32 Bitausgang von OFFMUXR 23812 ist auch mit dem Eingang von FEXT 23814 verbunden. Der erste, zweite und dritte Eingang von OFFMUXFS 23816 ist wie oben beschrieben verschaltet. Der vierte Eingang von OFFMUXFS 23816 ist ein 32 Biteingang, bei dem 31 Bits auf logisch Null gesetzt und 1 Bit auf logisch Eins gesetzt ist. Der fünfte Eingang ist ein 32 Biteingang, bei dem 31 Bits auf logisch 1 und 1 auf logisch Null gesetzt ist. Der sechste Eingang von OFFMUXFS 23816 ist ein 32 Bit-Literal- Eingang, der von FUSITT 11012 zur Verfügung gestellt wird und eine 32 Bit-Binärzahl darstellt, die einen Teil einer Mikrobefehls-FUCTL 20214, wie unten beschrieben, umfaßt. OFFMUXFS 23816's siebenter und achter Eingang sind mit FEXT 23814 verbunden. Der Eingang 7 umfaßt FIU- und TYPE-Felder von Namenstabelleneingängen, die in OFFMUXR 23812 gelesen wurden. Eingang 8 ist ein Eingang für allgemeine Zwecke, der Bits weiter befördert, die aus einem 32 Bit-Wort herausgenommen wurden, auf das in OFFMUXR 23812 zugegriffen wurde. Wie in Fig. 238 gezeigt, sind OFF- MUXFS 23816's erster, dritter, vierter, fünfter und sechster Eingang jeweils 32 Biteingänge, die geteilt wurden, so daß sie je zwei 16 Biteingänge zur Verfügung stellen. Das heißt, jeder dieser 32 Biteingänge ist in einen ersten Eingang aufgeteilt, der die Bits 0 bis 15 jenes 32 Biteingangs umfaßt, und einen zweiten Eingang, der die Bits 16 bis 31 umfaßt.
Der 32 Bitausgang von OFFMUXFS 23816 ist mit den Eingängen von OFFSCALE 23818 und OFFIESENC 23820 verbunden. Wie in Fig. 238 gezeigt, ist der Feldauswahlausgang (FSO) von OFFMUXFS 23816 ein 32 Bit-Wort, das in ein erstes Wort mit den Bits 0 bis 15 und ein zweites Wort mit den Bits 16 bis 31 eingeteilt ist. Der Ausgang FSO von OFFMUXFS 23816 reflektiert dadurch, wie weiter unten beschrieben wird, die aufgeteilte Struktur des ersten, dritten, vierten, fünften und sechsten Eingangs von OFFMUXFS 23816.
Die logischen Funktionen, die von OFFMUXFS 23816 bei der Erzeugung der Ausgabe FSO ausgeführt werden, und die genauer in den folgenden Beschreibungen erörtert werden, beinhalten:
(1) die Inhalte von OFFMUXR 23812 werden direkt durch OFFMUXFS 23816 durchgeschleust;
(2) ein 32 Bit-Wort wird direkt auf dem JPD-Bus 10142 durch OFFMUXFS 23816 durchgeschleust;
(3) ein Teil eines Mikrobefehls von FUCTL 20214, der aus einem literalen Wert besteht, wird direkt durch OFFMUXFS 23816 durchgeschleust;
(4) FSO wird auf die literalen Werte 0000 0000 gezwungen;
(5) FSO wird auf die literalen Werte 0000 001 gezwungen;
(6) Felder werden aus dem Namenstabelleneingang genommen;
(7) die Annahme eines 32 Bit-Wortes von OFFMUXR 23812 oder von JPD-Bus 10142 oder von 32 Bits eines Mikrobefehls von FUCTL 20214, und die Weitergabe der unteren 16 Bits, während die oberen 16 Bits auf logisch Null gesetzt werden;
(8) die Annahme eines 32 Bit-Wortes von OFFMUXR 23812 oder dem JPD-Bus 10142, oder die 32 Bits eines Mikrobefehls von FUCTL 20214, und die Weitergabe der höheren 16 Bits, während die unteren 16 Bits auf logisch Null gezwungen werden;
(9) die Annahme eines 32 Bit-Wortes von OFFMUXR 23812 oder von JPD-Bus 10142 oder dem Namensbus 20224, oder den 32 Bits eines Mikrobefehls von FUCTL 20214, und die Weitergabe der unteren 16 Bits, während das Vorzeichenbit 16 auf die oberen 16 Bits ausgedehnt wird; und
(10) die Annahme eines 32 Bit-Wortes vom Namensbus 20224, und die Weitergabe der untersten 8 Bits, während das Vorzeichenbit 24 auf die höchsten 24 Bits ausgeweitet wird.
Der 32 Bitausgang von OFFSCALE 23818 und der 3 Bitausgang von OFFIESENC 23820 sind mit dem zweiten respektive dritten Eingang von OFFMUXOS 23822 verbunden. OFFMUXOS 23822's erster Eingang ist, wie oben beschrieben, OFFMUX 20240's vierter Eingang und ist mit dem Ausgang BIAS 20246 verbunden. Schließlich ist OFFMUXOS 23822's 32 Bitausgang, OFFMUX (0-31) der zweite Ausgang von OFFMUX 20240 und ist, wie oben beschrieben, mit dem zweiten Eingang von OFFALU 20242 verbunden.

c.c. Detaillierter Betrieb vom Abstandsmultiplexer 20240

a.a.a. Interner Betrieb

Nachdem die Struktur von OFFMUX 20240, wie in Fig. 238 gezeigt, beschrieben wurde, wird unten der Betrieb von OFFMUX 20240 beschrieben. Zunächst wird der interne Betrieb von OFFMUX 20240 beschrieben, wie es in Fig. 238 gezeigt ist, danach dann der Betrieb von OFFMUX 20240 hinsichtlich DESP 20210.
Indem wir zuerst zu OFFMUXR 23812 Bezug nehmen, so ist OFFMUXR 23812 ein 32 Bitregister, das entweder ein 32 Bit-Wort vom MOD-Bus 10144, MOD (0-31) empfängt, oder ein 32 Bit-Wort, das von OFFSEL 20238, OFFSEL (0-31) empfangen wurde, und wird von OFFMUXIS 23810 ausgewählt. OFFMUXR 23812 stellt wiederum jene 32 Bit- Worte vom MOD-Bus 10144 oder OFFSEL 20238 als ersten Datenausgang von OFFMUX 20240 OFFALUSA 20244 zur Verfügung, und zwar als FEXT 23814's erster Eingang und als OFFMUXFS 23816's dritter Eingang. Der 32 Bitausgang von OFFMUXR 23812 nach OFFMUXFS 23816 wird zur Verfügung gestellt als zwei parallele 16 Bit-Worte, die für OFFMUXR's Ausgang (OFFMUXRO) (0-15) und (16-31) bestimmt sind. Wie oben beschrieben, kann die Ausgabe von OFFMUXFS 23816 nach OFFALUSA 20244 von OFFMUXR 23812 um 16 Plätze nach rechts verschoben werden und die 16 höchsten Bits können mit Nullen gefüllt werden.
FEXT 23814 empfängt OFFMUXRO (0-15) und (16-31) von OFFMUXR 23812 und nimmt bestimmte Felder von jenen 16 Bit-Worten heraus. Insbesondere entnimmt FEXT 23814 die FIU- und TYPE-Felder von NT 10350-Eingängen, die in OFFMUXR 23812 transferiert worden sind. FEXT 23814 kann dann jene FIU- und TYPE-Felder als siebten Eingang für OFFMUXFS 23816 zur Verfügung stellen. FEXT 23814 kann selektiv bestimmte andere Felder von 32 Bit-Worten, die sich in OFFMUXR 23812 befinden, herausnehmen und jene Felder als OFFMUXFS 23816's achter Eingang zur Verfügung stellen.
OFFMUXFS 23816 arbeitet als ein Multiplexer, um bestimmte Felder von den acht Eingängen von OFFMUXFS 23816 zu selektieren und entsprechende 32 Bitausgangsworte, Feldauswahlausgaben (FSO) zur Verfügung zu stellen, die jene ausgewählten Felder von OFFMUXFS 23816's Eingängen umfassen. Wie oben beschrieben, besteht FSO aus zwei parallelen 16 Bit-Worten, FSO (0-15) und FSO (16-31). Entsprechend ist OFFMUX 20240's dritter Eingang vom JPD-Bus 10142 ein 32 Biteingang, der sich als zwei 16 Bit-Worte präsentiert, JPD (0-15) und JPD (16-31). In ähnlicher Weise werden OFFMUXFS 23816's vierter, fünfter und sechster Eingang als 32 Bit-Worte präsentiert, die aus zwei parallelen 16 Bit-Worten bestehen, "0" (0-15) und (16-31), "1" (0-15) und (16-31), und L (0-15) und (16-31). OFFMUXFS 23816's zweiter Eingang vom NAME- Bus 20224 wird als einzelnes 16 Bit-Wort präsentiert, NAME (16-31), während OFF- MUXFS 23816's Eingänge von FEXT 23814 jeweils weniger als 16 Bit breit sind. OFFMUXFS 23816 kann für ein einzelnes 32 Bit-Ausgabewort FSO (0-15) so selektieren, daß es einen der entsprechenden 16 Biteingaben WD (0-15), "0" (0-15), "1" (0-15) oder L (0-15) enthält. In ähnlicher Weise kann FSO (16-31) jenes 32 Bitausgangsworts so ausgewählt werden, daß es eins von NAME (16-31), JPD (16-31), 0 (16-31), 1 (16-31), L (16-31) oder die Eingänge 7 und 8 von FEXT 23814 enthält. OFFMUXFS 23816 erlaubt es daher, daß 33 Bit-Worte, die zwei 16 Bitfelder umfassen, aus ausgewählten Bereichen der Eingaben von OFFMUXFS 23816 erzeugt werden können.
Der 32 Bitausgang von OFFMUXFS 23816 wird als Eingänge für OFFSCALE 23818 und OFFIESENC 23820 zur Verfügung gestellt. Indem wir uns zuerst auf OFFIESENC 23820 beziehen, so wird OFFIESENC 23820 insbesondere dafür benutzt, NT 10350-Eingänge (NTEs), die sich auf Vektoren von Datenworten beziehen, aufzulösen oder auszuwerten. Wie in Fig. 108 gezeigt, enthält Wort D eines NTE bestimmte Informationen, die sich auf den Zwischenelementabstand (IES) von Datenworten eines Vektors beziehen. Wort D eines NTE kann von MEM 10112 zum MOD-Bus 10144 und durch OFFMUX 20240 zum Eingang von OFFIESENC 23820 gelesen werden. OFFIESENC 23820 untersucht dann das IES-Feld von Wort D, um zu bestimmen, ob der Zwischenelementabstand dieses Vektors ein binäres Vielfaches, d. h. 1, 2, 4, 8,16, 32 oder 64 Bits ist. Insbesondere bestimmt OFFIESENC 23820, ob das 32 Bit-Wort D logische Nullen in den signifikantesten 25 Bits und eine einzelne logische Eins in den am wenigsten signifikanten 7 Bits enthält. Falls der Zwischenelementabstand ein solches binäres Vielfaches ist, können die Startadressen von Datenworten jenes Arrays bestimmt werden durch Linksverschiebung des Index (IES), um die Abstandsfelder der physikalischen Adressen von Worten in dem Vektor zu erhalten, und eine langsamere und kompliziertere Multiplikationsoperation wird nicht erforderlich. In solchen Fällen erzeugt OFFIESENC eine erste Ausgabe an FUCTL 20214, die IES-kodierbar (IESENC) ist, um anzuzeigen, daß jene Zwischenelementabstände durch einfaches Linksverschieben bestimmt werden können. OFFIESENC 23820 erzeugt dann eine verschlüsselte Ausgabe, verschlüsselte IES (ENCIES), für OFFMUXOS 23822. ENCIES ist dann ein verschlüsselter Wert, der den Betrag der Linksverschiebung spezifiziert, die notwendig ist, um den Indexwert (IES) in Wortabstände in jenem Vektor zu übersetzen. Wie in Fig. 238 gezeigt, ist ENCIES der dritte Eingang von OFFMUXOS 23822.
OFFSCALE 23818 ist ein Linksverschiebungsnetzwerk mit Auffüllen von Nullen in den am wenigsten signifikanten Bits, wenn Bits links verschoben werden. Der Betrag der Verschiebung durch OFFSCALE 23818 ist wählbar zwischen Null und 7 Bits. Die 32 Bit- Worte, die von OFFSCALE 23818 von OFFMUXFS 23816 nach OFFSCALE 23818 transferiert worden sind, können daher bitweise links verschoben werden, um Bits selektiv innerhalb jenes 32 Biteingangswortes neu zu positionieren. In Verbindung mit OFF- MUXFS 23816 und einer Wortumbruchsverschaltung, die durch OFFALU 20240's Ausgang nach OFFSEL 20238 zur Verfügung gestellt wird, kann OFFSCALE 23818 dafür benutzt werden, z. B. Eingänge für MHT 10716, MFT 10718, AOT 10712 und AST 10914 und anderen CS 10110-Datenstrukturen zu erzeugen und zu manipulieren.
OFFMUXOS 23822 ist ein Multiplexer, der seine ersten, zweiten und dritten Eingänge von BIAS 20246 respektive OFFSCALE 23818 und OFFIESENC 23820 hat. OFFMUXOS 23822 kann irgendeinen dieser Eingänge als zweiten Ausgang (OFEMUX) (0-31) von OFFMUX 20240 auswählen. Wie oben beschrieben, ist der zweite Ausgang von OFFMUX 20240 mit dem zweiten Eingang von OFFALU 20242 verbunden.
Nachdem der interne Betrieb von OFFMUX 20240 beschrieben wurde, wird im folgenden der Betrieb von OFFMUX 20240 hinsichtlich des Gesamtbetriebes von DESP 20210 beschrieben.

b.b.b. Betrieb hinsichtlich des Beschreiberprozessors 20210

Der erste Eingang von OFFMUX 20240 von OFFSEL 20238 erlaubt, daß Eingaben nach OFFSEL durch OFFMUXIS 23810 und in OFFMUXR 23812 transferiert werden können. Dieser Eingang erlaubt es OFFMUXR 23812 unter der Kontrolle von FUCTL 20214- Mikrobefehlen, mit irgendwelchen Eingaben von OFFSEL 20238 geladen zu werden. In einem bestimmten Beispiel kann die Ausgabe von OFFALU 20242 durch OFFSEL 20238's drittem Eingang und OFFMUX 20240's erstem Eingang zurückgeführt werden, und erlaubt es so OFFMUX 20240 und OFFALU 20242, sich wiederholende Operationen auf einem einzelnen 32 Bit-Wort durchzuführen.
OFFMUX 20240's zweiter Eingang vom MOD-Bus 10144 erlaubt es OFFMUXR 23812, direkt vom MOD-Bus 10144 geladen zu werden. Zum Beispiel können NTEs von einer gegenwärtig aktiven Prozedur in OFFMUXR 23812 geladen werden, um, wie oben beschrieben, verarbeitet zu werden. Darüber hinaus kann OFFMUX 20240's zweiter Eingang in Verbindung mit dem ersten Eingang von OFFSEL 20238 von MOD-Bus 10144 als parallele Eingangspfade nach OFFP 20218 benutzt werden. Diese parallelen Eingangspfade erlauben ein Pipelining von OFFP 20218-Operationen und ermöglichen es OFFSEL 20238 und OFFGRF 20234, unabhängig von OFFMUX 20240 zu operieren. Zum Beispiel kann FU 10120 eine Leseoperation von MEM 10112 nach OFFMUXR 23812 während eines ersten Mikrobefehls initiieren. Die so angeforderten Daten erscheinen auf dem MOD-Bus 10144 während eines zweiten Mikrobefehls und können über OFFMUX 20240's zweiten Eingang vom MOD-Bus 10144 in OFFMUXR 23812 geladen werden. Gleichzeitig kann FU 10120 beim Start eines zweiten Mikrobefehls veranlassen, daß eine unabhängige Operation von OFFSEL 20238 und OFFGRF 20234 ausgeführt werden soll, z. B. die Ausgabe von OFFALU 20242 in OFFGRF 20234 zu laden. Durch die Zurverfügungstellung eines unabhängigen Pfades in OFFMUX vom MOD-Bus 10144 ist OFFSEL 20238 frei, andere gleichzeitige Datentransferoperationen durchzuführen, während ein Datentransfer vom MOD-Bus 10144 nach OFFMUX 20240 gerade ausgeführt wird.
OFFMUX 20240's dritter Eingang vom JPD-Bus 10142 ist ein Datentransferpfad für allgemeine Zwecke. Zum Beispiel können Daten von LENGRF 20236 oder OFFALU 20242 nach OFFMUX 20240 durch den JPD-Bus 10142 und OFFMUX 20240's dritten Eingang transferiert werden.
OFFMUX 20240's vierter Eingang ist mit BIAS 20246 verbunden und wird hauptsächlich während Zeichenkettentransfers, wie oben beschrieben, benutzt. Das heißt, Längenfelder von physikalischen Beschreibern, die für Zeichenkettentransfers erzeugt worden sind, können durch OFFMUX 20240's vierten Eingang nach OFFMUX 20240 transferiert werden, um die Abstandsfelder von jenen physikalischen Beschreibern in OFFALU 20242 zu inkrementieren oder zu dekrementieren.
OFFMUX 20240's fünfter Eingang ist mit dem NAME-Bus 20224 verbunden. Wie unten beschrieben wird, werden Namen durch FUCTL 20214 NC 10226 zur Verfügung gestellt, um von MC 10226 logische Beschreiber aufzurufen, die Namen entsprechen, die als Teil von SINs-Abfolgen auf dem MOD-Bus 10144 erscheinen. Sobald ein Name NC 10226 präsentiert wird, wird jener Name in die Namensfalle (NT) 20254 transferiert und dort festgehalten. Wenn ein NC 10226-Fehler auftritt, d. h. NC 10226 enthält keinen Eingang, der einem bestimmten Namen entspricht, so wird dieser Name nachfolgend von NT 20254 nach OFFMUX 20240 über den NAME-Bus 20224 und OFFMUX 20240's fünften Eingang transferiert. Jener Name, der oben als 8, 12 oder 16 Bitbinärzahl beschrieben wurde, kann dann skaliert, d. h. multipliziert mit einer NTE-Größe, werden. Dieser skalierte Name kann dann zum Namentabellenzeiger (NTP) von MCRS 10366 dazu addiert werden, um die Adresse eines entsprechenden NTE in einer NT 10350 zu erhalten. Darüber hinaus kann ein Name, der sich aus einem NC 10226-Fehler oder einem Seitenfehler in dem entsprechenden NT 10350 ergibt oder der eine Folge von Namensauflösungen erfordert, in OFFGRF 20234 von OFFMUX 20240 über OFFALU 20242 und OFFSEL 20238's drittem Eingang transferiert werden. Dieser Name kann nachfolgend von OFFGRF 20234 gelesen oder wieder gespeichert werden, wie es erforderlich ist.
Indem wir uns jetzt auf die Ausgänge von OFFMUX 20240 beziehen, so erlaubt der erste Ausgang von OFFMUX 20240 von OFFMUXR 23812, daß die-Inhalte von OFFMUXR 23812 durch OFFALUSA 20244 zum ersten Eingang von OFFALU 20242 transferiert werden. Der zweite Ausgang von OFFMUX 20240 von OFFMUXOS 23822 wird direkt dem zweiten Eingang von OFFALU 20242 zur Verfügung gestellt. OFFALU 20242 kann gleichzeitig mit einer ersten Eingabe von OFFMUXR 23812 und einer zweiten Eingabe, z. B. ein manipuliertes Abstandsfeld von OFFMUXOS 23822, bedient werden.
Auf OFFALUSA 20244 Bezug nehmend, ist OFFALUSA 20244 ein Multiplexer. OFFALUSA 20244 kann den Ausgang von OFFGRF 20234 oder den ersten Ausgang von OFFMUX 20240 auswählen, entweder der erste Eingang von OFFALU 20242 zu sein, oder der Ausgang von OFFP 20218 zum OFFSET-Bus 20228 zu sein. Zum Beispiel kann ein Abstandsfeld von OFFGRF 20234 zum OFFSET-Bus 20228 gelesen werden, um das Abstandsfeld eines gegenwärtigen logischen Beschreibers zu sein, und kann gleichzeitig in OFFALU 20242 gelesen werden, um inkrementiert oder dekrementiert zu werden, um das Abstandsfeld eines nachfolgenden logischen Beschreibers in einem Zeichenkettentransfer zu erzeugen.
OFFALU 20242 ist eine 32 Bit arithmetische und logische Einheit für die allgemeine Verwendung, imstande, alle gewöhnlichen ALU-Operationen durchzuführen. Zum Beispiel kann OFFALU 20242 Abstandsfelder von logischen Beschreibern addieren, subtrahieren, inkrementieren oder dekrementieren. Darüber hinaus kann OFFALU 20242 als Transferpfad für Daten dienen, d. h. OFFALU 20242 kann Eingabedaten zu den Ausgängen von OFFALU 20242 transferieren, ohne mit diesen Daten zu arbeiten. OFFALU 20242's erster Ausgang ist, wie oben beschrieben, mit dem JPD-Bus 10142, mit dem dritten Eingang von OFFSEL 20238 und mit dem ersten Eingang von AONSEL 20248 verbunden. Daten, die durch OFFALU 20242 transferiert oder manipuliert wurden, können daher auf den JPD-Bus 10142 transferiert oder durch OFFSEL 20238 in OFFP 20218 hinein umgebrochen werden für nachfolgende, sich wiederholende Operationen. OFFALU 20242's Ausgaben nach AONSEL 20248 können z. B. dazu benutzt werden, AON-Felder von AON-Zeigern oder physikalischen Beschreibern, die von OFFP 20218 erzeugt wurden, nach AONGRF 20232 zu laden. Darüber hinaus erlaubt dieser Datenpfad FU 10120, AONGRF 20232 z. B. als Puffer oder temporärer Speicherplatz für Zwischen- oder Endergebnisse von FU 10120-Operationen zu benutzen.
OFFALU 20242's Ausgang zum OFFSET-Bus 20228 erlaubt es den Abstandsfeldern von logischen Beschreibern, direkt von OFFALU 20242 auf den OFFSET-Bus 20228 transferiert zu werden. Zum Beispiel kann ein Abstandsfeld eines logischen Beschreibers von OFFALU 20242 während eines ersten Systemtaktes erzeugt werden und sofort während eines zweiten Systemtaktes auf den OFFSET-Bus 20228 transferiert werden.
OFFALU 20242's dritter Ausgang geht zum NAME-Bus 20224. Wie weiter unten beschrieben wird, ist der NAME-Bus 20224 der Adreßeingang (ADR) nach NC 10226. OFFALU 20242's Ausgang zum NAME-Bus 20224 erlaubt es daher OFFP 20218, Adressen, d. h. Namen, zu erzeugen oder NC 10226 zur Verfügung zu stellen.
Nachdem der Betrieb von OFFP 20218 beschrieben wurde, wird im folgenden der Betrieb von LENP 20220 beschrieben.

e. Längenprozessor 20220 (Fig. 239)

Mit Bezug auf Fig. 202 ist eine Hauptfunktion des LENP 20220 die Erzeugung und Manipulation von Längenfeldern von logischen Beschreibern, die Längenfelder von logischen Beschreibern enthalten, die bei Zeichenkettentransfers erzeugt worden sind. LENP 20220 beinhaltet LENGRF 20236, LENSEL 20250, BIAS 20246 und LENALU 20252. LENGRF 20236 kann z. B. aus Fairchild 93422s bestehen. LENSEL 20250 kann z. B. aus SN74S257s, SN74S157s und SN74S244s, und LENALU 20252 kann z. B. aus SN74S381s bestehen.
Wie oben beschrieben, ist LENGRF 20236 ein 32 Bit breiter vertikaler Ausschnitt von GRF 10354. LENGRF 20236 arbeitet parallel mit OFFGRF 20234 und AONGRF 20232 und enthält teilweise Längenfelder von logischen Beschreibern. Darüber hinaus kann LENGRF 20236, wie auch oben beschrieben wurde, Daten enthalten.
LENSEL 20250 ist ein Multiplexer, der drei Eingänge hat und Ausgänge nach LENGRF 20236 und den ersten Eingang von BIAS 20246 zur Verfügung stellt. LENSEL 20250's erster Eingang kommt vom Längenbus 20226 und kann dazu benutzt werden, physikalische Beschreiber oder Längenfelder vom LENGTH-Bus 20226 in LENGRF 20236 oder in BIAS 20246 zu schreiben. Solche Längenfelder können vom LENGTH-Bus 20226 nach LENGRF 20236 geschrieben werden, z. B. während Operationen von Namensauswertungen oder Namenserkennungen. LENSEL 20250's zweiter Eingang kommt vom OFFSET- Bus 20228. LENSEL 20250's zweiter Eingang kann z. B. dazu benutzt werden, Längenfelder, die von OFFP 20218 generiert wurden, nach LENGRF 20236 zu laden. Darüber hinaus können Daten, mit denen OFFP 20218 gearbeitet hat, nach LENGRF 20236 zur Speicherung durch LENSEL 20250's zweiten Eingang gelesen werden.
LENSEL 20250's dritter Eingang kommt vom Ausgang von LENALU 20252 und ist ein Wortumbruchspfad, um die Ausgabe von LENALU 20252 nach LENGRF 20256 zurückzugeben. LENSEL 20250's dritter Eingang kann z. B. während Zeichenkettentransfers benutzt werden, wenn Längenfelder eines bestimmten logischen Beschreibers von LENALU 20252 inkrementiert oder dekrementiert werden und nach LENGRF 20236 zurückgegeben werden. Dieser Datenpfad kann auch z. B. dazu benutzt werden, ein 32 Bit- Wort von einer Lokation in LENGRF 20236 zu einer anderen Lokation in LENGRF 20236 zu verschieben. Wie oben bemerkt, wird LENSEL 20250's Ausgang auch dem ersten Eingang von BIAS zur Verfügung gestellt und erlaubt es, Daten, die am ersten, zweiten oder dritten Eingang von LENSEL 20250 auftauchen, dem ersten Eingang von BIAS 20246 zur Verfügung gestellt zu werden.
BIAS 20246 erzeugt, wie unten genauer beschrieben wird, Längenfelder von logischen Beschreibern während Zeichenkettentransfers. Wie oben beschrieben, können nicht mehr als 32 Datenbits von MEM 10112 während einer einzelnen Leseoperation gelesen werden. Ein Datenausdruck, der länger ist als 32 Bits, muß daher in einer Reihe oder einer Kette von Leseoperationen transferiert werden, wobei jede Leseoperation 32 oder weniger Datenbits transferiert. Die Längenfelder von logischen Beschreibern von Zeichenkettentransfers, die von BIAS 20246 erzeugt wurden, werden dem LENGTH-Bus 20226, LENALU 20252's zweitem Eingang und OFFMUX 20240's viertem Eingang, wie oben beschrieben, zur Verfügung gestellt. Diese Längenfelder von logischen Beschreibern von Zeichenkettentransfers, die wir als BIAS-Felder bezeichnen, werden durch BIAS 20246 dem LENGTH-Bus 20226 zur Verfügung gestellt, um Längenfelder von einer Reihe von logischen Beschreibern zu sein, die von DESP 20210 erzeugt wurden, um einen Zeichenkettentransfer auszuführen. Diese BIAS-Felder werden dem vierten Eingang von OFFMUX 20240 zur Verfügung gestellt, um die Abstandsfelder jener logischen Beschreiber zu inkrementieren oder zu dekrementieren, wie es oben beschrieben wurde. Diese BIAS-Felder werden dem zweiten Eingang von LENALU 20252 während Zeichenkettentransfers zur Verfügung gestellt, um in entsprechender Weise die Längenfelder eines Datenausdrucks, der in einem Zeichenkettentransfer nach MEM 10112 gelesen wird, zu dekrementieren. BIAS 20246 wird unten genauer beschrieben werden, nachdem zuerst LENALU 20252 kurz beschrieben wird.

a.a. Längen-ALU 20252

LENALU 20252 ist eine 32 Bit arithmetische und logische Einheit zur allgemeinen Verwendung, die imstande ist, alle gebräuchlichen arithmetischen und logischen Operationen durchzuführen. Insbesondere während eines Zeichenkettentransfers eines bestimmten Datenausdrucks empfängt LENALU 20252 die Längenfelder jenes Datenausdrucks von LENGRF 20236 und die sukzessiven BIAS-Felder von BIAS 20246. LENALU 20252 dekrementiert dann das gegenwärtige Längenfeld jenes logischen Beschreibers, um das Längenfeld zu erzeugen, das während der nächsten Leseoperation des Zeichenkettentransfers benutzt wird, und transferiert das neue Längenfeld zurück nach LENGRF 20236 über den dritten Eingang von LENSEL 20250.

b.b. BIAS 20246 (Fig. 239)

In Fig. 239 wird ein Ausschnitt aus einem Blockdiagramm von BIAS 20246 gezeigt. BIAS 20246 beinhaltet den BIAS-Speicher (BIASM) 23910, den Längendetektor (LDET) 23912, den nächsten Nullendetektor (NXTZRO) 23914 und den Auswahl-BIAS (SBIAS) 23916. Der Eingang von LDET 23912 ist der erste Eingang von BIAS 20246 und ist mit dem Ausgang von LENSEL 20250 verbunden. Der Ausgang von LDET 23912 ist mit dem Dateneingang von BIASM 23910 verbunden, und der Datenausgang von BIASM 23910 ist mit dem Eingang von NXTZRO 23914 verbunden. Der Ausgang von NXTZRO 23914 ist mit dem ersten Eingang von SBIAS 23916 verbunden. Der zweite Eingang von SBIAS 23916 ist der zweite Eingang von BIAS 20246, L8, und ist mit einem Ausgang von FUCTL 20214 verbunden. Der dritte Eingang von SBIAS 23916 ist der dritte Eingang von BIAS 20246, L, und ist mit noch einem anderen Ausgang von FCTL 20214 verbunden. Der Ausgang von SBIAS 23916 ist der Ausgang von BIAS 20246, und, wie oben beschrieben, ist mit dem LENGTH-Bus 20226, mit einem zweiten Eingang von LENALU 20252 und mit denk vierten Eingang von OFFMUX 20240 verbunden.
BIASM 23910 ist ein 7 Bit breiter Speicher freien Zugriffs, der gleichlang wie die SRs 10362 von GRF 10354 ist und gleich arbeitet und parallel dazu adressiert wird. BIASM 23910 hat Adreßlokationen, die der jeweiligen Adreßlokation der SRs 10362 entsprechen, und wird gleichzeitig mit jenen Adreßlokationen in den SRs 10362 adressiert. BIASM 23910 kann z. B. aus AMD 27S03As bestehen.
BIASM 23910 enthält einen BIAS-Wert von jedem logischen Beschreiber, der sich in den SRs 10362 befindet. Wie oben beschrieben, ist ein BIAS-Wert eine Zahl, die die Anzahl von Bits repräsentiert, die bei einer bestimmten Leseoperation von MEM 10112 gelesen werden soll, wenn ein Datenausdruck, der einen entsprechenden logischen Beschreiber hat, und mit einem Längenfeld in LENGRF 20236 gespeichert ist, von MEM 10112 gelesen werden soll. Anfangs werden die BIAS-Werte in BIASM 23910 geschrieben, in einer unten beschriebenen Weise, wenn ihre entsprechenden Längenfelder nach LENGRF 20236 geschrieben werden. Wenn ein bestimmter Datenausdruck kürzer ist als 32 Bits, so bedeutet der anfängliche BIAS-Wert von jenem Datenausdruck die aktuelle Länge jenes Datenausdrucks. Wenn z. B. ein Datenausdruck eine Länge von 24 Bits hat, so ist der zugehörige BIAS-Wert eine 6 Bit-Binärzahl, die 24 darstellt. Das Längenfeld jenes Datenausdrucks in LENGRF 20236 wird in ähnlicher Weise einen Längenwert von 24 beinhalten. Wenn ein bestimmter Ausdruck eine größere Länge als 32 Bits besitzt, wie z. B. 70 Bits, wie im vorherigen Beispiel beschrieben, so muß dieser Datenausdruck von MEM 10112 in einer Zeichenkettentransferoperation gelesen werden. Wie oben beschrieben, ist ein Zeichenkettentransfer eine Reihe von Leseoperationen, die 32 Bits auf einmal von MEM 10112 transferieren, mit einem letzten Transfer von 32 Bits oder weniger, der den Transfer jenes Datenausdrucks beendet. Die anfängliche Längenfeldeingabe solch eines Datenausdrucks in LENGRF 20236 beinhaltet, wenn man dasselbe Beispiel wie eben zugrunde legt, einen Wert von 70. Die anfängliche BIAS-Eingabe jenes Datenausdrucks, die in einen entsprechenden Adreßraum von BIASM 23910 geschrieben wurde, enthält einen BIAS-Wert von 32. Jener anfängliche BIAS-Wert von 32 zeigt an, daß mindestens die erste Leseoperation, die für den Transfer jenes Datenausdrucks von MEM 10112 nötig ist, 32 Datenbits transferiert.
Wenn ein Datenausdruck, der eine Länge von weniger als 32 Bits umfaßt, z. B. 24 Bits, von MEM 10112 gelesen werden soll, so wird der BIAS-Wert von 24 jenes Datenausdrucks von BIASM 23910 gelesen und dem LENGTH-Bus 20226 für jene Leseoperation als Längenfeld des logischen Beschreibers zur Verfügung gestellt. Gleichzeitig wird jener BIAS-Wert von 24 vom Längenfeld jenes Datenausdrucks abgezogen, das von LENGRF 20236 gelesen wurde. Das Subtrahieren jenes BIAS-Wertes vom Längenwert ergibt ein Ergebnis von Null, was anzeigt, daß keine weitere Leseoperation notwendig ist, um den Transfer des Datenausdrucks zu beenden.
Wenn ein Datenausdruck z. B. eine Länge von 70 Bits besitzt, und von MEM 10112 gelesen werden soll, so wird der anfängliche BIAS-Wert von 32 jenes Datenausdrucks von BIASM 23910 nach LENGTH-Bus 20226 als Längenfeld des ersten logischen Beschreibers eines Zeichenkettentransfers gelesen. Gleichzeitig wird das anfängliche Längenfeld jenes Datenausdrucks von LENGRF 20236 gelesen. Der anfängliche BIAS-Wert jenes Datenausdrucks, 32, wird vom anfänglichen Längenwert, 70, und LENALU 20252 abgezogen. Das Ergebnis jener Subtraktionsoperation ist die verbleibende Länge des Datenausdrucks, der in einer oder mehreren Leseoperationen transferiert werden muß. In diesem Beispiel zeigt das Subtrahieren des anfänglichen BIAS-Wertes vom anfänglichen Längenwert an, daß 38 Bits jenes Datenausdrucks noch transferiert werden müssen. Die Ausgabe von LENALU 20252, die das Ergebnis jener Subtraktion repräsentiert, z. B. 38, wird zum dritten Eingang von LENSEL 20250 zu LENGRF 20236 transferiert, und in einer Adreßlokation geschrieben, von der der anfängliche Längenwert jenes Datenausdrucks gelesen wurde. Diese neue Eingabe in das Längenfeld repräsentiert dann die verbleibende Länge des Datenausdrucks. Gleichzeitig untersucht LDET 23912 jenen verbleibenden Längenwert, der in LENGRF 20236 geschrieben wird, um zu bestimmen, ob die verbleibende Länge jenes Datenausdrucks größer oder kleiner oder gleich 32 Bits ist. Falls die verbleibende Länge größer als 32 Bits ist, erzeugt LDET 23912 einen nächsten BIAS-Wert von 32, der in BIASM 23910 geschrieben wird, und zwar an derselben Adreßlokation, die der anfängliche BIAS-Wert inne hatte. Falls die verbleibende Länge des Datenausdrucks kleiner ist als 32 Bits, erzeugt LDET 23912 eine 6 Bit- Binärzahl, die die aktuell verbleibende Länge jenes Datenausdrucks, der transferiert wird, repräsentiert. Die aktuell verbleibende Länge würde dann wieder an die Adressenlokation in BIASM 23910 geschrieben werden, die den anfänglichen BIAS-Wert enthält. Diese Operationen werden auch von LDET 23912 durchgeführt, wenn das anfängliche Längenfeld untersucht wird, und der entsprechende anfängliche BIAS-Wert erzeugt wird. Diese Leseoperationen werden, wie oben beschrieben, so lange durchgeführt, bis LDET 23912 entdeckt, daß das verbleibende Längenfeld 32 Bits oder weniger ist, und so entdeckt, daß jener Transfer jenes Datenausdrucks mit der nächsten Leseoperation abgeschlossen ist. Wenn dieses Ereignis entdeckt wird, erzeugt LDET 23912 eine 7 Biteingabe nach BIASM 23910, die zusammen mit dem letzten BIAS-Wert jenes Zeichenkettentransfers in BIASM 23910 geschrieben wird, und anzeigt, daß die verbleibende Länge nach der nächsten Leseoperation gleich Null sein wird. Wenn ein Schluß-BIAS-Wert von BIASM 23910 gelesen wird, so wird jenes siebente Bit beim Beginn der nächsten Leseoperation jenes Zeichenkettentransfers von NXTZRO 23914 untersucht, der nachfolgend eine Testbedingungsausgabe erzeugt, und zwar letztes Lesen (LSTRD) für FUCTL 20214. FUCTL 20214 kann dann die Ausführung jenes Zeichenkettentransfers nach jener letzten Leseoperation beenden, wenn der Transfer erfolgreich abgeschlossen wurde.
Wie oben beschrieben, so beträgt die Basislängeneinheit eines Datenausdrucks in CS 10110 32 Bits. Entsprechend können Datenausdrücke von 32 oder weniger Bits direkt transferiert werden, während Datenausdrücke von mehr als 32 Bits einen Zeichenkettentransfer erforderlich machen. Darüber hinaus erfordert der Transfer von Datenausdrücken durch einen Zeichenkettentransfer die Aufzeichnung der transferierten Länge und die der verbleibenden Länge, die transferiert werden muß, und zwar der Länge des Datenausdrucks selbst und des Datenspeicherplatzes der Lokation, wohin der Datenausdruck transferiert werden soll. Also speichert und arbeitet BIAS 20246 in der oben beschriebenen Weise die Längen- und BIAS-Felder der logischen Beschreiber sowohl des Datenausdrucks als auch der Lokation, zu der der Datenausdruck transferiert wird. FUCTL 20214 empfängt eine LSTRD-Testbedingung, wenn das BIAS-Feld des Quellenbeschreibers bevor oder gleichzeitig mit dem des Zielbeschreibers Null wird, d. h. daß der Transfer beendet ist, oder wenn das BIAS-Feld des Zieles vor dem der Quelle Null wird, und kann eine geeignete Mikrocodesteuerungsantwort zur Verfügung stellen. Es sei angemerkt, daß, falls das Quellen-BIAS-Feld vor dem Ziel-BIAS-Feld Null wird, der Rest der Lokation, zu der dieser Datenausdruck transferiert wird, mit Nullen gefüllt wird. Falls der Datenausdruck größer ist als die Speicherkapazität des Zieles, so wird die Ziellokation bis zur Kapazitätsgrenze gefüllt und FUCTL 20214 signalisiert, geeignete Aktionen zu initiieren.
Darüber hinaus, daß Datenausdruckstransfers ermöglicht werden, die unempfindlich gegenüber der Datenausdruckslänge sind, erlaubt es BIAS 20246, die Zeichenkettentransfers durch kurze knappe Mikrocodeschleifen durchzuführen, die unempfindlich gegenüber der Datenausdruckslänge sind. Ein Zeichenkettentransfer z. B. von Lokation A nach Lokation B wird folgendermaßen verschlüsselt:
(1) Hole von A, subtrahiere die Länge von BIAS A und aktualisiere Anstand und Länge von A;
(2) Speichere nach B, subtrahiere die Länge vom BIAS B und verzweige nach 1, wenn die Länge von B nicht Null wird, oder gehe bis zum Ende (Ende des Transfers), falls die Länge von B Null wird. Die Länge der Quelle (A) braucht nicht registriert zu werden, weil die Mikrocodeschleife so lange läuft, bis die Länge von B Null wird; wie oben beschrieben, wird B mit Nullen aufgefüllt, falls die Länge von A kleiner ist als die Länge von B oder B wird aufgefüllt und der Zeichenkettentransfer beendet, falls die Länge von A größer oder gleich der Länge von B ist.
LDET 23912 und NXTZRO 23914 ermöglichen es dadurch FUCTL 20214, automatisch einen Zeichenkettentransfer zu initiieren, wenn ein einziger Mikrobefehl von FUCTL 20214 auftritt, der eine Leseoperation durch DESP 20210 initiiert. Jener Mikrobefehl, der die Leseoperation initiiert, wird dann automatisch wiederholt, bis LSTRD FUCTL 20214 von NXTZRO 23914 anzeigt, daß der Zeichenkettentransfer vollendet ist. LDET 23912 und NXTZRO 23914 können z. B. aus S74S260s respektive SN74S133s, SN74S51s, SN74S00s, SN74S00s, SN74S04s, SN74S02s und SN74S32s bestehen.
Indem wir schließlich auf SBIAS 23916 Bezug nehmen, so ist SBIAS 23916 ein Multiplexer, der z. B. SN74S288s, SN74S374s und SN74S244s umfaßt. SBIAS 23916 wählt unter Mikrobefehlskontrolle von FUCTL 20214 den Ausgang von BIAS 20246, so daß er einer der BIAS-Werte von BIASM 23910, L8 oder L, ist. SBIAS 23916's erster Eingang von BIASM 23910 wurde oben beschrieben. SBIAS 23916's zweiter Eingang, L8, wird von FUCTL 20214 zur Verfügung gestellt und ist ein 8 Bit Mikrobefehl, der von FUSITT 11012 zur Verfügung gestellt wird. Der zweite Eingang von SBIAS 23916 erlaubt Mikrocodeauswahl der BIAS-Werte, die bei der Manipulation der Längen- und Abstandsfelder von logischen Beschreibern durch LENALU 20252 und OFFALU 20242 benutzt werden, und um Eingänge für MC 10226 zu generieren. SBIAS 23916's dritter Eingang, L, wird in ähnlicher Weise von FUCTL 20214 zur Verfügung gestellt und ist ein dekodierter Längenwert, der von Bereichen der Mikrobefehle in FUSITT 11012 abgeleitet wurde. Diese Mikrocodelängenwerte repräsentieren bestimmte, häufig vorkommende Datenausdruckslängen, wie z. B. die Längen 1, 2, 4, 8, 16, 32 und 64 Bits. Ein L- Eingabe, die eine Länge von 8 Bits repräsentiert, kann z. B. für das Byte-für-Byte-Lesen von MEM 10112 benutzt werden.
Nachdem der Betrieb von LENP 20220 beschrieben ist, wird im folgenden der Betrieb von AONP 20216 beschrieben.

f. AON-Prozessor 20216

a.a. AONGRF 20232

Wie oben beschrieben, beinhaltet AONP 20216 AONSEL 20248 und AONGRF 20232. AONGRF 20232 ist ein 28 Bit breiter vertikaler Ausschnitt aus GRF 10354 und speichert AON-Felder von AON-Zeigern und logischen Beschreibern. AONSEL 20248 ist ein Multiplexer, um Eingaben, die nach AONGRF 20232 geschrieben werden sollen, auszuwählen. AONSEL 20248 kann z. B. aus SN74S257s bestehen. AONGRF 20232 kann z. B. aus Fairchilds 93422s bestehen.
Wie oben beschrieben, ist AONGRF 20232's Ausgang mit dem AON-Bus 20230 verbunden, um es den AON-Feldern von AON-Zeigern und logischen Beschreibern zu erlauben, auf den AON-Bus 20230 von AONGRF 20232 transferiert zu werden. AONGRF 20232's Ausgang ist zusammen mit einem bidirektionalen Eingang vom AON- Bus 20230 mit einem zweiten Eingang von AONSEL 20248 und einem vierten Eingang von AONSEL 20238 verbunden. Dieser Datenpfad erlaubt es AON-Feldern, entweder von AONGRF 20232 oder vom AON-Bus 20230 nach AONGRF 20232 oder AONGRF 20234 geschrieben zu werden, oder als Eingabe für OFFMUX 20240 zur Verfügung gestellt zu werden.

b.b. Der AON-Auswähler 20248

AONSEL 20248's erster Eingang ist, wie oben beschrieben, mit dem Ausgang von OFFALU 20242 verbunden, und wird z. B. dafür benutzt, es AON-Feldern, die von OFFP 20218 erzeugt oder von OFFP 20218 manipuliert wurden, zu ermöglichen, in AONGRF 20232 geschrieben zu werden. AONSEL 20248's dritter Eingang ist ein 28 Bit-Wort, in dem jedes Bit auf logisch Null steht. AONSEL 20248's dritter Eingang erlaubt es AON- Feldern, die nur aus Nullen bestehen, nach AONGRF 20232 geschrieben zu werden. Ein AON-Feld, das nur aus Nullen besteht, wird dafür reserviert, daß die entsprechenden Eingaben in OFFGRF 20234 und LENGRF 20236 weder AON-Zeiger noch logische Beschreiber sind. AON-Felder, die nur aus Nullen bestehen, werden daher reserviert, um anzuzeigen, daß die entsprechenden Eingaben in OFFGRF 20234 und LENGRF 20236 Daten enthalten.
Summarisch gesehen und wie oben beschrieben, enthält DESP 29210 AONP 20216, OFFP 20218 und LENP 20220. OFFP 20218 enthält einen vertikalen Ausschnitt aus GRF 10354, OFFGRF 20234, um Abstandsfelder von AON-Zeigern und logischen Beschreibern zu speichern, und für die Speicherung von Daten, mit denen DESP 20210 operieren soll. OFFP 20218 ist der Hauptpfad für den Datentransfer von MEM 10112 nach JP 10114 und ist eine 32 Bit arithmetische und logische Einheit für allgemeine Zwecke, um alle gewöhnlichen arithmetischen und logischen Operationen durchzuführen. Darüber hinaus enthält OFFP 20218 Schaltkreise, wie z. B. OFFMUX 20240, zur Erzeugung und Manipulation von AON-, OFFSET- und LENGTH-Feldern von logischen Beschreibern und AON-Zeigern. OFFP 20218 kann auch Eingaben generieren und manipulieren für z. B. NC 10226, ATU 10228, PC 10234, AOT 10712, MHT 10716, MFT 10718 und andere Daten und Adreßstrukturen, die sich in MEM 10112 befinden. LENP 20220 beinhaltet einen vertikalen Ausschnitt aus GRF 10354, LENGRF 20236 zur Speicherung von Längenfeldern von logischen Beschreibern und zur Speicherung von Daten. LENP 20220 beinhaltet weiterhin BIAS 20246, das in Verbindung mit LENGRF 20236 und LENALU 20252 dazu benutzt wird, Längenfelder von logischen Beschreibern für MEM 10112-Leseoperationen zur Verfügung zu stellen, und insbesondere, um automatisch Zeichenkettentransfers durchzuführen. AONP 20216 enthält in ähnlicher Weise einen vertikalen Ausschnitt aus GRF 10354, AONGRF 20232. Eine Hauptfunktion von AONGRF 20232 ist die Speicherung und Bereitstellung von AON-Feldern von AON- Zeigern und logischen Beschreibern.
Nachdem die Struktur und der Betrieb von DESP 20210 beschrieben wurden, wird im folgenden die Struktur und der Betrieb der Speicherschnittstellen (MEMINT) 20212 beschrieben werden.

2. Die Speicherschnittstelle 20212 (Fig. 106, 240)

MEMINT 20212 umfaßt FU 10120's Schnittstelle zu MEM 10112. Wie oben beschrieben, beinhaltet MEMINT 20212 den Namenszwischenspeicher (NC) 10226, die Adressenübersetzungseinheit (ATU) 10228 und den Schutzzwischenspeicher (PC) 10234, die alle oben kurz beschrieben wurden. MEMINT 20212 beinhaltet weiter die Beschreiberfalle (DEST) 20256 und die Datenfalle (DAT) 20258. Funktionen, die von MEMINT 20212 durchgeführt werden, beinhalten (1) die Auflösung von Namen zu logischen Beschreibern durch NC 10226; (2) die Übersetzung von logischen Beschreibern in physikalische Beschreiber durch ATU 10228; und (3) die Bestätigung von Zugangsrechten auf Objekte durch PC 10234.
Wie in Fig. 202 gezeigt, ist NC 10226's Adreßeingang (ADR) mit dem NAME-Bus 20224 verbunden. NC 10226's Schreiblängenfeldeingang (WL) ist mit dem Ausgang von LENGRF 20236 verbunden. NC 10226's Schreibeabstandsfeldeingang (WO) und Schreibe- AON-Feldeingang (WA) sind mit OFFSET-Bus 20228 respektive AON-Bus 20230 verbunden. NC 10226's Lies-AON-Feld (RA)-, Lies-Abstandsfeld (RO)- und Lies-Längenfeld (RL)-Ausgänge sind mit AON-Bus 20230 respektive OFFSET-Bus 20228 und LENGTH-Bus 20226 verbunden.
Die bidirektionalen Kanäle AON (AON), Abstand (OFF) und Länge (LEN) von DEST 20256 sind mit bidirektionalen Bussen zu und von AON-Bus 20230 respektive OFFSET- Bus 20228 und LENGTH-Bus 20226 verbunden.
PC 10234 hat AON (AON)- und Abstands (OFF)-Eingänge, die mit AON-Bus 20230 respektive OFFSET-Bus 20228 verbunden sind. PC 10234 hat einen Schreibeeingabeeingang (WEN), der mit dem JPD-Bus 10142 verbunden ist. ATU 10228 hat AON (AON)-, Abstands (OFF)- und Längen (LEN)-Eingänge, die mit dem AON-Bus 20230 respektive OFFSET-Bus 20228 und dem LENGTH-Bus 20226 verbunden sind. Der Ausgang von ATU 10228 ist mit dem physikalischen Beschreiberbus (PD) 10146 verbunden.
Schließlich besitzt DAT 20258 einen bidirektionalen Kanals von und nach JPD-Bus 10142.

a.a. Die Beschreiberfalle 20256 und Datenfalle 20258

Zuerst auf DST 20256 und DAT 20258 Bezug nehmend, ist DST 20256 ein Register für den Empfang und die Ergreifung von logischen Beschreibern, die auf dem AON-Bus 20230, dem OFFSET-Bus 20228 und dem Längenbus 20226 erscheinen. In ähnlicher Weise ist DAT 20258 ein Register für den Empfang und das Ergreifen von Datenworten, die auf dem JPD-Bus 10142 erscheinen. DST 20256 und DAT 20258 können nachfolgend ergriffene logische Beschreiber und Datenworte nach AON-Bus 20230, OFFSET-Bus 20228 und dem LENGTH-Bus 20226 und dem JPD-Bus 10142 zurückgeben.
Wie oben beschrieben, werden viele CS 10110-Operationen, insbesondere MEM 10112- und JP 10114-Operationen, pipelineverarbeitet. Das heißt, Operationen werden mit bestimmten Sätzen innerhalb zwei oder mehrerer gleichzeitig ausgeführter Operationen überlappt. Zum Beispiel kann FU 10120 eine Leseanforderung an MEM 10112 absetzen und, während MEM 10112 diese Anforderung empfängt und bedient, eine zweite Leseanforderung absetzen. DEST 20256 und DAT 20258 helfen bei der Ausführung der überlappenden Operationen, indem sie eine temporäre Aufzeichnung dieser Operationen zur Verfügung stellen. Zum Beispiel ist ein Teil einer Lese- oder Schreibanforderung an MEM 10112 durch FU 10120 ein logischer Beschreiber, der ATU 10228 zur Verfügung gestellt wird. Wenn z. B. die erste Leseanforderung, die wir eben erwähnten, in einem ATU 10228-Zwischenspeicherfehler oder einer Schutzverletzung resultiert, so muß der logische Beschreiber jener ersten Anforderung wiederhergestellt werden für eine nachfolgende Aktion von CS 10110, wie es oben beschrieben wurde. Jener logische Beschreiber würde in DEST 20256 ergriffen und gespeichert sein und von daher sofort verfügbar sein, so daß DESP 20210 jenen Beschreiber nicht wieder generieren muß. DAT 20258 erfüllt einen ähnlichen Zweck hinsichtlich Daten, die nach MEM 10112 von JP 10114 geschrieben werden sollen. Das heißt, DAT 20258 empfängt und stellt eine Kopie eines jeden 32 Bit-Worts, das auf JPD-Bus 10142 durch JP 10114 transferiert wurde, sicher. Falls MEM 10112 nicht dazu imstande sein sollte, eine Schreibanforderung anzunehmen, so können jene Daten nachfolgend wieder von DAT 20258 zur Verfügung gestellt werden.

b.b. Namenszwischenspeicher 10226. Adreßübersetzungseinheit 10220 und Schutzzwischenspeicher 10234 (Fig. 106)

Bezug nehmend auf NC 10226, ATU 10228 und PC 10234, so sind diese Elemente von MEMINT 20212 vor allem Zwischenspeichermechanismen zur Steigerung der Geschwindigkeit von FU 10120's Schnittstelle zu MEM 10112, und daraus folgend zur Steigerung der Geschwindigkeit des Betriebs von CS 10110. Wie oben beschrieben, enthält NC 10226 einen Satz logischer Beschreiber, der bestimmten Operandennamen entspricht, die gegenwärtig in einem Prozeß auftauchen, der durch CS 10110 ausgeführt wird. NC 10226 stellt daher praktisch eine Hochgeschwindigkeitsauflösung von bestimmten Operandennamen in die entsprechenden logischen Beschreiber zur Verfügung: Wie oben im Zusammenhang mit Zeichenkettentransfers besprochen, beinhaltet NC 10226 im allgemeinen logische Beschreiber nur für Datenausdrücke, die kürzer als 256 Bits sind. NC 10226's Lese- und Schreibadressen sind Namen, die vom NAME-Bus 20224 zur Verfügung gestellt werden. Die Namenlese- und -schreibadressen können von DESP 20210 und insbesondere von OFFP 20218, wie es oben beschrieben wurde, oder von FUCTL 20214, wie es in der folgenden Beschreibung von FUCTL 20214 beschrieben wird, zur Verfügung gestellt werden. Die die logischen Beschreiber umfassenden NC 10226-Eingaben, von denen jede ein AON-Feld, ein Abstandsfeld, ein Längenfeld umfaßt, werden durch die Eingänge WA, WO und WL von NC 10226 vom AON-Bus 20230 respektive OFF- SET-Bus 20228 und LENGRF 20236's Ausgang nach NC 10226 geschrieben. Die logischen Beschreiber, die von NC 10226 als Antwort auf Namen gelesen werden, die NC 10226's ADR-Eingang zur Verfügung gestellt werden, werden dem AON-Bus 20230, dem OFFSET-Bus 20228 und dem LENGTH-Bus 20226 von den NC 10226-Ausgängen RA respektive RO und RL zur Verfügung gestellt.
ATU 10228 ist in ähnlicher Weise ein Zwischenspeichermechanismus, der für eine Hochgeschwindigkeitsübersetzung von logischen in physikalische Beschreiber sorgt. Im allgemeinen enthält zu einer gegebenen Zeit ATU 10228 einen Satz von Zuordnungen von logischen zu physikalischen Seitennummern für MEM 10112-Lese- und Schreibanforderungen, die augenblicklich durch JP 10114 an MEM 10112 gemacht werden oder antizipiert werden. Wie oben beschrieben, umfaßt jeder physikalische Beschreiber ein Rahmennummernfeld (FN), Felder für den Abstand innerhalb des Rahmens (O) und ein Längenfeld. Wie im Zusammenhang mit Zeichenkettentransfers besprochen, spezifiziert ein Längenfeld eines physikalischen Beschreibers, wie ein Längenfeld eines logischen Beschreibers einen Datenausdruck, der 32 Bits lang oder kürzer ist. Mit Bezug auf Fig. 106C, umfaßt ein logischer Beschreiber, wie oben diskutiert, ein 14 Bit AON-Feld, ein 32 Bit Abstandsfeld und ein Längenfeld, wobei das 32 Bit Abstandsfeld des logischen Beschreibers in 18 Bit Seitennummernfelder und ein 14 Bit Feld für den Abstand innerhalb der Seite (O) unterteilt ist. Bei der Übersetzung eines logischen in einen physikalischen Beschreiber werden die Längen- und O-Felder des logischen Beschreibers direkt als Längen- und O-Felder für den physikalischen Beschreiber benutzt. Die AON- und P- Felder des logischen Beschreibers werden in ein FN-Feld des physikalischen Beschreibers übersetzt. Weil keine aktuelle Übersetzung notwendig ist, kann ATU 10228 das L-Feld und O-Feld des logischen Beschreibers direkt, d. h. ohne zeitliche Verzögerung, MEM 10112 als O- und Längenfelder des entsprechenden physikalischen Beschreibers zur Verfügung stellen. Die Zwischenspeichereingänge von ATU 10228 umfassen daher FN- Felder von physikalischen Beschreibern, die den AON- und P-Feldern jener logischen Beschreiber entsprechen, für die ATU 10228 die entsprechenden Eingänge hat. Weil die FN-Felder des physikalischen Beschreibers vom Zwischenspeicher von ATU 10228, und nicht direkt wie bei den O- und den Längenfeldern eines physikalischen Beschreibers zur Verfügung gestellt werden, wird das FN-Feld eines physikalischen Beschreibers MEM 10112 z. B. einen Systemtakt später zur Verfügung gestellt als die O- und Längenfelder jenes physikalischen Beschreibers, wie oben besprochen wurde.
Mit Bezug auf Fig. 202 werden die FN-Felder des physikalischen Beschreibers, die nach ATU 10228 geschrieben werden sollen, im allgemeinen durch DFSP 20210 erzeugt. Die FN-Felder, die nach ATU 10228 geschrieben werden sollen, werden dem Dateneingang von ATU 10228 über den JPD-Bus 10142 zur Verfügung gestellt. Die Lese- und Schreibadressen für ATU 10228 bestehen aus AON- und P-Feldern von logischen Beschreibern und werden den AON- und OFF-Eingängen von ATU 10228 vom AON-Bus 20230 und dem OFFSET-Bus 20228 zur Verfügung gestellt. Die Lese- und Schreibadressen für ATU 10228 können von DFSP 20210 oder, wie weiter unten beschrieben, von FUCTL 20214 zur Verfügung gestellt werden. Die FN-Ausgaben von ATU 10228 werden zusammen mit den O- und Längenfeldern, die einen physikalischen Beschreiber umfassen, dem PD-Bus 10146 zur Verfügung gestellt.
PC 10234 ist ein Zwischenspeichermechanismus zur Bestätigung von Zugangsrechten aktiver Prozeduren auf Objekte, die durch logische Beschreiber identifiziert werden, die als Teil einer JP 10114-Lese- oder Schreibanforderung an MEM 10112 erzeugt wurden. Wie oben beschrieben, werden Zugangsrechte auf Objekte auf der Basis der Subjekte beurteilt. Ein Subjekt wurde definiert als eine spezielle Kombination aus Prinzipal, Prozeß und Bereich. Prinzipal, Prozeß und Bereich werden jeweils durch entsprechende UIDs identifiziert. Jedem Subjekt, das Zugangsrechte auf ein Objekt besitzt, wird eine aktive Subjektnummer (ASN) zugeteilt, wie es in einer vorangegangenen Beschreibung der CS 10110-Schutzmechanismen beschrieben wurde. Die ASN eines Subjekts, das gegenwärtig in CS 10110 aktiv ist, ist im ASN-Register 10916 in FU 10120 gespeichert. Die Zugangsrechte eines augenblicklich aktiven Subjekts auf augenblicklich aktive Objekte werden von jenen Objektzugangskontroll-Listen (ACL) 10918 gelesen und PC 10234 gespeichert. Wenn die gegenwärtige ASN wechselt, wird PC 10234 von den entsprechenden Zugangsrechteingaben bereinigt, und neue Eingaben, die der neuen ASN entsprechen, werden in PC 10234 geschrieben. Die Zugangsrechte einer bestimmten gegenwärtigen ASN auf ein bestimmtes Objekt können durch die Indizierung oder Adressierung von PC 10234 mit der AON, die das Objekt identifiziert, bestimmt werden. Adressen für Schreibeingaben in oder Leseeingaben von PC 10234 werden dem AON-Eingang von PC 10234 vom AON- Bus 20230 zur Verfügung gestellt. Eingaben, die in PC 10234 geschrieben werden sollen, werden vom JPD-Bus 10142 dem WEN-Eingang von PC 10234 zur Verfügung gestellt. PC 10234 wird auch mit Eingaben versorgt, die aus übersichtlichkeitsgründen nicht in Fig. 202 gezeigt werden, und von FUCTL 20214 stammen, und die gegenwärtige Operation anzeigen, die von JP 10114 bezüglich eines Objekts, das augenblicklich von FU 10120 adressiert wird, ausgeführt werden soll. Wann immer FU 10120 eine Lese- oder Schreibanforderung an MEM 10112 absetzt, die ein bestimmtes Objekt betrifft, so wird das AON-Feld jener Anforderung PC 10234 als Adresse zur Verfügung gestellt. Die Zugangsrechte des gegenwärtig aktiven Subjekts auf jenes Objekt werden vom entsprechenden PC 10234-Eingang gelesen und mit den FUCTL 20214-Eingaben verglichen, die die bestimmte Operation anzeigen, die von JP 10114 bezüglich jenes Objekts ausgeführt werden soll. Die von JP 10114 auszuführende Operation wird dann mit den Zugangsrechten des aktiven Subjekts auf jenes Objekt verglichen, und PC 10234 stellt eine Ausgabe zur Verfügung, die anzeigt, ob jenes aktive Subjekt die erforderlichen Rechte besitzt, um die beabsichtigte Operation durchzuführen. Die Indizierung vom PC 10234 und der Vergleich der Zugangsrechte mit der beabsichtigten Operation wird gleichzeitig zur Übersetzung des logischen Beschreibers der Speicheranforderung in einen entsprechenden physikalischen Beschreiber von ATU 10228 durchgeführt. Wenn PC 10234 anzeigt, daß jenes aktive Subjekt die erforderlichen Zugangsrechte besitzt, so wird die beabsichtigte Operation von JP 10114 ausgeführt. Wenn PC 10234 anzeigt, daß jenes aktive Subjekt die erforderlichen Zugangsrechte nicht besitzt, so zeigt PC 10234 an, daß eine Verletzung der Schutzmechanismen aufgetreten ist, und unterbricht die Ausführung der beabsichtigten Operation.

c.c. Struktur und Betrieb eines generalisierten Zwischenspeichers und NC 10226 (Fig. 240)

Nachdem die Gesamtstruktur und der Betrieb von NC 10226, ATU 10228 und PC 10234 beschrieben wurden, werden die Struktur und der Betrieb dieser Zwischenspeicher unten genauer beschrieben. Die Struktur und der Betrieb von NC 10226, ATU 10228 und PC 10234 sind ähnlich, ausgenommen daß NC 10226 ein Vierwegesatzassoziativ-Zwischenspeicher, ATU 10228 ein Dreiwegesatzassoziativ-Zwischenspeicher und PC 10234 ein Zweiwegesatzassoziativ-Zwischenspeicher ist.
Daher wird die Struktur und der Betrieb von NC 10226, ATU 10228 und PC 10234 unter Bezugnahme auf und Beschreibung von einem verallgemeinerten Zwischenspeicher, der jeweils NC 10226, ATU 10228 und PC 10234 ähnlich, aber nicht notwendigerweise identisch dazu ist, beschrieben. Wir werden auf NC 10226 bei der Beschreibung eines verallgemeinerten Zwischenspeichers unten Bezug nehmen, um sowohl die Struktur und den Betrieb des verallgemeinerten Zwischenspeichers zu verdeutlichen als auch um die Unterschiede zwischen dem verallgemeinerten Zwischenspeicher und NC 10226 zu beschreiben. ATU 10228 und PC 10234 werden dann durch die Beschreibung der Unterschiede zwischen ATU 10228 und PC 10234 und dem verallgemeinerten Zwischenspeicher beschrieben.
In Fig. 240 wird ein Ausschnitt aus einem Blockdiagramm eines verallgemeinerten Vierwegesatzassoziativ-Zwischenspeichers gezeigt. Der Kennzeichenspeicher (TS) 24010 umfaßt einen Kennzeichenspeicher A (TSA) 24012, Kennzeichenspeicher B (TSB) 24014, Kennzeichenspeicher C (TSC) 24016 und Kennzeichenspeicher D (TSD) 24018. Alle Sätze des Zwischenspeichers, durch TSA 24012 bis TSD 24018 repräsentiert, können, wie z. B. in NC 10226, bis zu 16 Eingänge enthalten, so daß TSA 24012 bis TSD 24018 jeweils 16 Worte lang sind.
Adreßeingaben in einen Zwischenspeicher werden in ein Kennzeichenfeld und ein Indexfeld unterteilt. Die Kennzeichenfelder werden in dem Kennzeichenspeicher des Zwischenspeichers gespeichert und indiziert, d. h. so adressiert, daß der Kennzeichenspeicher gelesen oder geschrieben werden kann durch das Indexfeld der Adresse. Ein Kennzeichen, das vom Kennzeichenspeicher als Antwort auf ein Indexfeld einer Adresse gelesen wurde, wird dann mit dem Kennzeichenfeld jener Adresse verglichen, um anzuzeigen, ob der Zwischenspeicher eine Eingabe besitzt, die jener Adresse entspricht, d. h. ob ein Zwischenspeichertreffer auftritt. Der NC 10226 z. B. kann eine Namenssilbe aus einem 8, 12 oder 16 Bit-Binärwort bestehen, wie oben beschrieben wurde. Die vier am wenigsten signifikanten Bits dieser Worte oder Namen umfassen das Indexfeld von NC 10226, während die übrigen 4, 8 oder 12 signifikantesten Bits das Kennzeichenfeld von NC 10226 umfassen. Die TSA 24012 bis TSD 24018 können daher jeweils 12 Eingänge breite Speicher sein, um die 12 Bit Kennzeichenfelder der 16 Bitnamen zu speichern. Index (IND) oder Adreßeingaben der TSA 24012 bis TSD 24018 würden in NC 10226 mit den vier am wenigsten signifikanten Bits des NAME-Bus 20224 verbunden sein, während die Kennzeicheneingaben (TAGI) der TSA 24012 bis TSD 24018 mit den 12 signifikantesten Bits des NAME-Bus 20224 verbunden wären.
Wie oben beschrieben, werden die Kennzeichenausgaben von TS 24010 mit den Kennzeichenfeldern der Adressen verglichen, die dem Zwischenspeicher vorgestellt werden, um zu bestimmen, ob der Zwischenspeicher eine Eingabe enthält, die jener Adresse entspricht. Mit NC 10226 als Beispiel werden die 12 Bit Kennzeichenausgaben (TAGOs) der TSA 24012 bis TSD 24018 mit den ersten Eingängen des Kennzeichenspeichertesters (TSC) 24019 respektive den Eingängen des Kennzeichenspeichertestes A (TSCA) 24020, des Kennzeichenspeichertesters B (TSCB) 24022, des Kennzeichenspeichertesters D (TSCD) 24024 und des Kennzeichenspeichertesters E (TSCE) 24026 verbunden. Die zweiten 12 Biteingänge der TSCA 24020 bis TSCE 24026 können mit den 12 signifikantesten Bits des NAME-Busses 20224 verbunden werden, um die Kennzeichenfelder der NC 10226-Adressen zu empfangen. TSCA 24020 bis TSCE 24026 vergleichen das Kennzeichenfeld einer Adresse mit den Kennzeichenausgaben, die von TSA 24012 bis TSE 24018 als Antwort auf das Indexfeld jener Adresse gelesen werden, und stellen vier Bitausgaben zur Verfügung, die anzeigen, welcher, falls überhaupt einer, der 16 möglichen Eingänge und ihrer assoziierten Kennzeichenspeicher jenem Adressenkennzeichenfeld entsprechen. TSCA 24020 bis TSCE 24026 können beispielsweise aus Fairchild 93S46s bestehen.
Die vier Bitausgaben der TSCA 24012 bis TSCE 24026 sind im verallgemeinerten Zwischenspeicher mit den Eingängen der Kennzeichenspeicher-Pipelineregister (TSPR) 24027 verbunden, und zwar mit den Eingängen der Kennzeichenspeicher-Pipelineregister A (TSPRA) 24028 respektive dem Kennzeichenspeicher-Pipelineregister B (TSPRB) 24030, dem Kennzeichenspeicher-Pipelineregister C (TSBRC) 24032 und dem Kennzeichenspeicher-Pipelineregister D (TSPRD) 24034. ATU 10228 und PC 10234 werden mit einer einzigen Zwischenspeicher-Zugriffsoperation in zwei Systemtakten pipelineverarbeitet. Während des ersten Systemtakts wird der Kennzeichenspeicher adressiert und die Kennzeichenspeicher darin werden mit den Kennzeichenfeldern der Adresse verglichen, um anzeigen zu können, ob ein Zwischenspeichertreffer vorliegt, d. h. ob der Zwischenspeicher eine Eingabe enthält, die einer bestimmten Adresse entspricht. Während des zweiten Systemtakts wird, wie unten beschrieben wird, ein entdeckter Zwischenspeichertreffer kodiert, um Zugang zu einem entsprechenden Eingang in dem Zwischenspeicher- Datenspeicher zu erhalten. Die Pipelineoperation über zwei Systemtakte hinweg wird durch Zwischenspeicher-Pipelineregister gewährleistet, die teilweise TSPRA 24028 bis TSPRD 24034 beinhalten. NC 10226 wird nicht pipelineverarbeitet und beinhaltet nicht die TSPRA 24028 bis TSPRD 24034. In NC 10226 werden die Ausgaben von TSCA 24012 bis TSCD 24024 direkt mit den Eingängen von TSHEA 24036 bis TSHED 24042 verbunden, wie unten beschrieben wird.
Die Ausgänge von TSPRA 24028 bis TSPRD 24034 sind mit den Eingängen des Kennzeichenspeichertrefferkodierers (TSHE) 24035 respektive dem Kennzeichenspeichertrefferkodierers A (TSHEA) 24036, dem Kennzeichenspeichertrefferkodierer B (TSHEB) 24038, dem Kennzeichenspeichertrefferkodierer C (TSHEC) 24040 und dem Kennzeichenspeichertrefferkodierer D (TSHED) 24042 verbunden. TSHEA 24036 bis TSHED 24042 kodieren die Biteingaben von TSPRA 24028 bis TSPRD 24034, um Einzelbitausgaben bereit zu stellen, die anzeigen, welcher, falls überhaupt, der vier Sätze des Zwischenspeichers eine Eingabe beinhaltet, die der Adresseneingabe entspricht.
Die Einzelbitausgaben der TSHEA 24036 bis TSHED 24042 sind mit den Eingängen des Trefferkodierers (HE) 24044 verbunden. HE 24044 kodiert Einzelbiteingaben von TSHEA 24036 bis TSHED 24042, um zwei Ausgabesätze zur Verfügung zu stellen. Die ersten Ausgaben von HE 24044 werden dem Zwischenspeichernutzungsspeicher (CUS) 24046 zur Verfügung gestellt und zeigen an, in welchem der vier Sätze des Zwischenspeichers, die den TSA 24012 bis TSD 24018 entsprechen, ein Zwischenspeichertreffer aufgetreten ist. Wie oben im Zusammenhang mit MC 20116 beschrieben und im folgenden noch näher erläutert, ist CUS 24046 ein Speicher, der Informationen für den Aufzeichnungsgebrauch der Zwischenspeichereingänge beinhaltet. Das heißt, CUS 24046 enthält Eingaben, die anzeigen, ob für einen bestimmten Index Satz A, Satz B, Satz C oder Satz D der vier Sätze des Zwischenspeichers als letztes genutzt wurde, und welcher als erster benutzt wurde. Die CUS 24046-Eingaben, die die Sätze A, B, C und D betreffen, werden in den Speichern CUSA 24088 respektive CUSB 24090, CUSC 24092 und CUSD 24094 gespeichert. Der zweite Ausgang von HE 24044 ist, wie unten beschrieben, mit dem Selektionseingang des Datenspeicherselektionsmultiplexers (DSSMUX) 24048 verbunden, um einen Ausgang des Datenspeichers (DS) 24050 zu wählen, der als Zwischenspeicherausgabe zur Verfügung gestellt werden soll, wenn ein Zwischenspeichertreffer auftritt.
Mit Bezug auf DS 24050 enthält, wie oben beschrieben, der Datenspeicher eines Zwischenspeichers Informationen oder Eingaben, die in jenem Zwischenspeicher gespeichert sind. Zum Beispiel ist jede Eingabe in NC 10226's DS 24050 ein logischer Beschreiber, der ein AON, einen Abstand und eine Länge enthält. Der Datenspeicher eines Zwischenspeichers ähnelt in Struktur und Organisation dem Kennzeichenspeicher jenes Zwischenspeichers und die Eingaben hierin werden durch den Kennzeichenspeicher jenes Zwischenspeichers und die damit verbundene Kennzeichenspeichervergleichs- und -dekodierlogik identifiziert und lokalisiert. In NC 10226 z. B. gibt es für jeden Namen, der einen Eingang in NC 10226 hat, eine Eingabe, nämlich das Kennzeichenfeld jenes Namens, das in TS 24010 gespeichert ist, und eine entsprechende Eingabe, einen logischen Beschreiber, der jenem Namen entspricht, in DS 24050. Wie oben beschrieben, ist NC 10226 ein Vierwegesatzassoziative Zwischenspeicher, so daß TS 24010 und DS 24050 jeweils vier Datensätze enthalten. Jeder Satz wurde oben so beschrieben, daß er bis zu 16 Eingaben enthalten kann. DS 24050 umfaßt daher vier 16 Wortspeicher. Jeder Speicher ist 65 Bits breit und paßt sich an die 28 Bits der AON, die 32 Bits des Abstands und die 5 Bits der Länge an. Diese vier Komponentendatenspeicher von DS 24050 werden in Fig. 240 als Datenspeicher A (DSA) 24052, Datenspeicher B (DSB) 24054, Datenspeicher C (DSC) 24056 und Datenspeicher D (DSD) 24058 bezeichnet. DSA 24052, DSB 24054, DSC 24056 und DSD 24058 entsprechen in Struktur, Inhalt und Operation den TSA 24012 respektive TSB 24014, TSC 24016 und TSD 24018.
Die Dateneingänge (DIs) von DSA 24052 bis DSD 24058 sind in NC 10226 z. B. mit dem AON-Bus 20230, dem OFFSET-Bus 20228 und dem LENGTH-Bus 20226 verbunden und beinhalten die Eingänge WA, WO, WL von NC 10226. Die DIs von DSA 24052 bis DSD 24058 werden, wie in NC 10226 oben beschrieben, dazu benutzt, NC 10226-Eingaben in DSA 24052 bis DSD 24058 zu schreiben. Die Adreßeingänge von DSA 24052 bis DSD 24058 sind mit den Adreßausgängen der Adressenpipelineregister (ADRPR) 24060 verbunden. Wie momentan beschrieben wird, umfassen die Adreßeingänge der DSA 24052 bis DSD 24058 außer bei Zwischenspeicherbereinigungsoperationen dieselben Indexfelder von Zwischenspeicheradressen, die als Adreßeingaben TS 24010 und ADRPR 24060 zur Verfügung gestellt werden, aber sie sind um einen Systemtakt aus Gründen der Pipelineverarbeitung verzögert. Wie oben beschrieben wurde, wird NC 10226 nicht pipelineverarbeitet und hat keine Verzögerung um einen Systemtakt. Eine Adreßeingabe in den Zwischenspeicher ergibt daher die entsprechenden Eingaben, die durch das Indexfeld jener Adresse ausgewählt werden, und die von TSA 24012 bis TSD 24018 und DSA 24052 bis DSD 24058 gelesen werden. Die vier Ausgaben der DSA 24052 bis DSD 24058, die durch ein spezielles Indexfeld jener speziellen Adresse selektiert werden, werden als Eingaben für DSSMUX 24048 zur Verfügung gestellt. DSSMUX 24048 wird gleichzeitig mit einer Auswahlsteuerungseingabe von HE 24044 versorgt. Wie oben beschrieben, wird diese Steuerungseingabe nach DSSMUX 24048 von den TS 24010- Kennzeicheneingaben abgeleitet und zeigt an, welcher der DSA 24052 bis DSD 24058 Eingänge der Adresse entspricht, die dem Zwischenspeicher zur Verfügung gestellt wird. DSSMUX 24048 wählt als Antwort auf jene Auswahlsteuerungseingabe eine der vier logischen Beschreiberausgaben von DS 24050 als Zwischenspeicherausgabe aus, die jener Adresse entspricht. Die Ausgabe von DSSMUX 24048 wird dann über den Puffertreiber (PD) 24062 als Zwischenspeicherausgabe z. B. in NC 10226 dem AON-Bus 20230, dem OFFSET-Bus 20228 und dem LENGTH-Bus 20226 zur Verfügung gestellt.
Mit Bezug auf ADRMUX 24062, wählt ADRMUX 24062 eine der beiden Quellen aus, um Adreßeingaben DS 24050 zur Verfügung zu stellen, d. h. um den DS 24050 zu indizieren. Wie oben beschrieben, umfaßt eine erste ADRMUX 24062-Eingabe Adressenindexfelder des Zwischenspeichers und, z. B. in NC 10226, ist mit den vier am wenigsten signifikanten Bits des NAME-Busses 20224 verbunden. Während Zwischenspeicherbereinigungsoperationen werden DS 24050-Adreßeingaben vom Bereinigungszähler (FLUSHCTR) 24066 zur Verfügung gestellt, der in dem Beispiel ein vier Bitzähler ist. Während Zwischenspeicherbereinigungsoperationen erzeugt FLUSHCTR 24066 sequentielle Bitadressen, die zur sequentiellen Adressierung der DSA 24052 bis DSD 24058 benutzt werden. Die Auswahl zwischen dem ersten und zweiten Eingang von ADRMUX 24062 bzw. dem Adressenindexfeld und dem FLUSHCTR 24066 wird durch die Adressenmultiplexerauswahl (ADRMUXS) von FUCTL 20214 gesteuert.
Der Gültigkeitsspeicher (VALS) 24068 und der Schmutzspeicher (DIRTYS) 24070 sind Speicher, die parallel mit TS 24010 arbeiten und adressiert werden. VALS 24068 enthält Eingaben, die die Gültigkeit der entsprechenden TS 24010- und DS 24050-Eingaben anzeigen. Das heißt, die VALS 24068-Eingaben zeigen an, ob die entsprechenden Eingaben an die entsprechenden Stellen in TS 24010 und DS 24050 geschrieben wurden. Im Beispiel kann VALS 24068 dadurch ein 16 Bit-Wort als vier Bit breiter Speicher sein. Jedes Bit eines VALS 24068-Wortes zeigt die Gültigkeit der entsprechenden Lokation in TSA 24012 und DSA 24052, TSB 24014 und DSB 24054, TSC 24016 und DSC 24056 und TSD 24018 und DSD 24058 an. DIRTYS 24070 zeigt in ähnlicher Weise an, ob die entsprechenden Eingaben in die entsprechenden Lokationen von TS 24010 und DS 24050 überschrieben oder modifiziert wurden. Auch DIRTYS 24070 ist ein 16 Bit-Wort, das vier bitweise gespeichert ist.
Die Adreßeingänge von VALS 24068 und DIRTYS 24070 sind, wie z. B. in NC 10226, mit den am wenigsten signifikanten Bits des NAME-Busses 20224 verbunden und werden so durch Indexfelder von NC 10226-Adressen parallel mit TS 24010 adressiert. Die Ausgaben der VALS 24068 werden den TSCA 24020 bis TSCE 24026 zur Verfügung gestellt, um Ausgaben von TSCA 24020 bis TSCE 24026 zu verhindern, wenn es zu einer ungültigen Konkurrenz zwischen einer TS 24010-Eingabe und einer NC 10226-Adreßeingabe kommt. Ähnliche Ausgaben von DIRTYS 24070 werden FUCTL 20214 für den Gebrauch bei Zwischenspeicherbereinigungsoperationen zur Verfügung gestellt, um anzuzeigen, welche NC 10226-Eingabe schmutzig ist und in ein MT 10350 zurückgeschrieben werden muß anstatt nicht beachtet zu werden.
Die Ausgänge von VALS 24068 und DIRTYS 24070 sind auch mit den Eingängen vom Gültigkeitspipelineregister (VALPR) 24072 und dem Schmutzpipelineregister (DIRTYPR) 24074 verbunden. VALPR 24072 und DIRTYPR 24074 sind Pipelineregister, die TSPRA 24028 bis TSPRD 24034 ähneln, und es sind für Zeit Steuerungszwecke vorgesehen, was jetzt beschrieben werden soll. Die Ausgänge von VALPR 24072 und DIRTYPR 24074 sind mit den Eingängen der Gültigkeitsschreiblogik (VWL) 24076 bzw. der Schmutzschreiblogik (DWL) 24078 verbunden. Wie oben beschrieben, ist NC 10226 kein pipelineverarbeitender Zwischenspeicher und beinhaltet weder VALPR 24072 noch DIRTYPR 24074; die Ausgänge von VALS 24068 und DIRTYS 24070 werden direkt mit den Eingängen von VWL 24076 und DWL 24078 verbunden. Die Ausgänge von VWL 24076 und DWL 24078 sind mit den Dateneingängen von VALS 24068 bzw. DIRTYS 24070 verbunden. Beim Auftreten einer Schreiboperation nach TS 24010 und DS 24050, d. h. hineinschreiben in oder modifizieren eines Zwischenspeichereingangs, so werden die entsprechenden Gültigkeits- und Schmutzworteingänge von VALS 24068 und DIRTYS 24070 durch das Indexfeld der Eingangsadresse des Zwischenspeichers gelesen. Die Ausgaben nach VALS 24068 und DIRTYS 24070 werden empfangen und gespeichert in VALPR 24072 bzw. DIRTYPR 24074. Beim Beginn des nächsten Systemtakts werden die Gültigkeits- und Schmutzworte in VALPR 24072 und DIRTYPR 24074 in VWL 24076 bzw. DWL 24078 gelesen. VWL 24076 und DWL 24078 verändern jene Gültigkeitsbzw. Schmutzworteingaben von VALS 24068 und DIRTYS 24070, je nachdem, ob die entsprechenden Eingänge in TS 24010 und DS 24050 beschrieben oder verändert wurden. Diese modifizierten Gültigkeits- oder Schmutzwörter werden dann während des zweiten Systemtaktes von VWL 24076 und DWL 24078 in VALS 24068 bzw. DIRTYS 24070 geschrieben. Die Steuerungseingaben von VWL 24076 und DWL 24078 werden von FUCTL 20214 zur Verfügung gestellt.
Indem wir uns schließlich auf die weitest zurückliegende Nutzungslogik (LRUL) 24080 beziehen, so zeichnet LRUL 24080 die Benutzung der Zwischenspeichereingänge auf. Wie oben beschrieben, ist der verallgemeinerte Zwischenspeicher von Fig. 240 ein Vierwegesatzassoziative-Zwischenspeicher, der z. B. bis zu 16 Eingänge in jedem der NC 10226- Sätze beinhaltet. Die Eingaben innerhalb eines bestimmten Satzes werden durch, wie es oben beschrieben wurde, die Indizierung des TS 24010 des Zwischenspeichers identifiziert, und DS 24050 kann gleichzeitig bis zu vier individuelle Eingänge enthalten, die alle denselben Index besitzen, aber sich dadurch unterscheiden, daß sie verschiedene Kennzeichen haben. In diesem Fall würde sich die eine Eingabe in Satz A befinden und TSA 24012 und DSA 24052 umfassend, die andere in Satz B und TSB 24014 und DSB 24054 umfassend, und so weiter. Weil die mögliche Anzahl von individuellen Eingängen mit dem gleichen Kennzeichen größer ist als die Anzahl der Zwischenspeichersätze, kann es notwendig sein, eine bestimmte Zwischenspeichereingabe zu löschen, wenn eine andere Eingabe dasselbe Kennzeichen besitzt und in den Zwischenspeicher geschrieben werden soll. Im allgemeinen würde die Eingabe gelöscht werden, die am längsten nicht mehr benutzt wurde, um eine Lokation in TS 24010 und DS 24050 zur Verfügung zu stellen, um die neue Eingabe hineinzuschreiben. LRUL 24080 hilft bei der Bestimmung, welche Zwischenspeichereingaben gelöscht werden sollen, wenn es notwendig ist für das Hineinschreiben einer neuen Eingabe, indem es die relative Nutzung der Zwischenspeichereingänge verfolgt und anzeigt. LRUL 24080 umfaßt vor allem einen Speicher, LRU- Speicher (MLRU) 24081, der ein Wort für jeden Zwischenspeichersatz enthält. Wie oben beschrieben, beinhaltet NC 10226 z. B. 16 Sätze aus jeweils vier Rahmen, so daß der Speicher von LRUL 24080 dem Beispiel entsprechend 16 Worte lang sein kann. Jedes Wort zeigt die relative Benutzung der vier Rahmen in einem Satz an und ist ein 6 Bit- Wort.
Die Worte werden durch die Eingaberegister A, B, C, D (RABCD) 24083 erzeugt und in LRUL 24080's MLRU 24081 geschrieben, und zwar gemaß einem Nur-Schreib-Algorithmus, der von HE 24044 ausgeführt wird, wie es eben beschrieben wird. Jedes Bit aller sechs Worte gehört zu einem Rahmenpaar innerhalb eines bestimmten Zwischenspeichersatzes und zeigt an, welcher der beiden Rahmen zuletzt benutzt wurde. Zum Beispiel enthält Bit 0 eine logische 1, wenn Rahmen A später benutzt wurde als Rahmen B, und eine logische 0, wenn Rahmen B später benutzt wurde als Rahmen A. In ähnlicher Weise gehört Bit 1 zu den Rahmen A und C, Bit 2 zu den Rahmen A und D, Bit 3 zu den Rahmen B und C, Bit 4 zu den Rahmen B und D und Bit 5 zu den Rahmen C und D. Anfangs werden alle Bits eines bestimmten LRUL 24080-Wortes auf Null gesetzt. Nehmen wir z. B. an, daß die Rahmen eines bestimmten Satzes in der Reihenfolge Rahmen A, Rahmen D, Rahmen B benutzt werden; die Bits 0 bis 5 jenes LRUL 24080-Wortes enthalten anfangs nur Nullen. Bei einer Bezugnahme auf Rahmen A, würden die Bits 0, 1 und 2, die sich auf die Rahmen A und B bzw. A und C bzw. A und D beziehen, auf logisch 1 gesetzt werden. Die Bits 3, 4 und 5, die sich auf die Rahmen B und C bzw. die Rahmen B und D und die Rahmen C und D beziehen, würden auf logisch 0 bleiben. Bei einer Bezugnahme auf Rahmen D bleiben die Bits 0 und 1, die sich auf die Rahmen A und B bzw. Rahmen A und C beziehen, auf logisch 1. Bit 2, das sich auf die Rahmen A und D bezieht, würde von logisch 1 auf logisch 0 gesetzt werden, um anzuzeigen, daß auf Rahmen D später Bezug genommen wurde als auf Rahmen A. Bit 3, das sich auf die Rahmen B und C bezieht, würde auf logisch 0 bleiben. Die Bits 4 und 5, die sich auf die Rahmen B und D bzw. die Rahmen C und D beziehen, würden auf logisch 0 gesetzt werden, obwohl sie bereits auf logisch 0 stehen, um anzuzeigen, daß Rahmen D später benutzt wurde als Rahmen B oder Rahmen C. Bei einer Bezugnahme auf Rahmen B, würde Bit 0, das sich auf die Rahmen A und B bezieht, auf logisch 0 gesetzt werden, um anzuzeigen, daß Rahmen B später benutzt wurde als Rahmen A. Die Bits 1 und 2, die sich auf die Rahmen A und C bzw. die Rahmen A und D beziehen, würden auf logisch 1 bzw. logisch 0 bleiben. Die Bits 3 und 4, die sich auf die Rahmen B und C bzw. die Rahmen B und D beziehen, würden auf logisch 1 gesetzt werden, um anzuzeigen, daß Rahmen B später benutzt wurde als Rahmen C oder Rahmen D. Bit 5 bleibt auf logisch 0.
Wenn es notwendig ist, eine Zwischenspeichereingabe in einem bestimmten Rahmen zu ersetzen, wird das LRUL 24080-Wort, das sich auf den Zwischenspeichersatz, der den Rahmen enthält, bezieht, von MLRL 24081 des LRUL 24080 durch das LRU-Register (RLRU) 24085 gelesen und durch die LRU-Dekodierlogik (LRUD) 24087 dekodiert, um anzuzeigen, welches der am frühesten benutzte Rahmen ist. Dieses Dekodieren wird mit Hilfe eines Nur-Lesespeichers ausgeführt, der als Dekodierauflösegerät arbeitet.
Nachdem die Struktur und der Betrieb eines verallgemeinerten Zwischenspeichers, wie er in Fig. 240 gezeigt ist, beschrieben wurde, und dabei Bezüge zu NC 10226 hergestellt wurden, um NC 10226 und seine Unterschiede zu dem verallgemeinerten Zwischenspeicher zu verdeutlichen, wird im folgenden die Struktur und der Betrieb von ATU 10228 und PC 10234 beschrieben. ATU 10228 und PC 10234 werden beschrieben, indem die Unterschiede zwischen ATU 10228 und PC 10234 und dem verallgemeinerten Zwischenspeicher und NC 10226 beschrieben werden. Zuerst wird ATU 10228 beschrieben, danach PC 10234.

d.d. Die Adressenübersetzungseinheit 10228 und der Schutzzwischenspeicher 10234

ATU 10228 ist ein dreiwegsatzassoziativer Zwischenspeicher mit 16 Sätzen, d. h. er enthält drei Rahmen für jeden Satz. Die Struktur und der Betrieb von ATU 10228 ist dem oben beschriebenen verallgemeinerten Zwischenspeicher ähnlich. Weil sie nur drei anstatt vier Rahmen pro Satz hat, beinhaltet ATU 10228 weder STD 24018 noch ATSCE 24026 noch ATSPRD 24034 noch ATSHED 24042 und auch nicht ADSD 24058. Wie oben beschrieben, umfassen die Adreßeingänge von ATU 10228 AON- und O-Felder von logischen Beschreibern. Die AON-Felder sind jeweils 28 Bits lang und die O-Felder umfassen die 18 signifikantesten Bits der Abstandsfelder eines logischen Beschreibers, so daß die Adreßeingaben in ATU 10228 48 Bits breit sind. Die vier am wenigsten signifikanten Bits der O-Felder werden als Index benutzt. Die AON-Felder und die 14 signifikantesten Bits des O-Feldes umfassen die Kennzeichen von ATU 10228. Die ATU 10228- Kennzeichen sind daher jeweils 42 Bits breit. Dementsprechend sind die TSA 24012, TSB 24014 und TSC 24016 von ATU 10228's TS 24010 jeweils 16 Worte lang und 42 Bits breit.
DSA 24052, DSB 24054 und DSC 24056 von ATU 10228 sind jeweils 16 Bits lang. Die ATU 10228-Ausgaben sind, wie oben beschrieben wurde, jeweils Rahmennummern (FN)- Felder von physikalischen Deskriptoren mit jeweils 13 Bits. ATU 10228's DSA 24052, DSB 24054 und DSC 24056 sind daher jeweils 13 Bits breit.
ATU 10228's LRUL 24080 ist in Struktur und Betrieb dem verallgemeinerten Zwischenspeicher ähnlich. Die LRUL 24080-Worte von ATU 10228, die jeweils einem ATU 10228-Satz entsprechen, sind jeweils 3 Bits breit, da 3 Bits ausreichend sind, um die relative Benutzung von drei Rahmen innerhalb eines Dreirahmengerätes anzuzeigen. In ATU 10228 zeigt Bit 1 des LRUL 24080-Wortes an, ob Rahmen A später als Rahmen B benutzt wurde, Bit 2, ob Rahmen A später als Rahmen C benutzt wurde, und Bit 3, ob Rahmen B später als Rahmen C benutzt wurde. Hinsichtlich aller anderen Dinge, und im Unterschied zu oben, ähnelt ATU 10228 in Struktur und Betrieb dem verallgemeinerten Zwischenspeicher.
Mit Bezug auf PC 10234, so ist PC 10234 ein zweiwegesatzassoziativer Zwischenspeicher mit acht Sätzen, d. h. er hat zwei Rahmen pro Satz. Da er zwei anstelle von vier Rahmen besitzt, beinhaltet PC 10234 weder TSC 24016 noch TSD 24018 noch TSCC 24024 noch TSCD 24026 noch TSPRC 24032 noch TSPRD 24034 noch TSHEC 24040 noch TSHED 24042 noch DSC 24056 noch DSD 24058.
Die Adreßeingaben von PC 10234 sind die 28 Bit AON-Felder von logischen Beschreibern. Die drei am wenigsten signifikanten Bits jener AON-Felder werden als Indizes zur Adressierung der TS 24010 und DS 24050 von PC 10234 benutzt. Die 25 signifikantesten Bits jener AON-Feldadresseneingänge werden als Kennzeichen für PC 10234 benutzt, so daß TSA 24012 und TSB 24014 von PC 10234 jeweils acht Wort mals 25 Bitspeicher sind.
Auf PC 10234's LRUL 24080 Bezug nehmend, reicht ein einzelnes Bit aus, um anzuzeigen, auf welchen der beiden Rahmen in den PC 10234-Sätzen am spätesten zugegriffen wurde. PC 10234's LRUL 24080's Speicher ist daher acht Worte oder Sätze lang und ein Bit breit.
Wie oben beschrieben, umfaßt PC 10234's Eingaben Informationen, die Zugangsrechte von bestimmten aktiven Subjekten auf bestimmte aktive Objekte betreffen. Jeder PC 10234-Eingang umfaßt 35 Bits an Information. Drei Bits dieser Informationen zeigen an, ob ein bestimmtes Subjekt Lese-, Schreibe- oder Ausführungsrechte bezüglich eines bestimmten Objektes besitzt. Die verbleibenden 32 Bits umfassen praktisch ein Längenfeld, das den Datenträger oder den Bereich anzeigt, d. h. die Anzahl von Datenbits jenes Objektes, zu dem jene Zugangsrechte gehören.
Wieder mit Bezug auf Fig. 240 unterscheidet sich PC 10234 von dem verallgemeinerten Zwischenspeicher und von NC 10226 und ATU 10228 dadurch, daß es außerdem eine Ausdehnungsüberprüfungslogik (EXTCHK) 24082 und eine Betriebsüberprüfungslogik (OPRCHK) 24084 enthält. Die PC 10234-Eingaben beinhalten, wie oben beschrieben wurde, drei Bits, die den Typ von Zugangsrechten identifizieren, die ein bestimmtes Subjekt auf ein bestimmtes Objekt hat. Diese drei Bits, die Leserecht (R), Schreibrecht (W) oder Ausführungsrecht (E) repräsentieren, werden einem ersten Eingang von OPRCHK 24084 zur Verfügung gestellt. Eine zweite Eingabe von OPRCHK 24084 wird von FUCTL 20214 zur Verfügung gestellt und spezifiziert, ob JP 10114 bezüglich jenes Objektes eine Leseoperation durchführen möchte (RI) oder eine Schreiboperation (WI) oder eine Ausführungsoperation (EI). OPRCHK 24084 vergleicht seine Zugangsrechtseingaben von DS 24050 mit OPRCHK 24084's beabsichtigte Operationseingaben von FUCTL 20214. Falls jenes Subjekt nicht die Rechte auf jenes Objekt besitzt, die erforderlich sind, um die beabsichtigte Operation von JP 10114 durchzuführen, so erzeugt OPRCHK 24084 eine Operationsverletzung (OPRV), die anzeigt, daß eine Schutzverletzung aufgetreten ist.
In ähnlicher Weise werden die 32 Bits einer PC 10234-Eingabe, die die Ausdehnungsrechte betreffen, als Eingabe (EXTENT) für EXTCHK 24082 zur Verfügung gestellt. Wie oben festgestellt, zeigt das EXTENT-Feld einer PC 10234-Eingabe die Länge oder Anzahl der Datenbits innerhalb eines Objektes an, zu dem jene Zugangsrechte gehören. Das EXTENT-Feld einer PC 10234-Eingabe wird durch EXTCHK 24082 mit dem Abstandsfeld des logischen Beschreibers der gegenwärtigen JP 10114-Anforderung an MEM 10112 verglichen, für den die gegenwärtige Schutzmechanismusüberprüfung gemacht wird. Falls der Vergleich der Ausdehnungsrechte und des Abstandsfeldes ergibt, daß die gegenwärtige Speicheranforderung über die Objektlänge hinausgeht, zu der die entsprechenden Rechte, die von DS 24050 gelesen werden, gehören, so generiert EXTCHK 24082 eine Ausdehnungsverletzungsausgabe (EXTV). EXTV zeigt an, daß eine gegenwärtig vorliegende Speicheranforderung durch JP 10114 zu einem Bereich eines Objektes führt, das nicht zu der PC 10234-Eingabe gehört, die von BS 24050 gelesen wurde. Wie oben beschrieben, ist jedes Lesen von oder Schreiben nach MEM 10112, auch als Teil eines Zeichenkettentransfers, ein 32 Bit-Wort. Von daher erzeugt EXTCHK 24032 eine EXTV-Ausgabe, wenn das Abstandsfeld eines gegenwärtigen logischen Beschreibers ein Objektsegment mit weniger als 32 Bits beschreibt, bezogen auf die Grenze, die durch das EXTENT-Feld der PC 10234-Eingabe als Antwort auf jenen logischen Beschreiber definiert wurde. EXTV und OPRV werden zusammen durch die Schutzverletzungsschaltung (PVG) 24086 verknüpft, um eine Schutzverletzungsausgabe zu erzeugen (PROTV), die anzeigt, daß entweder eine Bereichsverletzung oder eine Operationsverletzung aufgetreten ist.
Nachdem die Struktur und der Betrieb von MEMINT 20212 und oben die Struktur und der Betrieb von DESP 20210 beschrieben wurde, wird im folgenden die Struktur und der Betrieb von FUCTL 20214 beschrieben.

3. Die Zugriffseinheitsteuerungslogik 20214 (Fig. 202)

Die folgenden Beschreibungen werden ein genaueres Bild der Struktur und des Betriebes von FU 10120 ergeben. Als erstes wird der Gesamtbetrieb von FU 10120 beschrieben, danach die Struktur von FU 10120, und schließlich der genaue Betrieb von FU 10120.
Wie oben beschrieben, steuert FUCTL 20214 den Betrieb von JP 10114 bei der Ausführung von Prozeduren von Benutzerprozessen. Unter den Funktionen, die von FUCTL 20214 durchgeführt werden, sind erstens die Verwaltung und der Betrieb des Namensraumes, der UID und des AON-basierten Adressierungssystems des CS 10110, was oben beschrieben wurde; zweitens die Interpretation der SOPs der Benutzerprozesse, für die Bereitstellung von entsprechenden Mikrobefehlsabfolgen für FU 10120 und EU 10122, um den Betrieb von JP 10114 bei der Ausführung von Benutzerprozessen zu steuern, wie es oben beschrieben wurde; und drittens die Steuerung des Betriebes der CS 10110-internen Mechanismen, z. B. CS 10110' s Stapelspeichermechanismen.
Wie unten genauer erläutert wird, beinhaltet FUCTL 20214 einen Voraufnehmer (PREF) 20260, der eine Abfolge von logischen Adressen erzeugt, wobei jede logische Adresse ein AON- und ein Abstandsfeld zum Lesen der S-Instruktionen (SINs) eines Benutzerprogrammes von MEM 10112 umfaßt. Wie oben beschrieben, kann jede SIN aus einer S-Operation (SOP) und einem oder mehrerer Operandennamen bestehen und kann ein oder mehrere 32 Bit-Worte besetzen. SINs werden von MEM 10112 als eine Abfolge von einzelnen 32 Bit-Worten gelesen, so daß PREF 20260 kein Längenfeld bei einer MEM 10112-Leseanforderung für eine SIN spezifizieren braucht. SINs werden von MEM 10112 durch den MOD-Bus 10144 gelesen und in dem Instruktionspuffer (INSTB) 20262 aufgenommen und gespeichert. PARSER 20264 extrahiert oder analysiert die SOPs und die Operandennamen von INSTB 20262. PARSER 20264 stellt die Operandennamen NC 10226 und die SOPs FUS-Interpreter-Aufteilungstabelle (FUSDT) 11010 und der EU- Aufteilungstabelle (EUSDT) 20266 durch das OP-Coderegister (OPCODEREG) 20268 zur Verfügung. Der Betrieb von INSTB 20262 und PARSER 20264 wird durch den gegenwärtigen Programmzähler (CPC) 20270, den Anfangsprogrammzähler (IPC) 20272 und den Ausgeführte-Programme-Zähler (EPC) 20274 gesteuert.
Wie oben beschrieben, stellt FUSDT 11010 für jede SOP, die von OPCODEREG 20268 empfangen wurde, einen entsprechenden S-Interpreter-Aufteilungszeiger (SD) oder Adresse FUSITT 11012 zur Verfügung, um eine entsprechende Abfolge von Mikrobefehlen zu selektieren, um den Betrieb von JP 10114, insbesondere FU 10120, zu steuern. Wie oben beschrieben, enthält FUSITT 11012 auch Mikrobefehlsabfolgen zur Steuerung und Kontrolle des Betriebs der CS 10110-internen Mechanismen, z. B. jener Mechanismen, wie RCWS 10358, die beim Austauschen von Prozessen involviert sind. EUSDT 20266 führt analoge Funktionen zu EU 10122 aus und stellt SD-Zeiger EUS-Interpretertabellen (EUSITTs) zur Verfügung, die sich in EU 10122 befinden.
Der Mikroprogrammzähler (mPC) 20276 stellt sequentielle Adressen FUSITT 11012 zur Verfügung, um individuelle Mikrobefehle aus Mikrobefehlsabfolgen zu selektieren. Die Verzweigungs- und Case-Logik (BRCASE) 20278 stellt FUSITT 11012 Adressen zur Verfügung, um Mikrobefehlsabfolgen für Mikrobefehlsverzweigungen und Mikrobefehlsfalle auszuwählen. Der Wiederholungszähler (REPCTR) 20280 und das Seitennummernregister (PNREG) 20282 stellen FUSITT 11012 während FUSITT 11012-Ladeoperationen Adressen zur Verfügung.
Wie oben beschrieben, ist FUSITT 11012 ein beschreibbarer Mikrobefehlssteuerungsspeicher, der mit ausgewählten S-Interpretern (SINTS) von MEM 10112 geladen wird.
Die FUSITT 11012-Adressen werden auch von der Ereignislogik (EVENT) 20284 und vom JAM-Eingang von NC 10226 zur Verfügung gestellt. Wie weiter unten beschrieben werden wird, ist EVENT 20284 Teil der FUCTL 20214-Schaltlogik, die in erster Linie mit dem Betrieb der CS 10110-internen Mechanismen betraut ist. Der Eingang JAM von NC 10226 indiziert bestimmte FUCTL 20114-Steuerungsfunktionen für die Namensraumadreßmechanismen von CS 10110, und insbesondere für NC 10226. Die Auswahl zwischen den oben diskutierten Adreßeingaben nach FUSITT 11012 wird durch die nächste Adressengenerierungslogik für die S-Interpreter-Tabelle (SITTNAG) 20286 gesteuert.
Andere Bereiche der FUCTL 20214-Schaltlogik sind mit dem Betrieb von CS 10110- internen Mechanismen betraut. Zum Beispiel beinhaltet FUCTL 20214 den Rückgabenkontrollwort-Stapelspeicher (RCWS) 10358, der oben im Zusammenhang mit den Stapelspeichermechanismen von CS 10110 beschrieben wurde. Der Registeradressenerzeuger (RAG) 20288 stellt Zeiger für die Adressierung von GRF 10354 und RCWS 10358 zur Verfügung und beinhaltet Mikrostapelspeicherzeigerregister (MISPR) 10356.
Wie oben beschrieben, stellt der MISPR 10356-Mechanismus Zeiger für die Adressierung des Mikrostapelspeichers (MIS) 10368 zur Verfügung. Wie weiter unten beschrieben wird, befinden sich die aktuellen MIS 10368-Zeiger, die auf den gegenwartigen, den vorangegangenen und den Grundrahmen von MIS 10368 zeigen, im Mikrosteuerungswortregister 1 (MCW1) 20290. MCW1 20290 und das Mikrokontrollwortnullregister (MCW0) 20292 enthalten zusammen bestimmte Informationen, die die gegenwärtige Ausführungsumgebung einer durch FU 10120 ausgeführten Mikrobefehlsabfolge anzeigen. Diese Ausführungsinformationen helfen bei der Ausführung dieser Mikrobefehlsabfolgen. Die Zustandsregister (STATE) 20294 ergreifen und speichern bestimmte Informationen, die den Betriebszustand von FU 10120 betreffen. Wie weiter unten beschrieben wird, wird diese Information, die wir als Zustandsvektoren bezeichnen, dazu benötigt, den Betrieb von FU 10120 zu aktivieren und zu steuern.
Zeitmeßgeräte (TIMERS) 20296 überwachen die abgelaufene Zeit seit dem Auftreten von Ereignissen, die eine Bedienung durch FU 10120 erforderlich machen. Falls die Wartezeiten für diese Ereignisse bestimmte Grenzen überschreiten, so zeigen diese TIMERS 20296 an, daß diese Grenzen überschritten wurden, so daß ein Service jener Ereignisse initiiert werden kann.
Schließlich umfaßt die Schnittstellenlogikzugriffseinheit zu E-Einheit (FUEUINT) 20298 den FU 10120-Bereich der Schnittstelle zwischen FU 10120 und EU 10122. FUEUINT 20298 ist der Hauptpfad, durch den Betrieb von FU 10120 und EU 10122 koordiniert wird.
Nachdem der Gesamtbetrieb von FU 10120 beschrieben wurde, wird mit Hilfe von Fig. 202 die Struktur von FU 10120 beschrieben, nach dieser Beschreibung der Struktur von FU 10120 folgt eine genauere Beschreibung von FU 10120, in der genauere Diagramme bestimmter Bereiche von FU 10120 eingeführt werden, so wie es erforderlich ist, um die Klarheit der Darstellung zu vergrößern.

a.a. Die Gesamtstruktur der Zugriffseinheitssteuerungslogik 20214

Indem wir uns wieder auf Fig. 202 beziehen, beinhaltet Fig. 202, wie eben beschrieben wurde, einen Ausschnitt aus einem Blockdiagramm von FUCTL 20214. Der gleichen Beschreibungsreihenfolge folgend wie oben, besitzt PREF 20260 einen 28 Bit bidirektionalen Kanal, der mit dem AON-Bus 20230 verbunden ist, und einen 32 Bit bidirektionalen Anschluß, der vom OFFSET-Bus 20228 kommt. Ein Steuerungseingang von PREF 20260 ist mit dem Steuerungsausgang von INSTB 20262 verbunden.
Der 32 Bit-Dateneingang (DI) von INSTB 20262 ist mit dem MOD-Bus 10144 verbunden. Der 16 Bit-Output (DO) von INSTB 20262 ist mit dem 16 Bit bidirektionalen Eingang von OPCODEREG 20268 und dem 16 Bit NAME-Bus 20224 verbunden. OPCODEREG 20268's Eingang umfaßt acht Bits der SIN und drei Bits der Dialektauswahl. Wie oben beschrieben, ist der NAME-Bus 20224 mit dem 16 Bit bidirektionalen Anschlußpunkt der Namensfalle (NT) 20254 verbunden sowie mit dem Adreßeingang ADR von NC 10226 und mit den Ein- und Ausgängen von OFFP 20228. Die Steuerungseingänge von INSTB 20262 und PARSER 20264 sind mit einem Steuerungsausgang von CPC 20270 verbunden.
Der 32 Bit-Eingang von CPC 20270 ist mit dem JPD-Bus 10142 verbunden und CPC 20270's 32 Bit-Ausgang ist mit dem 32 Bit-Eingang von IPC 20272 verbunden. Der 32 Bit-Ausgang von IPC 20272 ist mit dem 32 Bit-Eingang von EPC 20274 und mit dem JPD-Bus 10142 verbunden. EPC 20274's 32 Bit-Ausgang ist in ähnlicher Weise verbunden mit dem JPD-Bus 10142.
Die elf Bit-Ausgänge von OPCODEREG 20268 sind mit elf Bit-Adreßeingängen von FUSDT 11010 und EUSDT 20266 verbunden. Diese elf Bit-Adreßeingänge nach FUSDT 11010 und EUSDT 20266 umfassen jeweils drei Bits Dialektauswahlcode und acht Bits SINT-Code. Die zwölf Bit SDT-Ausgänge von EUSDT 20266 sind mit den Eingängen des Mikrobefehlssteuerungsspeichers in EU 10122 verbunden, wie in einer folgenden Beschreibung von EU 10122 erläutert wird. FUSDT 11010 hat, wie weiter unten beschrieben wird, zwei Ausgänge, die mit dem Adreßbus (ADR) 20298 verbunden sind. Der erste Ausgang von FUSDT 11010 sind sechs Bit SDT-Zeiger oder Adressen, die den generischen SINTs entsprechen, wie weiter unten beschrieben wird. Der zweite Ausgang von FUSDT 11010 sind 15 Bit SDT-Zeiger oder Adressen für Algorithmen aus Mikrobefehlsfolgen, was auch weiter unten beschrieben werden wird.
Zuerst auf RCWS 10358 Bezug nehmend, hat RCWS 10358 einen ersten bidirektionalen Anschlußpunkt, der mit dem JPD-Bus 10142 verbunden ist. Der zweite, dritte und vierte bidirektionale Anschlußpunkt von RCWS 10358 ist verbunden mit einem bidirektionalen Anschlußpunkt von MCW1 20290 bzw. einem ersten bidirektionalen Anschlußpunkt EVENT 20284, und einem bidirektionalen Anschlußpunkt von mPC 20276. Ein Ausgang von RCWS 10358 ist mit dem ADR-Bus 20298 verbunden.
Ein Eingang von mPC 20276 ist mit dem ADR-Bus 20298 verbunden, und der erste und zweite Ausgang von mPC 20276 ist mit einem Eingang von BRCASE 20278 bzw. dem ADR-Bus 20298 verbunden. Ein Ausgang von BRCASE 20278 ist mit dem ADR-Bus 20298 verbunden.
Wie oben beschrieben, ist ein erster bidirektionaler Anschlußpunkt von EVENT 20284 mit RCWS 10358 verbunden. Ein zweiter bidirektionaler Anschlußpunkt von EVENT 20284 ist mit MCW0 20292 verbunden. Ein Ausgang von EVENT 20284 ist mit dem ADR-Bus 20298 verbunden.
Die Eingänge von RPCTR 20280 und PNREG 20282 sind mit dem JPD-Bus 10142 verbunden. Die Ausgänge von RPCTR 20280 und PNREG 20282 sind mit dem ADR-Bus 20298 verbunden.
Der ADR-Bus 20298 und ein Eingang eines ersten Ausgangs von FUSITT 11012 sind mit den Eingängen von SITTNAG 20286 verbunden. Der Ausgang von SITTNAG 20286 ist über den Kontrollspeicheradreßbus (CSADR) 20299 mit dem Adreßeingang von FUSITT 11012 verbunden. Der Dateneingang von FUSITT 11012 ist mit JPD-Bus 10142 verbunden. Die Steuerausgänge von FUSITT 11012 sind mit fast allen Elementen von JP 10114 verbunden und werden daher aus Übersichtlichkeitsgründen bei den gezeichneten physikalischen Verbindungen nicht im einzelnen gezeigt, sie werden aber in den folgenden Beschreibungen erwähnt.
Wie oben beschrieben, besitzen MCW0 20292 und MCW1 20290 bidirektionale Anschlußpunkte, die mit den bidirektionalen Anschlußpunkten von EVENT 20284 bzw. mit einem zweiten bidirektionalen Anschlußpunkt von RCWS 10358 verbunden sind. Die Ausgänge von MCW0 20292 und MCW1 20290 sind mit dem JPD-Bus 10142 verbunden. Die anderen Eingänge von MCW0 20292 und MCW1 20290 sind, wie unten weiter beschrieben wird, mit mehreren anderen Elementen von JP 10114 verbunden, und werden aus Übersichtlichkeitsgründen hier nicht im einzelnen gezeigt, aber im folgenden Text beschrieben. In ähnlicher Weise hat STATE 20294 eine große Zahl von Ein- und Ausgängen, die mit anderen Elementen von JP 10114 und insbesondere FU 10120 verbunden sind. Die Ein- und Ausgänge von STATE 20294 werden hier aus Übersichtlichkeitsgründen nicht angezeigt und im folgenden genauer beschrieben.
RAG 20288 hat einen Eingang, der mit dem JPD-Bus 10142 verbunden ist, und andere Eingänge, die z. B. mit MCW1 20290 verbunden sind. RAG 20288, das MISPR 10356 beinhaltet, stellt Ausgaben z. B. als Adreßeingaben für RCWS 10358 und GRF 10354 zur Verfügung. Wieder aus Übersichtlichkeitsgründen werden die Ein- und Ausgänge von RAG 20288 im einzelnen in Fig. 202 nicht gezeigt, aber im weiteren genauer beschrieben werden.
TIMERS 20296 empfangen Eingaben von EVENT 20284 und FUSITT 11012 und stellen Ausgaben für EVENT 20284 zur Verfügung. Aus Übersichtlichkeitsgründen wird dies nicht im einzelnen in Fig. 202 gezeigt, aber im folgenden beschrieben.
FUINT 20298 empfängt Steuerungseingaben von FUSITT 11012 und EU 10122. FUINT 20298 stellt Ausgaben für EU 10122 und andere Elemente von FUCTL 20214 zur Verfügung. Aus Übersichtlichkeitsgründen werden die Verbindungen von und zu FUINT 20298 im einzelnen in Fig. 202 nicht gezeigt, aber im weiteren genauer beschrieben.
Nachdem der Gesamtbetrieb und die Gesamtstruktur von FUCTL 20214 beschrieben wurden, wird der Betrieb von FUCTL 20214 im folgenden näher beschrieben. Während der folgenden Beschreibungen werden weitere Diagramme von bestimmten Bereichen von FUCTL 20214 eingeführt, wie es erforderlich ist, um die Struktur und den Betrieb von FUCTL 20214 einem Fachmann auf diesem Gebiet zu erläutern. Zuerst wird FUCTL 20214's Betrieb hinsichtlich des Zugriffs auf und der Interpretation von SINs, das sind SOPs und Operandennamen, beschrieben, danach folgt eine Beschreibung des Betriebs von FUCTL 20214 hinsichtlich der internen Mechanismen von CS 10110.

b.b. Der Betrieb der Zugriffseinheitssteuerungslogik 20214

Indem wir uns zuerst jenen Elementen von FUCTL 20214 zuwenden, die direkt mit der Steuerung von JP 10114 als Antwort auf SOPs und Namenssilben betroffen sind, so beinhalten jene Elemente: (1) PREF 20260; (2) INSTB 20262; (3) PARSER 20264; (4) CPC 20270, IPC 20272 und EPC 20274; (5) OPCODEREG 20268; (6) FUSDT 11010 und EUSDT 20266; (7) mPC 20276; (8) BRCASE 20278; (9) REPCTR 20280 und PNREG 20282; (10) ein Teil von RCWS 10358; (11) SITTNAG 20286; (12) FUSITT 11012; und (13) NT 20254. Diese Elemente von FUCTL 20214 werden unten in der obigen Reihenfolge beschrieben.

a.a.a. Voraufnehmer 20260, Instruktionspuffer 20262, Analysator 20264, Operationscoderegister 20268, CPC 20270, IPC 20272 und EPC 20274 (Fig. 241)

Wie oben beschrieben, erzeugt PREF 20260 eine Reihe von Adressen für MEM 10112, um die SINs von Benutzerprogrammen von MEM 10112 zu FUCTL 20214 zu lesen, und insbesondere zu INSTB 20262. Jede PREF 20260-Leseanforderung transferiert ein 32 Bit- Wort von MEM 10112. Jedes SIN kann ein SOP und eine oder mehrere Namenssilben umfassen. Jedes SOP kann z. B. acht Bits an Information umfassen, während jede Namenssilbe z. B. 8, 12 oder 16 Datenbits umfassen kann. Im allgemeinen, und wie es in weiteren Einzelheiten in einer folgenden Beschreibung von STATE 20294 beschrieben wird, erhält PREF 20260 Zugang zu MEM 10112 in abwechselnden 110 Nanosekundensystemtakten. PREF 20260's Zugang zu MEM 10112 hängt von INSTB 20262 ab, das anzeigt, ob INSTB 20262 dazu vorbereitet ist, eine SIN, die von MEM 10112 gelesen wurde, zu empfangen. Insbesondere erzeugt INSTB 20262 die Steuerungsausgabe- Abfrage-Voraufnahmen (QPF) für PREF 20260, um PREF 20260 zu aktivieren, eine Anforderung an MEM 10112 abzusetzen, wenn, wie unten weiter beschrieben wird, INSTB 20262 dazu bereit ist, eine SIN zu empfangen, die von MEM 10112 gelesen wurde.
PREF 20260 ist ein Zählregister, das z. B. SN74S163s umfaßt.
Die bidirektionalen Ein- und Ausgänge von PREF 20260 sind mit dem AON-Bus 20230 und dem OFFSET-Bus 20228 verbunden. Weil PREF 20260 nur einzelne 32 Bit-Worte liest, braucht PREF 20260 kein LENGTH-Feld als Teil einer SIN-Leseanforderung spezifizieren, d. h. ein AON- und ein OFFSET-Feld sind ausreichend, um ein einzelnes 32 Bit-Wort zu definieren. Beim Beginn des Lesens einer Abfolge von SINs von MEM 10112 wird die Adresse (AON- und OFFSET-Felder) des ersten 32 Bit-Wortes jener SIN- Sequenz MEM 10112 durch DESP 20210 zur Verfügung gestellt und gleichzeitig vom AON-Bus 20230 und OFFSET-Bus 20228 in PREF 20260 geladen. Danach wird, jedesmal wenn ein nachfolgendes 32 Bit-Wort der SIN-Sequenz von MEM 10112 gelesen wird, die in PREF 20260 befindliche Adresse inkrementiert, um die nachfolgenden 32 Bit- Worte jener SIN-Sequenz zu spezifizieren. Die nachfolgenden Einzelwortadressen werden für alle Worte nach dem ersten Wort der Sequenz MEM 10112 von PREF 20260 zur Verfügung gestellt.
Wie oben beschrieben, empfängt INSTB 20262 SINs von MEM 10112 über den MOD- Bus 10144 und stellt, mit PARSER 20264 und unter der Kontrolle von CPC 20270 arbeitend, Namenssilben dem NAME-Bus 20224 und SINs OPCODEREG 20268 zur Verfügung. INSTB 20262 ist zusammen mit PREF 20260 dafür vorgesehen, die Ausführungsgeschwindigkeit der SINs zu steigern.
In Fig. 241 wird ein genaueres Blockdiagramm von INSTB 20262, PARSER 20264, CPC 20270, IPC 20272 und EPC 20274 gezeigt. INSTB 20262 umfaßt, wie gezeigt, zwei 32 Bit-Register, die parallel 32 Bit-Eingänge von MOD-Bus 10144 besitzen. INSTB 20262 empfängt auch zwei Taktschreibeeingänge (WC), einen für jedes. 32 Bitregister von INSTB 20262, von der Instruktionspufferschreibsteuerung (INSTBWC) 24110. Die Ausgaben von INSTB 20262 sind als acht, acht Bit Basissilben (BSs) strukturiert, die als BS0 bis BS7 bezeichnet werden. BS0, BS2, BS4 und BS6 werden geodert und umfassen acht Bit gerade Basissilben (BSE) von INSTB 20262, während BS1, BS3, BS5 und BS7 in ähnlicher Weise geodert werden und die ungeraden Basissilben von INSTB 20262 umfassen. BS0 und BSE werden als Eingaben für PARSER 20264 zur Verfügung gestellt.
PARSER 20264 empfängt eine erste Steuereingabe gegenwärtigen Silbengrößenregister (CSSR) 24112, das mit CPC 20270 assoziiert ist. Eine zweite Steuerungseingabe für PARSER 20264 wird vom Instruktionspuffersilbendekodierregister (IBSCECR) 24114 zur Verfügung gestellt, das auch mit CPC 20270 assoziiert ist. PARSER 20264 stellt eine acht Bit-Ausgabe dem NAME-Bus 20224 und dem Eingang von OPCODEREG 20268 zur Verfügung.
Mit Bezug auf INSTBWC 24110, so stellt INSTBWC 24110, wie weiter unten beschrieben wird, Steuersignale zur Verfügung, die sich auf das Schreiben von SINs in INSTB 20262 vom MOD-Bus 10144 beziehen. INSTBWC 24110 stellt auch Steuersignale zur Verfügung, die zum Betrieb von PREF 20260 gehören. Zusätzlich zu den WC-Ausgaben nach INSTB 20262 stellt INSTBWC 24110 die Steuerungsausgabe QPF PREF 20260 zur Verfügung, die Steuerungsausgabe Instruktionspufferblockierung (IBHUNG) EVENT 20284 zur Verfügung und das Steuerungssignal Instruktionspufferwarten (IBWAIT) STATE 20294 zur Verfügung. INSTBWC 24110 empfängt auch eine Steuerungseingabe BRANCH von BRCASE 20278 und eine Fehlereingabe von TIMERS 20296.
Wieder Bezug nehmend auf CPC 20270, IPC 20272 und EPC 20274, so sind IPC 20272 und EPC 20274 in Fig. 241 so wie in Fig. 202 dargestellt. Die weitere FUCTL 20214- Schaltlogik wird als mit CPC 20270 verbunden gezeigt. CPC 20270 ist ein 29 Bit- Register, das die Bits 1 bis 25 (CPC (1-25)) von den Bits 1 bis 25 des JPD-Bus 10142 empfängt. Das Bit 0 (CPC0) von CPC 20270 wird von der CPC0 CPCO-Auswahl CPCOS 24116 zur Verfügung gestellt. Die Eingaben von CPCOS 24116 sind die Bit 1-Ausgabe von CPC 20270 (CPC1) und Bit 0 vom JPD-Bus 10142. Die Bits 26, 27 und 28 von CPC 20270 (CPC (26-28)) werden vom CPC-Multiplexer (CPCMUX) 24118 zur Verfügung gestellt. CPCMUX 24118 stellt auch eine Eingabe für IBSDECR 24114 zur Verfügung. Die Eingaben von CPCMUX 24118 sind die Bits 25, 26 und 28 vom JPD-Bus 10142 und eine drei Bit-Ausgabe von der CPC-arithmetischen und logischen Einheit (CPCALU) 24120. Ein erster Eingang von CPCALU 24120 ist mit den Ausgangsbits 26, 27 und 28 von CPC 20270 verbunden. Ein zweiter Eingang von CPCALU 24120 ist mit CSSR 24112 verbunden. CSSR 24112's Eingang ist mit dem JPD-Bus 10142 verbunden.
Wie oben beschrieben, ist INSTB 20262 als ein 64 Bit breites Register implementiert. INSTB 20262 ist in zwei 32 Bit-Worte organisiert, die als Instruktionspufferwort 0 (IB0) und Instruktionspufferwort 1 (IB1) bezeichnet werden, und operiert als FIFO-Pufferspeicher. PREF 20260 lädt bei jeder Speicherreferenz durch PREF 20260 entweder IB0 oder IB1. Nur PREF 20260 kann INSTB 20262 laden, und INSTB 20262 kann nur vom MOD-Bus 10144 geladen werden. Von INSTBWC 24110 werden verschiedene Taktgeber, der Instruktionspufferschreibtaktgeber 0 (IBWC0) und der Instruktionspufferschreibtaktgeber 1 (IBWC1) zur Verfügung gestellt, um IBW0 bzw. IBW1 in INSTB 20262 zu laden. IBWC0 und IBWC1 sind jeweils logisch verknüpfte 110 Nanosekundentaktgeber. Ein IBW0 oder IBW1 wird jeweils in INSTB 20262 geschrieben, wenn IBWC0 oder IBWC1 durch INSTBWC 24110 aktiviert wird. IBWC0 und IBWC1 werden nur dann aktiviert, wenn MEM 10112 anzeigt, daß Daten für INSTB 20262 verfügbar sind, indem es das Schnittstellensteuerungssignal DAVI, wie oben beschrieben, aufprägt.
Die Hauptaufgabe von INSTBWC 24110 ist die Steuerung von FU 10120 hinsichtlich des Schreibens von SINs nach INSTB 20262. Wie oben beschrieben, stellt INSTBWC 24110 IBWC0 und IBWC1 INSTB 20262 zur Verfügung. IBWC0 und IBWC1 werden durch die DAVI-Eingabe von INSTBWC 24110 über MEM 10112 aktiviert. Die Auswahl zwischen IBWC0 und IBWC1 wird durch INSTBWC 24110's Eingabe von CPC 20270 gesteuert. Insbesondere, und wie es unten weiter beschrieben wird, zeigt Bit 26 (CPC 26) von CPC 20270's 29 Bit-Wort an, ob IBW0 oder IBW1 nach INSTB 20262 geschrieben wird.
Zusätzlich zur Kontrolle des Schreibens der IBW0 und IBW1 in INSTB 20262, stellt INSTBWC 24110 Steuersignale Elementen von FU 10120 zur Lesesteuerung von SINs von MEM 10112 nach INSTB 20262 zur Verfügung. In dieser Hinsicht entdeckt INSTBWC 24110 bestimmte Bedingungen, die den Zustand der SIN-Worte in INSTB 20262 betreffen, und es stellt entsprechende Steuersignale, die eben beschrieben werden, anderen Elementen von FU 10120 zur Verfügung, so daß INSTB 20262 allgemein immer mindestens ein gültiges SOP oder eine Namenssilbe enthält. Zuerst entdeckt INSTBWC 24110, wenn INSTB 20262 nicht voll ist, d. h. entweder IBW0 oder IBW1 oder beide sind ungültig, z. B. weil IBW0 von INSTB 20262 gelesen und ausgeführt wurde, diese Bedingung und stellt das Steuersignal QPF PREF 20260 zur Verfügung, um ein Lesen von MEM 10112 zu initiieren. INSTBWC 24110 aktiviert augenblicklich entweder den IBW0 oder den IBW1-Bereich von INSTB 20262, um das Wort, das von MEM 10112 in Antwort auf die Anforderung PREF 20260 gelesen wurde, zu empfangen. Wie oben festgestellt, wird diese Operation initiiert, wenn INSTBWC 24110 durch die Erzeugung eines Gültigkeitskennzeichens entdeckt und anzeigt, daß entweder IBW0 oder IBW1 ungültig ist. In diesem Fall wird IBW0 oder IBW1 als ungültig angezeigt, wenn es von INSTB 20262 durch PARSER 20264 gelesen wurde. Wie weiter unten beschrieben wird, werden die INSTBWC 24110-Gültigkeitskennzeichen für IBW0 und IBW1 durch die Steuerungseingaben von INSTBWC 24110, die die Bits 26 bis 28 (CPC 26-28) von CPC 20270 umfassen, und von der Kennzeicheneingabe für die gegenwärtige Silbengröße oder Silbenwert (K) von CSSR 24112, erzeugt. Darauf entdeckt INSTBWC 24110, wenn INSTB 20262 leer ist, d. h. wenn sowohl IBW0 als auch IBW1 ungültig sind, wie es eben beschrieben wurde, oder wenn nur eine Hälfte einer 16 Bit-Namenssilbe in INSTB 20262 vorhanden ist. Als Antwort auf beide Bedingungen generiert INSTBWC 24110 ein Steuersignal IBWAIT für STATE 20294. Wie unten weiter beschrieben wird, resultiert IBWAIT darin, die Ausführung von Mikrobefehlen zu stoppen, die Bezug nehmen auf INSTB 20262. Die PREF 20260-Anforderungen an MEM 10112 sind dann schon initiiert, wie es oben beschrieben wurde, außer wenn bestimmte andere Bedingungen, die momentan beschrieben werden, auftreten. Als drittes entdeckt INSTBWC 24110, wenn INSTB 20262 leer ist und PREF 20260 blockiert ist, daß es unfähig dazu ist, Anforderungen an MEM 10112 abzusetzen, und der gegenwärtige Mikrobefehl es versucht, eine Silbe von INSTB 20262 zu analysieren. In diesem Fall erzeugt INSTBWC 24110 für EVENT 20284 das Steuersignal Instruktionspuffer-blockiert (IBHUNG). Wie unten weiter beschrieben wird, resultiert IBHUNG in der Initiierung einer Mikrobefehlsabfolge zur Restaurierung des Wortflusses in INSTB 20262. Als viertes entdeckt INSTBWC 24110 durch Mikrobefehlssteuersignale, die von FUSITT 11012 zur Verfügung gestellt werden, wenn eine Verzweigung in einer Mikrobefehlsabfolge auftritt, die von FUSITT 11012 als Antwort auf eine SOP zur Verfügung gestellt wird. In diesem Falle werden sowohl IBW0 als auch IBW1 als ungültig gekennzeichnet. INSTBWC 24110 ignoriert dann die SIN-Worte, die von MEM 10112 als Antwort auf eine vorher abgesetzte PREF 20260-Anforderung gelesen wurden, aber noch nicht empfangen wurden, als die Verzweigung auftrat. Dies verhindert, daß INSTB 20262 ungültige SIN-Worte empfängt; PREF 20260 und INSTB 20262 fahren dann damit fort, gültige SIN-Worte der Verzweigung anzufordern und zu empfangen.
Wie oben beschrieben, liest PARSER 20264, der unter der Kontrolle von CPC 20270 und CPC 20270 und unter CPC 20270 assoziierter Schaltlogik arbeitet, Namenssilben und SOPs von INSTB 20262 zum NAME-Bus 20224 bzw. OPCODEREG 20268. PARSER 20264 arbeitet als ein Multiplexer mit der dazu gehörenden Steuerungslogik.
Wie oben beschrieben, ist INSTB intern als acht Acht-Bit-Worte, BS0 bis BS7, strukturiert. IBW0 umfaßt BS0 bis BS3, während IBW1 BS4 bis BS7 umfaßt. Jede SOP umfaßt acht Datenbits und umfaßt daher eine Basissilbe, während jede Namenssilbe 8, 12 oder 16 Datenbits umfaßt und daher entweder eine oder zwei Basissilben umfaßt. Die Größe der Namenssilbe wird, wie oben festgestellt, durch den gegenwärtigen Silbengrößenwert K, der in CSSR 24112 gespeichert ist, angezeigt.
BS0 und BS4 werden in INSTB 20262 von den MOD-Bus 10144-Bits 0 bis 7 geladen, während BS2 und BS6 von den MOD-Bus 10144-Bits 16 bis 23 geladen werden. BS1 und BS5 werden von den MOD-Bus 10144-Bits 8 bis 15 geladen, während BS3 und BS7 von den MOD-Bus 10144-Bits 24 bis 31 geladen werden. Die ungerade gezählten Basissilbenausgaben BS1, BS3, BS5 und BS7 werden geodert, und umfassen so eine acht Bit Basissilbe, die ungerade Ausgabe BSO von INSTB 20262. Die gerade gezählten Basissilbenausgaben BS0, BS2, BS4 und BS6 von INSTB 20262 werden in ähnlicher Weise geodert und umfassen eine acht Bit Basissilbe, die gerade Ausgabe BSE. Zu jeder Zeit werden eine ungeradzahlige Basissilbenausgabe und eine geradzahlige Basissilbenausgabe von INSTB 20262 als Eingaben für den PARSER 20264 durch die Aktivierungs- und Selektionssignale Instruktionspuffer lesen und aktivieren (IBORE) ausgewählt, die INSTB 20262 durch IBSDECR 24114 zur Verfügung gestellt werden. IBSDECR 24114 enthält Dekodierschaltlogik. Der Eingang von IBSDECR 24114's Dekodierlogik umfaßt drei Bits (RCPC (26-28)), die von CPCMUX 24118 zur Verfügung gestellt werden. Wie in Fig. 241 angedeutet, kann CPC (26-28) von den JPD-Bus 10142-Bits 25 bis 28 oder vom Ausgang von CPCALU 24120 zur Verfügung gestellt werden. Eine Eingabe für CPCALU 24120 ist CPC (26-28) von CP 20270. Der Betrieb von CPC 20270 und CPC 20270's assoziierter Schaltlogik wird unten weiter beschrieben. RCPC (26-28) wird von IBSBECR 24114 dekodiert, um IBORE (0-7) für INSTB 20262 zu erzeugen. RCPC 26 und RCPC 27 werden dekodiert, um eine der vier ungeradzahligen Basissilbenausgaben (das sind BS1, BS3, BS5 und BS7) von INSTB 20262 als ungeradzahlige Basissilbeneingaben für PARSER 20264 auszuwählen. RCPC 28 wählt entweder die vorangehende oder die folgende geradzahlige Basissilbenausgabe von INSTB 20262 als geradzahlige Basissilbeneingabe für PARSER 20264. Die acht dekodierten Bits von IBORE (0-7), die von IBDECR 24114's Dekodierlogik erzeugt wurden, werden in das acht Bit-Register von IBDECR 24114 geladen und nachfolgend INSTB 20262 als IBORE (0-7) zur Verfügung gestellt.
PARSER 20264 wählt BSO oder BSE oder beide als Ausgabe von PARSER 20264 für den NAME-Bus 20224 oder für OPCODEREG 20268. Im Falle einer SOP oder einer acht Bit Namenssilbe wählen entweder BSO oder BSE als Ausgabe von PARSER 20264 aus. Im Falle einer 12 oder 16 Bit Namenssilbe werden sowohl BSO als auch BSE als Ausgabe von PARSER 20264 ausgewählt. POARSER 20264's Betrieb wird durch die Mikrobefehlssteuerungsausgaben von FUSITT 11012 gesteuert.
Die Programmzähler IPC 20272, EPC 20274 und CPC 20270 sind mit der Steuerung des Aufnehmens und des Analysierens von SINs assoziiert. Im allgemeinen arbeiten IPC 20272, EPC 20274 und CPC 20270 unter der Mikrobefehlskontrolle von FUSITT 11012.
CPC 20270 ist der gegenwärtige Programmzähler und beinhaltet 28 Bits, die auf die gegenwärtige Silbe in INSTB 20262 zeigen. Die Bits 29 bis 31 von CPC 20270 sind nicht vorgesehen, daher sind die Bits 29 bis 31 der Ausgabe von CPC 20270 Null, was Bytegrenzen für die SOPs garantiert. Die Inhalte von CPC 20270 sind daher auch Zeiger, und sind Byte-ausgerichtete Abstände in dem gegenwärtigen Prozedurobjekt. Der Anfangsprogrammzähler (IPC) 20272 ist ein Pufferregister, das mit dem Ausgang von CPC 20270 verbunden ist und für die Zeitüberlappung vorgesehen ist. IPC 20272 kann nur von CPC 20270 geladen werden, das, wie oben beschrieben wurde, 29 Bits breit ist, und die Bits 29, 30 und 31, die in IPC 29272 auf Null gesetzt werden, nicht beinhaltet. IPC 20272 kann auf den JPD-Bus 10142 als Startwert in einer unbedingten Verzweigung gelesen werden.
EPC 20274 ist ein 32 Bit-Register, das gewöhnlich einen Zeiger auf den gegenwärtig ausgeführten SOP enthält. Wenn eine SOP-Verzweigung auftritt, zeigt der Zeiger in EPC 20274 auf das SOP, von dem die Verzweigung ausgeführt wurde. Der Zeiger, der sich in EPC 20274 befindet, ist ein Abstand in das gegenwärtige Prozedurobjekt. EPC 20274 kann nur von IPC 20272 geladen werden und kann auf den JPD-Bus 10142 gelesen werden.
Indem wir uns wieder auf CPC 20270 beziehen, so ist CPC 20270, wie oben beschrieben, ein Zähler für die gegenwärtigen Silben. CPC 20270 enthält einen Zeiger auf die nächste SOP-Silbe oder Basissilbe, die von PARSER 20264 analysiert werden soll. Da SOPs immer auf Bytegrenzen liegen, ist der CPC 20270-Zeiger 29 Bits breit, CPC (0-28). Die drei niedrigen Bits des CPC 20270-Zeigers, d. h. CPC (29-31) existieren physikalisch gar nicht und werden immer als Null angenommen. Dadurch zeigt CPC 20270's Zeiger auf die nächste Befehlssilbe, die analysiert werden soll, immer auf Bytegrenzen.
Die CPC 20270 Bits 26 bis 28, CPC (26-28), zeigen, wie es oben beschrieben wurde, eine bestimmte Basissilbe in INSTB 20262 an. Die Bits 0 bis 25 (CPC (0-25)) von CPC 20270 zeigen 32 Bit-Worte, die in INSTB 20262 als IBW0 und IBW1 gelesen wurden, einer Abfolge von SINs an. Der CPC 20270-Zeiger wird jedesmal aktualisiert, wenn eine Analysieroperation ausgeführt wird, die eine Basissilbe von INSTB 20262 liest. Wie oben beschrieben, werden diese Analysieroperationen unter Mikrobefehlskontrolle von FUSITT 11012 durchgeführt.
CPC 20270 ist vom Konzept her ein 26 Bitzähler, der CPC (0-25) mit einem drei Bit- Register enthält, das als CPC (26-28) an die niederrangige Seite angehängt ist. Es wird diese Organisation benutzt, weil CPC (26-28) die von INSTB 20262 analysierten Basissilben zählt und abhängig von der gegenwärtigen Namenssilbengröße K, die in CSSR 24112 gespeichert ist, inkrementiert werden. CPC (0-25) zählt jedoch aufeinander folgende 32 Bit-Worte einer SIN-Abfolge und kann daher als Binärzähler implementiert werden. Wie in Fig. 241 gezeigt, kann CPC (26-28) vom Ausgang von CPCMUX 24118 geladen werden. Ein erster Eingang von CPCMUX 24118 ist mit den Bits 29 bis 31 des JPD- Busses 10142 verbunden. Dieser Eingang zu CPC (26-28) vom JPD-Bus 10142 ist dafür vorgesehen, daß CPC 20270 vom JPD-Bus 10142 geladen werden kann, z. B. wenn CPC 20270 mit einem Anfangszeigerwert geladen wird. Der zweite Eingang von CPCMUX 24118 kommt vom Ausgang von CPCALU 24120 und ist der Pfad, durch den CPC (26- 28) inkrementiert wird, wenn aufeinander folgende Basissilben von INSTB 20262 analysiert werden. Ein erster Eingang von CPCALU 24120 ist CPC (26-28) von CPC 20270. Der zweite Eingang von CPCALU 24120 ist ein zweifacher Eingang von CSSR 24112. Der erste Eingang von CSSR 24112 ist auf der am wenigsten signifikanten Bitposition logisch 1, d. h. auf der Position, die CPC (28) entspricht. Dieser Eingang wird benutzt, wenn einzelne Basissilben von INSTB 20262 analysiert werden, z. B. in einer acht Bit SOP oder einer acht Bit Namenssilbe. CSSR 24112's erster Eingang nach CPCALU 24120 inkrementiert CPC (0-32) um acht, d. h. einer für CPC (26-28), jedesmal wenn eine Einzelbasissilbe von INSTB 20262 analysiert wird. Der zweite Eingang zu CPCALU 24120 von CSSR 24112 ist K, das ist die gegenwärtige Namenssilbengröße. Wie oben beschrieben wurde, kann K 8,12 oder 16 sein. CPC (26-28) wird daher um eins inkrementiert, wenn K gleich 8 ist, und wird um zwei inkrementiert, wenn K 12 oder 16 ist. Wie in Fig. 241 gezeigt, wird K vom JPD-Bus 10142 in CSSR 24112 geladen.
CPC (0-25) arbeitet, wie oben beschrieben, als ein 26 Bitzähler, der jedesmal, wenn CPC (26-28) überläuft, inkrementiert wird. CPC (0-25) wird um die Übertragsausgabe von CPCALU 24120 inkrementiert. In der aktuellen Implementierung ist CPC 20270 organisiert, um die Anzahl der benötigten integrierten Schaltkreise zu reduzieren. CPC (1-25) ist als Zähler konstruiert, und die Eingaben des Zählers CPC (1-25) sind mit den Bits 1 bis 24 vom JPD-Bus 10142 verbunden, um ein Laden eines Anfangswertes des CPC 20270- Zeigers zu ermöglichen. CPC (0) und CPC (26-28) sind als vier Bit-Register implementiert. Der Betrieb der CPC (26-28)-Bereiche dieses Registers ist oben beschrieben worden. Der Eingang des CPC (0)-Bereichs dieses Registers ist mit dem Ausgang von CPCOS 24116 verbunden. CPCOS 24116 ist ein Multiplexer, der einen ersten Eingang hat, der mit Bit 0 vom JPD-Bus 10142 verbunden ist. Dieser Eingang vom JPD-Bus 10142 wird z. B. benutzt, wenn CPC 20270 mit einem Anfangszeigerwert geladen wird. Der zweite Eingang des CPCOS 24116 ist die Überlaufausgabe des CPC (1-25)-Zählers und erlaubt dem CPC 0-Bereich des vier Bit-Registers und dem CPC (1-25)-Zählers, als 26 Bitzähler zu arbeiten.
Schließlich kann, wie in Fig. 241 gezeigt, die Ausgabe von CPC 20270 in IPC 20272 geladen werden. Ein anfänglicher CPC 20270-Zeigerwert kann daher von JPD-Bus 10142 in CPC 20270 geschrieben werden und nachfolgend in IPC 20272 kopiert werden.
Indem wir wieder auf PARSER 20264 Bezug nehmen, so liest PARSER 20264, wie oben beschrieben oder analysiert, die Basissilben von INSTB 20262 zum NAME-Bus 20224. Der Eingang des PARSER 20264 ist ein 16 Bit-Wort, das eine acht Bit ungeradzahlige Basissilbe, BSO, und eine acht Bit geradzahlige Basissilbe, BSE, umfaßt. Je nachdem, ob PARSER 20264 gerade eine acht Bit SOP analysiert, oder eine acht Bit Namenssilbe oder eine 12 Bit Namenssilbe oder eine 16 Bit Namenssilbe, kann PARSER 20264 BSO, BSE oder beide als Ausgabe auf den NAME-Bus 20224 wählen.
Wenn PARSER 20264 Namenssilben analysiert und K nicht gleich 8 ist, d. h. entweder 12 oder 16 ist, so transferiert PARSER 20264 sowohl BSO als auch BSE auf den NAME-Bus 20224 und bestimmt, ob BSO oder BSE signifikanter sind. Die Entscheidung, ob BSO oder BSE signifikanter ist, wird von CPC (28) bestimmt. Wenn CPC (28) anzeigt, daß BSO am signifikantesten ist, so wird BSO auf den NAME-Bus 20224 in die Bits 0 bis 7 (NAME (0-7)) transferiert und BSE auf den NAME-Bus 20224 in die Bits 8 bis 15 (NAME (8-15)). Wenn CPC (28) anzeigt, daß BSE am signifikantesten ist, dann wird BSE auf NAME (0-7) und BSO auf NAME (8-15) transferiert. Diese Operation stellt sicher, daß Namenssilben auf dem NAME-Bus 20224 so angeordnet werden, wie sie im SIN-Strom auftreten.
Wenn PARSER 20264 Namenssilben der Silbengröße K = 8 analysiert, so wählt PARSER 20264 entweder BSO oder BSE, wie es von CPC (28) angezeigt wird, als Ausgabe für NAME (0-7). PARSER 20264 plaziert Nullen auf NAME (8-15).
Wenn PARSER 20264 SOPs von acht Bits analysiert, so wählt PARSER 20264 entweder BSO oder BSE als Ausgabe für NAME (0-7) aus, wie es von CPC (28) selektiert wurde. PARSER 20264 plaziert Nullen auf NAME (8-15). Gleichzeitig erzeugt PARSER 20264 OPREGE für OPCODEREG 20268, um den Transfer von NAME (0-7) nach OPCODE- REG 20268 zu aktivieren. OPCODEREG 20268 wird nicht geladen, wenn PARSER 20264 Namenssilben analysiert. Die Mikrobefehlseingabe von FUSITT 11012, die den Betrieb des PARSER 20264 steuert, bestimmt auch, ob PARSER 20264 ein SOP oder eine Namenssilbe analysiert, und steuert die Erzeugung von OPREGE.
Der Betrieb von NC 10226, der Namenssilben als Adreßeingaben vom NAME-Bus 20224 empfängt, wurde oben im Zusammenhang mit MEMINT 20212 besprochen. Die Namensfalle (NT) 20254 ist mit dem NAME-Bus 20224 verbunden, um Namenssilben zu empfangen und aufzunehmen, die von PARSER 20264 auf den NAME-Bus 20224 geschickt worden sind. Auch der Betrieb von NT 20254 wurde oben im Zusammenhang mit MEMINT besprochen.

b.b.b. Zugriffseinheitenaufteilungstabelle 11010, Ausführungseinheitenaufteilungstabelle 20266 und Operationscoderegister 20268 (Fig. 242)

Wie oben beschrieben, ist CS 10110 eine Mehrsprachenmaschine. Jedes Programm, das in einer Hochsprache programmiert wurde, wird in ein entsprechendes S-Sprachenprogramm kompiliert, das S-Spracheninstruktionen enthält, die als SOPs bezeichnet werden. CS 10110 stellt einen Satz oder ein Dialekt von Mikrocodeinstruktionen, die als S-Interpreter (SINTs) bezeichnet werden, für jede S-Sprache zur Verfügung. Die SINTs interpretieren die SOPs, um entsprechende Abfolgen von Mikrobefehlen für die genaue Steuerung der CS 10110-Operationen bereitzustellen. CS 10110's SINTs für FU 10120- und EU 10122- Operationen werden in FUSITT 11012 bzw. in einem entsprechenden Steuerspeicher in EU 10122 gespeichert, der in der folgenden Beschreibung von EU 10122 beschrieben wird. Jeder SINT umfaßt eine oder mehrere Abfolgen von Mikrobefehlen, wobei jede Mikrobefehlsabfolge einem bestimmten SOP in einem S-Sprachendialekt entspricht. Die Zugriffseinheit S-Interpreter-Aufteilungstabelle (FUSDT) 11010 und die Ausführungseinheit S-Interpreter-Aufteilungstabelle (EUSDT) 20266 enthalten für jeden S-Sprachendialekt einen S-Interpreter-Aufteiler (SD). Jeder SD umfaßt einen Satz SD-Zeiger (SDPs), wobei jeder SDP in einem bestimmten SD einem bestimmten SOP dieses SD-Dialekts entspricht. Jeder SDP ist eine Adresse, die auf eine Lokation in FUSITT 11012 oder EUSITT verweist, und zwar an den Anfang der entsprechenden Mikrobefehlsabfolge für die Interpretation des SOP, der jenem SDP entspricht. Wie weiter unten besprochen werden wird, werden die SOPs, die in OPCODEREG 20268 empfangen und gespeichert werden, dazu benutzt, Adressen in FUSDT 11010 und EUSDT 20266 zu erzeugen, um entsprechende SDPs auszuwählen. Jene SDPs werden dann durch ADR 20202 FUSITT 11012 zur Verfügung gestellt, oder EUSITT über den EUDIS-Bus 20206, um entsprechende Mikrobefehlsabfolgen von FUSITT 11012 und EUSITT auszuwählen.
In Fig. 242 wird ein genaueres Blockdiagramm von OPCODEREG 20268, FUSDT 11010 und EUSDT 20266 gezeigt. Wie daraus hervorgeht, umfaßt OPCODEREG 20268 ein OP- Codepufferregister (LOPCODE) 24210, ein Dialektregister (RDIAL) 24212, ein Ladeadressenregister (LADDR) 24214 und einen Zugriffseinheitsaufteilungskodierer (FUDISENC) 24216. Die Dateneingänge von LOPCODE 24210 sind mit dem NAME-Bus 20224 verbunden, um SOPs, die von INSTB 20262 analysiert wurden, zu empfangen. Die Ladeeingänge von RDIAL 24212 sind mit den Bits 28 bis 31 des JPD-Busses 10142 verbunden. Die Ausgänge von LOPCODE 24210, RDIAL 24212 und LADDR 24214 sind mit den Eingängen von FUDISENC 24216 verbunden. Die Ausgänge von FUDISENC 24216 sind mit den Adreßeingängen von FUSDT 11010 und EUSDT 20266 verbunden.
FUSDT 11010 umfaßt die Zugriffseinheitsaufteilungsdatei (FUDISF) 24218 und die Algorithmusdatei (AF) 24220. Die Adreßeingänge von FUDISF 24218 und AF 24220 sind, wie oben beschrieben, mit den Adreßausgängen von FUDISENC 24216 verbunden. Die Datenladeeingänge von FUDISF 24218 und AF 24220 sind mit den Bits 10 bis 15 bzw. den Bits 16 bis 31 vom JPD-Bus 10142 verbunden. Die SDP-Ausgaben von FUDISF 24218 und AF 24220 sind mit den ADR-Bussen 20202 verbunden.
EUSDT 20266 umfaßt die Ausführungseinheitaufteilungsdatei (EUDISF) 24222 und den Ausführungseinheitsaufteilungswähler (EUDISS) 24224. Die Adreßeingänge von EUDISF 24222 sind, wie oben beschrieben, mit den Ausgängen von FUDISENC 24216 verbunden. Die Datenladeeingänge von EUDISF 24222 sind mit den Bits 20 bis 31 des JPD-Busses 10142 verbunden. Die Eingänge von EUDISS 24224 sind mit dem SDP-Ausgang von EUDISF 24222, den Bits 20 bis 31 des JPD-Busses 10142 und mit dem Mikrocodeliteralausgang (mLIT) von FUSITT 11012 verbunden. Die SDP-Ausgänge von EUDISS 24224 sind mit dem EUDIS-Bus 20206 verbunden.
Wie oben beschrieben, stellt OPCODEREG 20268 Adressen, die von SOPs generiert wurden, die in OPCODEREG 20268 geladen wurden, FUSDT 11010 und EUSDT 20266 zur Verfügung, um SDPs auszuwählen, die als Adreßeingänge für FUSITT 11012 und EUSITT dienen sollen. LOPCODE 24210 empfängt und speichert acht Bit SOPs, die von INSTB 20262, wie oben beschrieben, analysiert wurden. OPCODEREG 20268 stellt auch FUSDT 11010 und EUSDT 20266 Adressen zur Verfügung, um FUSDT 11010 und EUSDT 20266 mit SDs für S-Sprachendialekte zu laden, die gegenwärtig von CS 10110 benützt werden. LOPCODE 24210 und RDIAL 24212 stellen, wie oben beschrieben, FUSDT 11010 und EUSDT 20266 Adressen zur Verfügung, wenn SOPs in SDPs übersetzt werden, und ADDR 24214 stellt Adressen zur Verfügung, wenn FUSDT 11010 und EUSDT 20266 mit SDs geladen werden.
Indem wir uns zuerst auf LADDR 24214 beziehen, so hat LADDR 24214 einen acht Bitzähler. Von LADDR 24214 werden FUSDT 11010 und EUSDT 20266 nur dann Adressen zur Verfügung gestellt, wenn FUSDT 11010 und EUSDT 20266 gerade mit SDs geladen werden, das sind Gruppen von SDPs für S-Sprachendialekte, die gerade von CS 10110 benutzt werden. Während dieser Operation wird der Ausgang von LADDR 24214 für FUSDT 11010 und EUSDT 20266 durch Mikrocodesteuersignale (die aus Übersichtlichkeitsgründen nicht gezeigt sind) von FUSITT 11012 zugänglich gemacht. Die Auswahl zwischen FUDISF 24218, AF 24220 und EUDISF 24222 für den Adressenempfang wird in ähnlicher Weise durch Mikrobefehlsaktivierungssignale (aus Übersichtlichkeitsgründen auch nicht gezeigt) besorgt, die von FUSITT 11012 zur Verfügung gestellt werden. Diese FUSDT 11010- und EUSDT 20266-Adreßaktivierungseingaben können jederzeit beliebig unter FUDISF 24218, AF 24220 oder EUDISF 24222 auswählen, um Adreßeingaben zu empfangen. SDPs, die in FUDISF 24218, AF 24220 und EUDISF 24222 geladen werden sollen, werden von den Bits 10 bis 15 (JPD (10-15)), den Bits 16 bis 31 (JPD (16-31)) und den Bits 20 bis 31 (JPD (20-31)) des JPD-Busses 10142 zur Verfügung gestellt. Die Inhalte der Adressen von LADDR 24214 werden sukzessive um eins inkrementiert, wenn jeweils sukzessive SDPs in FUSDT 11010 und EUSDT 20266 geladen werden. Die Inkrementierung von LADDR 24214 wird wiederum von Mikrobefehlssteuereingaben von FUSITT 11012 gesteuert.
Die Adreßeingaben für FUSDT 11010 und EUSDT 20266 werden während der Interpretation von SOPs von LOPCODE 24210 und RDIAL 24212 zur Verfügung gestellt. LOPCODE 24210 ist ein Registerzähler, der, wie oben beschrieben, Dateneingänge hat, die mit dem NAME-Bus 20224 verbunden sind, um SOPs vom PARSER 20264 zu empfangen. In einer ersten Betriebsart kann LOPCODE 24210 als Pufferregister arbeiten, das zu einem Zeitpunkt mit einem SOP vom Ausgang des PARSER 20264 geladen wird. In einer zweiten Betriebsart kann LOPCODE 24210 als ein Taktregister arbeiten, um sukzessive acht Biteingaben von den niedrigrangigen acht Bits des NAME-Busses 20224 (NAME (8-15)) zu empfangen. Das Laden von LOPCODE 24210 wird durch Mikrobefehlssteuerausgaben (aus Übersichtlichkeitsgründen nicht gezeigt) von FUSITT 11012 gesteuert.
Wie unten weiter beschrieben wird, werden die acht Bit SOPs, die in LOPCODE 24210 gespeichert sind, mit der Ausgabe von RDIAL 24212 verkettet, um FUSDT 11010 und EUSDT 20266 Adressen zur Verfügung zu stellen, um die SDPs auszuwählen, die bestimmten SOPs entsprechen. Jener Bereich dieser Adressen, die von LOPCODE 24210 zur Verfügung gestellt werden, das sind die acht Bit SOPs, wählt bestimmte SDPs innerhalb eines bestimmten SDs aus. Bestimmte SDs werden durch jenen Bereich dieser Adressen ausgewählt, der von den Inhalten von RDIAL 24212 zur Verfügung gestellt wird.
RDIAL 24212 empfängt und speichert vier Bit Dialektcode, die den bestimmten S- Sprachendialekt anzeigen, der gerade von CS 10110 benutzt wird, und die SOPs eines Benutzerprogramms ausführt. Diese vier Bit Dialektcodes werden vom JPD-Bus 10142 als JPD (28-31) zur Verfügung gestellt. Das Laden von RDIAL 24212 mit den vier Bit Dialektcodes wird durch Mikrobefehlssteuersignale kontrolliert, die von FUSITT 11012 zur Verfügung gestellt werden (aus Übersichtlichkeitsgründen nicht gezeigt).
Die vier Bit Dialektcodes in RDIAL 24212 definieren Teilbereiche in FUDISF 24218, AF 24220 und EUDISF 24222. Jeder Teilbereich beinhaltet SDPs für die verschiedenen S- Sprachendialekte, d. h. enthält einen anderen SD. FUDISF 24218, AF 24220 und EUDISF 24222 können z. B. acht 128-Wortteilbereiche oder vier 256-Wortteilbereiche enthalten. Ein einzelnes Bit des Dialektcodes, z. B. Bit 3, definiert, ob FUDISF 24218, AF 24220 und EUDISF 24222 vier oder acht Teilbereiche enthalten. Wenn FUSDT 11010 und EUSDT 20266 vier Teilbereiche enthalten, werden die zwei signifikantesten Bits der Adresse in FUSDT 11010 und EUSDT 20266 von den Dialektcodebits 1 und 2 zur Verfügung gestellt und bestimmen, welcher Teilbereich adressiert wird. Die niedrigrangigen acht Bits der Adresse von LOPCODE 24210 zur Verfügung gestellt und bestimmen, welches Wort in einem gewählten Teilbereich adressiert wird. Wenn FUSDT 11010 und EUSDT 20266 acht Teilbereiche enthalten, werden die drei signifikantesten Bits der Adresse in FUSDT 11010 und EUSDT 20266 von den Bits 0 bis 2 des Dialektcodes zur Verfügung gestellt, um einen bestimmten Teilbereich zu wählen, und die unteren sieben Bits der Adresse werden von LOPCODE 24210 zur Verfügung gestellt, um ein bestimmtes Wort im ausgewählten Teilbereich zu selektieren.
Wie oben beschrieben, wird die acht Bit-Ausgabe von LOPCODE 24210 und die vier Bit- Ausgabe von RDIAL 24212 miteinander durch FUDISENC 24216 verkettet, um eine zehn Bit-Adreßeingabe für FUSDT 11010 und EUSDT 20266 zur Verfügung zu stellen. FUDISENC 24216 ist ein Kodierkreis und wird weiter unten im Zusammenhang mit FUDISF 24218 beschrieben. Wie oben beschrieben, wird die Auswahl von FUDISF 24218, AF 24220 und EUDISF 24222, um Adreßeingaben von RDIAL 24212 und LOPCODE 24210 zu empfangen, durch Mikrobefehlssteueraktivierungseingaben gesteuert, die von FUSITT 11012 (aus Übersichtlichkeitsgründen nicht gezeigt) zur Verfügung gestellt werden.
Indem wir auf FUSDT 11010 Bezug nehmen, stellen sowohl FUDISF 24218 als auch AF 24220 FUSITT 11012 SDPs zur Verfügung, aber für verschiedene Zwecke. Allgemein kann man Mikrobefehlssteueroperationen in zwei Klassen unterteilen. Erstens gibt es jene Mikrobefehlsoperationen, die generisch sind, d. h. allgemeiner Natur, und die von einer großen Vielzahl von SOPs eines bestimmten Dialekts oder sogar mehrerer Dialekte genutzt oder angewendet werden. Ein Beispiel dieser Klasse von Mikrobefehlsoperationen ist der Zugriff auf Operandenwerte. FUDISF 24218 stellt SDPs für diese Klasse von Mikrobefehlsoperationen zur Verfügung. Wie unten beschrieben, ist FUDISF 24218 ein Speicher schnellen Zugriffs, der es einer einzelnen Mikrobefehlssteuerungsausgabe von FUSITT 11012 erlaubt, ein SOP von INSTB 20262 in LOPCODE 24210 zu analysieren, und FUDISF 24218 einen entsprechenden SDP zur Verfügung stellen läßt. Das heißt, ein SOP dieser generischen Klasse kann von INSTB 20262 analysiert werden und ein entsprechender SDP kann von FUDISF 24218 während eines einzigen Systemtaktes zur Verfügung gestellt werden. Der Betrieb von SUDISF 24218 vergrößert daher die Betriebsgeschwindigkeit von JP 10114, und zwar insbesondere beim Beginn der Ausführung neuer SOPs.
Die zweite Klasse der Mikrobefehlsoperationen sind jene, die spezifisch zu bestimmten SINTs oder zu bestimmten Gruppen von SINTs gehören. Diese Gruppen von SINTs können gänzlich innerhalb eines speziellen Dialektes, z. B. FORTRAN, sein oder können innerhalb eines oder mehrerer Dialekte existieren. SDPs für diese Klasse von Mikrobefehlsoperationen werden von AF 24220 zur Verfügung gestellt. Wie unten beschrieben wird, ist AF 24220 langsamer, aber größer als FUDISF 24218. Im allgemeinen enthält AF 24220 Mikrobefehlsabfolgen, die spezifisch sind für bestimmte SINTs. Im allgemeinen werden generische Mikrobefehlsoperationen vor jenen Operationen, die spezifisch für bestimmte SINTs sind, ausgeführt, so daß SDPs von AF 24220 zu einem späteren Zeitpunkt verlangt werden als jene von FUDISF 24218. SDPs für spezifische SINT- Operationen können daher ohne Einbuße an Ausführungsgeschwindigkeit der SOPs von dem langsameren AF 24220 zur Verfügung gestellt werden.
Indem wir wieder auf FUDISF 24218 Bezug nehmen, so ist FUDISF 24218 ein 1024 Wort mal sechs Bit bipolarer Speicher schnellen Zugriffs. Jedes Wort, was darin enthalten ist, ist, wie oben beschrieben, ein SDP oder eine Anfangsadresse auf eine entsprechende Mikrobefehlsabfolge in FUSITT 11012. Wie weiter unten beschrieben wird, ist FUSITT ein 8K (8192)-Wortespeicher. SDPs, die von FUDISF 242.18 zur Verfügung gestellt werden, sind jeweils, wie oben beschrieben, sechs Bits breit und können daher eine begrenzte, 32 Wortfläche des Adreßraums von FUSITT 11012 adressieren. FUDISF 24218 ist imstande, FUSITT 11012 SDPs durch Mikrobefehlssteuersignale (die aus Übersichtlichkeitsgründen nicht gezeigt werden) von FUSITT 11012 zur Verfügung zu stellen. Die sechs Bit SDPs von FUDISF 24218 werden von FUDISENC 24216 kodiert, um FUSITT 11012's Adreßraum in Inkrementen von vier Mikrobefehlen zu adressieren, d. h. in Inkrementen von vier Adreßlokationen. Die SDPs von FUDISF 24218 adressieren daher auf einmal vier Mikrobefehle von FUSITT 11012's Mikrobefehlsabfolgen. Wie weiter unten beschrieben wird, erzeugt mPC 20276 aufeinander folgende Mikrobefehlsadressen für FUSITT 11012, um aufeinander folgende Mikrobefehle einer Abfolge auszuwählen, die sich anschließt an einen anfänglichen Mikrobefehl, der von FUSDT 11010 durch ein SDP selektiert wurde. Ein SDP von FUDISF 24218 wählt daher den ersten Mikrobefehl aus einem Block von vier Mikrobefehlen aus, und mPC 20276 wählt die folgenden drei Mikrobefehle aus jener Abfolge von vier Mikrobefehlen aus. Eine Abfolge von vier Mikrobefehlen kann daher an einem Stück oder sequentiell für jeden FUDISF 24218 SDP ausgeführt werden, der als Antwort auf einen generischen SOP zur Verfügung gestellt wurde. FUDISENC 24216 kodiert die sechs Bit SDPs von FUDISF 24218, um diese Abfolgen aus vier Mikrobefehlen auszuwählen, so daß das am wenigsten signifikante Bit dieser SDPs das 24. Bit der FUSITT 11012-Adreßeingänge besetzt usw. Die zwei am wenigsten signifikanten Bits einer FUSITT 11012-Adresse oder SDP, die von FUDISF 24218 zur Verfügung gestellt werden, werden auf Null gesetzt, während das neunte und höhere Bits fest verdrahtet werden können, um jedem beliebigen Block von 128 Adressen in FUSITT 11012 zu definieren. Diese feste Verdrahtung der signifikantesten Bits der FUSITT 11012-Adressen von FUDISF 24218 erlaubt, einen Satz von generischen Mikrobefehlsabfolgen von FUDISF 24218 wählen zu lassen, so daß sie wie gewünscht innerhalb FUSITT 11012's Adreßraum lokalisiert werden können. FUDISENC 24216 umfaßt einen Satz Treiberverknüpfungsglieder.
Wie oben beschrieben, werden die SDPs für generische Mikrobefehle, die gerade von CS 10110 bei der Ausführung eines Benutzerprogramms benutzt werden, in FUDISF 24218 von den Bits 10 bis 15 des JPD-Busses 10142 (JPD (10-15)) geschrieben. Adressen für das Laden von SDPs in FUDISF 24218 werden, wie oben beschrieben, von LADDR 24214 zur Verfügung gestellt. LADDR 24214 ist fähig, Ladeadressen zur Verfügung zu stellen, und FUDISF 24218 ist dazu imstande, mit Mikrobefehlssteuersignalen (aus Übersichtlichkeitsgründen nicht gezeigt) beschrieben zu werden, die von FUSITT 11012 zur Verfügung gestellt werden.
Sich auf AF 24220 beziehend, ist AF 24220, wie oben beschrieben, von größerer Kapazität als FUDISF 24218, hat aber eine längere Zugriffszeit. AF 24220 ist ein 1024 Worte mal 15 Bit Speicher. Im allgemeinen werden zwei Systemtakte dazu benötigt, um ein DSP von AF 24220 zu erhalten. Während des ersten Systemtaktes wird ein SOP in LOPCODE 24210 geladen und während des zweiten Systemtaktes wird AF 24220 adressiert, um einen entsprechenden SDP zur Verfügung zu stellen. SDPs, die von AF 24220 zur Verfügung gestellt werden, sind jeweils 15 Bits breit und daher dazu imstande, größere Adreßräume zu adressieren als jene von FUSITT 11012. Wie oben beschrieben, ist FUSITT 11012 ein 8K-Wortspeicher. Wenn FUSITT 11012 durch ein AF 24220-SDP adressiert wird, das eine Adreßlokation außerhalb des Adreßraums von FUSITT 11012 referenziert, erzeugt FUSITT 11012 eine Mikrobefehlsausgabe nicht im Steuerspeicher für EVENT 20284, wie es oben beschrieben wurde. Ein AF 24220-SDP, der aus diesem Ereignis resultiert, wird dann dazu benutzt, bestimmte Mikrobefehlsabfolgen zu adressieren, die in MEM 10112 gespeichert sind. Diese Mikrobefehle werden dann von MEM 10112 ausgeführt und nicht von FUSDT 11010. Diese Operation erlaubt es bestimmten Mikrobefehlsabfolgen, z. B. selten genutzte Mikrobefehlsabfolgen, in MEM 10112 zu bleiben, und befreit so die Adreßräume von AF 24220 und FUSITT 11012 von häufiger benutzten SOPs.
Wie oben beschrieben, wird AF 24220 mit SDPs für SINTs, die gerade von CS 10110 bei der Ausführung von Benutzerprogrammen benutzt werden, von den Bits 16 bis 31 des JPD-Busses 10142 (JPD (16-31)) geladen. Wie oben ebenfalls besprochen, werden Adressen, um SDPs in AF 24220 zu laden, von LADDR 24214 zur Verfügung gestellt. LADDR 24214 ist imstande, Ladeadressen zu liefern, und AF 24220 ist imstande, SDPs durch Mikrobefehlssteuersignale (die aus Übersichtlichkeitsgründen nicht gezeigt werden), die von FUSITT 11012 zur Verfügung gestellt werden, zu empfangen.
Indem wir schließlich auf EUSDT 20266 Bezug nehmen, so kann EU 10122 von drei Quellen mit SDPs versorgt werden. Die EU 10122-SDPs gönnen von EUDISF 24222, vom JPD-Bus 10142 oder von Literalfeldern von Mikrobefehlen, die von FUSITT 11012 bereitgestellt werden, zur Verfügung gestellt werden. Die SDPs von EUDISF 24222 sind jeweils zwölf Bit breit und umfassen neun Bit für Adressen in EUSITT und drei Bits für Informationen über das Operandenformat.
EUDISF 24222 ist ein 1024 Wort mal 12 Bit Speicher. Wie oben besprochen, werden Adressen, um SDPs von EUDISF 24222 zu lesen, von OPCODEREG 20268 zur Verfügung gestellt, indem es einen vier Bit Dialektcode von RDIAL 24212 und einen acht Bit-SOP von LOPCODE 24210 miteinander verkettet. Von EUDISF 24222 zur Verfügung gestellte SDPs werden als erste Eingabe nach EUDISS 24224 bereitgestellt.
EUDISS 24224 ist ein Multiplexer. Wie eben beschrieben, sind die SDPs von EUDISF 24222 die erste Eingabe für EUDISS 24224. Eine zweite zwölf Bit-Eingabe von EUDISS 24224 wird von den Bits 20 bis 31 des JPD-Busses 10142 (JPD (20-31)) zur Verfügung gestellt. Eine dritte Eingabe von EUDISS 24224 ist eine zwölf Bit-Eingabe, die von einem Literalfeld einer FUSITT 11012-Mikrobefehlsausgabe zur Verfügung gestellt wird. EUDISS 20224 wählt von diesen drei Eingaben eine aus, die auf den EUDIS-Bus 20206 transferiert werden soll, um als Ausführungseinheits-SDP für EUSITT zur Verfügung gestellt zu werden. Die Auswahl zwischen den Eingaben von EUDISS 20224 wird durch Mikrobefehlssteuersignale (aus Übersichtlichkeitsgründen nicht gezeigt) von FUSITT 11012 zur Verfügung gestellt.
Wie oben beschrieben, wird EUDISF 24222 von den Bits 20 bis 31 des JPD-Busses 10142 (JPD (20-31)) mit SDPs für S-Sprachendialekte, die gegenwärtig gerade von CS 10110 benutzt werden, geladen. Adressen zur Ladung von SDPs in EUDISF 24222 werden, wie oben beschrieben, von LADDR 20214 zur Verfügung gestellt. FUSITT 11012 stellt Aktivierungssignale (aus Übersichtlichkeitsgründen nicht gezeigt) für LADDR 24214 und EUDISF 24222 zur Verfügung, um das Schreiben von SDPs nach EUDISF 24222 zu aktivieren.
Die Struktur und der Betrieb der Schaltlogik von FUCTL 20214 für den Zugriff auf und das Analysieren von SINs von MEM 10112 zur Bereitstellung von Namenssilben und SOPs und für die Interpretation von SOPs, um SDPs für FUSITT 11012 und EUSITT von FUSDT 11010 und EUSDT 20266 zur Verfügung zu stellen, wurde oben beschrieben. Wie oben beschrieben, sind die SDPs, die von FUSDT 11010 und EUSDT 20266 zur Verfügung gestellt werden, Anfangs- oder Startadressen, die auf den ersten Mikrobefehl von Mikrobefehlsabfolgen zeigen. Die Adressen für Mikrobefehle, die jenen anfänglichen Mikrobefehlen folgen, werden von FUCTL 20214's nächste Adresse-Generator-Schaltlogik zur Verfügung gestellt, die mPC 20276, BRCASE 20278, REPCTR 20280 und PNREG 20282, EVENT 20284 und SITTNAG 20286 beinhalten kann. mPC 20276, BRCASE 20278, REPCTR 20280 und PNREG 20282 und SITTNAG 20286 sind hauptsächlich damit betraut, während der Ausführung von Mikrobefehlsfolgen als Antwort auf SOPs die nächsten Adressen zu erzeugen, und werden unten beschrieben. EVENT 20284 und andere Bereiche der FUCTL 20214-Schaltlogik sind eher mit der Erzeugung von Mikrobefehlsabfolgen hinsichtlich CS 10110-interner Mechanismusoperationen betraut und werden in einer späteren Beschreibung beschrieben werden. Auch EU 10122 enthält Schaltlogik für die Erzeugung von nächsten Adressen, und diese Schaltlogik wird in einer folgenden Beschreibung von EU 10122 beschrieben werden.

c. c. c. Der Nächste-Adressen-Generator 24310 (Fig. 243)

Wie oben festgestellt, werden in FU 10120 erste oder Anfangsmikrobefehle der Mikrobefehlsabfolgen zur Interpretation von SOPs von FUSDT 11010 zur Verfügung gestellt. Die darauf folgenden Adressen der Mikrobefehle innerhalb dieser Abfolgen werden im allgemeinen von mPC 20276 und BRCASE 20278 zur Verfügung gestellt. mPC 20276 stellt, wie weiter unten beschrieben wird, sequentielle Adressen zur Auswahl sequentieller Mikrobefehle der Mikrobefehlsabfolgen zur Verfügung. BRCASE 20278 stellt Adressen zur Auswahl von Mikrobefehlen zur Verfügung, wenn eine Mikrobefehlsverzweigungsoperation oder eine Mikrobefehlscaseoperation erforderlich ist. REPCTR 20280 und PNREG 20282 stellen Adressen für das Schreiben oder Laden von Mikrobefehlsabfolgen in FUSITT 11012 zur Verfügung. Andere Bereiche der FUCTL 20214-Schaltlogik, z. B. EVENT 20284, stellt Adressen zur Auswahl von Mikrobefehlsabfolgen zur Verfügung, um Mikrobefehlsabfolgen zur Steuerung des Betriebs der CS 10110-internen Mechanismen auszuwählen. SITTNAG 20286 wählt aus diesen Mikrobefehlsadreßquellen jene Adressen für FUSITT 11012 aus, die erforderlich sind, um die Mikrobefehle der Operation auszuwählen, die gerade von CS 10110 ausgeführt wird.
In Fig. 243 wird ein Ausschnitt aus einem Blockdiagramm von FU 10120's Nächste- Adresse-Generator (NAG) 24310 gezeigt. Über FUSDT 11010 hinaus enthält NAG 24310 mPC 20276, BRCASE 20278, EVENT 20284, REPCTR 20280 und PNREG 20282, einen Teil von RCWS 10358 und SITTNAG 20286. EVENT 2084 ist, wie oben beschrieben, hauptsächlich mit der Ausführung der Mikrobefehlsabfolgen betraut, die CS 10110-interne Mechanismen steuern. EVENT 20284 wird hier nur gezeigt, um seine Beziehungen zu anderen Bereichen von NAG 24310 zu verdeutlichen. EVENT 20284 wird in einer folgenden Beschreibung von FUCTL 20214's Schaltlogik, die die CS 10110-internen Mechanismen steuert, weiter beschrieben werden. In ähnlicher Weise wird der Betrieb von RCWS 10358 teilweise in der vorliegenden Beschreibung von NAG 24310 beschrieben und teilweise in einer folgenden Beschreibung der Steuerung der CS 10110-internen Mechanismen.
Indem wir uns zuerst auf NAG 24310's Struktur beziehen, wurden die Verbindungen zwischen FUSDT 11010, RCWS 10358, mPC 20276, BRCASE 20278, REPCTR 20280, PNREG 20282, EVENT 20284 und SITTNAG 20286 oben mit Bezug auf Fig. 202 beschrieben. NAG 24310's Struktur wird unten nur in den Punkten beschrieben, in denen sich Fig. 243 von Fig. 202 unterscheidet.
Indem wir uns zuerst auf SITTNAG 20286 beziehen, wird SITTNAG 20286 als das EVENT-Verknüpfungsglied (EVNTGT) 24310 und den Nächste-Adressenauswahl- Multiplexer (NASMUX) 24312 umfassend, dargestellt. NASMUX 24312 umfaßt den NAS-Multiplexer A (NASMUXA) 24314, NASMUXB 24316, NASMUXC 24318 und NASMUXD 24320. Die Ausgaben von EVNTGT 24310 und NASMUXA 24314 bis NASMUXD 24320 werden nach CSADR 20204 geodert, um Mikrobefehlsauswahladressen FUSITT 11012 zur Verfügung zu stellen.
ADR 20202 wird in Fig. 243 als neun Busse umfassend, Adresse A (ADRA)-Bus 24322 bis Adresse I (ADRI)-Bus 24338, dargestellt. Der Ausgang des EVENT 20284 ist mit dem Eingang des EVNTGT 24310 über den ADRA-Bus 24322 verbunden. Die Ausgänge von REPCTR 20280 und PNREG 20282 und der Ausgang von AF 24220 sind mit den Eingängen von NASMUXA 24314 über den ADRB-Bus 24324 bzw. den ADRC-Bus 24326 verbunden. Die Ausgänge von RCWS 10358 und FUDISENC 24216 sind mit den Eingängen von NASMUXB 24316 über den ADRD-Bus 24328 bzw. den ADRE-Bus 24330 verbunden. Die Ausgänge von BRCASE 24278 und ein zweiter Ausgang von mPC 20276 sind mit den Eingängen von NASMUXC 24318 über den ADRF-Bus 24332 bzw.
den ADRG-Bus 24334 verbunden. Ein zweiter Ausgang von mPC 20276 und der JAM- Ausgang von NC 10226 sind mit den Eingängen von NAMUXD 24320 über den ADRH- Bus 24336 bzw. den ADRI-Bus 24338 verbunden. ADR 20202 umfaßt so einen Satz von Bussen, der die Quellen von Mikrobefehlsadressen mit den Eingängen von SITTNAG 20286 verbindet.
Indem wir uns auf mPC 20276 beziehen, umfaßt mPC 20276 einen Mikroprogrammzähler Zähler (mPCC) 24340 und eine arithmetische und logische Einheit für den Mikroprogrammzähler (mPCALU) 24342. Der Dateneingang von mPCC 24340 ist mit dem CSADR-Bus 20204 verbunden. Der Ausgang von mPCC 24340 ist mit einem ersten Eingang von mPCALU 24342 verbunden und ist mPC 20276's dritter Ausgang nach BRCASE 20278. Der zweite Eingang von mPCALU 24342 ist ein Satz aus 15 Binärzahlen, der z. B. durch feste Verdrahtung binär Eins sein kann. Der Ausgang von mPCALU 24342 umfaßt einen ersten Ausgang von mPC 20276 nach RCWS 10358 und mPC 20276's zweiten Ausgang zu den Eingängen NASMUXC 24318 und NASMUXD 24320.
BRCASE 20278 wird in Fig. 243 gezeigt und umfaßt den Maskierungs- und Verschiebungsmultiplexer (MSMUX) 24344, die Casemaskierungs- und Verschiebungslogik (CASEMS) 24346, den Verzweigungs- und Casemultiplexer (BCMUX) 24348 und die arithmetische und logische Einheit für Verzweigungen und Case (BCALU) 24350. Ein erster Eingang von MSMUX 24344 (AONBC, oben nicht gezeigt) ist mit dem Ausgang von AONGRF 20232 verbunden. Ein zweiter Eingang von MSMUX 24344 (AOFF- MUXR, oben nicht gezeigt) ist mit dem Ausgang von OFFMUXR 23812 verbunden. Der Ausgang von MSMUX 24344 ist mit dem Eingang von CASEMS 24346, und der Ausgang von CASEMS 24346. ist mit einem ersten Eingang von BCMUX 24348 verbunden. Ein zweiter Eingang von BCMUX 24348, BLIT, ist mit einem Literalfeldausgang von FUSITT 11012's Mikrobefehlsausgang verbunden. Der Ausgang von BCMUX 24348 und ein dritter Ausgang von mPC 20276 vom Ausgang von mPCC 24340 ist mit dem ersten bzw. zweiten Eingang von BCALU 24350 verbunden. Der Ausgang von BCALU 24350 umfaßt die BRCASE 20278-Ausgaben nach NASMUXC 24318.
Eine Adresse für die Auswahl eines nächsten Mikrobefehls kann FUSITT 11012 durch SITTNAG 20286 von acht verschiedenen Quellen zur Verfügung gestellt werden. Die erste Quelle ist der Ausgang von mPC 20276. Die Ausgabe von mPC 20276 wird als Mikroprogrammzählen plus 1 (mPC + 1) bezeichnet und besteht aus 15 Adreßbits. Die zweite Quelle kommt von EVENT 20284 und umfaßt fünf Adreßbits. Die dritte Quelle ist die Ausgabe von FUDISP 24218 und FUDISENC 24216 und umfaßt, wie oben beschrieben, sechs Adreßbits. Die vierte Quelle ist die Ausgabe von AF 24220 und umfaßt, wie oben beschrieben, 15 Adreßbits. Die fünfte Quelle ist die Ausgabe von BRCASE 20278. Die Ausgabe von BRCASE 20278 wird als Verzweigungs- und Caseadresse (BRCASEADR) bezeichnet und umfaßt 15 Adreßbits. Die sechste Quelle ist eine Ausgabe von RCWS 10358. Die Ausgabe von RCWS 10358 wird als RCWS-Adresse (RCWSADR) bezeichnet und umfaßt 15 Adreßbits. Die siebente Quelle ist REPCTR 20280 und PNREG 20282, deren Ausgaben (REPPN) zusammen 15 Adreßbits umfassen. Die achte Quelle schließlich ist die JAM-Eingabe von NC 10226, die fünf Adreßbits umfaßt. Diese Adreßquellen unterscheiden sich in ihrer Adreßbitanzahl, die sie zur Verfügung stellen, aber eine Mikrobefehlsadresse, die durch SITTNAG 20286 auf den CSADR-Bus 20202 geschaltet wird, umfaßt immer 15 Adreßbits. Wenn eine bestimmte Quelle weniger als 15. Bits heranbringt, wird diese Adresse von SITTNAG 20286 auf 15 Bits erweitert. Die Erweiterung der Adreßbits kann im allgemeinen durch die feste Verdrahtung von zusätzlichen Adreßeingabebits in SITTNAG 20286 von jeder dieser Quellen durchgeführt werden und wird unten beschrieben.
Indem wir auf mPC 20276 Bezug nehmen, ist mPCC 24340 ein 15 Bit Register und mPCALU 24342 ist eine 15 Bit-ALU. mPCC 24340 ist, wie oben beschrieben, mit dem CSADR-Bus 20204 verbunden und wird mit Mikrobefehlsadressen, die gegenwärtig FUSITT 11012 vorliegen, sequentiell geladen. mPCC 24340 enthält daher die Adresse des gegenwärtig ausgeführten Mikrobefehls. mPCALU 24342 ist für die Inkrementierung um Eins der Adresse, die in mPCC 24340 enthalten ist, ausgelegt. Die mPC+ 1-Ausgabe von mPCALU 24342 ist daher immer die Adresse des nächsten sequentiellen Mikrobefehls. mPC + 1 ist, wie oben beschrieben, eine 15 Bit Adresse und wird daher nicht in SITTNAG 20286 erweitert.
Indem wir Bezug nehmen auf BRCASE 20278, so stellt BRCASE 20278, wie oben beschrieben, die nächsten Mikrobefehlsadressen für mPC 20276's relative Verzweigungen und für Caseverzweigungen zur Verfügung. Die nächsten Mikrobefehlsadressen für relative Verzweigungen und für Caseverzweigungen in Mikroprogrammen werden beide als Adressen relativ zu der Adresse des gegenwärtig ausgeführten Mikrobefehls, wie er in mPCC 24340 gespeichert ist, generiert, aber sie unterscheiden sich in der Art und Weise, in der diese relative Adressen erzeugt werden. Betrachten wir zunächst Caseverzweigungen, so werden Caseverzweigungsadressen relativ zur Adresse des gegenwärtig ausgeführten Mikrobefehls teilweise von MSMUX 24344 und von CASEMS 24346 erzeugt. Wie oben beschrieben, empfängt MSMUX 24344, der ein Multiplexer ist, zwei Eingaben. Die erste Eingabe ist AONBC vom Ausgang von AONGRF 20232, und die zweite Eingabe ist OFFMUXR vom Ausgang von OFFMUXR 23812. Beide Eingaben sind acht Bits oder ein Byte breit. Unter der Kontrolle der Mikrobefehlsausgabe von FUSITT 11012 agierend, selektiert MSMUX 24344 entweder die Eingabe AONBC oder die Eingabe OFFMUXR als acht Bit-Ausgabe für den Eingang von CASEMS 24346. CASEMS 24346 ist ein Maskierungs- und Verschiebungskreis, der in Struktur und Betrieb dem von FIU 20160 ähnlich ist, der aber mit Bytes und nicht mit 32 Bit-Worten operiert. CASEMS 24346 manipuliert unter der Mikrobefehlskontrolle von FUSITT 11012 die acht Biteingabe von MSMUX 24344 durch Maskieren und Verschieben, um einen acht Bit Casewert (CASE- VAL) als Ausgabe für BCMUX 24348 zur Verfügung zu stellen. CASEVAL repräsentiert eine Mikrobefehlsadressenverschiebung relativ zu der Adresse eines gegenwärtig ausgeführten Mikrobefehls und kann als acht Bitzahl eine Verschiebung von 0 bis 255 Adreßlokationen in FUSITT 11012 ausdrücken.
BCMUX 24348 ist ein acht Bit Multiplexer, in Struktur und Betrieb MSMUX 24344 ähnelnd, und wird durch Mikrobefehlseingaben, die von FUSITT 11012 zur Verfügung gestellt werden, gesteuert. Beim Ausführen einer Caseoperation selektiert BCMUX 24348 die CASEVAL-Eingabe für MCMUX 24348's Ausgang als erste Eingabe für BCALU 24350. BCALU 24350 ist eine 16 Bit arithmetische und logische Einheit. Die zweite Eingabe von BCALU 24350 ist eine 15 Bit Adresse des gegenwärtig ausgeführten Mikrobefehls von mPCC 24340. BCALU 24350 operiert unter der Mikrobefehlskontrolle, die von FUSITT 11012 zur Verfügung gestellt wird, und addiert bei der Ausführung einer Caseoperation CASEVAL zur Adresse des gegenwärtig ausgeführten Mikrobefehls. Während einer Caseoperation wird die Übertragseingabe von BCALU 24350 durch Mikrobefehlssteuerung von FUSITT 11012 gezwungenermaßen auf Eins gesetzt, so daß die zweite Eingabe von BCALU 24350 praktisch mPC + 1 ist, oder die Adresse des gegenwärtig ausgeführten Mikrobefehls plus 1. Die Ausgabe BRCASEADR von BCALU 24350 ist daher eine 15 Bit Caseadresse, die um zwischen 0 und 256 FUSITT 11012- Adreßlokationen größer ist als die Adreßlokation des gegenwärtig ausgeführten Mikrobefehls. Die aktuelle Casewert-Adressenverschiebung von der Adresse des gegenwärtig ausgeführten Mikrobefehls wird entweder durch die Eingabe AONBC oder die Eingabe OFFMUXR nach MSMUX 24344 bestimmt, und diese Maskierungs- und Verschiebungsoperationen werden von CASEMS 24346 ausgeführt.
Caseoperationen, wie oben beschrieben, können z. B. zur Interpretation und Manipulation von CS 10110-Tabelleneingängen benutzt werden. Zum Beispiel enthalten Namenstabelleneingänge von Namenstabellen 10350 Kennzeichenfelder, die Information tragen, die bestimmte Operationen betreffen, die bei der Auflösung und Auswertung jener Namenstabelleneingänge durchgeführt werden sollen. Diese Operationen können als Caseverzweigungen in Mikrobefehlsabfolgen zur Auflösung und Auswertung jener Namenstabelleneingänge implementiert werden. Im vorliegenden Beispiel kann während der Auflösung eines Namenstabelleneingangs die Mikrobefehlsabfolge, die jene Auflösung vornimmt, ein Byte des Kennzeichenfeldes jenes Namenstabelleneingangs von AONGRF 20232 oder OFFMUXR 23812 und durch MSMUX 24344 nach CASEMS 24346 lesen lassen. Diese Mikrobefehlsabfolge veranlaßt dann CASEMS 24346, jenes Kennzeichenfeld-Byte zu verschieben und zu maskieren, um ein CASEVAL zur Verfügung zu stellen. Jener CASEVAL hat einen Wert, der von den Kennzeichen innerhalb jenes Kennzeichenfeld-Bytes abhängt und stellt, wenn er zu mPC + 1 addiert wird, eine FUSITT 11012- Mikrobefehlsadresse für eine Mikrobefehlsabfolge zur Verfügung, zur Behandlung jenes Namenstabelleneingangs gemäß jener Kennzeichenbits.
Wie oben beschrieben, kann BRCASE 20278 auch Mikrobefehlsadressen für Verzweigungen erzeugen, die innerhalb der Ausführung einer gegebenen Mikrobefehlsabfolge auftreten. In diesem Fall veranlassen die Mikrobefehlssteuersignale von FUSITT 11012 BCMUX 24348, den zweiten Eingang von BCMUX 24348 als Ausgang für BCALU 24350 zu wählen. BCMUX 24348's zweiter Eingang ist das Verzweigungsliteral (BLIT). Wie oben beschrieben, wird BLIT vom Literalfeld eines Mikrobefehlswortes der FUSITT 11012-Mikrobefehlsausgabe zur Verfügung gestellt. Die BLIT-Ausgabe von BCMUX 24348 wird zur Adresse des gegenwärtig ausgeführten Mikrobefehls von mPCC 24340 und zu BCALU 24350 addiert, um eine 15 Bit-BRCASEADR einer Mikrobefehlsadresse zur Verfügung zu stellen, zu der von der Adresse des gegenwärtig ausgeführten Mikrobefehls verzweigt wurde. BRCASEADR kann z. B. jede beliebige von vier Verzweigungsoperationen repräsentieren. Mögliche Verzweigungsoperationen sind: Erstens eine bedingte kurze Verzweigung; zweitens ein bedingter kurzer Aufruf; drittens ein langes Go To; und viertens ein langer Aufruf. In jedem dieser möglichen Verzweigungsoperationen wird BLIT als das Zweierkomplement des gewünschten Verzweigungswertes behandelt, d. h. der Mikrobefehlsadressenabstand relativ zur Adresse des gegenwärtig ausgeführten Mikrobefehls. Das BLIT-Feld kann daher praktisch zur Adresse des gegenwärtig ausgeführten Mikrobefehls addiert oder von ihm subtrahiert werden, um eine Mikrobefehlsadresse zur Verfügung zu stellen, die eine positive oder negative Verschiebung von der Adresse des gegenwärtig ausgeführten Mikrobefehls hat. Bei einer bedingten kurzen Verzweigung oder einem bedingten kurzen Aufruf ist das 14 Bit-Literalfeld eine vorzeichenerweiterte 8 Bit-Zahl. Die Mikrobefehlsadressen für eine bedingte kurze Verzweigung und einen bedingten kurzen Aufruf können daher an eine Adresse innerhalb eines Bereiches von + 127 bis -128 FUSITT 11012-Adreßlokationen relativ zur Adresse des gegenwärtig ausgeführten Mikrobefehls zeigen. Im Falle eines langen Go To oder eines langen Aufrufs ist das BLIT-Feld eine 14 Bit-Zahl, die den Abstand relativ zur Adresse des gerade ausgeführten Mikrobefehls repräsentiert. BRCASEADR kann in diesen Fällen eine FUSITT 11012-Mikrobefehlsadresse innerhalb eines Bereichs von +8191 bis -8192 FUSITT 11012-Adreßlokationen von der Adresse des gegenwärtig ausgeführten Mikrobefehls repräsentieren. BRCASE 20278 versorgt daher FU 10120 mit der Fähigkeit, den vollen Bereich der Case- und Verzweigungsoperationen bei Mikrobefehlsabfolgen auszuführen.
Indem wir auf RCWS 10358 Bezug nehmen, speichert RCWS, wie oben beschrieben wurde, Informationen hinsichtlich Mikrobefehlsfolgen, deren Ausführung angehalten wurde. RCWS 10358 erlaubt es, die Ausführung jener Mikrobefehlsabfolgen zu einem späteren Zeitpunkt wieder aufzunehmen. Ein Rückkehrkontrollwort (RCW) kann während jeder Mikrobefehlsabfolge auf RCWS 10358 geschrieben werden, die eine andere Mikrobefehlsabfolge aufruft. Die aufrufende Mikrobefehlsabfolge kann z. B. unterbrochen werden, um ein Ereignis zu bedienen, wie es weiter in einer folgenden Beschreibung beschrieben wird, oder kann in einem Stau resultieren. Ein Stau ist ein Aufruf einer Mikrobefehlsabfolge, der durch die Operation der CS 10110-Hardware und nicht von einer Mikrobefehlsabfolge erzwungen wurde. Der Betrieb von RCWS 10358 hinsichtlich der CS 10110-internen Mechanismen wird in einer folgenden Beschreibung von EVENT 20284, STATE 20294 und MCW1 20290 und MCW0 20292 beschrieben werden. Für die Angelegenheiten der vorliegenden Diskussion enthält jener Bereich einer RCW, der mit der Interpretation von SOPs betraut ist, erstens bestimmte Zustandsinformationen von FUSITT 11012, und zweitens eine Rückkehradresse in FUSITT 11012. Es sei festgestellt, daß der Zustand von FUSITT 11012 von STATE 20294 zur Verfügung gestellt wird, wie es unten beschrieben wird, und jener Bereich eines RCWE, der die FUSITT 11012- Zustandsinformationen enthält, wird in einer folgenden Beschreibung beschrieben werden. Die Mikrobefehlsadreßbereiche von RCWS werden vom Ausgang von mPCALU 24342 zur Verfügung gestellt. Diese Mikrobefehlsadresse ist die Adresse des Mikrobefehls, zu der FU 10120 bei der Rückkehr von einem Aufruf, Ereignis oder Stau zurückkehrt. Beim Auftreten eines Aufrufs oder Staus ist die Mikrobefehlsrückkehradresse mPC + 1, das ist die Adresse des Mikrobefehls nach dem Mikrobefehl, der den Aufruf oder die Rückkehr veranlaßte. Für abgebrochene Mikrobefehlsfolgen ist die Mikrobefehlsrückkehradresse mPC, das ist die Adresse des ausführenden Mikrobefehls zu dem Zeitpunkt, wenn der Abbruch auftritt.
Bei der Rückkehr von einem Aufruf, der Bedienung eines Ereignisses oder der Bedienung eines Staus, wird der FU 10120-Zustandskennzeichenbereich von RCWE in STATE 20294 geladen. Die Mikrobefehlsrückkehradressen werden von RCWS 10358 als 15 Bit-RCWS- ADR für SITTNAG 20286 zur Verfügung gestellt und auf CSADR 20204 aufgeprägt. RCWSADR ist für FUSITT 11012 vorgesehen, um den nächsten Mikrobefehl auszuwählen, und wird in mPCC 24340 von CSADR 20204 geladen.
Wie oben beschrieben, ist RCWS 10358 mit dem JPD-Bus 10142 durch einen bidirektionalen Bus verbunden. RCWs können in RCWS 10358 vom JPD-Bus 10142 geschrieben werden, oder von RCWS 10358 zum JPD-Bus 10142 gelesen werden. Der 15 Bit-Bereich für die nächste Mikrobefehlsadresse und der Einzelbitbereich von RCW über den FUSITT 11012-Zustand wird von den Bits 16 bis 31 des JPD-Busses 10142 geschrieben oder dorthin gelesen. FU 10120 kann den vorliegenden unteren RCW oder den vorigen RCW in RCWS 10358 vom JPD-Bus 10142 schreiben und kann den vorliegenden unteren RCW oder vorigen RCW oder einen anderen ausgewählten RCW auf den JPD-Bus 10142 lesen. RCWS 10358 stellt dadurch ein Mittel zur Speicherung und Rückgabe von Mikrobefehlsadressen von Mikrobefehlsabfolgen zur Verfügung, deren Ausführung gestoppt wurde, und auch ein Mittel, um Mikrobefehlsadressen und FUSITT 11012-Zustandskennzeichen von und zum JPD-Bus 10142 zu lesen und zu schreiben.
Wie oben beschrieben, stellen REPCTR 20280 und PNREG 20282 Mikrobefehlsadressen zum Schreiben von Mikrobefehlen in FUSITT 11012 zur Verfügung. REPCTR 20280 ist ein acht Bitzähler, und PNREG 20282 ist ein sieben Bitregister. Die acht Bit-Ausgabe von REPCTR 20280 wird mit der sieben Bit-Ausgabe von PNREG 20282 links verkettet, um 15 Bit Mikrobefehlsadressen REPPN zur Verfügung zu stellen. Das heißt, REPCTR 20280 stellt die acht niedrigrangigen Bits der Mikrobefehlsadresse, während PNREG 20282 die sieben signifikantesten Bits der Adresse zur Verfügung stellt.
REPCTR kann von den Bits 24 bis 31 des JPD-Bus 10142 geladen werden und kann von den Bits 24 bis 31 des JPD-Bus 10142 gelesen werden. Darüber hinaus können die acht Bits der Mikrobefehlsadresse in REPCTR 20280 inkrementiert oder dekrementiert werden, wie Mikrobefehle in FUSITT 11012 geschrieben werden.
Wie oben beschrieben, enthält PNREG 20282 die sieben signifikantesten Bits der Mikrobefehlsadresse. Diese Adreßbits können von den Bits 17 bis 23 des JPD-Busses 10142 in PNREG 20282 geschrieben werden. Die Inhalte von PNREG 20282 dürfen im allgemeinen nicht zum JPD-Bus 10142 gelesen werden und dürfen nicht inkrementiert oder dekrementiert werden.
Indem wir uns auf die JAM-Eingabe für SITTNAG 20286 von NC 10226 beziehen, können bestimmte Namensauswerte- oder -auflöseoperationen in Staus resultieren. Ein Stau funktioniert als ein Aufruf von Mikrobefehlsabfolgen zur Bedienung von Staus; sie werden von der FU 10120-Hardwareschaltlogik gezwungen, die bei Namenssilbenauswerkingen und -auflösungen involviert ist.
Die JAM-Eingabe für SITTNAG 20286 umfaßt sechs Stauadreßbits. Drei Bits werden von NC 10226 zur Verfügung gestellt und drei Bits werden von FUSITT 11012's Mikrobefehlsausgabe als Teil von Mikrobefehlsabfolgen zur Korrektur von Namenssilbenauswertungen und -auflösungen zur Verfügung gestellt. Die drei Bits der Adresse von NC 10226 bilden die signifikantesten drei Bits der JAM-Adresse. Einer dieser Bits schaltet die JAM-Adresse auf den CSADR-Bus 20204 auf und ist von daher kein echtes Adreßbit. Die Ausgabe von FUSITT 11012 stellt die drei weniger signifikanten Bits der JAM-Adresse bereit und spezifiziert die bestimmte Mikrobefehlsabfolge, die erforderlich ist, um den bestimmten Stau zu bedienen, der aufgetreten ist. Daher spezifiziert während Namensauswertungen oder Namensauflösungen die Mikrobefehlsabfolge, die von FUSITT 11012 zur Verfügung gestellt wird, um Namensauswertungen oder -auflösungen durchzuführen, welche Mikrobefehlsabfolgen initiiert werden müssen, wenn ein Stau auftritt. Die drei Bits der JAM-Adresse, die von NC 10226 zur Verfügung gestellt werden, bestimmen, erstens daß ein Stau aufgetreten ist, und zweitens stellen zwei Bits für Adressen bereit, die, in Kombination mit den drei Adreßbits von FUSITT 11012, die bestimmte Mikrobefehlsabfolge spezifizieren, um den Stau zu verwalten, zur Verfügung. Die JAM-Adreßeingaben von NC 10226 und FUSITT 11012 stellen daher sechs von 15 Bits der JAM-Adresse zur Verfügung. Die verbleibenden neun Bits der JAM-Adresse werden z. B. durch fest verdrahtete Eingaben für NASMUXD 24320 zur Verfügung gestellt. Diese fest verdrahteten Adreßbits zwingen die JAM-Adresse dazu, FUSITT 11012 in Blocks von vier Mikrobefehlsadressen zu adressieren, in einer Weise, die den Adreßeingaben für FUDISF 24218 und FUDISENC 24216 ähnlich ist.
Die Adreßeingaben, die SITTNAG 20286 von FUSDT 11010 zur Verfügung gestellt werden, wurden oben bei der Beschreibung der Zugriffs-Analysier- und Aufteilungsoperationen von FUCTL 20214 beschrieben. Die Adreßeingaben, die von EVENT 20284 zur Verfügung gestellt werden, werden in einer folgenden Beschreibung der FUCTL 20214-Operationen hinsichtlich der CS 10110-internen Mechanismen beschrieben werden.
Indem wir schließlich auf SITTNAG 20286 Bezug nehmen, umfaßt SITTNAG 20286, wie oben beschrieben, EVNTGT 24310 und NASMUX 24312. Eingaben werden NASMUX 24312, wie oben beschrieben, von FUSDT 11010, mPC 20276, BRCASE 20278, RCWS 10358, REPCTR 20280 und PNREG 20282 und durch eine JAM-Eingabe zur Verfügung gestellt. Diese Eingaben werden im allgemeinen im Zusammenhang mit FUCTL 202 14- Operationen beim Zugriff auf, Analysieren von und Interpretieren von SOPs und Namenssilben zur Verfügung gestellt. Diese Operationen sind daher vorrangig direkt mit der Ausführung von Benutzerprogrammen betraut, d. h. der Ausführung von SIN-Abfolgen. NASMUX 24312 wählt zwischen diesen Eingaben aus und transferiert die ausgewählten Adreßeingaben auf CSADR 20204 als Mikrobefehlsadressen für FUSITT 11012 unter der Mikrobefehlskontrolle von Mikrobefehlsausgaben von FUSITT 11012. Die Mikrobefehlsadreßausgaben werden SITTNAG 20286 von EVENT 20284 als Antwort auf Ereignisse, wie unten beschrieben wird, zur Verfügung gestellt, die bei der Ausführung von Benutzerprogrammen bei Operationen von CS 10110 auftreten. Diese Mikrobefehlsadressen von EVENT 20284 werden auf CSADR 20204 aufgeschaltet, um geeignete Mikrobefehlsabfolgen durch EVNTGT 24310 auszuwählen. EVNTGT 24310 ist von NASMUX 24312 getrennt, um es EVNTGT 24310 zu ermöglichen, NASMUX 24312 zu überschreiben und EVENT 20284 Mikrobefehlsadressen zur Verfügung zu stellen, während NASMUX 24312 aufgrund des Auftretens von bestimmten Ereignissen gesperrt ist. Diese Ereignisse sind im allgemeinen mit dem Betrieb von CS 10110-internen Mechanismen verbunden. Die Struktur und der Betrieb von EVENT 20284 zusammen mit STATE 20294, MCW1 20290 und MCW0 20292 und anderen Bereichen von RCWS 10358 werden unten beschrieben.

c.c. Der FUCTL 20214-Steuerschaltkreis für CS 10110- interne Mechanismen (Fig. 244 bis 249)

Bestimmte Bereiche des Steuerschaltkreises von FUCTL 20214 sind direkter mit dem Betrieb der CS 10110-internen Mechanismen betraut, z. B. die Stapelspeichermechanismen von CS 10110. Dieser Schaltkreis kann STATE 20294, EVENT 20284, MCW1 20290 und MCW0 20292, Bereiche von RCWS 10358, REG 20288 und die Zeitmeßgeräte 20296 beinhalten. Diese Steuerelemente von FUCTL 20214 werden unten, beginnend mit STATE 20294, beschrieben.

a.a.a. Zustandslogik 20294 (Fig. 244A-244Z)

Im allgemeinen werden alle CS 10110-Operationen, einschließlich der Ausführung von Mikrobefehlen, von CS 10110's Betriebszustand gesteuert. CS 10110 hat eine Anzahl von Betriebszuständen, von jetzt an als Zustände bezeichnet, wobei jeder Zustand durch bestimmte Operationen definiert wird, die in jenem Zustand ausgeführt werden können. Jeder dieser Zustände wird im weiteren unten beschrieben werden. Der gegenwärtige Zustand von CS 10110 wird durch einen Satz von Zustandskennzeichen angezeigt, die in einem Satz von Registern in STATE 20294 gespeichert sind. Jeder Zustand wird von dem vorhergehenden Zustand betreten und wird in einen folgenden Zustand verlassen. Der nächste Zustand von CS 10110 wird durch Zufallslogikschaltungen entdeckt, die überall in CS 10110 verteilt sind, um bestimmte Bedingungen zu entdecken, die anzeigen, in welchen Zustand CS 10110 als nächstes eintreten wird. Die Ausgaben dieser Schaltungen zur Entdeckung des nächsten Zustands werden als Eingaben für die STATE 20294- Register zur Verfügung gestellt. Ein bestimmtes Zustandsregister wird gesetzt und stellt eine Zustandskennzeichenausgabe zur Verfügung, wenn CS 10110 in den Zustand eintritt, der mit jenem bestimmten Register assoziiert ist. Die Zustandskennzeichenausgaben von STATE 20294's Zustandsregistern werden als Aktivierungssignale überall in CS 10110 zur Verfügung gestellt, um die Initiierung von Operationen zu aktivieren, die innerhalb des gegenwärtigen Zustands von CS 10110 erlaubt sind, und um die Initiierung von Operationen zu verhindern, die innerhalb des gegenwärtigen Zustands von CS 10110 nicht erlaubt sind.
Bestimmte Zustände von CS 10110 und die dazugehörigen STATE 20294-Zustandsregister und Zustandskennzeichenausgaben sind:
(1) MO: Der initiale Zustand jedes Mikrobefehls. Der Zustand MO wird immer als erster Datenzyklus jedes Mikrobefehls betreten. Während MO darf CS 10110's Zustand nicht geändert werden, was ermöglicht, daß ein Mikrobefehl vom Zustand MO willkürlich abgebrochen und wieder neu gestartet werden kann. Bei der normalen Ausführung von Mikrobefehlen folgt auf Zustand MO der Zustand M1, der unten beschrieben wird, d. h. der Zustand MO wird nach Zustand M1 verlassen. Der Zustand MO kann vom Zustand MO und vom Zustand M1, Zustand AB, Zustand LR, Zustand NR oder Zustand MS betreten werden, von denen jeder unten beschrieben wird.
(2) EP: Aktivier-Pause-Zustand. Der Zustand EP wird betreten, wenn der Zustand MO zum ersten Mal in einem Mikrobefehl betreten wird. Wenn jener Mikrobefehl eine Pause verlangt, zwingt jener Mikrobefehl den Zustand MO, für einen Systemtakt wieder betreten zu werden. Wenn der Zustand MO länger als einen Systemtakt andauert, wird der Zustand EP bei jeder Erweiterung des Zustands MO betreten, es sei denn, die Erweiterung ist ein Ergebnis einer Pausenanforderung.
(3) SR: Quellen-GRF-Zustand. Der SR-Zustand ist für einen Systemtakt aktiv, indem das SR-Zustandregister das Laden eines GRF 10354-Ausgabenregisters aktiviert. Der Zustand SR wird bei jedem Zustand MO-Zyklus wieder betreten, außer bei einem Zustand MO-Zyklus, der von einem Mikrobefehl erzeugt wurde, der eine Erweiterung des Zustands MO anfordert. Wenn alle STAT 20294-Zustandsregister gelöscht sind, kann DP 20218, weil es von GRF 10354 lesen will, das SR-Zustandsregister alleine setzen.
(4) M1: Der Schlußzustand einer normalen Mikrobefehlsausführung. Der Zustand M1 ist der Ausgangszustand einer normalen Mikrobefehlsausführung. Das FUSITT 11012- Mikrobefehlsregister, das unten beschrieben wird, wird beim Ausgang aus Zustand M1 mit dem nächsten Mikrobefehl geladen. Darüber hinaus aktiviert die Kennzeichenausgabe vom Zustand M1 von STATE 20294 alle CS 10110-Register, Daten auf ihren Eingängen zu empfangen, d. h. Daten auf den Eingängen dieser Register werden auf die Ausgänge dieser Register getaktet. Der Zustand M1 kann vom Zustand M1 oder vom Zustand MO oder vom Zustand MW oder vom Zustand MWA oder vom Zustand WB betreten werden.
(5) LA: Ladeakkumulator-Aktivierungszustand. Der Zustand LA wird beim Ausgang aus Zustand M1 durch Mikrobefehle, die Daten von MEM 10112 nach OFF- MUXR 23812 lesen, betreten. Wie oben beschrieben, dient OFFMUXR 23812 als Akkumulator für allgemeine Zwecke für DESP 20210. Der Zustand LA überlappt in die Ausführung von nächsten Mikrobefehlen und bleibt so lange bestehen, bis Daten von MEM 10112 als Antwort auf eine MEM 10112-Anforderung zurückgegeben werden. Wenn MEM 10112 durch die Aufprägung von DAVFA signalisiert, daß Daten verfügbar sind, aktiviert das LA-Zustandskennzeichen das Laden von Daten in OFFMUXR 23812. Wenn der nächste Mikrobefehl auf OFFMUXR 23812 Bezug nimmt, wird die Ausführung jenes Mikrobefehls so lange verzögert, bis das Lesen nach OFPMUXR 23812 vollendet ist, was von CS 10110 durch das Verlassen des Zustands LA angezeigt wird.
(6) RW: Lade-GRF 10354-Wartestatus. Der Zustand RW wird vom Zustand M1 bei Mikrobefehlen, die Daten von MEM 10112 nach GRF 10354 lesen, betreten. Das RW-Kennzeichen blockiert die Initiierung eines nächsten Mikrobefehls, d. h. verhindert den Eingang in Zustand M0 und bleibt den CS 10110-Systemtakt vorhanden, währenddem Daten als Antwort auf eine Anforderung von MEM 10112 zurückgegeben werden. Der Zustand RW initiiert den Lade-GRF-Aktivierungszustand, der unten beschrieben wird.
(7) LR: Lade-GRF-Aktivierungszustand. Der Zustand LR wird parallel mit dem Zustand RW betreten, und zwar beim letzten Systemtakt von RW und dauert einen CS 10110-Systemtakt an. Das LR-Kennzeichen aktiviert das Schreiben von MEM 10112- Ausgabedaten in GRF 10354.
(8) MR: Speicherreferenzierungsbeendigungszustand. Der Zustand MR wird beim Übergang zum Zustand M0 betreten, wann immer ein vorheriger Mikrobefehl eine logische oder physikalische Adreßreferenz an MEM 10112 macht. Das MR-Kennzeichen aktiviert die Erkennung aller Referenzierungsereignisse von MEM 10112, die unten beschrieben werden, die auftreten können. Der Zustand MR dauert einen Systemtakt an. Falls ein MEM 10112-Speicherreferenzierungsereignis auftritt, erzwingt jenes Ereignis den Ausgang vom Zustand MR in die Zustände AB und MA, sonst hat der Zustand MR keinen Einfluß auf die Auswahl des nächsten Zustands.
(9) SB: Zurückspeicheraktivierungszustand. Der Zustand SB wird während des Zustands M0 betreten, wenn ein Mikrobefehl auf einen Mikrobefehl folgt, der ein Zurückspeichern eines Ergebnisses einer EU 10122-Operation erzeugte. Das SB-Kennzeichen verschaltet jenes Resultat so, daß es über den JPD-Bus 10142 in MEM 10112 geschrieben wird.
(10) AB: Mikrobefehlsabbruchzustand. Der Zustand AB wird von einem ersten M0-Zustand aus, nachdem eine Ereignisanforderung erkannt wurde, wie es in einer folgenden Beschreibung beschrieben wird, betreten. Der Zustand AB kann vom Zustand M0 oder vom Zustand AB betreten werden und unterdrückt einen Eingang in den Zustand M1. Wenn es eine unvollendete Referenz an MEM 10112 gab, d. h. die Referenz wurde nicht abgebrochen und die Daten sind von MEM 10112 nicht zurückgegeben worden, so verbleibt JP 10114 im Zustand AB, bis die MEM 10112-Referenz vollendet ist. Sollte ein Abbruch aufgrund eines MEM 10112-Referenzereignisses stattgefunden haben, so dauert der Zustand AB nur zwei Systemtakte an. Wie in einer folgenden Beschreibung von EVENT 20284 beschrieben werden wird, wird der Zustand M0 bei einem ersten Mikrobefehl eines Managers für ein Ereignis, das den Abbruch verursacht, von Zustand AB betreten. Das AB-Kennzeichen verschaltet die Manageradresse des Ereignisses mit der höchsten erkannten Priorität auf den CSADR-Bus 20204, um eine entsprechende Ereignismanager-Mikrobefehlsabfolge auszuwählen. EVENT 20284 wird die Steuerung des CSADR-Busses 20204 während aller Zustand AB-Systemtakte zugewiesen.
(11) AR: Der Mikrobefehlsabbruch-Zurückstellungszustand. Der Zustand AR wird parallel mit dem ersten Systemtakt des Zustands AB betreten und dauert einen Systemtakt lang. Das AR-Kennzeichen setzt verschiedene STATE 20294-Zustandsregister zurück, wenn ein Abbruch auftritt. Wenn es keine unvollendeten MEM 10112-Referenzen gibt, ist der nächste Systemtakt im Zustand AB der letzte. Bei unvollendeten MEM 10112- Referenzen wird der Zustand AR betreten, aber der Zustand AB bleibt so lange aktiv, bis die Referenz abgeschlossen ist. Sollte ein Ereignisanforderungsservice höherer Priorität erkannt werden, während JP 10114 im Zustand AB ist, so wird der Zustand AR wieder betreten. Der Zustand AB bleibt für zwei Systemtakte während aller bedienten Ereignisanforderungen aktiv.
(12) MA: MEM 10112-Referenz Abbruch. Der Zustand MA wird parallel mit dem Zustand AB betreten, wenn eine MEM 10112-Referenz abgebrochen wird, wie es von MEM 10112 durch die aufgeprägte Steuersignalausgabe ABORT angezeigt wird. Der Zustand MA dauert einen Systemtakt an, und das Kennzeichen des Zustands AB erzeugt ein MEM 10112-Referenzabbruch-Kennzeichen, das, wie unten beschrieben, in einer Wiederholung der MEM 10112-Referenz resultiert. Das AB-Kennzeichen setzt auch die MEM 10112-Beendigungszustände, wie unten beschrieben, zurück.
(13) NW: Nano-Unterbrechungs-Wartezustand. Der Zustand NW wird vom Zustand M0 aus betreten von einem Mikrobefehl, der eine Nano-Unterbrechungsahforderung an EU 10122 für eine EU 10122-Operation veranlaßt. FU 10120 verbliebt im Zustand NW, bis EU 10122 jene Unterbrechung bestätigt. Verschiedene EU 10122- Ereignisse können zu diesem Zeitpunkt Anforderungen stellen. Der Zustand NW wird in den Zustand AB oder den Zustand M1 verlassen.
(14) FM: Der erste Mikrobefehl eines SIN. Der Zustand FM wird parallel mit dem Zustand M0 beim ersten Mikrobefehl eines jeden SIN betreten und dauert einen Systemtakt lang. Das FM-Kennzeichen verhindert die vorzeitige Benutzung von AF 24220 und aktiviert die Erkennung von SIN-Eingangsereignissen. Der Zustand FM wird bei der Rückkehr von allen Abbrüchen wieder betreten, die während des Zustands M0 des ersten Mikrobefehls eines SIN unternommen wurden.
(15) SOP: Ursprungseingang zum ersten SIN. Der Zustand SOP wird betreten, wenn der Zustand M0 des ersten Mikrobefehls eines SOP betreten wird, und er wird verlassen bei jedem beliebigen Verlassen jenes Mikrobefehls. Der Zustand SOP wird nur einmal pro SOP betreten. Das SOP-Kennzeichen kann z. B. zur Überwachung der Leistungsfähigkeit von JP 10114 benutzt werden.
(16) EU: EU 10122-Operandenpuffer nicht verfügbar. Der Zustand EU wird vom Zustand M0 eines Mikrobefehls betreten, der versucht, Daten in den EU 10122-Operandenpuffer zu lesen, der in einer folgenden Beschreibung beschrieben wird, wobei der EU 10122-Operandenpuffer voll ist. Wenn ein neuer SOP betreten wird, können drei Zugriffe auf Daten von MEM 10112 durchgeführt werden, bevor der EU 10122-Operandenpuffer voll ist; zwei Zugriffe würden den EU 10122-Operandenpuffer füllen, aber EU 10122 kann einen Operanden während eines zweiten Zugriffs übernehmen, und dabei den Platz für einen dritten Operanden im EU 10122-Operandenpuffer frei machen.
(17) NR: Langes Pipelinelesen. Der Eingang in den Zustand NR deaktiviert die Überlappung von MEM 10112-Lesevorgängen und verhindert die Ausführung des nächsten Mikrobefehls. Ein folgender Mikrobefehl betritt so lange nicht den Zustand M0, wie die angeforderten Daten von MEM 10112 nicht zurückgegeben werden. Der Zustand NR wird vom Zustand NR oder vom Zustand M1 betreten.
(18) NS: Nichtpipeline-Zurückspeichern. Der Zustand NS wird parallel mit dem Zustand SB betreten, wann immer ein Mikrobefehl auftaucht, der ein Pipelinezurückspeichern oder einen Schreibvorgang an MEM 10112 anfordert. Das Zustand NS-Kennzeichen erzeugt den Eingang in den Zustand M0 eines folgenden Mikrobefehls beim Verlassen des Zustands SB.
(19) WA: Lade den Steuerspeicherzustand A. Der Zustand WA wird vom Zustand M0 aus von einem Mikrobefehl betreten, der das Laden von Mikrobefehlen in FUSITT 11012 steuert. Das WA-Zustandskennzeichen steuert die Auswahl von Adressen für den CSADR-Bus 20204 zum Schreiben in FUSITT 11012 und erzeugt einen Schreibaktivierungspuls für FUSITT 11012, um Mikrobefehle in FUSITT 11012 zu schreiben.
(20) WB: Lade den Steuerspeicherzustand B. Der Zustand WB wird vom Zustand WA aus betreten und wird dazu benutzt, ein geeignetes Zeitintervall für das Schreiben in FUSITT 11012 zu erzeugen. Der Zustand WB erweitert auch den Zustand M1 auf zwei Systemtakte, um eine gültige Adreßeingabe an FUSITT 11012 sicherzustellen, wenn ein nächster Mikrobefehl von FUSITT 11012 gelesen werden soll.
Nachdem bestimmte CS 10110-Zustände und Operationen, die innerhalb jener Zustände ausgeführt werden können, beschrieben wurden, werden als nächstes mit Hilfe der Fig. 244A bis 244Z Zustandsabfolgen für bestimmte CS 10110-Operationen beschrieben. Die Fig. 244A bis 244Z repräsentieren jene Zustandszeitsteuerungsabfolgen, die nötig sind, die wichtigsten Merkmale der CS 10110-Zustandszeitsteuerung anzuzeigen. Jede Zustandszeitsteuerung, die in den Fig. 244A bis 244V gezeigt wird, setzt volle Pipelineverarbeitung der CS 10110-Operationen, z. B. Pipelineverarbeitung von Lese- und Schreibvorgängen von und zu MEM 10112 durch JP 10114 voraus. Pipelineverarbeitung wird nicht angenommen in den Fig. 244W bis 244Z. Mit Bezug auf die Fig. 244A bis 244Z, so werden diese Figuren in der Form eines zeitlichen Diagramms gezeichnet, wobei die Zeit von links nach rechts wächst. Aufeinander folgende horizontal positionierte Kästchen repräsentieren aufeinander folgende CS 10110-Zustände während aufeinander folgenden CS 10110 110 Nanosekunden Systemtakte. Vertikal ausgerichtete Kästchen repräsentieren alternative CS 10110-Zustände, die während eines bestimmten Systemtaktes auftreten können. Horizontal erstreckte gepunktete Linien, die bestimmte Zustände in den Fig. 244A bis 244Z miteinander verbinden, repräsentieren ein unbestimmtes Zeitintervall, das ein ganzzahliges Vielfaches der 110 Nanosekunden-Systemtakte von CS 10110 ist.
Sich der Reihe nach auf die Fig. 244A bis 244Z beziehend, bedeuten die Zustandszeitsteuerungsabfolgen, die darin gezeigt werden, folgendes:
(1) Fig. 244A; die Zustandszeitsteuerung der Ausführung eines normalen Mikrobefehls, bei dem keine Ereignisse und keine MEM 10112-Referenzen auftreten.
(2) Fig. 244B; die Ausführung eines normalen Mikrobefehls, bei dem keine Ereignisse und keine MEM 10112-Referenzen auftreten, mit einer Pause von einem Systemtakt im Zustand M0.
(3) Fig. 244C; ein Mikrobefehl fordert die Erweiterung des Zustands M0 für einen Systemtakt an, es treten keine Ereignisse und keine MEM 10112-Referenzen auf.
(4) Fig. 244D; ein Schreiben von DESP 20210 nach MEM 10112, z. B. von GRF 10354 oder von OFFALU 20242. Der Anschlußpunkt von MEM 10112 ist verfügbar und die MEM 10112-Referenz wird während des ersten sequentiellen Auftretens der Zustände M0 und M1 gemacht.
(5) Fig. 244E; ein Schreiben nach MEM 10112 von DESP 20210, wie es oben beschrieben wurde. Der Anschlußpunkt von MEM 10112 ist für eine unbestimmte Anzahl von Systemtakten nicht verfügbar. Es wird eine MEM 10112-Referenz während des ersten sequentiellen Auftretens der Zustände M0 und M1 gemacht.
(6) Fig. 244F; Schreiben eines EU 10122-Ergebnisses zurück nach MEM 10112. MEM 10112 ist verfügbar und eine Schreiboperation wird initiiert während des ersten sequentiellen Auftretens der Zustände M0 und M1.
(7) Fig. 244G; das Zurückschreiben eines EU 10122-Ergebnisses in MEM 10112, wie oben beschrieben. Der MEM 10112-Anschlußpunkt ist für eine unbestimmte Anzahl von Systemtakten nicht verfügbar oder EU 10122 hat kein fertiges Ergebnis, das nach MEM 10112 geschrieben werden kann. Die Schreiboperation wird während des ersten sequentiellen Auftretens der Zustände M0 und M1 initiiert.
(8) Fig. 244H; ein Lesen eines EU 10122-Ergebnisses in FU 10120. Das EU 10122-Ergebnis ist für eine unbestimmte Anzahl von Systemtakten nicht verfügbar.
(9) Fig. 244I; ein Lesen von MEM 10112 nach OFFMUXR 23812, ohne Verzögerungen. Der Mikrobefehl, der dem Mikrobefehl folgt, der das Lesen von MEM 10112 initiiert, referenziert OFFMUXR 23812 nicht.
(10) Fig. 244J; ein Lesen von MEM 10112 nach OFFMUXR 23812 mit Daten von MEM 10112, die um eine unbestimmte Anzahl von Systemtakten verspätet sind. Der nächste Mikrobefehl, der dem folgt, der das Lesen von MEM 10112 initiierte, referenziert OFFMUXR 23812 nicht.
(11) Fig. 244K; ein Lesen von MEM 10112 nach OFFMUXR 23812. Der nächste Mikrobefehl, der dem Mikrobefehl folgt, der das Lesen von MEM 10112 initiierte, referenziert OFFMUXR 23812.
(12) Fig. 244L; ein Lesen von MEM 10112 nach GRF 10354. Das Lesen nach GRF 10354 wird durch das erste sequentielle Auftreten der Zustände M0 und M1 initiiert.
(13) Fig. 244M; ein Lesen von MEM 10112 nach GRF 10354 und nach OFFMUXR 23812. In diesem Fall dürfen die Leseoperationen nicht überlappen.
(14) Fig. 244N; JP 10114 bedient eine Ereignisanforderung und initiiert eine entsprechende Ereignismanager-Mikrobefehlsabfolge, es treten keine MEM 10112- Referenzen auf.
(15) Fig. 244O; JP 10114 bedient eine Ereignisanforderung wie oben festgestellt. MEM 10112-Referenzen werden während des ersten sequentiellen Auftretens der Zustände M0 und M1 gemacht und es tritt ein MEM 10112-Referenzereignis auf. Im Falle eines MEM 10112-Referenzereignisses wird der Zustand MA einen Systemtakt lang betreten. Das tritt nur dann auf, wenn eine MEM 10112-Referenz gemacht und abgebrochen wurde.
(16) Fig. 244P; ein Ereignis tritt in einer MEM 10112-Referenz auf, die während des ersten sequentiellen Auftretens der Zustände M0 und M1 gemacht wurde. Die MEM 10112-Referenz resultiert nicht in einem Speicherreferenzereignis. CS 10110 bleibt im Zustand AB, bis die MEM 10112-Referenz durch die Rückkehr der Daten von MEM 10112 vollendet ist.
(17) Fig. 244Q; ein Lesen von Daten von MEM 10112 oder dem JPD-Bus 10142 zur EU 10122-Operandenwarteschlange. Die EU 10122-Operandenwarteschlange ist nicht voll.
(18) Fig. 244R; ein Lesen von Daten von MEM 10112 oder dem JPD-Bus 10142 zur EU 10122-Operandenwarteschlange. Die EU 10122-Operandenwarteschlange ist voll, wenn der Mikrobefehl, der das Lesen initiiert, abgesetzt wird.
(19) Fig. 244S; eine Anforderung an EU 10122 nach einer "Nanounterbrechung" durch FU 10120, bei dem keine Ereignisse auftreten.
(20) Fig. 244T; FU 10120 setzt eine "Nanounterbrechungs"-Anforderung an EU 10122 ab, und es tritt ein EU 10122-Zustandsüberlauf, wie er in einer folgenden Beschreibung weiter beschrieben wird, auf. Es werden keine anderen Ereignisse erkannt, wie in einer folgenden Beschreibung des EVENT 20284 beschrieben wird.
(21) Fig. 244U; FU 10120 setzt eine "Nanounterbrechungs"-Anforderung an EU 10122 ab. Ein anderes Ereignis wird während des Zustandes M0 erkannt, und es resultiert ein Abbruch. Der erste Abbruchzustand wird für das nicht EU 10122-Ereignis betreten. Alle Abbrüche, die in Zustand M0 erkannt wurden, werden vor dem Eingang in den Zustand M0 unternommen oder bestätigt. Daher wird, wenn im Zustand M0 es noch einmal versucht wird, den ursprünglichen Mikrobefehl vom Zustand M0 wieder einzugeben, der nächste Abbruch wegen eines EU 10122-Stapelspeicherüberlaufereignisses erkannt, weil der EU 10122-Stapelspeicherüberlauf eine höhere Priorität besitzt.
(22) Fig. 244V; ein Laden eines 27 Bit Mikrobefehlssegmentes in FUSITT 11012.
In den Fig. 244A bis 244V wurde pipelineverarbeitendes Lesen und Schreiben von MEM 10112 und der JP 10114-Operationen angenommen. In den Fig. 244W bis 244Z wird ein nicht überlappender Betrieb von JP 10114 angenommen.
(23) Fig. 244W; ein Lesen von Daten von MEM 10112 nach OFFMUXR 23812.
(24) Fig. 244X; ein Lesen von Daten von MEM 10112 in die EU 10122-Operandenwarteschlange.
(25) Fig. 244Y; ein Schreiben eines EU 10122-Ergebnisses in MEM 10112.
(26) Fig. 244Z; ein Lesen eines 32 Bit SIN-Wortes von MEM 10112 als Antwort auf eine Voraufnahme- oder eine bedingte Voraufnahmeanforderung.
Nachdem die allgemeine Struktur und der allgemeine Betrieb von STATE 20294 und die Betriebszustände und Operationen des CS 10110 beschrieben wurden, wird im folgenden die Struktur und der Betrieb des EVENT 20284 beschrieben.

b.b.b. Die Ereignissteuerung 20284 (Fig. 245, 246, 247, 248)

Ein Ereignis ist eine Anforderung nach einem Wechsel der Abfolge der Ausführung von Mikrobefehlen, die von der CS 10110-Schaltlogik und nicht durch die gerade ausgeführten Mikrobefehle erzeugt wird. Das Auftreten eines Ereignisses resultiert in der Bereitstellung einer Mikrobefehlsabfolge durch FUSITT 11012, die als Ereignismanager bezeichnet wird, die die CS 10110-Operationen gemäß der Bedürfnisse jenes Ereignisses modifiziert. Ereignisanforderungssignale können durch die Schaltlogik von CS 10110, die intern in JP 10114 ist, erzeugt werden, d. h. von FU 10120 oder EU 10122 oder von der CS 10110- Schaltlogik, die extern von JP 10114 liegt, z. B. von IOP 10116 oder von MEM 10112. Die Ereignisanforderungssignale werden als Eingaben für EVENT 20284 zur Verfügung gestellt. Wie unten beschrieben wird, maskiert EVENT 20284 die Ereignisanforderungen, um zu bestimmen, welche Ereignisse während eines bestimmten CS 10110-Betriebszustandes erkannt werden, es weist Prioritäten zu, um mehrfache Ereignisanforderungen zu bedienen, und erstellt Manageradressen für FUSITT 11012 für die Mikrobefehlsabfolgen, die diese Anforderungen bedienen. EVENT 20284 stellt dann jene Managermikrobefehlsadressen FUSITT 11012 durch EVNTGT 24310 zur Verfügung, um die Ausführung der ausgewählten Ereignismanagermikrobefehlsabfolgen zu initiieren.
Bestimmte Bezeichnungen und Ausdrücke werden während der gesamten folgenden Beschreibung benützt. Die folgenden Absätze definieren ihren Gebrauch und stellen Beispiele zur Verdeutlichung dieser Ausdrücke zur Verfügung. Ein Ereignis "stellt eine Anforderung", wenn eine Bedingung in der CS 10110-Hardwareoperation in einem Ereignisanforderungssignal resultiert, das EVENT 20284 zur Verfügung gestellt wird. Wie weiter unten beschrieben wird, werden diese Ereignisanforderungssignale EVENT 20284 kombinatorisch logisch zur Verfügung gestellt, das die Gültigkeit jener "Anforderungen" bestimmt.
Eine Ereignisanforderung "wird erkannt", wenn sie nicht maskiert ist, d. h. ihre Weiterverarbeitung wird verhindert. Die Maskierung kann explizit sein, indem Masken benutzt werden, die von FUSITT 11012 erzeugt wurden, oder können implizit sein und von einem unsauberen CS 10110-Zustand herrühren oder ungültig aufgrund anderer Überlegungen sein. Das heißt, bestimmte Ereignisse werden nur während bestimmter CS 10110-Zustände erkannt, obwohl jene Anforderungen während bestimmter anderer Zustände erkannt werden können. Jede Anzahl von Anforderungen, z. B. bis zu 31, können gleichzeitig erkannt werden.
Eine Ereignisanforderung wird "bedient", falls sie die Ereignisanforderung mit der höchsten Priorität ist, die auftritt. Wenn eine Anforderung bedient wird, wird eine entsprechende Adresse einer entsprechenden Mikrobefehlsabfolge in FUSITT 11012 für ihre Managermikrobefehlsabfolge auf den CSADR-Bus 20204 durch EVENT 20284 geschaltet. Eine Anforderung wird bedient, wenn CS 10110 den Zustand AB betritt. Der Zustand AB schaltet die ausgewählte Ereignismanagermikrobefehlsadresse auf den CSADR-Bus 20204.
Zusammenfassend kann eine Anzahl von Ereignissen Bedienung durch JP 10114 verlangen. Von diesen Ereignissen können alle, manche oder gar keine erkannt werden. Nur eine Ereignisanforderung, die mit der höchsten Priorität, wird bedient, wenn JP 10114 in den Zustand AB eintritt. Die Mikrobefehlssteuerung von CS 10110 transferiert dann zu jener Ereignismanagermikrobefehlsabfolge. Eine notwendige Bedingung, um in den Zustand AB einzutreten, ist, daß eine Ereignisanforderung gemacht und erkannt wurde.
Eine Mikrobefehlsabfolge "vollendet", "ist vollendet" oder "erreicht Vollendung", wenn CS 10110 den Zustand M1 verläßt, während jene Mikrobefehlsabfolge aktiv ist. Eine Mikrobefehlsabfolge kann, wie oben beschrieben, im Zustand M0 eine unbestimmte Zeit, bevor sie ihre Vollendung, wenn überhaupt, erreicht, abgebrochen werden.
Eine MEM 10112-Referenz "vollendet", "ist vollendet" oder "erreicht Vollendung", wenn die angeforderten Daten zum spezifizierten Ziel zurückgegeben werden, d. h. von MEM 10112 zum Anforderer gelesen werden, oder MEM 10112 empfängt Daten, die nach MEM 10112 geschrieben werden sollen.
"Ablaufverfolgungsfallen" sind ein inhärentes Merkmal der Mikrobefehle, die gerade ausgeführt werden. Ablaufverfolgungsfallen treten bei jedem Mikrobefehl eines gegebenen Typs (falls er nicht maskiert ist) auf, z. B. während einer Mikrobefehlsabfolge zur Durchführung einer Namensauswertung oder -auflösung, und treten bei jedem Mikrobefehl dieser Abfolge auf. Im allgemeinen muß ein Ablaufverfolgungsfallenereignis vor der Ausführung des nächsten Mikrobefehls bedient werden. Ablaufverfolgungsfallen unterscheiden sich von Unterbrechungen darin, daß eine Unterbrechung, wie unten beschrieben, nicht bei der Ausführung jedes Mikrobefehls einer Mikrobefehlsabfolge auftritt, sondern nur bei denen, wo bestimmte andere Bedingungen betrachtet werden müssen.
"Unterbrechungen" sind die größte Klasse der Ereignisse in JP 10114. Das Auftreten einer Unterbrechung kann im allgemeinen nicht für eine bestimmte Ausführung eines bestimmten Mikrobefehls zu einem bestimmten Augenblick vorhergesagt werden. Unterbrechungen erfordern ihre Bedienung vor der Ausführung des nächsten. Mikrobefehls, bevor die Ausführung des gegenwärtigen Mikrobefehls vollenden kann, oder bevor der nächste SIN beginnt. Eine Unterbrechung kann in keinem Zusammenhang mit der Ausführung irgendeines Mikrobefehls sein und wird bedient, bevor der nächste Mikrobefehl begonnen wird.
Eine "Maschinenüberprüfung" ist ein Ereignis, das JP 10114 nicht allein verwalten kann, oder dessen Auftreten weitere Aktionen von JP 10114 suspekt macht. Diese Ereignisse werden in den EVENT 20284-Registern gehalten und resultieren in einer Anforderung an DP 10118, den Betrieb von JP 10114 für nachfolgende Handlungen zu stoppen.
Zusammenfassend betrachtet gibt es drei größere Klassen von Ereignissen in CS 10110, nämlich Ablaufverfolgungsfallen, Unterbrechungen und Maschinenüberprüfungen. Alle diese Klassen von Ereignissen werden unten genauer beschrieben, beginnend mit den Ablaufverfolgungsfallen.
Der Zustand aller möglichen Ablaufverfolgungsfallen-Ereignisanforderungen, ob sie anfordern oder nicht anfordern, wird bei der Beendigung des Zustands M1 und bei der Beendigung des Zustands AB in die EVENT 20284-Register geladen. Das heißt, weil Fängeranforderungen eine Funktion des gegenwartig ausgeführten Mikrobefehls sind, wird der Zustand einer Fängeranforderung am Ende des Zustandes M1 jedes gegenwärtig ausgeführten Mikrobefehls in die EVENT 20284-Ablaufverfolgungsfallenregister geladen. In ähnlicher Weise wird, falls irgendwelche Fallenanforderungen erkannt werden, der Zustand AB am Ende des ersten Systemtaktes des nächstfolgenden Zustands M0 eintreten, und ihr Zustand wird am Ende des Zustands AB geladen.
Erkannte oder unmaskierte Fallenanforderungen können auf RCWS 10358 als hängende Anforderungen geschoben werden. Unerkannte oder maskierte Ablaufverfolgungsfallenanforderungen können auf RCWS 10358 als nicht wartende Anforderungen geschoben werden und werden im folgenden nicht beachtet. Nachfolgend können, wenn die Mikrobefehlsfolge mit einer Rückkehr zur aufrufenden Mikrobefehlsfolge endet, die Ablaufverfolgungsfallenanforderungsbits in einem RCWS 10358 dazu benutzt werden, Ablaufverfolgungsfallenereignisanforderungen zu generieren.
Beim Verlassen des Zustands AB werden alle Ablaufverfolgungsfallenanforderungen, außer Mikrohaltepunkten und Mikrobefehlsablaufverfolgungsfallen, die unten beschrieben werden, in die entsprechenden EVENT 20284-Ablaufverfolgungsfallenanforderungsregister als nicht anfordernd geladen. Mikrohaltepunkt und Mikrobefehlsablaufverfolgungsfalle werden im allgemeinen immer Puffer-gespeichert als anfordernd bei der Vollendung des Zustands AB. Ablaufverfolgungsfallen können explizit maskiert werden durch eine Spurenartenmaske, eine Untrennbarkeitsartenmaske und durch eine Spurenaktivierungseingabe, die alle von FUSITT 11012, wie unten beschrieben, erzeugt werden. Die Mikrohaltepunktfalle kann auch durch das Löschen eines Spurenaktivierungsbits in einem Spurenaktivierungsfeld von bestimmten Mikrobefehlen, die Ablaufverfolgungsfallen enthalten, maskiert werden. Im allgemeinen ist die Maskierung wirksam vom Zustand M0 des Mikrobefehls, der die Maske erzeugt, bis zur Vollendung eines Mikrobefehls, der die Maske löscht. Ablaufverfolgungsfallen, die durch einen Mikrobefehl erzeugt werden, der eine Maske löscht, werden so behandelt, als ob man einen folgenden Mikrobefehl während seines M0-Zustands abbrechen würde.
In Fig. 245 wird die Zustandszeitsteuerung für eine typische Fallenanforderung von CS 10110 und die Erzeugung einer Mikrobefehlsadresse für eine entsprechende Ablaufverfolgungsfallenmanager-mikrobefehlsabfolge durch EVENT 20284 gezeigt. Fig. 245 wurde mit denselben Konventionen, wie oben im Zusammenhang mit den Fig. 244A bis 244Z beschrieben, gezeichnet. In Fig. 245 verursacht ein Mikrobefehl, der in den Zuständen M0 und M1 ausführt, eine Ablaufverfolgungsfallenanforderung, aber er erzeugt keinen MR (Speicherreferenz)-Beendigungszustand. Die Ablaufverfolgungsfallenanforderung an EVENT 20284 wird durch Zeitpunkt A signalisiert. Diese Ablaufverfolgungsfallenanforderung wird in die EVENT 20284-Ablaufverfolgungsfallenereignisregister weitergeschoben, und eine Abbruchanforderung wird STATE 20294 zur Verfügung gestellt. Zum Zeitpunkt B tritt FU 10120 in die Zustände AB und AR ein. Die Mikrobefehlsadresse für eine Managermikrobefehlsabfolge des Ereignisses mit der höchsten Priorität, das in EVENT 20284 vorliegt, wird FUSITT 11012 präsentiert, und die Ausführung der adressierten Mikrobefehlsabfolge beginnt. Zum Zeitpunkt C verläßt FU 10120 die Zustände AB und AR und tritt in den Zustand AB ein. Der Zustand AB wird am Ende des nächsten 110 Nanosekunden-Systemtakts verlassen. Die Adresse der ausgewählten Ereignismanagermikrobefehlsabfolge verbleibt auf dem CSADR-Bus 20204 für die Dauer des Zustands AB. Zum Zeitpunkt D wird ein Zeiger in RCWS 10358, der in einer folgenden Beschreibung beschrieben wird, inkrementiert, wodurch praktisch das Rückkehrsteuerungswort des ersten Mikrobefehls, d. h. des Mikrobefehls, der beim ersten Zustand M0 ausgeführt wurde, auf RCWS 10358 geschoben. Der erste Mikrobefehl der Mikrobefehlsabfolge des Ablaufverfolgungsfallenereignismanagers wird von FUSITT 11012 zur Verfügung gestellt. Die Ausführung der Managermikrobefehlsabfolge beginnt am Anfang des dritten Zustands M0 der zeitlichen Zustandsfolge in Fig. 245. Das EVENT 20284-Ablaufverfolgungsfallenregister für dieses Ereignis wird nun in nicht anfordernden Zustand versetzt und bleibt so bis zum Übergang aus dem zweiten Zustand M1 heraus, wie es in Fig. 245 gezeigt ist. Zu diesem Zeitpunkt schieben die EVENT 20284-Register neue Fallenanforderungen weiter. Schließlich zum Zeitpunkt E, werden die Ablaufverfolgungsfallenereignisregister von EVENT 20284 mit neuen Fallenanforderungen weitergeschoben, die sich aus der Ausführung des Mikrobefehls ergeben, der in den Zuständen M0 und M1 zwischen den Zeitpunkten D und E ausgeführt wurde. Fallen aufgrund eines Mikrobefehls, der vor dem Zeitpunkt A in den Zuständen M0 und M1 ausgeführt wurde, aber nicht bedient wurde, werden wieder angefordert, wenn das vorher geschobene RCW, wie oben beschrieben, von RCWS 10358 bei der Rückkehr von der zum Zeitpunkt D initiierten Mikrobefehlsabfolge des Ablaufverfolgungsfallenereignismanagers zurückgegeben wurde. Alle Ablaufverfolgungsfallenanforderungen, die bedient worden sind, werden explizit in RCWS 10358's RCWs durch ihre Ereignismanagermikrobefehlsabfolgen gelöscht, um ein Wiederauftreten jener Fallenanforderungen zu verhindern. Da Ablaufverfolgungsfallenereignisanforderungen, die sich aus Lese- oder Schreibvorgängen nach MEM 10112 ergeben, wieder auftreten, falls jene Anforderungen wiederholt werden, erzeugt EVENT 20284 Speicherwiederholungsunterbrechungen nach jeder abgebrochenen MEM 10112-Lese- oder Schreibanforderung, um sicherzustellen, daß diese Fallen evtl. bedient werden. Die Ereignismanagermikrobefehlsabfolgen für diese Lese- und Schreibablaufverfolgungsfallenereignisse deaktivieren explizit bediente Ablaufverfolgungsfallenereignisanforderungen durch das Löschen von Bits im logischen Beschreiber der abgebrochenen Speicher-Lese- und Schreibanforderung.
Nachdem die Gesamtstruktur und der Betrieb von Ablaufverfolgungsfallenereignissen beschrieben wurden, werden bestimmte spezifische Ablaufverfolgungsfallenereignisse unten genauer beschrieben. Die Ablaufverfolgungsfallenereignisse, die in CS 10112 auftreten, können Namensablaufverfolgungsfallen, SOP-Ablaufverfolgungsfallen, Mikrobefehlsablaufverfolgungsfallen, Mikrohaltepunkt-Ablaufverfolgungsfallen, logische Schreibablaufverfolgungsfallen, logische Leseablaufverfolgungsfallen, UID-Leseablaufverfolgungsfallen und UID-Schreibablaufverfolgungsfallen beinhalten. Diese Ablaufverfolgungsfallen werden unten in der obigen Reihenfolge beschrieben.
Eine Namensspurenfalle wird bei jeder Mikrobefehlsabfolge angefordert, die eine Auswertung oder Auflösung einer Namenssilbe enthält. Namensablaufverfolgungsfallen werden durch das Dekodieren bestimmter Mikrobefehlsfelder jener Mikrobefehlsabfolgen zur Verfügung gestellt. Das Namensablaufverfolgungsfallenfeld wird entweder durch eine Spurenmaske, eine Untrennbarkeitsmaske oder durch Spurenaktivierung, wie oben beschrieben, maskiert. All diese Masken werden durch Mikrobefehlssteuersignale gesetzt und gelöscht, die während der Mikrobefehlsabfolgen zur Verfügung gestellt werden, die Aufrufe beinhalten zur Auflösung oder Auswertung von Namenssilben.
Eine SOP-Spurenfalle kann angefordert werden, wann immer FU 10120 in den Zustand FM eintritt (erster Mikrobefehl eines SOP). SOP-Ablaufverfolgungsfallen können durch Spurenmasken, Untrennbarkeitsmasken oder Ablaufverfolgungsfallenaktivierung maskiert werden, und werden auch durch Mikrobefehlssteuerausgaben von FUSITT 11012 zur Verfügung gestellt. Im allgemeinen ist der erste Mikrobefehl einer solchen Mikrobefehlsabfolge, die solche SOPs unterbricht, nicht vollendet, bevor eine Spurenfalle genommen wird.
Mikrobefehlsablaufverfolgungsfallen können bei der Vollendung von Mikrobefehlen angefordert werden, die keinen Return-Befehl beinhalten, d. h. jene Mikrobefehle, die die Mikrobefehlssteuerung von CS 10110 nicht der aufrufenden Mikrobefehlsabfolge zurückgeben. Für Mikrobefehlsabfolgen, die Return-Befehle enthalten, wird der Zustand der Mikrobefehlsablaufverfolgungsfallenanforderung in einem entsprechenden RCW benutzt. Jeder Mikrobefehl, für den eine Mikrobefehlsspurenfalle nicht maskiert ist, wird während des Zustands M0 der Ausführung jenes Mikrobefehls abgebrochen. Mikrobefehlsablaufverfolgungsfallen können durch Spurenmasken, Untrennbarkeitsmasken oder Spurenaktivierung von FUSITT 11012 maskiert werden. Eine Mikrohaltepunktfalle kann bei der Ausführung von Mikrobefehlen angefordert werden, die keine Rückkehrbefehle enthalten, in denen aber ein Spurenaktivierungsbit in einem Mikrobefehl aufgeprägt ist. Eine Mikrohaltepunktfalle kann durch eine Spurenmaske, Untrennbarkeitsmaske oder Spurenaktivierung maskiert werden. Darüber hinaus steuert ein Spurenaktivierungsbit eines Mikrobefehlsfeldes in diesen Mikrobefehlsabfolgen die Erkennung von Mikrohaltepunktfallen. Mikrohaltepunktfallen werden daher immer angefordert, wenn eine Mikrobefehlsspurenfalle angefordert wird, aber sie haben zusätzliche Aktivierungsbedingungen, die in den Mikrobefehlen ausgedrückt werden. Da nur erkannte Fallen auf RCWS 10358 in einem RCW geschoben werden, können eine Mikrobefehlsspurenfalle und eine Mikrohaltepunktfalle, die unterschiedliche Anforderungszustände haben, gleichzeitig in RCWS 10358 vorliegen.
Es können logische Schreibablaufverfolgungsfallen angefordert werden, wenn sie durch einen Bitsatz in einem logischen Beschreiber während einer Mikrobefehlsabfolge aktiviert werden, die eine Schreibanforderung für MEM 10112 absetzt und dabei logische Beschreiber gebraucht. Logische Schreibablaufverfolgungsfallen werden nur dann erkannt, wenn sie während eines Zustands auftreten, der unmittelbar vom Zustand MR (Speicherreferenzbeendigung) gefolgt wird. Eine logische Schreibspurenfalle resultiert darin, daß die Schreibanforderung nach MEM 10112 abgebrochen wird. Logische Schreibablaufverfolgungsfallen können durch Spurenmasken, Untrennbarkeitsmasken oder Ablaufverfolgungsfallenaktivierung maskiert werden. Eine weitere Bedingung für die Erkennung einer logischen Schreibspurenfalle wird durch den Zustand von bestimmten Bits in einem logischen Beschreiber der Speicherschreibanforderung bestimmt. Logische Schreibablaufverfolgungsfallen werden im allgemeinen nicht auf RCWS 10358 als Teil eines RCW geschoben, weil abgebrochene MEM 10112-Anforderungen wieder erzeugt werden, so daß logische Schreibablaufverfolgungsfallen wiederholt werden können.
Logische Leseablaufverfolgungsfallen sind in allen Beziehungen den logischen Schreibablaufverfolgungsfallen ähnlich, aber sie treten während MEM 10112-Leseanforderungen auf. Die Erzeugung von logischen Leseablaufverfolgungsfallen wird wieder teilweise durch bestimmte Bits in logischen Beschreibern der MEM 101 12-Leseanforderungen gesteuert.
In bestimmten Implementierungen von CS 10110 können UID-Ablaufverfolgungsfallen angefordert werden, wenn FU 10120 eine MEM 10112-Leseoperation anfordert, die auf einer UID-Adresse oder einem UID-Zeiger basiert. UID-Leseablaufverfolgungsfallen werden erkannt, wenn sie angefordert werden, und es gibt im allgemeinen keine explizite Maskierung von UID-Leseablaufverfolgungsfallen. Die Erzeugung der UID-Leseablaufverfolgungsfallen wird durch bestimmte Bits in logischen Beschreibern der MEM 10112- Leseanforderung gesteuert. UID-Leseablaufverfolgungsfallenanforderungen resultieren darin, daß die MEM 10112-Leseanforderungen abgebrochen werden und CS 10110 in den Zustand AB eintritt. Die Managermikrobefehlsabfolgen für die UID-Leseablaufverfolgungsfallen setzen im allgemeinen das gefangene Aktivierungsbit im logischen Beschreiber der MEM 10112-Leseanforderung zurück, bevor sie die MEM 101 12-Leseanforderung erneut absetzen.
UID-Schreibablaufverfolgungsfallen sind den UID-Leseablaufverfolgungsfallen ähnlich und werden durch Bits im logischen Beschreiber in der MEM 10112-Schreibanforderung gesteuert, die auf UID-Adressen oder UID-Zeigern basiert.
Nachdem oben die Struktur und der Betrieb der Ablaufverfolgungsfallenereignisse beschrieben wurden, werden unten die Unterbrechungsereignisse des CS 10110 beschrieben.
Wie oben beschrieben, bilden die Unterbrechungen die größte Klasse der CS 10110- Ereignisse. Man kann Unterbrechungen in eine oder mehrere verschiedene Klassen einteilen. Erstens sind die Speicherreferenz-Wiederholungsunterbrechungen jene Unterbrechungsereignisse, die im allgemeinen mit Lese- und Schreibanforderungen nach MEM 10112 assoziiert sind, in denen eine Lese- oder Schreibanforderung an MEM 10112 abgesetzt wird, und ein Unterbrechungsereignis resultiert. Das Unterbrechungsereignis wird gemanagt und die MEM 10112-Anforderung wird wiederholt. Zweitens, die Unterbrechungen mit verzögerter Bedienung sind jene Unterbrechungen, bei denen CS 10110 die Bedienung einer Unterbrechung verzögert, bis es in ein neues SIN eintritt. Viertens treten Mikrobefehlsbedienungsunterbrechungen auf, wenn ein augenblicklich ausgeführter Mikrobefehl die Hilfe einer Ereignismanagermikrobefehlsabfolge verlangt, um vollendet zu werden. Schließlich asynchrone Unterbrechungsereignisse jederzeit auftreten und müssen bedient werden, bevor CS 10110 den Zustand M0 des nächsten Mikrobefehls verlassen kann. Diese Unterbrechungsereignisse werden als nächstes unten in der obigen Reihenfolge beschrieben.
Eine Speicherreferenz-Wiederholungsunterbrechung wird angefordert, wenn z. B. ein Mikrobefehl einen Befehl ausführt und ein entsprechendes RCW-Lesen von RCWS 10358 anzeigt, daß eine Speicherreferenz vor dem Eingang in die Mikrobefehlsabfolge abgebrochen wurde, von der die Rückkehr ausgeführt wurde. Dieser Typ von Unterbrechungsereignis tritt bei allen abgebrochenen Speicherreferenzen auf. Wenn ein Ereignis für irgendein Ereignis bedient wird, d. h. in den Abbruchzustand übergegangen wird, und es noch eine ausstehende Speicherreferenz, die nicht abgebrochen ist, gibt, wird die Speicherreferenz vollendet, bevor der Zustand AB verlassen wird. Es wird keine Speicherwiederholungsunterbrechungsanforderung in RCW geschrieben, das auf RCWS 10358 geschrieben wird. Wenn im umgekehrten Sinne eine Speicherreferenz abgebrochen wird, wird eine Speicherwiederholungsunterbrechungsanforderung in ein RCW geschrieben, das auf RCWS 10358 geschoben wird, sogar wenn das Ereignis, das bedient wird, nicht jenes Ereignis ist, das die Speicherreferenz abgebrochen hat.
Es gibt zwei zeitliche Zustandsabfolgen für die Ausführung der Speicherwiederholungsunterbrechungen. Im ersten Fall gibt es keine MEM 10112-Referenzen in dem Mikrobefehl, der einen Rückkehrbefehl ausführt. Im zweiten Fall führt ein Mikrobefehl, der einen Rückkehrbefehl ausführt, eine Rückkehr aus und macht auch eine MEM 10112-Referenz. In Fig. 246 wird ein CS 10110-Zustandszeitdiagramm für den ersten Fall gezeigt. Fig. 246 wurde mit den gleichen Konventionen gezeichnet, die bei den Fig. 244 und 245 gebraucht wurden. Wie oben beschrieben, wird im ersten Fall ein Mikrobefehl in den Zuständen M0 und M1, auf den Zeitpunkt D folgend, ausgeführt, der einen Rückkehrbefehl ausführt. Eine unterbrochene MEM 10112-Referenz wurde in den Zuständen M0 und M1, die vor dem Zeitpunkt A lagen, gemacht. Eine MEM 10112-Referenz-Abbruchanforderung wird bei CS 10110's Eintritt in den Zustand MR gemacht, der dem Zeitpunkt A folgt. Da eine Speicherwiederholungsunterbrechung nur von einem RCW angefordert wird, das von RCWS 10358 zur Verfügung gestellt wird, wird eine Speicherwiederholungsunterbrechung nur angezeigt, wenn der Mikrobefehl einen Rückkehrbefehl ausführt, der darin resultiert, daß RCWS 10358 solch ein RCW zur Verfügung stellt. Daher wird ein Register für die Speicherwiederholungsunterbrechungsanforderung von EVENT 20284 mit "nicht anfordernd" zu diesem Zeitpunkt geladen. Zum Zeitpunkt B tritt CS 10110 in die Zustände AB, AR und MA ein. Zu diesem Zeitpunkt wird eine Speicherreferenzabbruchanforderung aufgeprägt und in ein RCW geschrieben, wenn der Zustand AB kurz vor dem Zeitpunkt D verlassen wird. Zum Zeitpunkt D verläßt CS 10110 den Zustand AR und den Zustand MA. Wie eben beschrieben, verbleibt CS 10110 im Zustand B bis zum Zeitpunkt D. Zum Zeitpunkt D wird die Speicherreferenzabbruchanforderung in RCWS 10358 als Teil eines RCW geschrieben und, wie unten weiter beschrieben wird, werden verschiedene RCWS-Stapelspeicherzeiger inkrementiert, um jenen RCW in RCWS 10358 zu laden. Zu diesem Zeitpunkt empfängt EVENT 20284's Unterbrechungsanforderungsregister "keine Anforderung" als Zustand der Speicherwiederholungsunterbrechung. Der erste Mikrobefehl der Managermikrobefehlsabfolge der Speicherwiederholungsunterbrechung wird von FUSITT 11012 zur Verfügung gestellt. Zum Zeitpunkt E wird der letzte Mikrobefehl der Managermikrobefehlsabfolge der Speicherwiederholungsunterbrechung von FUSITT 11012 zur Verfügung gestellt, und ein Rückkehrbefehl wird dekodiert. Der vorherige RCWS 10358-Stapelspeicherzeiger wird, wie oben beschrieben, selektiert, um RCWS 10358 zu adressieren, um das vorher geschriebene RCW als Ausgabe für EVENT 20284's Register für Speicherwiederholungsunterbrechungsereignisse zur Verfügung zu stellen. Zum Zeitpunkt F wird das Speicherwiederholungsunterbrechungsregister von EVENT 20284 vom Ausgang von RCWS 10358 geladen, und RCWS 10358's Stapelspeicherregisterzeiger werden dekrementiert. Zu diesem Zeitpunkt wird eine Speicherwiederholungsunterbrechungsanforderung gemacht und, wie unten beschrieben, in das gegenwärtige Rückkehrsteuerungswort geschrieben, ob es bedient wird oder nicht. Darauf wiederholt JP 10114 die abgebrochene MEM 10112-Referenz.
Im zweiten Fall, in dem der Mikrobefehl, der die Rückkehr ausführt, auch eine MEM 10112-Referenz macht, ist die CS 10110-Zustandszeitsteuerung identisch bis zum Zeitpunkt F. Zum Zeitpunkt F wird eine MEM 10112-Wiederholungsanforderung nicht erkannt und der Zustand der Speicherwiederholungsunterbrechung, der in das gegenwärtige Rückgabesteuerungswort geschrieben wird, ist "nicht anfordernd", außer wenn die gegenwärtige MEM 10112-Referenz unterbrochen wird. Die vorige MEM 10112-Wiederholungsunterbrechungsanforderung wird nicht beachtet, weil angenommen wird, daß sie nicht länger erforderlich ist. Daher gibt es zwei Wege, um eine Speicherwiederholungsunterbrechungsanforderung zu vermeiden oder abzubrechen. Ersten kann jener Bereich des RCW, der eine MEM 10112-Wiederholungsunterbrechungsanforderung empfängt, als "nicht anfordernd" zurückgeschrieben werden. Zweitens, es kann eine abgebrochene MEM 10112-Referenz im selben Mikrobefehl gemacht werden, der von einem Manager zurückkehrt, der die abgebrochene MEM 10112-Referenz bedient.
Bestimmte CS 10110-Ereignisse resultieren im Abbruch einer MEM 10112-Lese- oder Schreibreferenz und können in der Wiederholung der MEM 10112-Referenzen resultieren. Diese Ereignisse können enthalten:
(1) logische Lese- und Schreibfallen, und in bestimmten Implementierungen von CS 10110, UID-Lese- und Schreibfallen, wie oben besprochen;
(2) ein PC 10234-Fehler;
(3) die Aufdeckung einer Schutzverletzung durch PC 10234;
(4) eine Seitenüberquerung in einer MEM 10112-Lese- oder Schreibanforderung;
(5) eine lange Adressenübersetzung, das ist ein ATU 10228-Fehler, der von JP 10114 verlangt, einen logischen Beschreiber auszuwerten, um einen entsprechenden physikalischen Beschreiber zur Verfügung zu stellen;
(6) die Aufdeckung eines Rücksetzschmutzbitkennzeichens von ATU 10228 bei einer MEM 10112-Schreibanforderung, wie oben beschrieben;
(7) ein FU 10120-Stapelspeicherüberlauf;
(8) eine illegale FU 10120-Aufteilung;
(9) ein Namensablaufverfolgungsfallenereignis, wie oben beschrieben;
(10) eine Zurückspeicherausnahme, wie sie unten beschrieben wird;
(11) EU 10122-Ereignisse, die im Abbruch eines Zurückspeicherns, d. h. einer Schreibanforderung an MEM 10112 von EU 10122, resultieren;
(12) eine Leseanforderung an einen nicht beschleunigten Stapelspeicherrahmen, d. h. ein Stapelspeicherrahmen, der sich augenblicklich in MEM 10112 befindet, und nicht zu den JP 10114-Stapelspeichermechanismen beschleunigt wird; und
(13) bedingte Verzweigungen in SIN-Abfolgen, die ausstehende MEM 10112- Lesereferenzen von PREF 20216 ergeben;
von diesen Ereignissen wurden die logischen Lese- und Schreibfallen, die UID-Lese- und Schreibfallen und die Namensablaufverfolgungsfallen oben beschrieben. Andere Ereignisse, die oben aufgelistet sind, werden unten noch genauer beschrieben.
Eine PC 10234-Fehlerunterbrechung kann bei einer logischen MEM 10112-Referenz angefordert werden, das ist der Fall, wenn ein logischer Beschreiber als Eingabe für ATU 10228 zur Verfügung gestellt wird, und ein Schutzzustand nicht in PC 10234 zwischengespeichert ist. PC 10234 zeigt, wie oben beschrieben wurde, durch die Bereitstellung einer Ausgabe Ereignisschutzverletzung (EVENTPVIOL) für EVENT 20284 an, daß eine entsprechende Eingabe in PC 10234 nicht vorliegt. PC 10234 prägt gleichzeitig eine Abbruchausgabe (ABORT) auf, um CS 10110 in den Zustand AB zu zwingen und dadurch jene MEM 10112-Referenz abzubrechen.
Eine MEM 10112-Referenzunterbrechung wegen Seitenüberquerung wird angefordert, wenn eine logische MEM 10112-Referenz, d. h. ein logischer Beschreiber, einen Operanden spezifiziert, der sich auf zwei logischen Seiten von MEM 10112 befindet. Eine Ausgabe von ATU 10228 bricht solche MEM 10112-Referenzen durch die Aufprägung einer Abbruchausgabe (ABORT) ab.
Eine Schutzverletzungsunterbrechung wird angefordert, wenn eine logische MEM 10112- Referenz nicht saubere Zugangsrechte besitzt, eine Modusverletzung, oder wenn jene Referenz sich auf einen illegalen Bereich jenes Objektes zu beziehen scheint, eine Ausdehnungsverletzung. Wieder zeigt PC 10234 das Auftreten eines Schutzverletzungsereignisses an, das durch eine Mikrobefehlssteuerungsausgabe von FUSITT 11012 deaktiviert werden kann.
Ein langes Adressenübersetzungsereignis kann bei einer logischen MEM 10112-Referenz angefordert werden, für die ATU 10228 keine zwischengespeicherte Eingabe besitzt. ATU 10228 bricht jene MEM 10112-Referenz durch die Aufprägung der Ausgaben ABORT und Länge-Adressen-Übersetzungsereignis (EVENTLAT) ab.
Eine Schmutzbitzurücksetz-Ereignisunterbrechung kann angefordert werden, wenn JP 10114 versucht, auf eine MEM 10112-Seite zu schreiben, die eine zwischengespeicherte Eingabe in ATU 10228 hat, deren Schmutzbit nicht gesetzt ist. ATU 10228 bricht jene MEM 10112-Schreibanforderung ab durch die Aufprägung der Ausgaben ABORT und Schreibe-Lange-Adressen-Übersetzungsereignis (EVENTWLAT).
Ein FU 10120-Benutzerstapelspeicher-Überlaufereignis kann angefordert werden, wenn der Abstand zwischen einem gegenwärtigen Rahmenzeiger und dem Basisrahmenzeiger, der oben im Zusammenhang mit den CS 10110-Stapelspeichermechanismen beschrieben wurde, größer ist als ein gegebener Wert. Wie oben beschrieben, ist dieser Wert in CS 10110 acht. Ein Benutzerstapelspeicher-Überlaufereignis wird so lange weiter angefordert, bis der gegenwärtige Rahmenzeiger oder der Basisrahmenzeiger seinen Wert ändert, so daß die oben definierte Differenzenbeschränkung nicht länger verletzt wird. Ein Benutzerstapelspeicher-Überlaufereignis kann durch eine Spurenmaske, eine Untrennbarkeitsmaske oder durch Aktivierungsausgaben eines Mikrobefehls von FUSITT 11012 maskiert werden. Eine Managermikrobefehlsabfolge für Benutzerstapelspeicher-Überlaufereignisse muß ausgeführt werden, wobei eine oder mehrere dieser Masken gesetzt sind, um eine Rekursion dieser Ereignisse zu verhindern. CS 10110 soll auf dem Überwachungsstapelspeicher (MOS) 10370 laufen, wenn Benutzerstapelspeicher-Überlaufereignisse maskiert werden. Die Benutzerstapelspeicher-Überlaufereignisse werden in keines der EVENT 20284-Ereignisregister geladen und auch nicht in ein RCW geschrieben, das auf RCWS 10358 geschrieben wird.
Illegale EU 10122-Aufteilungsereignisse werden durch EUSDT 20266 angefordert, wenn FU 10120 versucht, eine initiale Mikrobefehlsabfolgenadresse aufzuteilen oder EU 10122 für eine EUSITT-Adresse zur Verfügung zu stellen, die für ein Benutzerprogramm nicht zugangbar ist. Illegale EU 10122-Aufteilungsereignisse werden im allgemeinen nicht maskiert. Illegale EU 10122-Aufteilungsereignisanforderungen werden gelöscht, wenn CS 10110 den Zustand AB verläßt. Die Managermikrobefehlsabfolge für illegale EU 10122- Aufteilungsereignisse sollte im allgemeinen die Eingänge für die illegalen EU 10122- Aufteilungsereignisse in den RCWs zurücksetzen, um eine Rekursion dieser Ereignisse zu verhindern.
EU 10122 zeigt ein Rückspeicherausnahmenereignis an, falls eine von mehreren Ausnahmebedingungen während arithmetischer Operationen auftritt. Diese Ereignisse werden erkannt, wenn CS 10110 in den Zustand SB eintritt und werden ignoriert, außer beim Zurückspeichern von EU 10122-Ergebnissen nach MEM 10112. Diese Ereignisse können von einer Mikrobefehlsausgabe von FUSITT 11012 deaktiviert werden, sie werden aber im allgemeinen nicht maskiert. Rückspeicherausnahmenereignisse können in RCWs geschrieben werden, um in RCWS 10358 abgespeichert zu werden, und sie werden gelöscht, wenn CS 10110 den Zustand AB verläßt. Wieder sollte eine Managermikrobefehlsabfolge für Rückspeicherausnahmenereignisse die Rückspeicherausnahmenereignisse, die in die RCWs geschrieben wurden, zurücksetzen, um eine Rekursion dieser Ereignisse zu vermeiden.
Wie oben beschrieben, sind die nächstgrößere Klasse der Unterbrechungsereignisse die verzögerte Bedienungsunterbrechungen. CS 10110 verzögert die Bedienung der Verzögerte-Bedienungsunterbrechungen so lange, bis ein neues SOP eintritt. Verzögerte Bedienungsunterbrechungen, die erkannt wurden, werden vor der Vollendung der Ausführung des ersten Mikrobefehls jenes neuen SOP bedient. Verzögerte Bedienungsunterbrechungen beinhalten nicht fatale MEM 10112-Fehler, Intervalltaktgeber-Überläufe und Unterbrechungen von IOS 10116. Diese Unterbrechungen werden unten in der obigen Reihenfolge beschrieben.
Eine nonfatale MEM 10112-Unterbrechung wird von MEM 10112 signalisiert, wenn ein korrigierbarer (Einzelbit)-MEM 10112-Fehler auftritt. Nonfatale Speicherfehlerunterbrechungen werden nur während des Zustands M0 des ersten Mikrobefehls eines SOPs erkannt. MEM 10112 prägt weiter die nonfatale Speicherfehlerunterbrechung auf, bis JP 10114 eine Bestätigung veranlaßt, um MEM 10112's Fehlerprotokoll zu lesen.
Eine Intervalltaktgeber-Überlaufunterbrechung wird von TIMERS 20296 angezeigt, wenn, wie oben beschrieben, ein Intervalltaktgeber nach Null inkrementiert und so anzeigt, daß die erlaubte Zeitgrenze für die Ausführung einer Operation überschritten wurde. Intervallzeitgeber-Überlaufunterbrechungen werden während des Zustands M0 des ersten Mikrobefehls eines SOPs erkannt. TIMERS 20296 fordern solche Unterbrechungen so lange an, bis sie durch eine Mikrobefehlsausgabe von FUSITT 11012 gelöscht werden.
IOS 10116 zeigt eine IOS 10116-Unterbrechung an, um anzuzeigen, daß eine Interprozessor-Nachricht von IOS 10116 nach JP 10114 hängt. IOS 10116 prägt eine IOS 10116-Unterbrechungsanforderung, die in einem Register gespeichert ist, so lange auf, bis sie durch eine Mikrobefehlssteuerungsausgabe von FUSITT 11012 gelöscht wird. Die IOS 10116-Unterbrechungen werden während des Zustands M0 des ersten Mikrobefehls eines SOP erkannt.
Die nächste größere Klasse der CS 10110-Ereignisse sind die Unterbrechungen aufgrund von Anforderungen von Mikrobefehlsabfolgen, die bedient werden müssen, um ihre Ausführung zu vollenden. Diese Unterbrechungen müssen bedient werden, bevor eine Mikrobefehlsabfolge vollendet werden kann. Mikrobefehlsbedienungsunterbrechungen beinhalten illegale SOP-Ereignisse, Mikrobefehle nicht in FUSITT 11012 vorhanden- Ereignisse, ein versuchtes Analysieren eines blockierten INSTB 20262, Unterlauf eines FU 10120-Stapelspeichers, ein NC 10226-Zwischenspeicherfehler oder ein EU 10122- Zwischenspeicherüberlauf. Jedes dieser Ereignisse wird unten in der obigen Reihenfolge beschrieben.
Ein illegales SOP-Ereignis wird von FUSDT 11010 angezeigt, um anzuzeigen, daß ein gegenwärtiger SOP-Code ein langer Code ist, d. h. größer als acht Bits ist, während der gegenwärtige Dialekt (S-Sprache) nur Kurzoperationscodes erwartet, d. h. acht Bit SOPs. Eine illegale SOP-Unterbrechung wird nicht bei nicht implementierten SOPs innerhalb des richtigen Codelängenbereichs entdeckt. Illegale SOP-Ereignisse werden im allgemeinen nicht maskiert. FUSDT 11010 zeigt weiterhin ein illegales SOP-Ereignis an, bis ein neues SOP in OPCODEREG 20268 geladen wird. Illegale SOP-Ereignisse werden während des ersten Mikrobefehls eines SOP, d. h. während des Zustandes FM erkannt. Sollte eine Managermikrobefehlsabfolge für ein Ereignis höherer Priorität die Inhalte von OPCODE- REG 20268 verändern, wird wieder ein vorheriges illegales SOP-Ereignis angezeigt, wenn das abgebrochene SOP wiederholt wird.
Die Abwesenheit eines Mikrobefehls in FUSITT 11012 wird von FUSITT 11012 durch die Aufprägung von Kontrollspeicheradresse ungültig (CSADVALID) angezeigt. Diese FUSITT 11012-Ausgabe zeigt an, daß eine spezielle Mikrobefehlsadresse außerhalb FUSITT 11012's Adreßraum liegt. Die Ausgabe von FUSITT 11012 wird bei einem solchen Ereignis nicht bestimmt und Paritätsüberprüfung der Mikrobefehlsausgabe wird verhindert. Die Managermikrobefehlsabfolge für diese Ereignisse laden die FUSITT 11012-Adresse Null mit dem angeforderten Mikrobefehl von MEM 10112, der oben beschrieben wurde, und kehren zur ursprünglichen Mikrobefehlsabfolge zurück.
Ein versuchtes Analysieren eines blockierten INSTB 20262 wird durch INSTBWC 24110 angezeigt, wenn eine Analysieroperation versucht wird, INSTB 20262 leer ist und PREF 20260 gegenwärtig nicht SINs von MEM 10112 anfordert. Im allgemeinen werden diese Ereignisse nicht maskiert. Wenn ein Ereignis höherer Priorität bedient wird, werden diese Ereignisse wieder angezeigt, wenn der abgebrochene Mikrobefehl erneut ausprobiert wird, falls die ursprünglichen Bedingungen immer noch die gleichen sind.
Ein Fu 10120-Stapelspeicher-Unterlaufereignis wird angefordert, wenn ein gegenwärtiger Mikrobefehl einen vorherigen Stapelspeicherrahmen referenziert, der nicht in einem beschleunigten Stapelspeicher ist, d. h. der gegenwärtige Stapelspeicherzeiger ist der untere Stapelspeicherzeiger. FU 10120-Unterlaufereignisse werden im allgemeinen nicht maskiert und werden bei einem wiederholten Versuch wieder angefordert, wenn der Mikrobefehl abgebrochen wurde und dieses Ereignis nicht bedient wurde.
Eine NC 10226-Fehlerunterbrechung tritt bei einer MEM 10112-Lese- oder Schreiboperation auf, wenn ein Laden oder Lesen von NC 10226 versucht wird und es keinen gültigen NC 10226-Block gibt, der jener Namenssilbe entspricht. Ein NC 10226-Fehlerereignis resultiert nicht in einer Anforderung nach einer Namensauswertung oder Namensauflösung. Im allgemeinen werden diese Ereignisse nicht maskiert und resultieren in einer Anforderung, die wieder abgesetzt wird, wenn der aus jenem Ereignis resultierende Mikrobefehl wiederholt wird und nicht bedient wurde.
Ein EU 10122-Stapelspeicher-Überlaufereignis wird von EU 10122 angefordert, um anzuzeigen, daß EU 10122 bereits gegenwärtig mindestens eine Unterbrechungsebene bedient, und FU 10120 eine andere anfordert. Wie in einer folgenden Beschreibung von EU 10122 beschrieben wird, enthält EU 10122 einen eine Ebene tiefen Stapelspeicher, um Unterbrechungen zu handhaben. Die EU 10122-Stapelspeicher-Überlaufereignisse werden während des Zustands NW aktiviert. Alle vorher hängenden Ereignisse werden bedient sein, bevor die EU 10122-Stapelspeicher-Überlaufereignisanforderungen erkannt werden. Diese Ereignisse werden sofort beim Eintritt in einen folgenden Zustand M0 bedient, weil sie die Unterbrechungsereignisse mit der höchsten Priorität sind. Die EU 10122-Stapelspeicher-Überlaufereignisse dürfen im allgemeinen nicht maskiert werden, und sind sie einmal erkannt, sind sie die nächsten, die bedient werden.
Schließlich sind die dritte größere Klasse der CS 10110-Unterbrechungsereignisse die asynchronen Ereignisse. Asynchrone Ereignisse müssen im allgemeinen bedient werden, bevor der Zustand M0 eines Mikrobefehls verlassen wird, nachdem sie erkannt wurden. Asynchrone Ereignisse beinhalten fatale Speicherfehlerereignisse, AC-Leistungsfehlerereignisse, Eieruhr-Überlaufereignisse und EU 10122-Stapelspeicher-Unterlaufereignisse. Die CS 10110-Eieruhr ist ein Teil von TIMERS 20296 und wird als Teil von TIMERS 20296 besprochen. Diese Ereignisse werden unten in der obigen Reihenfolge beschrieben.
Fatale MEM 10112-Fehlerereignisse werden von MEM 10112 durch die Aufprägung der Steuerungssignalausgabe PMODI angefordert, das oben beschrieben wurde, wenn das letzte Datum, das von MEM 10112 gelesen wurde, einen nicht korrigierbaren Fehler enthält. Fatale MEM 10112-Fehlerereignisse werden im ersten Zustand M0 nach ihrem Auftreten erkannt. Fatale MEM 10112-Fehlerereignisse werden in einem EVENT 20284- Ereignisregister gespeichert und werden beim Eintritt in ihre Bedienungsmikrobefehlsabfolge gelöscht. Im allgemeinen dürfen fatale MEM 10112-Fehlerereignisse nicht maskiert werden.
AC-Leistungsfehlerereignisse werden von DP 10118 durch die Aufprägung des Ausgabesignals ACFAAIL angezeigt, wenn DP 10118 einen Leistungsfehler in CS 10110 entdeckt. Die Erkennung von AC-Leistungsfehlerereignissen wird beim Eintritt in die Manager-Mikrobefehlsabfolge für die AC-Leistungsfehlerereignisse deaktiviert. Es werden keine weiteren AC-Leistungsfehlerereignisse erkannt, bis DP 10118 den Betrieb von JP 10114 wieder initiiert.
Wie unten beschrieben wird, ist FUCTL 20214's Eieruhr ein Teil von TIMERS 20296. Eieruhr-Überlaufereignisse werden von TIMERS 20296 angezeigt, wann immer die Eieruhr von TIMERS 20296 einen Überlauf des Eieruhrzählers anzeigt. Eieruhr-Überlaufereignisse können wie in einer folgenden Beschreibung beschrieben werden.
Schließlich werden EU 10122-Stapelspeicher-Unterlaufereignisse durch EU 10122 signalisiert, wenn es ein Wort von EU 10122's Stapelspeichermechanismen lesen soll und kein beschleunigter Stapelspeicherrahmen vorhanden ist. EU 10122 hält so lange diese Ereignisunterbrechung aufrecht, bis JP 10114 durch Initiierung einer Managermikrobefehlsabfolge diese bestätigt.
Die obigen Beschreibungen von CS 10110-Ereignissen haben festgestellt, daß die Erkennung bestimmter jener Ereignisse maskiert werden kann, d. h. gesperrt werden kann, um die Erkennung anderer Ereignisse mit höherer Priorität zu ermöglichen. Bestimmte dieser Maskierungsoperationen wurden in den obigen Beschreibungen kurz beschrieben und werden unten genauer beschrieben. Im allgemeinen kann die Erkennung von Ereignissen auf fünf verschiedenen Wegen maskiert werden, wobei vier von ihnen im eigentlichen Sinne als Masken bezeichnet werden. Diese vier Masken werden durch Mikrobefehlssteuerung von FUSITT 11012 erzeugt und beinhalten asynchrone Masken für im allgemeinen asynchrone Ereignisse. Überwachungsmasken werden für jene CS 10110- Operationen benützt, die auf den Überwachungsstapelspeicher (MOS) 10370 ausgeführt werden, wie oben im Zusammenhang mit den CS 10110-Stapelspeichermechanismen erläutert wurde. Ablaufverfolgungsmasken werden im Zusammenhang mit Ablaufverfolgungsfallenereignissen benutzt. Untrennbarkeitsmasken werden von FUSITT 11012 erzeugt oder als ein integraler oder untrennbarer Teil von bestimmten Mikrobefehlen zur Verfügung gestellt und erlauben die Erkennung bestimmter ausgewählter Ereignisse während bestimmter einzelner Mikrobefehle. Bestimmte andere Ereignisse, wie z. B. logische Lese- und Schreibfallen und UID-Lese- und Schreibfallen werden durch Kennzeichenbits in logischen Beschreibern erkannt oder maskiert, die mit jenen Operationen assoziiert sind. Schließlich resultieren bestimmte Mikrobefehle darin, daß FUSITT 11012 Mikrobefehlssteuerungsausgaben zur Verfügung stellt, die die Erkennung von bestimmten Ereignissen aktiviert oder verhindert, aber sie unterscheiden sich von Untrennbarkeitsmasken dadurch, daß sie nicht mit einzelnen bestimmten Mikrobefehlen assoziiert sind.
In Fig. 247 werden der Prioritätslevel und geeignete Masken bestimmter CS 10110- Ereignisse in drei vertikalen Spalten aufgeführt. Informationen, die die Priorität und die Maskierung bestimmter Ereignisse betreffen, werden in den horizontalen Eingängen gezeigt, die sich jeweils auf alle drei vertikalen Spalten beziehen. Die linke Spalte mit dem Titel Prioritätslevel beinhaltet die relative Priorität des Ereignisses in dieser Zelle. Die zweite Spalte mit dem Namen EVENT spezifiziert, um welches Ereignis es sich in dieser Tabellenzelle handelt. Ein bestimmtes Ereignis gewährt allen Ereignissen höherer Priorität Vorrang und hat Vorrang gegenüber allen Ereignissen niedrigerer Priorität. Die dritte Spalte in Fig. 247 mit dem Namen maskiert durch spezifiziert für jede Zeile, welche Masken benutzt werden können, um das entsprechende Ereignis zu maskieren. Ein A bedeutet den Gebrauch von asynchronen Masken, ein M den Gebrauch von Überwachungsmasken, T den Gebrauch von Ablaufverfolgungsfallenmasken und I bedeutet, daß Untrennbarkeitsmasken benutzt werden können. DES zeigt an, daß ein Ereignis durch Kennzeichenbits von logischen Beschreibern aktiviert oder maskiert wird, während MCWD anzeigt, daß ein bestimmtes Ereignis durch Mikrobefehlssteuerungssignalausgaben, die von FUSITT 11012 zur Verfügung gestellt werden, maskiert werden können. NONE zeigt an, daß ein bestimmtes Ereignis im allgemeinen nicht maskiert werden darf.
Die letzte größere Klasse der CS 10110-Ereignisse wurde oben als Maschinenüberprüfungsereignisse beschrieben. Im allgemeinen stellt EVENT 20284, falls irgendeines dieser Ereignisse von der Verknüpfungslogik in EVENT 20284 aufgedeckt wird, DP 10118 ein Maschinenüberprüfen-Signal zur Verfügung. DP 10118 stoppt dann den Betrieb von JP 10114, und es werden Managermikrobefehlsabfolgen für die Maschinenüberprüfungsereignisse initiiert. Ein Beispiel für diese Maschinenüberprüfungsereignisse sei, wenn FU 10120 es versucht, ein EU 10122-Ergebnis nach MEM 10112 zurückzuspeichern, und EU 10122 einen Paritätsfehler in EU 10122's Steuerspeicher signalisiert. Diese Ereignisse werden in den Ereignisregistern von EVENT 20284 gespeichert und erkannt, wenn FU 10120 in den Zustand AB eintritt. EU 10122 hat dann vorher seinen Betrieb unterbrochen, bis eine korrigierende Mikrobefehlsabfolge initiiert werden kann. Das gleiche Ereignis tritt auf, wenn FU 10120 versucht, ein EU 10122 arithmetisches Operationsergebnis oder Prüfergebnis zu benutzen, das einen Paritätsfehler in EU 10122's Steuerspeicher hat. Sollte MOS 10370 über- oder unterlaufen, wird dieses Ereignis entdeckt, die Operationen von FU 10120 gestoppt und korrigierende Mikrobefehlsabfolgen initiiert. Ein MOS 10370-Überlauf oder -Unterlauf tritt immer dann auf, wenn ein vorheriger MOS 10370-Stapelspeicherrahmen referenziert wird, oder der MOS 10370- Stapelspeicherzeiger gleich dem untersten MOS 10370-Stapelspeicherzeiger ist, oder der Unterschied zwischen dem gegenwärtigen und dem unteren MOS 10370-Stapelspeicherzeiger größer ist als 16. Unterläufe resultieren in einem Operationstransfer nach MJS 10368, während Überläufe durch DP 10118 verwaltet werden. Schließlich werden Maschinenüberprüfungsereignisse angezeigt, wenn ein Paritätsfehler in einem Mikrobefehl entdeckt wird, der gerade durch FUSITT 11012 während des Zustands M0 jenes Mikrobefehls zur Verfügung gestellt wird.
Nachdem der allgemeine Betrieb von EVENT 20284 beschrieben wurde, wird im folgenden die Struktur und der Betrieb von EVENT 20284 kurz beschrieben.
In Fig. 248 wird ein Ausschnitt aus einem Blockdiagramm von EVENT 20284 gezeigt. EVENT 20284 beinhaltet den Ereignisdetektor (EDET) 24810, die Ereignismasken und Registerschaltkreise (EMR) 24812 und die Ereignismanagerauswahllogik (EHS) 24814. EDET 24810 umfaßt Zufallslogikschaltungen und empfängt, wie oben beschrieben, Eingaben, die Ereignisbedingungen von anderen Bereichen von CS 10110's Schaltkreisen repräsentieren. EDET 24810 deckt das Auftreten solcher CS 10110-Betriebsbedingungen auf, die anzeigen, daß jene Ereignisse aufgetreten sind, und es stellt Ausgaben für EMR 24812 zur Verfügung, die anzeigen, welche Ereignisse angefordert werden.
EMR 24812 beinhaltet einen Registersatz, z. B. SN74S194s, die die Ereignisregister von EVENT 20284 umfassen. Diese Register werden durch Maskeneingaben, die eben beschrieben werden, aktiviert, um die Maskierung jener Ereignisse zu aktivieren, die in die Ereignisregister von EVENT 20284 geschoben werden. Bestimmte, oben beschriebene Ereignisse werden nicht geschoben, und es werden logische Schaltungen, die Maskenaktivierungseingaben besitzen, zur Verfügung gestellt, um die Maskierung jener nicht geschobenen Ereignisse zu aktivieren. Die EMR 24812-Maskeneingaben sind asynchrone, Überwachungs-, Ablaufverfolgungsfallen und Untrennbarkeitsmasken respektive AMSK, MMSK, TMSK und ISMK, die von FUSITT 11012 zur Verfügung gestellt werden. Die Maskeneingänge, die von FUSITT 11012's Mikrobefehlsausgaben (mWRD) abgeleitet werden, werden von den Mikrobefehlssteuerausgaben von FUSITT 11012 zur Verfügung gestellt. EMR 24812 stellt Ausgaben, die Maskierungs- und Demaskierungsereignisse repräsentieren, zur Verfügung, die für EHS 24814 angefordert wurden.
EHS 24814 umfaßt logische Schaltungen, die aufdecken, welche der EHS 24814 unmaskierten Ereignisanforderungen die höchste Priorität besitzt. EHS 24814 wählt die Anforderungseingabe für ein unmaskiertes Ereignis mit der höchsten Priorität aus und stellt eine entsprechende Ereignismanagermikrobefehlsadresse EVNTGT 24310 über den ADRA-Bus 24322 zur Verfügung. Diese Adressenausgaben von EHS 24814 sind fünf Bit- Adressen, die den Anfangsmikrobefehl der Ereignismanagermikrobefehlsabfolge des unmaskierten Ereignisses mit der gegenwärtig höchsten Priorität auswählen. Wie oben im Zusammenhang mit MASMUX 24312 beschrieben, sind bestimmte Eingaben von EVNTGT 24310 fest verdrahtet, um EVNTGT 24310 eine volle 15 Bit-Adreßausgabe zur Verfügung zu stellen. EVENT 20284 stellt auch von EHS 24814 für SITTNAG 20286 eine Ereignisaktivierungsselektions (EES)-Ausgabe zur Verfügung, um EVNTGT 24310 zu aktivieren, Mikrobefehlsadressen für den CSADR-Bus 20204 zur Verfügung zu stellen, wenn EVENT 20284 eine Mikrobefehlsadresse zur Verwaltung eines gegenwartigen Ereignisses zur Verfügung stellen muß.
Nachdem die Struktur und der Betrieb der Schaltkreise von FUCTL 20214 beschrieben wurden, die die Mikrobefehlsadressen für FUSITT 11012 zur Verfügung stellen, wird im folgenden FUSITT 11012 beschrieben.

c.c.c. Zugriffsseinheit-S-Interpretertabelle 11012 (Fig. 249)

In Fig. 249 wird ein Ausschnitt aus einem Blockdiagramm von FUSITT 11012 gezeigt. Die Adreß (ADR)- und Daten (DATA)-Eingänge des Mikrobefehlssteuerspeichers (mCS) 24910 sind mit dem CSADR-Bus 20204 über den Adressentreiber (ADRDRV) 24912 bzw. mit dem JPD-Bus 10142 über den Datentreiber (DDRV) 24194 verbunden. mCS 24910 umfaßt einen Speicher zur Speicherung von Mikrobefehlsabfolgen, die gerade von CS 10110 benützt werden. mCS 24910 ist ein 8K (8192) Worte mal 80 Bit breiter Speicher. Das heißt, mCS 24910 kann z. B. bis zu 8192 80 Bit breite Mikrobefehle enthalten. Mikrobefehle, die in mCS 24910 geschrieben werden sollen, werden, wie oben beschrieben, dem DATA-Eingang von mCS 24910 vom JPD-Bus 10142 über DDRV 24914 zur Verfügung gestellt. Mikrobefehlsadressen, die in mCS 24910 geschrieben werden sollen oder von dort gelesen werden sollen, werden dem ADR-Eingang von mCS 24910 vom CSADR-Bus 20204 über ADRDRV 24912 zur Verfügung gestellt. ADRDRV 24912 und DDRV 24914 sind Puffertreiber, die z. B. SN74S240s und SN74S244s umfassen.
Auch mit dem Ausgang von ADRDRV 24912 verbunden ist der Eingang der nicht vorhandenen Mikrobefehlslogik (NPmIS) 24916. NPmIS 24916 umfaßt Leseadressen zur Überwachung von logischen Schaltungen, die mCS 24910 zur Verfügung gestellt werden. Wenn eine auf dem CSADR-Bus 20204 vorhandene Mikrobefehlsleseadresse auf eine Adreßlokation nicht innerhalb mCS 24910's Adreßraum Bezug nimmt, das ist ein nicht vorhandener Mikrobefehl, erzeugt NmnIS 24916 eine Ereignisanforderungsausgabe, die dieses Auftreten anzeigt. Wie oben beschrieben, ruft FUCTL 20214 dann so von MEM 10112 adressierte Mikrobefehle auf und führt sie aus.
Wie in Fig. 249 angedeutet, stellt mCS 24910 drei Ausgabensätze zur Verfügung. Diese Ausgaben sind die direkte Ausgabe (DO), die direkte dekodierte Ausgabe (DDO) und die gepufferte dekodierte Ausgabe (BDO). Im allgemeinen wird die Steuerinformation innerhalb eines bestimmten Mikrobefehlswortes beim nächsten Systemtakt, nachdem die Adresse jenes bestimmten Mikrobefehlswortes mCS 24910's ADR-Eingang zur Verfügung gestellt wurde, benutzt. Das heißt, während eines ersten Systemtakts wird eine Mikrobefehlsadresse mCS 24910's ADR-Eingang zur Verfügung gestellt. Jener ausgewählte Mikrobefehl erscheint während jenes Systemtakts auf dem mCS 24910's DO-, DDO- und BDO-Ausgängen und wird nach der Dekodierung während des nächsten Systemtakts benutzt. Die Ausgänge DO, DDO und BDO unterscheiden sich in der Zeitverschiebung, bevor die dekodierten Mikrobefehlsausgaben für den Gebrauch verfügbar sind.
mCS 24910's DO-Ausgang stellt bestimmte Bits von Mikrobefehlsworten direkt bestimmten Zielen oder Benutzern durch direkte Ausgangspuffer (DOB) 24918 zur Verfügung. Diese Mikrobefehlsbits werden weitergeschoben und an ihren Zielorten dekodiert, wie es verlangt wird. DOB 24918 kann z. B. SN74S04s umfassen.
mCS 24910's DDO-Ausgang stellt dekodierte Mikrobefehlssteuerausgaben für Funktionen zur Verfügung, die die Präsenz von vollständig dekodierten Steuersignalen beim Beginn des Systemtakts erfordern, in dem jene dekodierten Steuersignale benutzt werden. Wie in Fig. 249 gezeigt, ist mCS 24910's DDO-Ausgang mit dem Eingang der direkten Dekodierlogik (DDL) 24920 verbunden. DDL 24920 umfaßt logische Schaltungen zur Dekodierung bestimmter Mikrobefehlswortbits während desselben Systemtakts, in dem jene Bits durch mCS 24910's DDO zur Verfügung gestellt werden. Diese Mikrobefehlsbits werden, wie oben beschrieben, während desselben Systemtakts, in dem eine entsprechende Adresse mCS 24910's ADR-Eingang zur Verfügung gestellt wird, zur Verfügung gestellt. Während dieses Systemtakts dekodiert DDL 24920 die Mikrobefehlsbits von mCS 24910's DDO, um am Ende dieses Systemtakts vollständig dekodierte Ausgaben bereit zu stellen. Die Ausgänge von DDL 24920 sind mit den Eingängen des direkten Dekodierregisters (DDR) 24922 verbunden. DDR 24922 ist ein Register, das z. B. aus SN74S374s besteht. DDL 24920's vollständig dekodierte Ausgaben werden in DDR 24922 am Ende des Systemtakts geladen, in dem, wie oben beschrieben, eine Adresse mCS 24910's ADR- Eingang zur Verfügung gestellt wird, und mCS 24910's entsprechende DDO-Ausgabe wird von DDL 24920 dekodiert. Vollständig dekodierte Mikrobefehlssteuerausgaben, die den mCS 24910's DDO-Ausgängen entsprechen, sind daher am Beginn des zweiten Systemtakts verfügbar. Mikrobefehlssteuerausgaben von DDR 24922 sind daher am Beginn des zweiten Systemtakts für FU 10120 für jene FU 10120-Operationen verfügbar, die sofortige, d. h. unverzögerte, Mikrobefehlssteuersignalausgaben von FUSITT 11012 erfordern.
Schließlich wird mCS 24910's BDO für jene FU 10120-Operationen zur Verfügung gestellt, die beim Beginn des zweiten Systemtakts nicht sofort Mikrobefehlssteuersignale erfordern. Wie in Fig. 249 gezeigt, ist mCS 24910's BDO mit den Eingängen des gepufferten Dekodierregisters (BDR) 24924) verbunden. Die Ausgabebits eines Mikrobefehlswortes von mCS 24910's BDO werden den Eingängen von BDR 24924 während des Systemtakts zur Verfügung gestellt, in dem eine entsprechende Adresse mCS 24910's ADR-Eingang zur Verfügung gestellt wird. Die Ausgaben von mCS 24910's BDO werden in BDR 24924 am Ende dieses Systemtakts geladen. BDR24924's Ausgänge sind mit den Eingängen der gepufferten Dekodierlogik (BDL) 24926 verbunden. BDL 24926 umfaßt logische Schaltungen zur Dekodierung von BDR 24924-Ausgaben. BDL 24926 stellt daher dekodierte Mikrobefehlssteuerausgaben FU 10120 einige Zeit später als zum Beginn des zweiten Systemtakts zur Verfügung. Die Mikrobefehlssteuerausgaben von BDL 24926 sind daher in bezug auf das Erscheinen der Mikrobefehlssteuerausgaben von DDR 24922 zeitverzögert, aber weil BDR 24924 Mikrobefehlswortbits anstelle von dekodierten Mikrobefehlswortbits speichert, muß BDR 24924 anteilmäßig weniger Bits als DDR 24922 speichern.
Schließlich sind, wie in Fig. 249 gezeigt, die Ausgänge von DDR 24922 und BDR 24924 mit den Eingängen des Mikrobefehlswort-Paritätsüberprüfers (mWPC) 24928 verbunden. mWPC 24928 umfaßt logische Schaltungen zur Überprüfung der Parität von Ausgaben von DDR 24922 und BDR 24924. Ein Paritätsfehler der Ausgaben von DDR 24922 oder BDR 24924 zeigt einen möglichen Fehler in der Mikrobefehlsausgabe von mCS 24910 an. Wenn ein solcher Fehler von mWPC 24928 entdeckt wird, erzeugt mWPC 24928 einen entsprechenden Mikrobefehlswort-Paritätsfehler (mWPE).

d.d. Steuerung der internen Mechanismen von CS 10110

Mit den SRs 10362, den Stapelspeichermechanismusflächen von GRF 10354, verbunden sind zwei CS 10110-Steuerstrukturen, die hauptsächlich mit dem Betrieb der internen Mechanismen von CS 10110 verbunden sind. Eine erste davon, die als Maschinensteuerungsblock bezeichnet wird, beschreibt die gegenwärtige Ausführungsumgebung eines JP 10114-Mikroprogramms, d. h. die JP 10114-Mikrobefehlsabfolgen. Der Maschinensteuerungsblock umfaßt zwei Informationsworte, die sich in MCW1 20290 und MCW0 20292 befinden. Diese Maschinensteuerungsworte enthalten alle Steuerungszustandsinformationen, die notwendig sind, um das gegenwärtige JP 10114-Mikroprogramm auszuführen. Die zweite Kontrollstruktur ist ein Bereich von RCWS 10358, der, wie oben beschrieben, eine ähnliche Struktur wie die SRs 10362 besitzt. Jeder Registerrahmen auf MIS 10368 oder MOS 10370 hat - mit Ausnahme des obersten (gegenwärtigen) Registerrahmens - ein mit sich verbundenes Rückkehrsteuerungswort (RCW), das sich in RCWS 10358 befindet. RCWs werden kreiert, wenn die MIS 10362- oder MOS 10370-Registerrahmen auf MIS 10362 oder MOS 10370 wegen der Erzeugung eines neuen gegenwärtigen Registerrahmens geschoben, d. h. bewegt, werden. Ein gegenwärtiger RCW existiert in der vorhandenen Verkörperung von CS 10110 nicht.
RCWS 10358 wird im folgenden beschrieben werden, gefolgt vom Maschinensteuerungsspeicher.

a.a.a. Stapelspeicher des Rückkehrsteuerungswortes 10358 (Fig. 251)

In Fig. 251 wird eine diagrammartige Darstellung eines RCW von RCWS 10358 gezeigt. Wie oben beschrieben, enthalten die RCWs von RCWS 10358 Informationen, die notwendig sind, um die Ausführung einer Mikrobefehlsfolge wieder aufzunehmen oder weiterzuführen, wenn die Ausführung jener Mikrobefehlsfolge unterbrochen wurde. Die Ausführung einer Mikrobefehlsabfolge kann unterbrochen werden, wenn es erforderlich ist, ein CS 10110-Ereignis, wie es oben beschrieben wurde, zu bedienen, oder falls jene Mikrobefehlsabfolge die Ausführung einer anderen Mikrobefehlsabfolge aufruft, so wie es der Fall ist in Verzweigungen oder Caseoperationen.
Wie in Fig. 251 gezeigt, kann jedes RCW z. B. 32 Informationsbits enthalten. Die RCW- Bits 16 bis 31 sind primär damit betraut, die gegenwärtigen Mikrobefehlsadressen von Mikrobefehlsabfolgen zu speichern, die unterbrochen wurden, wie es oben beschrieben wurde. Die Bits 17 bis 31 enthalten Mikrobefehlsabfolge-Rückkehradressen. Eine Rückkehradresse ist, wie oben beschrieben, die Adresse des augenblicklich ausgeführten Mikrobefehls einer Mikrobefehlsabfolge, deren Ausführung unterbrochen wurde. Wenn JP 10114 von der Bedienung eines Ereignisses oder der Ausführung einer gerufenen Mikrobefehlsabfolge zurückkehrt, wird die Rückkehradresse von RCWS 10358 für SITTNAG 20286 und durch den CSADR-Bus 20204 nach FUSITT 11012 als nächste Mikrobefehlsadresse zur Verfügung gestellt, um die Ausführung jener Mikrobefehlsabfolge wieder aufzunehmen. Das Bit 16 eines RCW enthält ein Zustandsbit, das anzeigt, ob der spezielle Mikrobefehl, auf das sich das Rückkehradreßfeld bezieht, der erste Mikrobefehl eines bestimmten SOPs ist. Das heißt, Bit 16 eines RCW speichert den CS 10110-Zustand FM.
Die Bits 8 bis 15 eines RCW beinhalten Informationen, die zum gegenwärtigen Bedingungscode von JP 10114 und zu wartenden Unterbrechungsanforderungen gehören. Insbesondere enthält Bit 8 ein Bedingungscodebit, das, wie oben beschrieben, anzeigt, ob eine bestimmte Prüfbedingung zutrifft. Das RCW-Bit 8 ist daher, wie oben beschrieben, ein Mittel, mit dem JP 10114 Ergebnisse einer bestimmten Prüfung von einer Mikrobefehlsabfolge zur anderen weitergeben kann. Die Bits 9 bis 15 eines RCW enthalten Informationen, die die augenblicklich wartenden Unterbrechungen betreffen. Diese Unterbrechungen wurden oben im allgemeinen im Zusammenhang mit EVENT 20284 besprochen. Insbesondere enthält das RCW-Bit 9 den wartenden Zustand von illegalen EU 10122-Aufteilungsunterbrechungsanforderungen; das RCW-Bit 10 enthält den wartenden Zustand von Anforderungen für Namensablaufverfolgungsfallen; das RCW-Bit 11 enthält den wartenden Zustand von Rückspeicherunterbrechungsanforderungen; das RCW-Bit 12 enthält den wartenden Zustand von Speicherwiederholungsunterbrechungsanforderungen; das RCW-Bit 13 enthält den wartenden Zustand von SOP-Ablaufverfolgungsfallenanforderungen; das RCW-Bit 14 enthält den wartenden Zustand von Anforderungen über Mikroablaufverfolgungsfallen; und das RCW-Bit 15 enthält den wartenden Zustand von Mikrohaltepunktfallenanforderungen. Die Unterbrechungen verwaltende Mikrobefehlsabfolge, die den Gebrauch der CS 10110-Mechanismen erfordert, die Informationen über wartende Unterbrechungen enthalten, müssen im allgemeinen jene Informationen sicherstellen und speichern. Diese Sicherstellungs- und Zurückspeicheroperation wird durch den Gebrauch der Bits 9 bis 15 der RCWs von RCWS 10358 durchgeführt. Beim Eintritt in eine Mikrobefehlsabfolge zur Verwaltung der Unterbrechungen werden diese Bitkennzeichen gesetzt, um die Unterbrechungen anzuzeigen, die zum Zeitpunkt des Eintritts in jene Mikrobefehlsabfolge noch ausstanden. Weil diese Bits dazu benutzt werden, Unterbrechungsanforderungen bei einer Rückkehr zu initiieren, können wartende Unterbrechungen bei einer Rückkehr durch das Zurücksetzen der geeigneten Bits der Bits 9 bis 15 abgebrochen werden. Diese Fähigkeit kann dazu benutzt werden, Mikrobefehlsablaufverfolgungsfallen, wie sie oben beschrieben wurden, zu implementieren.
Wie in Fig. 251 angezeigt, werden die RCW-Bits 0 bis 7 nicht in einer gegenwärtigen Verkörperung von CS 10110 benutzt. Die RCW-Bits 0 bis 7 sind in der gegenwärtigen Verkörperung von CS 10110 nicht implementiert, aber sie werden für zukünftigen Gebrauch in Reserve gehalten.
Wie oben beschrieben, können RCWs über den JPD-Bus 10142 in RCWS 10358 geschrieben oder von dort gelesen werden. Das ermöglicht, daß die Inhalte von RCWS 10358 anfangs wie gewünscht geschrieben werden können oder von RCWS 10358 nach MEM 10112 gelesen werden können und nachfolgend abgespeichert werden können, wie es für das Austauschen von Prozessen in CS 10110 erforderlich ist.

b.b.b. Maschinensteuerungsblock (Fig. 252)

Wie oben beschrieben, umfaßt FUCTL 20214's Maschinensteuerungsblock ein Maschinensteuerungswort 1 (MCW1) und ein Maschinensteuerungswort 0 (MCW0). MCW1 und MCW0 befinden sich in den Registern MCW1 20290 bzw. MCW0 20292. MCW1 und MCW0 beschreiben die gegenwärtige Ausführungsumgebung des gegenwärtigen Mikroprogramms von FUCT1 20214, das ist die Mikrobefehlsabfolge, die gegenwärtig von JP 10114 ausgeführt wird.
In Fig. 252 wird eine diagrammartige Darstellung von MCW0 und MCW1 gezeigt. Wie darin angezeigt, können MCW0 und MCW1 z. B. je 32 Informationsbits enthalten, die die Ausführungsumgebung des gegenwärtigen Mikroprogramms betreffen.
Sich auf MCW0 beziehend, enthält MCW0 sechs Unterfelder für die Ausführungsumgebung. Die Bits 0 bis 3 enthalten eine Unterfeld für den oberen Stapelspeicherzähler (TOSCNT), das ein Zeiger auf den gegenwärtigen Rahmen des beschleunigten Mikrostapelspeichers (MIS) 10368 ist. Das TOSCNT-Feld wird anfangs so gesetzt, daß es auf den Rahmen 1 von MIS 10368 zeigt. Die Bits 4 bis 7 umfassen ein Unterfeld für einen oberen Stapelspeicher-1-Zähler (TOS-1CNT), das ein Zeiger auf den vorherigen Rahmen des beschleunigten MIS 10368 ist, d. h. zu dem MIS 10368-Rahmen, der auf den folgt, auf den das TOSCNT-Unterfeld zeigt. Das TOS-1CNT-Unterfeld wird anfangs auf Rahmen 0 von MIS 10368 gesetzt. Die Bits 8 bis 11 umfassen ein Unterfeld für einen unteren Stapelspeicherzähler BOSCNT, der ein Zeiger auf den unteren Rahmen des beschleunigten MIS 10368 ist. Das BOSCNT-Unterfeld wird anfangs so gesetzt, daß es auf Rahmen 1 von MIS 10368 zeigt. Die TOSCNT-, TOS-1CNT- und BOSCNT-Unterfelder von MCWO können je nachdem wie Rahmen zwischen MIS 10368 und SS 10336 transferiert werden unter Mikroprogrammsteuerung inkrementiert und dekrementiert werden.
Die Bits 17 bis 23 und die Bits 24 bis 31 von MCW0 umfassen zusammen Unterfelder für ein Seitennummernregister (PNREG) und ein Wiederholungszähler (REPCTR), die zusammen eine Mikrobefehlsadresse umfassen, die auf den Mikrobefehl zeigt, der augenblicklich in FUSITT 11012 geschrieben wird.
Die Bits 12 bis 15 von MCW0 umfassen ein Eieruhr (EGGT)-Unterfeld, das unten im Zusammenhang mit TIMERS 20296 weiter beschrieben wird. Bit 16 von MCW0 wird in der gegenwärtigen Verkörperung von CS 10110 nicht benutzt.
Sich auf MCW1 beziehend, so umfaßt MCW1 vier Unterfelder. Von den 32 Bits, die MCW1 umfaßt, werden die Bits 0 bis 15 und 24 bis 25 in der gegenwärtigen Verkörperung von CS 10110 nicht benutzt. Bit 16 umfaßt ein Bedingungscode (CC)-Unterfeld, das Ergebnisse von bestimmten Überprüfungsbedingungen in JP 10114 anzeigt. Wie oben beschrieben, wird das CC-Unterfeld automatisch sichergestellt und in den RCWs von RCWS 10358 gespeichert.
Die Bits 17 bis 19 von RCW1 umfassen ein Unterbrechungsmasken (IM)-Unterfeld. Die drei Bits des IM-Unterfelds werden dazu benutzt, um eine Hierarchie der nicht unterbrechbaren JP 10114-Betriebszustände für die Mikrobefehlssteuerung anzuzeigen. Das heißt, der drei Bit-Code, der darin gespeichert ist, zeigt die relative Fähigkeit an, zwischen drei sonst nicht unterbrechbaren JP 10114-Betriebszuständen zu unterbrechen. Die Bits 20 bis 23 umfassen ein Unterbrechungsanforderungs (IR)-Unterfeld, das eine Unterbrechungsanforderung anzeigt. Diese Unterbrechungsanforderungen können beispielsweise Eieruhr-Überlauf-, Intervallzeitmesser-Überlauf- oder nicht fatale Speicherfehler, die oben beschrieben wurden, anzeigen. Schließlich umfassen die Bits 26 bis 31 ein Unterfeld für Ablaufverfolgungsfallen-Aktivierung, das anzeigt, welche Ablaufverfolgungsfallen-Ereignisse, die oben beschrieben wurden, gegenwärtig aktiviert sind. Diese Aktivierungen können Namensablaufverfolgungs-Aktivierungen, logische Nachvollzugsaktivierungen, logische Schreibablauf-Verfolgungsaktivierungen, SOP-Ablaufverfolgungsaktivierungen, Mikrobefehlsaktivierungen und Mikrobefehlshaltepunkt-Aktivierungen beinhalten.
MCW0 und MCW1 wurden oben so beschrieben, daß sie sich in Registern befinden, die individuell für sich existieren, und zwar MCW1 20290 und MCW0 20292. In einer gegenwärtigen Verkörperung von CS 10110 existieren MCW1 20290 und MCW0 20292 nicht als eine einheitliche, diskrete Registerstruktur, sondern sie umfassen statt dessen individuelle Register, die sich physikalisch in anderen Bereichen von FUCTL 20214 befinden. MCW1 20290 und MCW0 20292 und MCW1 und MCW0 wurden so beschrieben, um die in ihnen enthaltene Informationsstruktur besser voneinander abgetrennt darzustellen. Darüber hinaus wurde diese Näherung dazu benutzt, die Art und Weise zu illustrieren, durch die der gegenwärtige Ausführungszustand von JP 10114 durch den JPD- Bus 10142 gesteuert und überwacht werden kann. Wie in Fig. 202 angezeigt, haben MCW1 20290 und MCW0 20292 Ausgänge, die mit dem JPD-Bus 10142 verbunden sind und es so erlauben, den aktuellen Ausführungszustand von JP 10114 aus FUCTL 20214 herauszulesen. Die individuellen Bits oder Unterfelder von MCW0 und MCW1 können, wie oben beschrieben wurde, durch von FUSITT 11012 zur Verfügung gestellte Mikrobefehlssteuerung geschrieben werden. In einer gegenwärtigen physikalischen Verkörperung von CS 10110 befinden sich jene Register von MCW0 20292, die die Unterfelder TOSCNT, TOS-1CNT und BOSCNT beinhalten, in RAG 20288. Jene Bereiche von MCW0 20292, die das Unterfeld EGGT enthalten, befinden sich in TIMERS 20296. Die MCW0 20292-Register, die PNREG- und REPCTR-Unterfelder enthalten, umfassen physikalisch gesehen REPCTR 20280 und PNREG 20282. In MCW1 20290 existiert das CC-Unterfeld als Ausgang von FUCTL 20214's Überprüfungsschaltkreisen. Jene MCW1 20290-Register, die die IN-, IR- und TTE-Unterfelder enthalten, befinden sich innerhalb EVENT 20284.
Nachdem die FUCTL 20214-Struktur und ihr Betrieb, soweit sie RCWS 10358, MCW1 20290 und MCW0 20292 und FUCTL 20214 betreffen, beschrieben wurden, wird im folgenden RAG 20288 beschrieben.

c.c.c. Registeradressengenerator 20288 (Fig. 253)

In Fig. 253 wird ein Ausschnitt aus einem Blockdiagramm von RAG 20228 mit einer diagrammartigen Darstellung von GRF 10354, BIAS 20246 und RCWS 10358 gezeigt. Wie oben beschrieben, enthalten die JP 10114-Register und Stapelspeichermechanismen die allgemeine Registerdatei (GRF) 10354, BIAS 20246 und RCWS 10358. GRF 10354 ist in einer gegenwärtigen Verkörperung von CS 10110 ein 256 Worte mal 92 Bit breiter Registervektor. GRF 10354 ist horizontal unterteilt, um globale Register (GRs) 10360 und Stapelspeicherregister (SRs) 10362 bereit zu stellen, die jeweils 128 der 256 Register von GRF 10354 enthalten. GRF 10354, d. h. sowohl die GRs 10360 als auch die SRs 10362, ist vertikal in drei vertikale Ausschnitte unterteilt, die als AONGRF 20232, OFFGRF 20234 und LENGRF 20236 bezeichnet werden. AONGRF 20232, OFFGRF 20234 und LENGRF 2036 sind 28 Bits bzw. 32 Bits und 32 Bits breit. Die GRs 10360 werden als ein Vektor von 128 individuellen Registern benutzt, wobei jedes Register ein 92 Bit-Wort enthält. Die SRs 10362 sind strukturiert und werden benutzt als ein Vektor von 16 Registerrahmen, wobei jeder Rahmen acht Register und jedes Register ein 92 Bit breites Wort enthält. Acht dieser Sr 10362-Rahmen werden als Mikrostapelspeicher (MIS) 10362 benutzt, und die verbleibenden acht der SR 10362-Rahmen werden als Überwachungsstapelspeicher (MOS) 10370 benutzt. Lediglich für Adressierungszwecke, wie weiter unten beschrieben wird, werden die GRs 10360 betrachtet, als ob sie in der gleichen Weise wie die SRs 10362 strukturiert sind, d. h. als 16 Rahmen mit jeweils acht Registern.
BIAS 20246 ist, wie oben beschrieben wurde, ein Registervektor innerhalb BIAS 20246. BIAS 20246 enthält 128 sechs Bit breite Register oder Worte und arbeitet parallel mit dem SR 10362-Bereich von GRF 10354 und wird auch dazu parallel adressiert. RCWS 10358 ist, wie oben beschrieben, ein Vektor aus 16 Registern oder Worten, wobei jedes Register ein 32 Bit RCW enthält. RCWS 10358 ist in der gleichen Weise strukturiert und arbeitet parallel mit den SRs 10362, wobei jedes RCWS 10358-Register einem SR 10362-Rahmen mit acht Registern entspricht. Wie unten beschrieben, wird RCWS 10358 parallel mit den SR 10362-Rahmen adressiert.
Die Quellen- und Zielortregisteradressen (SDAR) zur Auswahl eines GRF 10354-Registers, von dem gelesen bzw. auf das geschrieben werden soll, werden von RAG 20288 zur Verfügung gestellt. Wie oben beschrieben wurde, arbeitet BIAS 20246 parallel mit dem SR 10362-Bereich von GRF 10354 und wird auch parallel dazu adressiert, d. h. parallel mit den SRs 10362. Die BIAS 20246-Register sind daher parallel mit den Adreßeingängen der SRs 10362 verbunden und werden gleichzeitig mit den GRs 10360 adressiert. Die RCWS 10358-Register arbeiten auch parallel mit den SRs 10362 und werden parallel adressiert. Die Adreßeingänge der RCWS 10358-Register sind daher parallel mit den Adreßeingängen der SR 10362-Register verbunden.
Die RAG 20288-Adreßeingänge für GRF 10354 und für BIAS 20246 und RCWS 10358 können in diesen Register selektieren, so daß sie entweder Quellenregister sind, d. h. Register, die Daten zur Verfügung stellen, oder Zielortregister sind, d. h. Register, die Daten empfangen. Die RAG 20288-Adreßausgänge werden als Quellen- und Zielortregisteradressenausgänge (SDADR) von RAG 20288 bezeichnet. RAG 20288's SDADR- Ausgang ist mit dem Adreßeingang des Register umfassenden GRF 10354, BIAS 20246 und RCWS 10358 verbunden. Wie oben beschrieben, sind die SRs 10362 als 16 Rahmen mit acht Registern pro Rahmen strukturiert, und RCWS 10358 ist als 16 Rahmen mit jeweils einem Register enthaltend strukturiert. GRF 10354 und BIAS 20246 sind als Einzelregister strukturiert und werden als solche gebraucht, aber werden für Adressierungszwecke so betrachtet, als ob sie 16 Rahmen mit jeweils acht Registern pro Rahmen umfassen. Jede SDADR-Ausgabe von RAG 20288 ist ein acht Bit-Wort, in dem das signifikanteste Bit anzeigt, ob das adressierte Register, sei es ein. Quellen- oder ein Zielortregister, sich in den GRs 10360 oder innerhalb der SRs 10362, BIAS 20246 und RCWS 10358 befindet. Die vier nächsten signifikantesten Bits umfassen ein Rahmenauswahlfeld zur Auswahl einer von 16 Rahmen innerhalb der GRs 10360 oder innerhalb der SRs 10362, BIAS 20246 oder RCWS 10358. Die drei niedrigstsignifikanten Bits umfassen ein Registerauswahlfeld, das ein spezielles Register auswählt innerhalb des Rahmens, der durch das Rahmenauswahlfeld ausgewählt wurde.
Innerhalb eines einzigen Systemtakts kann die SDADR-Ausgabe von RAG 20288 ein Quellenregister auswählen, und Daten können von jenem Quellenregister gelesen werden, oder die SDADR-Ausgabe kann ein Zielortregister wählen und Daten können in jenes Zielortregister geschrieben werden. Wie oben beschrieben, erfordert jeder JP 10114- Mikrobefehl wenigstens zwei Systemtakte für seine Ausführung, d. h. einen ersten Systemtakt im Zustand M0 und einen zweiten Systemtakt im Zustand M1. Während eines einzelnen Mikrobefehls kann daher ein Quellenregister ausgewählt und Daten von jenem Quellenregister gelesen werden und ein Zielortregister kann ausgewählt und Daten können in jenes Zielortregister geschrieben werden. Bestimmte Operationen können jedoch mehr als einen Mikrobefehl zu ihrer Ausführung erforderlich machen. Zum Beispiel eine Lese- Aktualisier-Schreib-Operation, in der Daten von einem bestimmten Register gelesen, abgeändert und in jenes Register zurückgeschrieben werden, können zwei oder mehr Mikrobefehle für ihre Ausführung erforderlich machen.
Indem wir uns zunächst auf RAG 20288's Struktur beziehen, so enthält RAG 20288 MISPR 10356. MISPR 10356 enthält einen oberen Stapelspeicherzähler (TOSCNT) 25310, einen oberen Stapelspeicher-1-Zähler (TOS-1CNT) 25312 und einen unteren Stapelspeicherzähler (BOSCNT) 25314. Die Inhalte von TOSCNT 25310, TOS-1CNT 25312 und BOSCNT 25314 sind Zeiger auf den gegenwärtigen bzw. den vorherigen und den unteren Rahmen der SRs 10362, d. h. Zeiger auf MIS 10368. Wie unten beschrieben wird, werden diese Zeiger auch dazu benutzt, MOS 10370 zu adressieren. TOSCNT 25310, TOS-1CNT 25312 und BOSCNT 25314 sind jeweils vier Bit-Binärzähler, die z. B. SN74S163s umfassen.
Die Dateneingänge von TOSCNT 25310 bis BOSCNT 25314 sind mit dem JPD-Bus 10142 verbunden. Die Steuereingänge von TOSCNT 25310 bis BOSCNT 25314 sind mit den Mikrobefehlssteuerausgängen von FUSITT 11012 verbunden. Die Datenausgänge von TOSCNT 25310 bis BOSCNT 25314 sind mit den Dateneingängen des Quellenregisteradressen-Multiplexers (SRCADR) 25316 und mit den Dateneingängen des Zielortregisteradressen-Multiplexers (DSTADR) 25318 verbunden. Die Datenausgänge von TOSCNT 25310 und BOSCNT 25314 sind mit den Eingängen der Stapelspeicher-Ereignisüberwachungslogik (SEM) 25320 verbunden.
Die Quellen- und Zielortrahmenadressen werden, wie unten weiter beschrieben wird, durch SRCADR 25316 bzw. DSTADR 25318 ausgewählt. Zusätzlich zu den Dateneingängen von TOSCNT 25310 und BOSCNT 25314 sind die Dateneingänge von SRCADR 25316 und DSTADR 25318 mit dem Mikrobefehlswort CONEXT-Unterfeldausgang von FUSITT 11012 verbunden. Die Steuereingänge von SRCADR 25316 und DSTADR 25318 sind mit dem Mikrobefehlswort RS- und RD-Unterfeldausgängen von FUSITT 11012 verbunden. Der Quellenrahmenadressenfeld (SRCFADR)-Ausgang von SRCADR 25316 und der Zielortrahmenadressenfeld (DSTFADR)-Ausgang von DSTADR 25318 sind mit den Eingängen des Quellen- und Zielortregisteradressen-Multiplexers (SDADRMUX) 25322 verbunden. SRCFADR und DSTFADR umfassen Rahmenauswahlfelder von RAG 20288 und SDADR-Ausgänge für Quellen- bzw. Zielortregister.
Zusätzlich zu den SRCFADR- und DSTFADR-Ausgängen von SRCADR 25316 und DSTADR 25318 empfängt SDADRMUX 25322 Mikrobefehlswort SRC- bzw. DST- Unterfeldeingaben von den Mikrobefehlsausgaben von FUSITT 11012. Wie oben beschrieben, ist ein SRC-Unterfeld eine drei Bit-Zahl, die ein Quellenregister bezeichnet, d. h. ein Quellenregister innerhalb eines von SRCFADR ausgewählten Rahmens. DST ist in ähnlicher Weise eine drei Bit-Zahl, die ein Zielortregister auswählt innerhalb eines von DSTFADR angezeigten Rahmens. Die SRC-Unterfeldeingabe für SDADRMUX 25322 wird mit SRCADR 25316 verkettet, um, wie oben beschrieben, Register bzw. Rahmenfelder einer Quellenregister SDADR-Ausgabe für SDADRMUX 25322 zu umfassen. In ähnlicher Weise wird das DST-Unterfeld mit der DSTFADR-Ausgabe von DSTADR 25318 verkettet, um Register und Rahmen-Unterfelder einer Zielortregister SDADR- Ausgabe für SDADRMUX 25322 zu umfassen. Die Auswahl zwischen Quellen- und Zielortregisteradresseneingaben für SDADRMUX 25322 zur Generierung einer entsprechenden Quellen- oder Zielortregister SDADR-Ausgabe für SDADRMUX 25322 wird durch Mikrobefehlseingaben kontrolliert (aus Übersichtlichkeitsgründen nicht gezeigt), die mit den Kontrolleingängen von SDADRMUX 25322 verbunden sind. RDWS 25324 ist ein PROM, das MD-Felder von Mikrobefehlsworten während der Lesevorgänge von MEM 10112 dekodiert und Registerauswahlfelder einer Zielortregisteradresse bereit stellt, und das einen jener Zeiger als Rahmenauswahlfeld auswählt.
Ein Ereignisausgang von SEM 25320 ist mit einem Eingang von EVENT 20284, wie oben beschrieben, verbunden. SRCADR 25316, DSTADR 25318 und SDADRMUX 25322, wie unten beschrieben, arbeiten als Multiplexer und können z. B. aus SN74S153s bestehen. Nachdem die Struktur und die Organisation von GRF 10354, BIAS 20246 und RCWS 10358, und die Struktur von RAG 20288 beschrieben wurden, wird im folgenden der Betrieb von RAG 20288, um Quellen- oder Zielortregisteradreßausgaben SDADR zu erzeugen, beschrieben. Zuerst wird die Adressierung der JP 10114-Stapelspeichermechanismen, die die SRs 10362 und RCWS 10358 umfassen, beschrieben, danach folgt die Adressierung der GRs 10360 und BIAS 20246.
Der SR 10362-Bereich von GRF 10354, RCWS 10358 und BIAS 20246 werden durch den gegenwärtigen, vorangehenden und unteren Rahmenzeiger adressiert, die in TOSCNT 25310 bzw. TOS-1CNT 25312 und BOSCNT 25314 enthalten sind. Der gegenwärtige, vorherige und untere Zeiger umfassen Rahmenauswahlfelder von SDADRMUX 25322. Wie oben beschrieben, werden die gegenwärtige, vorherige und untere Zeigerausgaben von TOSCNT 25310 bis BOSCNT 25314 als Eingaben für SRCADR 25316 und DSTADR 25318 zur Verfügung gestellt. Das Mikrobefehlswort RS-Unterfeld, das die Eingabe von SRCADR 25316 steuert, wählt entweder den gegenwärtigen, vorherigen oder den unteren Zeiger als Eingabe für SRCADR 25316 aus, um eine Ausgabe für SRCFADR von SRCADR 25316 zu umfassen, d. h. ein Rahmenauswahlfeld der Quellenregisteradresse zu sein. In ähnlicher Weise wählt das Mikrobefehlswort RD-Unterfeld zur Kontrolle der Eingabe von DSTADR 25318 entweder den gegenwärtigen, vorherigen oder unteren Zeiger als Eingabe für DSTADR 25318 aus, um DSTADR 25318's DSTFADR-Ausgabe zu umfassen, das ist das Rahmenauswahlfeld der Zielortregisteradresse. Wie oben beschrieben, werden SRCFADR und DSTFADR als Eingaben für SDADRMUX 25322 zur Verfügung gestellt. Die Mikrobefehlswort SRC- und DST-Unterfeldeingaben für SDADRMUX 25322 bestimmen gleichzeitig die Quellen- und Zielortregister innerhalb der Quellen- bzw. Zielortrahmen, die durch SRCFADR und DSTFADR spezifiziert werden. SDADRMUX 25322 wählt dann unter Mikrobefehlskontrolle arbeitend entweder SRCFADR und SRC, um die SDADR-Ausgabe für SR 10362 als Quellenregisteradresse zu umfassen, oder wählt DSTFADR und DST als SDADR-Ausgabe, die eine Zielortregisteradresse spezifiziert. Durch Mikrobefehlskontrolle von SRCADR 25316, DSTADR 25318 und SDADRMUX 25322 kann ein CS 10110-Mikroprogramm einen Quellenrahmen und Quellenregister innerhalb SR 10362 auswählen und gleichzeitig einen möglichen unterschiedlichen Zielortrahmen und unterschiedliches Zielortregister innerhalb SR 10362 spezifizieren. Alle möglichen Kombinationen von Quellenrahmen und Register und von Zielortrahmen und Register sind in den GRs 10360, SRs 10362, BIAS 20246 und RCWS 10358 gültig.
Die Steuerung von SRCADR 25316, DSTADR 25318 und SDADRMUX 25322 bei der Adressierung des SR 10362-Bereichs von GRF 10354 und RCWS 10358 wird teilweise durch den gegenwärtigen CS 10110-Zustand gesteuert. Zu den oben beschriebenen Betriebszuständen von CS 10110 zugehörig sind die Zustände M1 und RW. Wenn CS 10110 weder im Zustand RW noch im Zustand M1 ist, so wird SR 10362 durch SRCADR 25316 und das Mikrobefehlswort SRC-Unterfeld adressiert, d. h. SR 10362 und RCWS 10358 werden mit Quellenregisteradressen versorgt, wenn CS 10110 weder in den Zuständen RW noch M1 ist. Wenn CS 10110 in den Zustand M1 eintritt, so werden SR 10362 und RCWS 10358 über DSTADR 25318 und durch das Mikrobefehlswort DST- Unterfeld adressiert. Das heißt, SR 10362 und RCWS 10358 werden während des Zustands M1 mit Zielortregisteradressen versorgt. In ähnlicher Weise werden SR 10362 und RCWS 10358 mit Zielortregisteradressen versorgt, wenn CS 10110 im Zustand RW arbeitet, d. h. wenn Daten gerade von MEM 10112 gelesen werden und in SR 10362 oder RCWS 10358 geschrieben werden. In diesem Fall werden jedoch die niedrigrangigen drei Bits der Zielortregisteradresse, das ist das Registerauswahlfeld, von RDS 25324 zur Verfügung gestellt, das das Mikrobefehlswort-Unterfeld MD (Speicherzielort) dekodiert. Auch RDS 25324 stellt eine Steuereingabe zur Verfügung, die DSTADR 25318 dazu benutzt, um entweder den gegenwärtigen, vorherigen oder Basiszeiger von MISPR 10356 auszuwählen, um das Rahmenauswahlfeld der Zielortregisteradresse zu umfassen.
Wie oben festgestellt, werden das Rahmenauswahlfeld von Quellen- und Zielortregisteradressen von TOSCNT 25310, TOS-1CNT 25312 und BOSCNT 25314 zur Verfügung gestellt. Wie oben beschrieben, werden die signifikantesten Bits von Quellen- und Zielortregisteradressen auf logisch 1 oder logisch 0 gezwungen, je nachdem, ob GR 10360 oder SR 10362 oder BIAS 20246 und RCWS 10358 gerade adressiert werden. Die Inhalte von TOSCNT 25310 bis BOSCNT 25314, das sind der gegenwärtige, vorherige und Basiszeiger, werden durch Mikrobefehlssteuerausgaben von FUSITT 11012 kontrolliert. Der gegenwärtige und vorherige Zeiger ändern sich, je nachdem wie die Stapelspeicher zu MIS 10368 "heruntergedrückt" oder von MIS 10368 "heraufgedrückt" werden, und JP 10114 Aufrufe bzw. Rückkehren durchführt. In ähnlicher Weise werden der gegenwärtige, vorherige und Basiszeiger inkrementiert oder dekrementiert, je nachdem wie die MIS 10368-Rahmen zwischen MIS 10368 und MEM 10112 transferiert werden, wie es oben im Zusammenhang mit den CS 10110-Stapelspeichermechanismen beschrieben wurde.
Indem wir uns zuerst auf die Operationen des gegenwärtigen und vorherigen Zeigers beziehen, so werden der gegenwärtige und vorherige Zeiger in TOSCNT 25310 und TOS- 1CNT 25312 anfangs so gesetzt, daß sie auf die Rahmen 1 bzw. 0 von MIS 10368 zeigen und vom JPD-Bus 10142 geladen werden. TOSCNT 25310 und TOS-1CNT 25312 werden zum Zählen aktiviert, wenn zwei Bedingungen zutreffen. Die erste Bedingung hängt vom gegenwärtigen Betriebszustand von CS 10110 ab. TOSCNT 25310 und TOS-1CNT 25312 werden während des letzten Systemtakts der CS 10110-Betriebszustände M1 oder AB zum Zählen aktiviert. Die zweite Bedingung hängt davon ab, ob JP 10114 gerade einen Aufruf oder eine Rückkehr durchführt. TOSCNT 25310 und TOS-1CNT 25312 können zum Zählen aktiviert werden, wenn ein gegenwärtiger Mikrobefehl anzeigt, daß JP 10114 gerade einen Aufruf oder eine Rückkehr ausführt, oder wenn CS 10110 gerade den Zustand AB verläßt, weil das Verlassen des Zustands AB eine implizite Aufrufoperation ist. Sowohl ein Aufruf als auch ein impliziter Aufruf, d. h. ein Verlassen des Zustands AB, veranlaßt, daß TOSCNT 25310 und TOS-1CNT 25312 inkrementiert werden. Eine Rückkehr veranlaßt TOSCNT 25310 und TOS-1CNT 25312, dekrementiert zu werden.
Mit Bezug auf BOSCNT 25314, so wird der untere Rahmenzeiger anfangs vom JPD-Bus 10142 geladen, um auf MIS 10368's Rahmen 1 zu zeigen. Wieder ist die Inkrementierung oder Dekrementierung von BOSCNT 25314 vom CS 10110-Betriebszustand abhängig und davon, welche Operation ausgeführt werden soll. BOSCNT 25314 wird zum Zählen aktiviert, wenn der Zustand M1 verlassen wird. Darüber hinaus muß das DEVCMD- Unterfeld eines gegenwärtigen Mikrobefehlswortes anzeigen, daß BOSCNT 25314 inkrementiert oder dekrementiert werden muß. BOSCNT 25314 wird beim Verlassen des Zustands M1 inkrementiert oder dekrementiert, wie es durch das Unterfeld des Mikrobefehlswortes DEVCMD angezeigt wird.
SEM 25320 überwacht die relativen Werte des gegenwärtigen und unteren Zeigers, die sich in TOSCNT 25310 und BOSCNT 25314 befinden, und stellt Ausgaben für EVENT 20284 zum Zwecke der Kontrolle des Betriebes von MIS 10368 und MOS 10370 zur Verfügung. SEM 25320 umfaßt einen nur Lesespeicher, z. B. 93S427s, die den gegenwärtigen und den unteren Zeiger als Eingaben empfängt. SEM 25320 entdeckt drei Ereignisse, die beim Betrieb von TOSCNT 25310 und BOSCNT 25314 auftreten und daher im Betrieb von MIS 10368 und MOS 10370 auftreten. Erstens entdeckt SEM 25320 einen MIS 10368-Stapelspeicherüberlauf. Dieses Ereignis wird angezeigt, wenn der vorhandene Wert des gegenwärtigen Rahmenszeigers um wenigstens 8 größer ist als der vorhandene Wert des unteren Rahmenzeigers. Zweitens entdeckt SEM 25320, wenn MIS 10368 nur einen Informationsrahmen enthält. Dieses Ereignis wird angezeigt, wenn der Wert des gegenwärtigen Rahmenzeigers gleich ist mit dem Wert des unteren Rahmenzeigers. In diesem Falle befindet sich der vorherige Rahmen von MIS 10368 in MEM 10112 und muß von MEM 10112 geholt werden, bevor eine Referenz zu dem vorherigen Stapelspeicherrahmen gemacht werden kann. Drittens entdeckt SEM 25320, wenn MIS 10368 und MOS 10370 voll sind. Dieses Ereignis wird angezeigt, wenn der vorhandene Wert des gegenwärtigen Rahmenzeigers um 16 größer ist als der vorhandene Wert des unteren Rahmenzeigers. Wenn dieses Ereignis auftritt, endet jeder weitere Versuch, einen Rahmen auf MIS 10368 oder MOS 10370 zu schreiben, in einem MOS 10370-Stapelspeicherüberlauf. EVENT 20284 antwortet auf jene Ereignisse, die von SEM 25320 angezeigt werden, indem es die Ausführung einer geeigneten Ereignis-Managermikrobefehlsabfolge initiiert, wie oben beschrieben wurde. Es sollte festgestellt werden, daß MIS 10368 und MOS 10370 in derselben Weise adressiert werden, d. h. durch den Gebrauch des gegenwärtigen, vorherigen und unteren Rahmenzeigers, und bestimmter Mikrobefehlswort-Unterfelder. Der Hauptunterschied zwischen dem Betrieb von MIS 10368 und MOS 10370 ist in der Art und Weise, in der Stapelspeicherüberläufe verwaltet werden. Im Falle von MIS 10368 werden Stapelspeicherrahmen zwischen MIS 10368 und MEM 10112 transferiert, so daß MIS 10368 praktisch ein bodenloser Stapelspeicher ist. MOS 10370 hingegen enthält maximal acht Stapelspeicherrahmen in der gegenwärtigen Verkörperung von CS 10110, so daß nicht mehr als acht Ereignisse auf MOS 10370 zu einer gegebenen Zeit geschoben werden können.
GR 10360 wird in einer ähnlichen Weise wie SR 10362, BIAS 20246 und RCWS 10358 adressiert, d. h. durch SRCADR 25316, DSTADR 25318 und SDADRMUX 25322. Wieder werden die Registerauswahlfelder der Quellen- und Zielortregisteradressen durch Mikrobefehlswort SRC- und DST-Unterfelder zur Verfügung gestellt. Das Rahmenauswahlfeld der Quellen- und Zielortregisteradressen wird jedoch durch das Mikrobefehlswort CONEXT-Unterfeld spezifiziert. In diesem Fall spezifizieren die Mikrobefehlswort RS- und RD-Unterfelder, daß die Runenauswahlfelder von Quellen- und Zielortregisteradressen vom CONEXT-Unterfeld zur Verfügung gestellt werden müssen. Entsprechend stellen SRCADR 25316 und DSTADR 25318 das CONEXT-Unterfeld als SRCFADR- und DSTFADR-Eingaben für SDADRMUX 25322 zur Verfügung.
Nachdem die Struktur und der Betrieb von RAG 20288 beschrieben wurden, werden unten TIMERS 20296 beschrieben.
In Fig. 254 wird ein Ausschnitt aus einem Blockdiagramm von TIMERS 20296 gezeigt. Wie darin angezeigt, beinhaltet TIMERS 20296 das Intervallzeitmeßgerät (INTTMR) 25410, die Eieruhr (EGGTMR) 25412 und die Eieruhr-Taktaktivierungsschaltung (EGENB) 25416.

d.d.d. Zeitmeßgeräte 20296 (Fig. 254)

Indem wir zuerst auf INTTMR 25410 Bezug nehmen, besteht die Hauptfunktion von INTTMR 25410 darin, die architektonische Zeit von CS 10110, wie es oben im Zusammenhang mit den Fig. 106A und weiteren Beschreibungen der CS 10110-UID- Adressierung beschrieben wurde, zu verwalten. Wie darin beschrieben, ist ein Bereich aller UID-Adressen, die von allen CS 10110-Systemen erzeugt werden, ein Objektseriennummern (OSN)-Feld. Das OSN-Feld definiert eindeutig jedes Objekt, das durch den Betrieb von oder für den Gebrauch in einer speziellen CS 10110 kreiert wurde. Das OSN- Feld einer UID eines Objektes wird bei einem bestimmten CS 10110 durch die Bestimmung des Erzeugungszeitpunktes jenes Objektes relativ zu einem willkürlichen historischen Startzeitpunktes, der allen CS 10110-Systemen gemeinsam ist, erzeugt. Jene Zeit wird innerhalb einer Speicherstelle oder Adreßlokation von MEM 10112 verwaltet, aber durch den Betrieb von INTTMR 25410 gemessen.
INTTMR 25410 ist ein 28 Bit-Zähler, der durch eine 110 Nanosekunden-Takteingabe (110NSCLK) getaktet wird und durch eine ein Megaherz-Taktaktivierungseingabe (CLK1MHZENB) zum Zählen aktiviert wird. INTTMR 25410 kann daher mit einer ein Megaherz-Rate getaktet werden, um in ein Mikrosekundenintervallen die Zeit zu messen. Das maximale Zeitintervall, das durch INTTMR 25410 gemessen werden kann, ist daher 268.435 Sekunden.
Wie in Fig. 254 angezeigt, kann INTTMR 25410 vom JPD-Bus 10142 geladen und dorthin gelesen werden. Im Normalbetrieb wird die MEM 101 12-Lokation, die die architektonische Zeit für ein bestimmtes CS 10110 enthält, mit der gegenwärtigen architektonischen Zeit zum Zeitpunkt des Hochfahrens jenes bestimmten CS 10110 geladen werden. Gleichzeitig wird INTTMR 25410 nur mit Nullen geladen. Danach wird INTTMR 25410 in ein Mikrosekundenintervallen getaktet. Die architektonische Zeit, die in MEM 10112 gespeichert ist, wird periodisch, wenn INTTMR 25410 überläuft, in entsprechender Weise aktualisiert. Daher kann zu jeder Zeit die gegenwärtige architektonische Zeit auf eine Mikrosekunde genau durch das Lesen der architektonischen Zeit von der vorherigen aktualisierten architektonischen Zeit, die in MEM 10112 gespeichert ist, und das abgelaufene Intervall seit der letzten Aktualisierung der architektonischen Zeit von INTTMR 25410 bestimmt werden. Beim Auftreten eines Fehlers von CS 10110 kann die architektonische Zeit in MEM 10112 und INTTMR 25410 in MEM 10112 durch das Lesen des abgelaufenen Zeitintervalls seit der letzten Änderung der architektonischen Zeit gesichert werden. Wenn der Normalbetrieb von CS 10110 wieder aufgenommen wird, kann INTTMR 25410 mit einem Betrag geladen werden, der die gegenwärtige architektonische Zeit repräsentiert. Wie in Fig. 254 gezeigt, wird INTTMR 25410 vom JPD-Bus 10142 geladen, wenn INTTMR 25410 durch eine Ladeaktivierungseingabe (LDE), die von DP 10118 zur Verfügung gestellt wird, aktiviert wird.
Indem wir uns auf EGGTMR 25412 beziehen, so werden bestimmte CS 10110-Ereignisse, insbesondere die asynchronen Ereignisse, die oben im Zusammenhang mit EVENT 20284 beschrieben wurden, durch EVENT 20284 bei der Beendigung des Zustands M1 des ersten Mikrobefehls eines SOP empfangen oder bestätigt. Da bestimmte CS 10110- Mikrobefehle lange Ausführungszeiten haben, können diese asynchronen Ereignisse einem ausgedehnten Latenz- oder Warteintervall unterworfen werden, bevor sie bedient werden. EGGTMR 25412 mißt die tatsächliche Latenzzeit wartender asynchroner Ereignisse und stellt EVENT 20284 eine Ausgabe zur Verfügung, wenn eine vorher bestimmte maximale Latenzzeit überschritten wird.
Wie in Fig 254 angedeutet, wird EGGTMR 25412 durch eine 110 Nanosekunden-Takteingabe (110NSCLK) getaktet. EGGTMR 25412 wird anfangs durch eine Ladeeingabe (LDZRO) am Ende des Zustands M1 des ersten Mikrobefehls eines jeden SOP, das von CS 10110 ausgeführt wird, auf Null gesetzt oder auch, wenn es spezifisch so durch das DEVCMD-Unterfeld eines Mikrobefehlswortes instruiert wird. EGGTMR 25412 wird inkrementiert, wenn es dazu durch eine Taktaktivierungseingabe (CLKNB) von EG- GENB 25416 aktiviert wird. Es gibt zwei notwendige Bedingungen für EGGTMR 25412, um inkrementiert zu werden. Die erste Bedingung ist das Auftreten eines asynchronen Ereignisses, das durch die Eingabe ASYEVNT von EVENT 20284 für EGGENB 25416 angezeigt wird. Die zweite Bedingung ist, daß mindestens 16 Mikrosekunden seit der letzten Inkrementierung von EGGTMR 25412 vergangen sind. Dieses Intervall wird durch einen vier Bit-Ausgang von INTTMR 25410 gemessen, der, wie in Fig. 254 gezeigt, mit einem Eingang von EGGENB 25416 verbunden ist. EGGTMR 25412 ist ein vier Bit- Zähler und läuft daher über und erzeugt eine Ausgabe OVRFLW für EVENT 20284 256 Mikrosekunden nach dem Beginn eines SOP, falls ein asynchrones Ereignis aufgetreten ist, und mindestens 16 Mikrosekunden seit dem Beginn jenes SOP vergangen sind. EGGTMR 25412 garantiert daher eine maximale Bedienungslatenzzeit von 256 Mikrosekunden für asynchrone Ereignisse.

e.e.e. Zugriffseinheit 10120's Schnittstelle zur Ausführungseinheit 10122

Schließlich umfaßt, wie oben beschrieben, die Schnittstelle von FU 10120 zu EU 10122 hauptsächlich den EUDIS-Bus 20206 für die Bereitstellung von EUDPs für EUSITT von EU 10122 und FUINT 20298. Der Betrieb von EUSDT 20266 und EUDIS-Bus 20206 wurden oben beschrieben und werden weiter in einer folgenden Beschreibung von EU 10122 beschrieben. FUINT 20298 ist hauptsächlich mit der Erzeugung von Ereignisanforderungen für von EU 10122 signalisierte Bedingungen betraut, so daß diese Ereignisse bedient werden können. In dieser Hinsicht umfaßt FUINT 20298 hauptsächlich Schaltungen, die Ereignisanforderungen von EU 10122 empfangen und entsprechende Ausgaben für EVENT 20284 bereitstellen. Eine andere Schnittstellenfunktion, die von FUINT 20298 ausgeführt wird, ist die Erzeugung eines "Transfer-vollständig"-Signal, das von FU 10120 erzeugt wird und EU 10122 zur Verfügung gestellt wird, um sicherzustellen, daß ein von EU 10122 erzeugtes und von dort nach FU 10120 gelesenes Ergebnis empfangen wurde. Dieses Transfer-vollständig-Signal zeigt EU 10122 an, daß EU 10122's Ergebnisregister, das in einer folgenden Beschreibung von EU 10122 beschrieben wird, für weitere Nutzung durch EU 10122 verfügbar ist. Dieses Transfer-vollständig-Signal wird durch eine Ausgabe von FUSITT 11012 als Teil einer Mikrobefehlsabfolge für den Transfer von Daten von EU 10122 nach FU 10120 oder MEM 10112 erzeugt.
Nachdem die Struktur und der Betrieb von FU 10120 einschließlich DESP 20210, MEMINT 20212 und FUCTL 20214 beschrieben wurde, werden unten die Struktur und der Betrieb von EU 10122 beschrieben.

C. Ausführungseinheit 10122 (Fig. 203, 255-268)

Wie oben beschrieben, ist EU 10122 ein arithmetisches Prozessor, der imstande ist, arithmetische Operationen mit Ganzzahlen, gepackten und ungepackten Dezimalzahlen und Fließkommazahlen einfacher und doppelter Genauigkeit durchzuführen. Eine Hauptfunktion von EU 10122 ist es, FU 10120 von bestimmten arithmetischen Operationen zu entbinden, um so die Effektivität von CS 10110 zu vergrößern.
Der Operandentransfer von MEM 10112 nach EU 10122 wird durch FU 10120 genauso wie der Transfer von Ergebnissen von arithmetischen Operationen von EU 10122 nach FU 10120 oder MEM 10112 durch FU 10120 kontrolliert. Darüber hinaus werden EU 10122- Operationen durch FU 10120 durch von EUSDT 20266 für EU 10122 bereitgestellte EU 10122-Aufteilungszeiger initiiert. Die EU 10122-Aufteilungszeiger können sowohl die für die Ausführung von SINs erforderlichen arithmetischen Operationen als auch bestimmte EU 10122-Operationen initiieren, die beim Management der CS 10110-Ereignisse helfen. Wie oben beschrieben, werden die EU 10122-Aufteilungszeiger in Mikrobefehlsabfolgen zur Steuerung von EU 10122 durch EU 10122's EUSITT übersetzt, das in Struktur und Betrieb FUSITT 11012 ähnlich ist. Wie unten weiter beschrieben wird, beinhaltet EU 10122 eine Warteschlange für das Empfangen und Speichern von EU 10122-Aufteilungszeigerabfolgen von FU 10120. Darüber hinaus beinhaltet EU 10122 eine allgemeine Registerdatei oder einen Schnellspeicher, der GRF 10354 ähnlich ist. EU 10122's allgemeine Registerdatei wird teilweise bei den EU 10122-Stapelspeichermechanismen ähnlich wie die SRs 10362 von FU 10120 benutzt.
In Fig. 203 wird ein Ausschnitt aus einem Blockdiagramm von EU 10122 gezeigt. EU 10122's allgemeine Struktur und Betrieb werden zuerst mit Bezug auf Fig. 203 beschrieben. Dann wird EU 10122's Struktur und Betrieb mit weiteren Einzelheiten mit der Hilfe von nachfolgenden Figuren beschrieben, die je nach Erfordernissen vorgestellt werden.
Wie in Fig. 203 angezeigt, beinhalten die Hauptelemente von EU 10122 die Ausführungseinheit Steuerlogik (EUCL) 20310, den Ausführungseinheits-IO-Puffer (EUIO) 20312, die Multiplizierlogik (MULT) 20314, die Exponentenlogik (EXP) 29316, die Multipliziersteuerlogik (MULTCNTt) 20318 und die Prüfungs- und Schnittstellenlogik (TSTINT) 20320. EUCL 20310 empfängt die Aufteilungszeiger (EUDPs) der Ausführungseinheit von EUSDT 20266 und stellt entsprechende Mikrobefehlsabfolgen zur Verfügung, um den Betrieb von EU 10122 zu steuern.
EUIO 20312 empfängt Operanden oder Daten von MEM 10112, und übersetzt jene Operanden in bestimmte Formate, die von EU 10122 am wirksamsten benutzt werden können. EUIO 20312 empfängt Ergebnisse der EU 10122-Operationen und übersetzt jene Ergebnisse in MEM 10112 oder FU 10120 zu übergebende Formate, und stellt jene Resultate MEM 10112 und FU 10120 zur Verfügung.
MULT 20314 und EXP 20316 sind arithmetische Einheiten zur Durchführung von arithmetischen Manipulationen der EU 10122-Operationen. Insbesondere führt EXP 20316 Operationen hinsichtlich der Exponentenfelder von Gleitkommaoperationen einfacher und doppelter Genauigkeit durch. MULT 20314 führt arithmetische Manipulationen hinsichtlich der Mantissenfelder bei Gleitkommaoperationen einfacher und doppelter Genauigkeit, und bei arithmetischen Operationen hinsichtlich Ganzzahl- und gepackter Dezimalzahloperationen durch. MULTCNTL 20318 steuert und koordiniert den Betrieb von MULT 20314 und EXP 20316 und die Vorausrichtung und Normalisierung der Mantissen- und Exponentenfelder bei Gleitkommaoperationen. Schließlich führt TSTINT 20320 bestimmte Prüfoperationen hinsichtlich der EU 10122-Operationen durch und ist die Schnittstelle zwischen EU 10122 und FU 10120.

a. Allgemeine Struktur von EU 10122

1. I/O der Ausführungseinheit 20312

Indem wir uns zuerst auf EUIO 20312 beziehen, so beinhaltet EUIO 20312 den Operandenpuffer (OPB) 20322, den Endergebnisausgabemultiplexer (FROM) 20324 und den Exponentenausgabemultiplexer (EXOM) 20326. OPB 20322 hat erste und zweite Eingänge, die mit dem MOD-Bus 10144 bzw. dem JPD-Bus 10142 verbunden sind. OPB 20322 hat einen ersten Ausgang, der mit einem ersten Eingang des Multipliziereingaben- Multiplexers (MULTIM) 20328 und MULT 20314 verbunden ist. Ein zweiter Ausgang von OPB 20322 ist mit den ersten Eingängen des Eingabenselektors A (INSELA) 20330 und des Eingabenmultiplexers der allgemeinen Registerdatei der Exponentenausführungseinheit (EXRM) 20332 in EXP 20316 verbunden.
FROM 20324 hat einen Ausgang, der mit dem JPD-Bus 10142 verbunden ist. Ein erster Eingang von FROM 20324 ist mit dem Eingangsmultiplexer der Multiplizierausführungseinheit in der allgemeinen Registerdatei (MULTRM) 20334 und MULT 20314 verbunden. Ein zweiter Eingang von FROM 20324 ist mit dem Ausgang des Endergebnisregisters (RFR) 20336 von MULT 20314 verbunden. EXOM 20326 hat einen Ausgang, der mit dem JPD-Bus 10142 verbunden ist. EXOM 20326 hat einen ersten Eingang, der mit dem Ausgang des Skalenregister (SCALER) 20338 von EXP 20316 verbunden ist. EXOM 20326 hat einen zweiten und dritten Eingang, die mit dem nächste-Adressen-Generator (NAG) 20340 bzw. der Befehlswarteschlange (COMQ) 20342 von EUCL 20310 verbunden sind.

2. Steuerlogik der Ausführungseinheit 20310

Indem wir uns auf EUCL 20310 beziehen, so beinhaltet EUCL 20310 NAG 20340, COMQ 20342, die S-Interpretertabelle der Ausführungseinheit (EUSITT) 20344 und die Mikrobefehlssteuerregister- und Dekodierlogik (mCRD) 20346. COMQ 20342 hat einen Eingang, der mit dem EUDIS-Bus 20206 für den Empfang von SDPs von EUSDT 20266 verbunden ist. COMQ 20342 hat, wie oben beschrieben wurde, einen ersten Ausgang, der mit einem dritten Eingang von EXOM 20326 verbunden ist, und hat einen zweiten Ausgang, der mit einem Eingang von NAG 20340 verbunden ist. NAG 20340 hat, wie oben beschrieben wurde, einen ersten Ausgang, der mit dem zweiten Eingang von EXOM 20326 verbunden ist. NAG 20340 hat einen zweiten Ausgang, der mit einem ersten Eingang von EUSITT 20344 verbunden ist. Wie oben beschrieben, entspricht EUSITT 20344 FUSITT 11012 und speichert Mikrobefehlssequenzen zur Steuerung des Betriebes von EU 10122 als Antwort auf die EU 10122-Aufteilungszeiger von FU 10120. EUSITT 20344 hat einen zweiten Eingang, der mit dem JPD-Bus 10142 verbunden ist, und hat einen Ausgang, der mit dem Eingang von mCRD 20346 verbunden ist. mCRD 20346 beinhaltet ein Register und eine Logik für den Empfang und das Dekodieren von Mikrobefehlen, die von EUSITT 20344 zur Verfügung gestellt werden. Zusätzlich zu einem Eingang von EUSITT 20344 hat mCRD 20346 Ausgänge, die dekodierte Mikrobefehlssteuersignale allen Stellen von EU 10122 zur Verfügung stellen. mCRD 20346 hat auch einen zweiten Ausgang, der mit einem ersten Eingang des Eingabenauswählers B (IN- SELB) 20348 und mit EXP 20316 verbunden ist.

3. Multipliziererlogik 20314

Indem wir auf MULT 20314 Bezug nehmen, so beinhaltet MULT 20314 zwei parallele arithmetische Operationspfade für die Durchführung von Additions-, Subtraktions-, Multiplikations- und Divisionsoperationen mit gepackten Dezimalzahlen, ganzen Zahlen und den Mantissenbereichen von Gleitkommazahlen einfacher und doppelter Genauigkeit. MULT 20314 beinhaltet auch einen verwandten Bereich in EU 10122's allgemeiner Registerdatei, einen Speicher für das Abspeichern von in arithmetischen Operationen benutzten Konstanten und bestimmte Eingangsdatenselektionsschaltkreise. Jener Bereich der GRF von EU 10122, der sich in MULT 20314 befindet, umfaßt die Multiplizierregisterdatei (MULTRF) 20350. Der Ausgang von MULTRF 20350 ist mit einem zweiten Eingang von MULTIM 20328 verbunden. Ein erster Eingang von MULTRF 20350 ist mit einem Ausgang von RFR 20336 verbunden, und ein zweiter Eingang von MULTRF 20350 ist mit einem Ausgang von MULTRM 20334 verbunden. Der erste und der zweite Eingang von MULTRM 20334 sind wiederum mit dem Ausgang von RFR 20336 bzw. dem Ausgang der Behältergrößenlogik (CONSIZE) 20352 von TSTINT 20320 verbunden.
MULTIM 20328 wählt die Eingabedaten für MULT 20314's arithmetische Schaltkreise und hat, wie oben beschrieben wurde, einen ersten und zweiten Eingang, der mit einem ersten Ausgang von OPB 20322 bzw. mit dem Ausgang von MULTRF 20350 verbunden ist. Der Ausgang von MULTIM 20328 ist über den Multiplizier (MULT)-Bus 20354 mit dem Eingang des Multiplizierquotientenregisters (MQR) 20356 und mit dem Eingang des Halbbyteverschiebers (NIBSHF) 20358 verbunden. Ein anderer Eingang für MQR 20356 und NIBSHF 20358 wird durch den Konstantenspeicher (CONST) 20360 zur Verfügung gestellt. CONST 20360 ist ein Speicher für das Speichern von konstanten Werten, die bei MULT 20314-Operationen benutzt werden. Der Ausgang von CONST 20360 ist mit dem MULT-Bus 20354 verbunden. Dadurch können die arithmetischen Schaltkreise von MULT 20314 mit den Eingaben von OPB 20322, MULTRF 20350 und CONST 20360 versorgt werden.
MULT 20314's arithmetischer Schaltkreis umfaßt zwei parallele arithmetische Operationspfade, die als gemeinsame Eingänge die Ausgänge von MULTIM 20328 und CONST 20360 haben. Das gemeinsame Ende dieser parallelen arithmetischen Operationspfade ist der Endregisterverschieber (FRS) 20362. Ein erster Pfad für arithmetische Operationen wird durch NIBSHF 20358 zur Verfügung gestellt, dessen Eingang mit dem MULT-Bus 20354 verbunden ist. Der Ausgang von NIBSHF 20358 ist mit einem ersten Eingang von FRS 20362 verbunden und ein Steuereingang von NRBSHF 20358 ist mit einem Ausgang der Multipliziersteuerlogik (MULTCNT) 20364 und MULTCNTL 20318 verbunden.
Der zweite Pfad für arithmetische Operationen von MULT 20314 wird durch MQR 20356 zur Verfügung gestellt. Wie oben beschrieben, ist MQR 20356's Eingang mit dem MULT-Bus 20354 verbunden. MQR 20356's Ausgang ist mit einem ersten und zweiten Eingang der mal 1 und mal 2-Multiplizierschieber (MULTSHFT12) 20366 und den mal 4 und mal 8-Multiplizierschiebern (MULTSHFT48) 20368 verbunden. Die Ausgänge von MULTSHFT12 und MULTSHFT48 sind mit einem ersten bzw. einem zweiten Eingang der ersten Multiplizier-arithmetischen und logischen Einheit (MULTALU1) 20370 verbunden. MULTALU1 20370's Ausgang ist mit dem Eingang des Multiplizierarbeitsregisters (MWR) 20372 verbunden. Der Ausgang von MWR 20372 ist mit einem ersten Eingang der zweiten Multiplizier-arithmetischen und logischen Einheit (MULTALU2) 20374 verbunden. Ein zweiter Eingang von MULTALU2 20374 ist mit dem Ausgang von RFR 20336 verbunden. Der Ausgang von MULTALU2 ist mit einem zweiten Eingang von FRS 20362 verbunden. Wie oben beschrieben, ist der erste Eingang von FRS 20362 mit dem Ausgang von NIBSHF 20368 verbunden. Der Ausgang von FRS 20362 ist mit dem Eingang von RFR 20336 verbunden.
Wie oben beschrieben, ist der Ausgang von RFR 20336 mit dem zweiten Eingang von MULTALU2 20374, mit dem ersten Eingang von MULTRF 20350, mit dem ersten Eingang von MULTRM 20334 und mit einem zweiten Eingang von FROM 20324 verbunden. Der Ausgang von RFR 20336 ist auch mit dem Eingang des führenden Nullendetektors (LZD) 20376 von MULTCNTL 20318 und mit den Eingängen der Ausnahmenlogik (ECPT) 20378, CONSIZE 20352 und TSTINT 20320 verbunden.

4. Exponentenlogik 20316

Indem wir auf EXP 20316 Bezug nehmen, so führt, wie oben beschrieben, EXP 20316 bestimmte Operationen hinsichtlich der Exponentenfelder von Gleitkommazahlen einfacher und doppelter Genauigkeit in Gleitkommaoperationen in EU 10122 durch. EXP 20316 beinhaltet einen zweiten Bereich der EU 10122 allgemeinen Registerdatei, die hier als Exponentenregisterdatei (EXPRF) 20380 geführt wird. Obwohl sie als individuelle Registerdateien geführt werden, umfassen MULTRF 20350 und EXPRF 20380, wie in GRF 10354 eine einheitliche Registerdateistruktur mit einer gemeinsamen parallelen Adressierung der entsprechenden Register darin.
Der Ausgang von EXPRF 20380 ist mit einem zweiten Eingang von INSELA 20330 verbunden. Ein erster Eingang von EXPRF 20380 ist mit dem Ausgang von EXRM 20332 verbunden. Wie oben beschrieben, ist ein erster Eingang von EXRM 20332 mit dem zweiten Ausgang von OPB 20322 über den EXPQ-Bus 20325 verbunden. Ein zweiter Eingang von EXRM 20332 ist mit dem Ausgang des Skalierungsregisters (SCALER) 20338 verbunden. Ein zweiter Eingang von EXPRF 20380 ist mit dem Ausgang der Vorzeichenlogik (SIGN) 20382 verbunden. Der Eingang von SIGN 20382 ist mit dem zweiten Ausgang von SCALER 20338 verbunden.
INSELA 20330, INSELB 20348, die Exponenten-ALU (EXPALU) 20384 und SCALER 20338 umfassen die arithmetischen Schaltkreise von EXP 20316 zur Manipulation der Exponentenfelder von Gleitkommazahlen. INSELA 20330 und INSELB 20348 selektieren den ersten bzw. zweiten Eingang für EXPALU 20384. Wie oben beschrieben, ist ein erster Eingang von INSELA 20330 mit dem zweiten Ausgang von OPB 20322 über den EXPQ-Bus 20325 verbunden. Der zweite Eingang von INSELA 20330 ist mit dem Ausgang von EXPRF 20380 verbunden. Der Ausgang von INSELA 20330 ist mit dem ersten Eingang von EXPALU 20384 verbunden. Der erste Eingang von INSELB 20348 ist, wie oben beschrieben wurde, mit einem zweiten Ausgang von mCRD 20346 verbunden. Der zweite Eingang von INSELB 20348 ist mit dem Ausgang von OPB 20322 über den EXPQ-Bus 20325 verbunden. Der dritte Eingang von INSELB 20348 ist mit dem Ausgang des SCALER 20338 verbunden, und der vierte Eingang von INSELB 20348 ist mit dem Ausgang von LZD 20376 verbunden. Der Ausgang von INSELB 20348 ist mit dem zweiten Eingang von EXPALU 20384 verbunden. Der Ausgang von EXPALU 20384 ist mit dem Eingang SCALER 20338 verbunden.
Wie oben beschrieben, ist der zweite Ausgang von SCALER 20338 mit dem Eingang von SIGN 20382 verbunden, und der erste Ausgang ist mit dem zweiten Eingang von EXRM 20332 und dem dritten Eingang von INSELB 20348 verbunden. Der erste Ausgang von SCALER 20338 ist auch mit dem EXPQ-Bus 20325, dem ersten Eingang von EXOM 20326 und einem zweiten Eingang von MULTCNT 20364 verbunden.

5. Multipliziersteuerung 20318

Wie oben beschrieben, stellt MULTCNTL 20318 bestimmte Steuersignale und Informationen zur Steuerung und Koordinierung des Betriebs von EXP 20316 und MULT 20314 bei der Durchführung arithmetischer Operationen mit Gleitkommazahlen zur Verfügung. MULTCNTL 20318 beinhaltet LZD 20376 und MULTCNT 20364. Der Eingang von LZD 20376 ist mit dem Ausgang von RFR 20336 über den FR-Bus 20337 verbunden. Der Ausgang von LZD 20376 ist mit einem zweiten Eingang von MULTCNT 20364 und einem vierten Eingang von INSELB 20348 verbunden. Ein zweiter Eingang von MULTCNT 20364 ist mit dem Ausgang von SCALER 20338 verbunden. Wie oben beschrieben, ist der Steuerausgang von MULTCNT 20364 mit den Steuereingängen von NIBSHF 20358 verbunden.

6. Prüfungs- und Schnittstellenlogik 20320

Schließlich beinhaltet TSTINT 20320 ECPT 20378, CONSIZE 20352 und die Prüfbedingungslogik (TSTCON) 20386. Der Eingang von ECPT 20378 und der erste Eingang von CONSIZE 20352 sind mit dem Ausgang von RFR 20336 über den FR-Bus 20337 verbunden. Ein zweiter Eingang von CONSIZE 20352 ist mit dem LENGTH-Bus 20226 verbunden. Ein Ausgang von CONSIZE 20352 ist zusammen mit anderen Eingängen von EU 10122 (aus Übersichtlichkeitsgründen nicht gezeigt) mit TSTCON 20386 verbunden. Der Ausgang von TSTCON 20386 ist mit NAG 20340 verbunden (aus Übersichtlichkeitsgründen nicht gezeigt). TSTCON 20386 und ECPT 20378 haben Ausgänge zu und Eingänge von FUINT 20298 von FU 10120.
Nachdem die Gesamtstruktur von EU 10122 oben beschrieben wurde, wird im folgenden mit der Hilfe weiterer Diagramme, die bei Bedarf eingeführt werden, der Betrieb von EU 10122 beschrieben. Schließlich wird der Betrieb von TSTINT 20320 einschließlich einer Beschreibung der genauen Steuersignalschnittstellen zwischen EU 10122 und FU 10120 über TSTINT 20320 und FUINT 20298 beschrieben. Zusätzlich zur Definition der Schnittstelle zwischen EU 10122 und FU 10120 werden bestimmte Merkmale des Betriebs von EU 10122 beschrieben, in denen jene Operationen in Zusammenarbeit mit MEM 10112 und FU 10120 durchgeführt werden. Zum Beispiel befinden sich die Stapelspeichermechanismen von EU 10122, die teilweise Bereiche von MULTRF 20350 und EXPRF 20380 umfassen, teilweise in MEM 10112, so daß der Betrieb der Stapelspeichermechanismen von EU 10122 kooperative Operationen durch EU 10122, MEM 10112 und FU 10120 erfordert.

b. Betrieb der Ausführungseinheit 10122 (Fig. 255)

1. Steuerlogik der Ausführungseinheit 20310 (Fig. 255)

In Fig. 255 wird ein genaueres Blockdiagramm von EUCL 20310 gezeigt. Wie oben beschrieben, empfängt EUCL 20310 die EU 10122-Aufteilungszeiger über den EUDIS- Bus 20206 von EUSDT 20266 und FUCTL 20214. Die EU 10122-Aufteilungszeiger wählen bestimmte EU 10122-Mikrobefehle zur Ausführung der arithmetischen Operationen von EU 10122 aus, wie es erforderlich ist, um Benutzerprogramme, d. h. SOPs, auszuführen, und bei der Verwaltung der JP 10114-Ereignisse zu unterstützen. Wie oben beschrieben, beinhalten die Hauptelemente von EUCL 20310 COMQ 20342, EUSITT 20344, mCRD 20346 und NAG 20340.

a.a. Befehlswarteschlange 20342

Die Eingänge von COMQ 20342 sind mit dem EUDIS-Bus 20206 verbunden, um die EU 10122-Aufteilungszeiger, die von EUSDT 20266 zur Verfügung gestellt werden, zu empfangen und zu speichern. Jeder EU 10122-Aufteilungszeiger umfaßt zwei Informationsfelder. Ein erstes Informationsfeld enthält eine zehn Bit-Anfangsadresse einer entsprechenden Mikrobefehlsabfolge, die sich in EUSITT 20344 befindet. Das zweite Feld jedes EU 10122-Aufteilungszeigers ist ein sechs Bit-Feld, das bestimmte Steuerinformationen, wie z. B. Informationen zur Identifizierung des Datenformats der entsprechenden Operanden, mit denen gearbeitet werden soll, enthält. In diesem Fall spezifizieren die Steuerfeldbits der Aufteilungszeiger, ob die Operanden, mit denen gearbeitet werden soll, vorzeichenbehaftete oder nicht vorzeichenbehaftete Ganzzahlen, gepackte oder ungepackte Dezimalzahlen oder Gleitkommazahlen einfacher oder doppelter Genauigkeit sind.
COMQ 20342 umfaßt zwei ein Wort breite und zwei Worte tiefe Registerdateien. Ein erstes dieser Registerfelder umfaßt den SOP-Befehlswarteschlangen-Steuerspeicher (CQCS) 25510 und den SOP-Befehlswarteschlangen-Adreßspeicher (CQAS) 25512. Zusammen umfassen CQCS 25510 und CQAS 25512 eine ein Wort breite mal zwei Worte tiefe Registerdatei zum Empfangen und Speichern der EU 10122-Aufteilungszeiger, die den SOPs entspricht, d. h. Aufteilungszeiger zur Initiierung der EU 10122-Operationen, die direkt mit der Ausführung eines Benutzerprogramms betraut sind. Die Adressenfelder dieser SOPs werden in CQAS 25512 empfangen, während die Steuerfelder in CQCS 25510 empfangen und gespeichert werden. COMQ 20342 ist dadurch imstande, bis zu zwei sequentielle EU 10122-Aufteilungszeiger, die den SOPs eines Benutzerprogramms entsprechen, aufzufangen und zu speichern. Diese SOP-abgeleiteten Aufteilungszeiger werden in der Reihenfolge, in der sie von FU 10120 empfangen werden, ausgeführt. EU 10122 ist daher imstande, einen augenblicklich ausgeführten SOP-Aufteilungszeiger und einen wartenden SOP-Aufteilungszeiger zu empfangen und zu speichern. Weitere SOP- Aufteilungszeiger können in COMQ 20342 in dem Maße gelesen werden, wie vorherige SOPs ausgeführt werden.

b.b. Befehlswarteschlangen-Ereignissteuerspeicher 25514 und Befehlswarteschlangen-Ereignisadreßsteuerspeicher 25516

Der Befehlswarteschlangen-Ereignissteuerspeicher (CQCE) 25514 und der Befehlswarteschlangen-Ereignisadreßsteuerspeicher (CQAE) 25516 sind in Funktion und Betrieb CQCS 25510 bzw. CQAS 25512 ähnlich. CQCE 25514 und CQAE 25516 empfangen und speichern jedoch EU 10122-Aufteilungszeiger, die die EU 10122-Operationen initiieren, die von FU 10120, wie es erforderlich ist zur Verwaltung der JP 10114-Ereignisse, angefordert werden. Wieder umfassen CQCE 25514 und CQAE 25516 eine ein Wort breite und zwei Worte tiefe Registerdatei. CQAE 25516 empfängt und speichert die Adreßfelder der Ereignisaufteilungszeiger, während CQCE 25514 die entsprechenden Steuerfelder der Ereignisaufteilungszeiger empfängt und speichert. Auch COMQ 20342 ist dazu imstande, bis zu zwei sequentielle Ereignisaufteilungszeiger auf einmal zu empfangen und zu speichern.
Wie in Fig. 255 gezeigt, werden die Ausgaben von CQAS 25512 und CQAE 25516, d. h. die Adreßfelder der EU 10122-Aufteilungszeiger, als Eingaben für den Fallunterscheidungsmultiplexer (SCASE) 25518 und den Startadressenauswahlmultiplexer (SAS) 25520 und NAG 20340, die unten weiter beschrieben werden, zur Verfügung gestellt. Die Steuerfeldausgaben von CQCS 25510 und CQCE 25514 werden als Eingaben für OPB 20322, das unten beschrieben wird, zur Verfügung gestellt.

c.c. S-Intepretertabelle der Ausführungseinheit 20344

Indem wir uns auf EUSITT 20344 beziehen, so ist EUSITT 20344, wie oben beschrieben, ein Speicher für die Speicherung von Mikrobefehlsabfolgen zur Steuerung des Betriebs von EU 10122 als Antwort auf die EU 10122-Aufteilungszeiger, die von FU 10120 empfangen werden. Diese Mikrobefehlsabfolgen können im allgemeinen den Betrieb von EU 10122 bei der Ausführung von arithmetischen Operationen als Antwort auf die SOPs eines Benutzerprogramms steuern, oder bei der Steuerung der Ausführung von EU 10122- Operationen unterstützen, die benötigt werden, um JP 10114-Ereignisse zu bedienen. EUSITT 20344 kann z. B. ein 60 Bit breiter mal 1.280 Worte langer Speicher sein, der in Seiten von 128 Worten pro Seite strukturiert ist. Ein Bereich der EUSITT 20344-Seiten kann in nur-Lesespeicher enthalten sein, z. B. für das Speichern von Mikrobefehlsabfolgen zur Verwaltung der JP 10114-Ereignisse. Die verbleibenden Bereiche von EUSITT 20344 können als Speicher freien Zugriffs konstruiert sein, z. B. zum Speichern von Mikrobefehlsabfolgen zur Ausführung von EU 10122-Operationen als Antwort auf SOPs von Benutzerprogrammen. Diese Struktur erlaubt es, daß EU 10122-Mikrobefehlsabfolgen, die mit dem Betrieb der JP 10114-internen Mechanismen betraut sind, z. B. zur Verwaltung von JP 10114-Ereignissen, praktisch permanent in EUSITT 20344 gespeichert sind. Jener Bereich von EUSITT 20344, der aus Speicher freien Zugriffs konstruiert ist, kann zur Speicherung von Mikrobefehlsabfolgen für die Ausführung von SOPs benutzt werden. Diese Speicher freien Zugriffs können als beschreibbarer Steuerspeicher benutzt werden, um es zu ermöglichen, daß Mikrobefehlsabfolgen zur Ausführung von SOPs von einer oder mehreren augenblicklich von CS 10110 benutzten S-Sprachen von MEM 10112 nach Bedarf in EUSITT 20344 geschrieben werden können.
Wie oben beschrieben, ist EUSITT 20344's zweiter Eingang ein Daten (DATA)-Eingang, der mit dem JPD-Bus 10142 verbunden ist. EUSITT 20344's Dateneingang wird dazu benutzt, um Mikrobefehlsabfolgen von MEM 10112 über den JPD-Bus 10142 in EUSITT 20344 zu schreiben. EUSITT 20344's erster Eingang ist ein Adreß (ADR)-Eingang, der mit dem Ausgang des Adressentreibers (ADRD) 25522 und NAG 20340 verbunden ist. Die Adreßeingänge, die von ADRD 25522 zur Verfügung gestellt werden, selektieren Wortlokationen innerhalb EUSITT 20344 für das Schreiben von Mikrobefehlen in EUSITT 20344 oder für das Lesen von Mikrobefehlen von EUSITT 20344 nach mCRD 20346 zur Steuerung des Betriebs von EU 10122. Die Erzeugung dieser Adreßeingaben nach EUSITT 20344 durch NAG 20340 wird unten beschrieben.

d. d. Mikrocodesteuerdekodierregister 20346

Der Ausgang von EUSITT 20344 ist mit dem Eingang von mCRD 20346 verbunden. Wie oben beschrieben, ist mCRD 20346 ein Register für den Empfang von Mikrobefehlen von EUSITT 20344 und eine Dekodierlogik für das Dekodieren jener Mikrobefehle und zur Bereitstellung der entsprechenden Steuersignale an EU 10122. Wie in Fig. 255 gezeigt, ist das diagnostische Prozessormikroprogrammregister (DPmR) 25524 ein 60 Bit-Register, das parallel mit dem Ausgang von EUSITT 20344 mit dem Eingang von mCRD 20346 verbunden ist. DPmR 25524 kann mit 60 Bit-Mikrobefehlen von DP 10118 geladen werden. Diagnostische Mikrobefehle können daher direkt in den Eingang von mCRD 20346 geladen werden, um direkte Mikrobefehle durch die Mikrobefehlssteuerung von EU 10122 zur Verfügung zu stellen.
Die Ausgaben von mCRD 20346 werden im allgemeinen allen Bereichen von EU 10122 zur Verfügung gestellt, um die detaillierten Operationen von EU 10122 zu steuern. Bestimmte Ausgänge von mCRD 20346 sind mit den Eingängen des nächsten Adressenquellenauswahl-Multiplexers (NASS) 25526 und des Seitenadressenschaltgliedes für lange Verzweigungen (LBPAG) 25528 und NAG 20340 verbunden. Wie weiter unten beschrieben wird, werden diese Ausgaben von mCRD 20346 dazu benutzt, um Adreßeingaben für EUSITT 20344 zu erzeugen, wenn bestimmte Mikrobefehlsabfolgen Sprünge oder lange Verzweigungen zu anderen Mikrobefehlsabfolgen aufrufen. Die Ausgänge von mCRD sind auch parallel mit den Eingängen der Mikrobefehlsparitätsprüfungslogik der Ausführungseinheit (EUmIPC) 25530 verbunden. EUmIPC 25530 überprüft die Parität aller Mikrobefehlsausgaben von mCRD 20346, um Fehler in mCRD 20346's Ausgaben zu entdecken.

e.e. Nächste-Adressen-Generator 20340

Wie oben beschrieben, werden Lese- und Schreibadressen durch NAG 20340 über ADRD 25522 EUSITT 20344 zur Verfügung gestellt. Die Adreßeingaben nach ADRD 25522 werden entweder von NASS 25526 oder vom Diagnoseprozessor-Adressenregister (DPAR) 25532 zur Verfügung gestellt. Im Normalbetrieb werden die Adreßeingaben für EUSITT 20344 von NASS 25526, wie momentan beschrieben, zur Verfügung gestellt. DP 10118 kann jedoch EUSITT 20344-Adressen in DPAR 25532 laden. Diese Adressen können dann von DPAR 25532 durch ADRD 25522 gelesen werden, um individuell Adreßlokationen innerhalb EUSITT 20344 auszuwählen. DPAR 25532 kann insbesondere dazu benutzt werden, Adressen bereit zu stellen, daß man durch die Mikrobefehlssequenzen von EU 10122 Mikrobefehl für Mikrobefehl durchgehen kann.
Wie oben beschrieben, ist NASS 25526 ein Multiplexer, der Eingänge von drei NAG 20340-Adreßquellen besitzt. NASS 25526's erster Adreßeingang ist vom Sprung (JMP)- Ausgang von mCRD 20346 und LBPAG 25528. Diese Adreßeingänge werden teilweise benutzt, wenn ein gegenwärtiger Mikrobefehl einen Sprung oder eine weite Verzweigung zu einem anderen Mikrobefehl oder einer Mikrobefehlsabfolge aufruft. Die zweite Adreßquelle wird von SAS 25520 bereitgestellt und besteht im allgemeinen aus Anfangsadressen von Mikrobefehlsabfolgen. SAS 25520 ist ein Multiplexer, der einen ersten Eingang von CQAS 25512 und CQAE 25516 hat, d. h. Startadressen von Mikrobefehlsabfolgen, die SOPs entsprechen oder zur Bedienung von JP 10114-Ereignissen dienen. Ein zweiter SAS 25520-Eingang wird vom Unterprogramm-Rückkehradressenstapelspeicher (SUBRA) 25534 zur Verfügung gestellt. Im allgemeinen und wie unten weiter beschrieben wird, arbeitet SUBRA 25534 als Stapelspeichermechanismus zur Abspeicherung der gegenwärtigen Mikrobefehlsadressen von unterbrochenen Mikrobefehlsabfolgen. Diese gespeicherten Adressen können nachfolgend benutzt werden, um die Ausführung jener unterbrochenen Mikrobefehlsabfolgen wieder aufzunehmen. Die dritte Adressenquelle für NASS 25526 wird vom Generator für sequentielle und Caseadressen (SCAG) 25536 zur Verfügung gestellt. Im allgemeinen SCAG 25536 Adressen, um sequentielle Mikrobefehle innerhalb einer speziellen Mikrobefehlsabfolge zu selektieren. SCAG 25536 erzeugt auch Mikrobefehlsadressen für Mikrobefehlscaseoperationen. Wie in Fig. 255 angezeigt, werden die Ausgaben von SCAG 25536 und SAS 25520 busmäßig zusammengefaßt, um eine einzelne NASS 25526-Eingabe zu umfassen. Die Auswahl zwischen den Ausgaben von SCAG 25536 und SAS 25520 wird durch Steuereingaben (aus Übersichtlichkeitsgründen nicht gezeigt) für SCAG 25536 und SAS 25520 zur Verfügung gestellt. Die Auswahl zwischen NASS 25526's Adreßeingängen wird durch die Auswahlsteuerungslogik für nächste Adressen (NASSC) 25538 gesteuert, die Steuerungseingaben für NASS 25526 bereit stellt. NASSC 25538 ist praktisch ein Multiplexer, der Steuerungseingaben von TSTCON 20386 und TSTINT 20320 empfängt. Wie unten beschrieben wird, überwacht TSTCON 20386 bestimmte Betriebsbedingungen oder Betriebszustände innerhalb EU 10122 und stellt die entsprechenden Eingaben für NASSC 25538 zur Verfügung. NASSC 25538 dekodiert praktisch diese Steuerungseingaben von TSTCON 20386, um eine Selektionssteuerungseingabe für NASS 25526 zur Verfügung zu stellen.
Nachdem die Gesamtstruktur und der Betrieb von NAG 20340 beschrieben wurden, wird im folgenden der Betrieb von NAG 20340 genauer beschrieben.
Indem wir uns zuerst auf die Adreßeingänge von NASS 25526 beziehen, die vom JMP- Ausgang von mCRD 20346 und IBPAG 25528 zur Verfügung gestellt werden, so dient diese Adressenquelle zur Auswahl eines nächsten Mikrobefehls durch einen gegenwärtigen Mikrobefehl. Der JMP-Ausgang von mCRD 20346 erlaubt es einem gegenwärtigen Mikrobefehl, einen Sprung zu einem anderen Mikrobefehl innerhalb derselben Seite von EUSITT 20344 zu steuern. NASS 25526's Eingabe über LBPAG 25528 wird von einem anderen Bereich der Ausgabe von mCRD 20346 zur Verfügung gestellt, die Seiten innerhalb EUSITT 20344 spezifiziert. Diese Eingabe über LBPAG 25528 erlaubt die Ausführung von langen Verzweigungsoperationen, d. h. Sprüngen von einem Mikrobefehl in einer Seite von EUSITT 20344 zu einem Mikrobefehl in einer anderen Seite. Darüber hinaus wird NASS 25526's Eingabe über den JMP-Ausgang von mCRD 20346 und über LBPAG 25528 dazu benutzt, um ein Leerlauf- oder Standby-Programm auszuführen, wenn EU 10122 augenblicklich keine von FU 10120 angeforderte Mikrobefehlsabfolge ausführt. In diesem Fall steuert ein Leerlaufprogramm TSTCON 20386, die EU 10122-Aufteilungszeigereingaben von FU 10120 für EU 10122 zu überwachen. Wenn keine EU 10122- Aufteilungszeiger in COMQ 20342 vorhanden sind und auch keine im Wartezustand, so steuert TSTCON 20386 NASSC 25538 dahingehend, Steuereingaben für NASS 25526 zur Verfügung zu stellen, um NASS 25526's Eingang von mCRD 20346 und LBPAG 25528 auszuwählen. Die Leerlaufroutine testet die Eingaben ständig auf EU 10122-Aufteilungszeiger, bis ein solcher Aufteilungszeiger in COMQ 20342 empfangen wurde. Zu diesem Zeitpunkt entdeckt TSTCON 20386 den wartenden Aufteilungszeiger und veranlaßt NASSC 25538, Steuerausgaben für NASS 25526 zur Verfügung zu stellen, um den Eingang von NASS 25526 im allgemeinen von SAS 25520 auszuwählen. TSTCON 20386 und NASSC 25538 veranlassen NASS 25526 auch, Eingaben von SAS 25520 bei einer Rückkehr von einem gerufenen Mikrobefehl zu einer vorher unterbrochenen Mikrobefehlsabfolge auszuwählen.
Wie oben beschrieben, empfängt SAS 25520 Startadressen von COMQ 20342 und von SUBRA 25534. SAS 25520 wählt den Ausgang von CQAS 25512 oder den von CQAE 25516 als Eingang für NASS 25526, wenn eine Mikrobefehlsabfolge zur Ausführung von SOPs eines Benutzerprogrammes oder zur Bedienung eines JP 10114-Ereignisses initiiert werden soll. SAS 25520 wählt eine Adreßausgabe von SUBRA 25534 bei einer Rückkehr von einem gerufenen Unterprogramm zu einem vorher ausführenden, aber unterbrochenen Unterprogramm. SUBRA 25534 ist, wie oben beschrieben, praktisch ein Stapelspeichermechanismus zur Speicherung von Adressen von gegenwartig ausführenden Mikrobefehlen, wenn jene Mikrobefehlsabfolgen unterbrochen werden. SUBRA 25534 ist ein elf Bit breites mal acht Worte tiefes Register, bei dem bestimmte Register für den Gebrauch beim Stapeln von Ereignismanagermikrobefehlsabfolgen ausgelegt sind. Andere Bereiche von SUBRA 25534 werden zum Stapeln von Mikrobefehlsabfolgen zur Ausführung von SOPs benutzt, d. h. zum Stapeln von Mikrobefehlsabfolgen, bei denen eine erste Mikrobefehlsabfolge eine zweite Mikrobefehlsabfolge aufruft. SUBRA 25534 arbeitet nicht als first-in/ first-out-Stapelspeicher, sondern als Speicher freien Zugriffs, in dem die Adreßeingaben, die die Register und SUBRA 25534 auswählen, von Mikrobefehlsausgaben von mCRD 20346 zur Verfügung gestellt werden. Die Operationen von SUBRA 25534 als Stapelspeichermechanismus wird daher von Mikrobefehlsabfolgen, die in EUSITT 20344 gespeichert sind, gesteuert. Wie in Fig. 255 angezeigt, werden die Adressen von gegenwärtigen Mikrobefehlen von unterbrochenen Mikrobefehlsabfolgen dem Dateneingang von SUBRA 25534 vom Ausgang von SCAG 25536, der im folgenden beschrieben wird, zur Verfügung gestellt.
Wie oben beschrieben, erzeugt SCAG 25536 sequentielle Adressen, um sequentielle Mikrobefehle innerhalb von Mikrobefehlsabfolgen auszuwählen und um Mikrobefehlsadressen für Caseoperationen zu erzeugen. SCAG 25536 enthält ein nächste-Adressen- Register (NXTR) 25540, eine arithmetische und logische Einheit für nächste Adressen (NAALU) 25542 und SCASE 25518. NAALU 25542 ist eine zwölf Bit arithmetische und logische Einheit. Ein erster elf Bit-Eingang von NAALU 25542 ist mit dem Ausgang von ADRD 25522 verbunden und daher die gegenwärtige Adresse, die EUSITT 20344 zur Verfügung gestellt wird. Eine zweite vier Bit-Eingabe zu NAALU 25542 wird vom Ausgang von SCASE 25518 zur Verfügung gestellt. Während der sequentiellen Ausführung einer Mikrobefehlsabfolge ist die Ausgabe von SCASE 25518 binär Null und die Übertragseingabe von NAALU wird auf Eins gezwungen. Die Ausgabe von NAALU 25542 ist daher um eins größer als die gegenwärtige Mikrobefehlsadresse, die EUSITT 20344 zur Verfügung gestellt wird, und wird daher die Adresse des nächsten sequentiellen Mikrobefehls sein. Wie in Fig. 255 gezeigt, empfängt SCASE 25518 eine Eingabe vom Ausgang von SCALER 20338. Diese Eingabe wird während Caseoperationen benutzt und ermöglicht, daß eine datensensitive Zahl als Ausgabe von SCASE 25518 für den zweiten Eingang von NAALU 25542 ausgewählt wird. SCASE 25518's Eingabe von SCALER 20338 erlaubt es daher NAG 20340, Mikrobefehlsabfolge-Caseoperationen durchzuführen, bei denen die Casewerte von den Inhalten von SCALER 20338 bestimmt werden.
Die Ausgaben der nächsten Adressen von NAALU 25542 werden in NXTR 25540 geladen, das aus drei Zustandsausgaberegistern besteht. Die nächste-Adressen-Ausgänge von NXTR 25540 sind gemeinsam mit den Ausgängen von SAS 25520 mit dem zweiten Eingang von NASS 25526, wie oben beschrieben, verbunden. Während normaler Ausführung von Mikrobefehlsabfolgen wählt daher SCAG 25536 über NASS 25526 und ADRD 25522 sequentielle Mikrobefehle von EUSITT 20344 aus. SCAG 25536 kann auch, wie eben beschrieben, die nächsten Mikrobefehlsadressen in Mikrobefehls-Caseoperationen zur Verfügung stellen.
Alles in allem ist NAG 20340 dazu imstande, alle gewöhnlichen Mikrobefehlsadreßoperationen durchzuführen. Zum Beispiel erlaubt NAG 20340 die Auswahl von nächsten Mikrobefehlen durch gegenwärtige Mikrobefehle entweder für Sprungoperationen oder lange Verzweigungsoperationen durch NASS 25526's Eingang vom mCRD 20346's JMP oder durch LBPAG 25528. NAG 20340 kann Startadressen von Mikrobefehlsabfolgen über COMQ 20342 und SAS 25520 zur Verfügung stellen, oder es kann Rückkehradressen zu unterbrochenen und stapelgespeicherten Mikrobefehlsabfolgen über SUBRA 25534 und SAS 25520 zur Verfügung stellen. NAG 20340 kann sequentiell Mikrobefehle einer speziellen Mikrobefehlsabfolge durch den Betrieb von SCAG 25536 adressieren, oder es kann Mikrobefehls-Caseoperationen über SCAG 25536 durchführen.

2. Operandenpuffer 20322

Nachdem die Struktur und der Betrieb von EUCL 20310 beschrieben wurden, werden unten die Struktur und der Betrieb von OPB 20322 beschrieben. Wie oben beschrieben, empfängt OPB 20322 Operanden, d. h. Daten, von MEM 10112 und FU 10120 über den MOD-Bus 10144 und den JPD-Bus 10142. OPB 20322 kann dann bestimmte Operandenformatübersetzungen durchführen, um MULT 20314 und EXP 20316 die Daten in den für sie optimal nutzbaren Formaten zur Verfügung zu stellen. Wie oben beschrieben, kann EU 10122 arithmetische Operationen mit ganzen Zahlen, gepackten und ungepackten Dezimalzahlen und Gleitkommazahlen einfacher oder doppelter Genauigkeit durchführen.
Zusammenfassend betrachtet kann daher OPB 20322 ganzzahlige, Gleitkomma einfacher und doppelter Genauigkeit und gepackte und ungepackte Dezimaloperanden von MEM 10112 und FU 10120 empfangen und geeignete Felder jener Operanden MULT 20314 und EXP 20316 in Formaten zur Verfügung stellen, die von MULT 20314 und EXP 20316 am wirksamsten benutzt werden. Dabei extrahiert OPB 20322 die Exponenten- und Mantissenfelder von Gleitkommaoperanden einfacher und doppelter Genauigkeit, um Exponenten- und Mantissenfelder dieser Operanden EXP 20316 bzw. MULT 20314 zur Verfügung zu stellen und entpackt oder konvertiert ungepackte Dezimaloperanden zu gepackten Dezimaloperanden, die von MULT 20314 am effizientesten genutzt werden können.
Nachdem die Struktur und der Betrieb von OPB 20322 beschrieben wurden, wird im folgenden die Struktur und der Betrieb von MULT 20314 beschrieben.

3. Multiplizierer 20314 (Fig. 257, 258)

MULT 20314 führt, wie oben beschrieben, Additions-, Subtraktions-, Multiplikations- und Divisionsoperationen mit Mantissenfeldern von Gleitkommaoperanden einfacher und doppelter Genauigkeit, Ganzzahloperanden und Dezimaloperanden durch. Wie oben im Zusammenhang mit OPB 20322 beschrieben, konvertiert OPB 20322 ungepackte Dezimaloperanden zu gepackten Dezimaloperanden für die Bearbeitung durch MULT 20314. MULT 20314 ist daher praktisch dazu imstande, alle arithmetischen Operationen mit ungepackten Dezimaloperanden durchzuführen.

a.a. Datenpfade und Speicher vom Multiplizierer 20314 (Fig. 257)

In Fig. 257 wird ein genaueres Blockdiagramm der Datenpfade und des Speichers von MULT 20314 gezeigt. Wie oben beschrieben, enthalten die Hauptelemente von MULT 20314 Speicherelemente, die MULTRF 20350 und CONST 20360, die Multiplexerlogik für Operandeneingang und Ergebnisausgang, die MULTIM 20328 und MULTRM 20334 beinhalten, und die arithmetische Operationslogik umfassen. Die Multiplexerlogik des Operandeneingangs und Ergebnisausgangs von MULT 20314 und Speicherelemente werden zuerst beschrieben, danach folgt eine Beschreibung der arithmetischen Operationslogik von MULT 20314.
Wie oben beschrieben, werden Eingangsdaten, die Operanden beinhalten, MULT 20314's arithmetischer Operationslogik über den MULTIN-Bus 20354 zur Verfügung gestellt. Der MULTIN-Bus 20354 kann mit Daten von drei Quellen versorgt werden. Eine erste Quelle ist CONST 20360, das ein 512 Worte mal 32 Bit breiter nur-Lesespeicher ist. CONST 20360 wird dazu benutzt, um bei arithmetischen Operationen benutzte Konstanten zu speichern. Insbesondere speichert CONST 20360 die Zonenfelder für ungepackte Dezimaloperanden, d. h. ASCII-Zeichen. Wie oben beschrieben, werden ungepackte Dezimaloperanden durch OPB 20322 empfangen und in gepackte Dezimaloperanden für effizientere Nutzung durch MULT 20314 konvertiert. Daher sind die Ausgaben von Endresultaten, die von solchen Operanden durch MULT 20314 erzeugt wurden, im gepackten Dezimalformat. Wie unten beschrieben wird, kann MULT 20314 dazu benutzt werden, diese gepackten Dezimalergebnisse in ungepackte Dezimalergebnisse durch das Einfügen von Zonenfeldern zu konvertieren. Wie in Fig. 257 angezeigt, werden Adreßeingaben für CONST 20360 vom EXPQ-Bus 20325 und vom Ausgang von mCRD 20346 zur Verfügung gestellt. Die Auswahl zwischen diesen Adreßeingängen wird durch den CONST- Adressenmultiplexer (CONSTAM) 25710 bereit gestellt. CONST 20360-Adressen werden im allgemeinen von EUCL 20310, können aber alternativ vom EXPQ-Bus 20325 für Spezialoperationen zur Verfügung gestellt werden.
Operandendaten werden dem MULTIN-Bus 20354 durch MULTIM 20328, der ein 64 Bit- Multiplexer mit doppeltem Eingang ist, zur Verfügung gestellt. Der erste Eingang von MULTIM 20328 wird vom OPQ-Bus 20323 zur Verfügung gestellt und umfaßt Operandeninformation, die von OPB 20322 bereit gestellt wird. Der OPQ-Bus 20323 ist ein 56 Bit breiter Bus, und Operandendaten, die auf ihm erscheinen, können 32 Bit-Ganzzahloperanden umfassen; 32 Bit gepackte Dezimaloperanden, die entweder direkt von OPB 20322 zur Verfügung gestellt werden oder als ein Ergebnis der Konversion von ungepackten Dezimaloperanden zu gepackten Dezimaloperanden von OPB 20323; 24 Bit-Operandenmantissenfelder einfacher Genauigkeit; oder 56 Bit-Operandenmantissenfelder doppelter Gleitkommagenauigkeit. Wie oben beschrieben, können bestimmte OPQ-Bus 20323- Felder, abhängig vom Operanden, mit Nullen oder mit Vorzeichenerweiterung aufgefüllt sein.
Die zweite Eingabe von MULTIM 20328 wird von MULTRF 20350 zur Verfügung gestellt. MULTRF 20350 ist ein 16 Worte mal 64 Bit breiter Speicher freien Zugriffs. Wie in den Fig. 203 und 257 angezeigt, ist MULTRF 20350 zwischen den Ausgang von RFR 20336 über den FR-Bus 20337 und dem Eingang der arithmetischen Operationslogik von MULT 20314 über MULTIM 20328 und den MULTIN-Bus 20354 verschaltet. MULTRF 20350 kann daher als Schnellspeicher zum Abspeichern von Zwischenergebnissen bei arithmetischen Operationen einschließlich sich wiederholender arithmetischer Operationen benutzt werden. Darüber hinaus wird ein Bereich von MULTRF 20350 wie in GRF 10354 als ein EU 10122-Stapelspeichermechanismus ähnlich wie MIS 10368 und MOS 10370 in FU 10120 benutzt. Der Betrieb des EU 10122-Stapelspeichermechanismus wird in einer folgenden Beschreibung der Schnittstellen von EU 10122 mit MEM 10112 und FU 10120 beschrieben werden. Die Adreßeingaben (ADR) von MULTRF 20350 werden vom Adressenmultiplexer der Multipliziererregisterdatei (MULTRFAM) 25712 zur Verfügung gestellt.
MULTRFAM 25712 ist ein zweifacher vier Bit-Multiplexer, der z. B. aus SN74S258s besteht. Zusätzlich zu den Adreßeingaben für MULTRF 20350 stellt MULTRFAM 25712 Adreßeingaben für EXPRF 20380 zur Verfügung. Wie oben beschrieben, umfassen MULTRF 20350 und EXPRF 20380 zusammen eine EU 10122-allgemeine Registerdatei ähnlich wie GRF 10354 und FU 10120. Von daher werden MULTRF 20350 und EXPRF 20380 parallel adressiert, um parallele Eingaben von und zu MULTRF 20350 und EXPRF 20380 zu lesen und zu schreiben. Die Adreßeingaben für MULTRFAM 25712 werden zuerst von den Ausgängen von mCRD 20346 zur Verfügung gestellt, und daher wird Mikrobefehlssteuerung für Adressierung von MULTRF 20350 und EXPRF 20380 bereit gestellt. Der zweite Adreßeingang für MULTRFAM 25712 wird vom Ausgang des Adressenzählers der Multipliziererregisterdatei (MULTRFAC) 25714 zur Verfügung gestellt.
MULTRFAC 25714 ist ein vier Bit-Zähler und wird dazu benutzt, sequentielle Adressen MULTRF 20350 und EXPRF 20380 zu erzeugen. Die Anfangsadressen werden in MULTRFAC 25714 vom Adressenzählermultiplexer der Multiplizierregisterdatei (MULT- RFACM) 25716 geladen. MULTRFACM 25716 ist ein zweifacher vier Bit-Multiplexer. Die Eingaben zu MULTRFACM 25716 werden als erstes von den Ausgängen von mCRD 20346 zur Verfügung gestellt. Dieser Eingang erlaubt die Mikrobefehlsselektion einer Anfangsadresse, die nach MULTRFAC 25714 geladen werden soll und nachfolgend dafür benutzt werden soll, um sequentielle MULTRF 20350- und EXPRF 20380-Adressen zu erzeugen. Ein zweiter Adreßeingang für MULTRFACM 25716 wird vom OPQ-Bus 20323 zur Verfügung gestellt. Der Eingang von MULTRFACM 25716 vom OPQ-Bus 20323 erlaubt es, daß eine einzelne Adresse oder Startadresse einer Adreßfolge durch den JPD- Bus 10142 oder den MOD-Bus 10144 z. B. von MEM 10112 oder FU 10120 ausgewählt werden kann.
Die Ausgaben von Zwischen- und Endergebnissen der arithmetischen Logik von MULT 20314 werden den Dateneingängen von MULTRF 20350 direkt vom FR-Bus 20337 und von MULTRM 20334 zur Verfügung gestellt. Die Eingaben für MUTRM 20334 wiederum werden vom FR-Bus 20337 und vom Ausgang von CONSIZE 20352 und TSTINT 20320 zur Verfügung gestellt.
Der FR-Bus 20337 ist ein 64 Bit-Bus, der mit dem 64 Bit-Ausgang von RFR 20336 verbunden ist und die End- und Zwischenergebnisse von arithmetischen Operationen von MULT 20314 überträgt. Wie in einer folgenden Beschreibung der arithmetischen Operationslogik von MULT 20314 klar werden wird, ist der Ausgang von RFR 20336, und somit auch der FR-Bus 20337, 64 Bits breit. Die 64 Bits werden zur Verfügung gestellt, um die Sicherstellung aller signifikanten Datenbits bestimmter MULT 20314-arithmetischen Operationszwischenergebnissen zu gewährleisten, insbesondere von Operationen, in denen 64 Bit-Mantissenfelder von Gleitkommazahlen doppelter Genauigkeit involviert sind. Darüber hinaus kann MULT 20314, wie es momentan beschrieben wird und auch schon oben festgestellt wurde, ein Endergebnis im gepackten Dezimalformat in ein Endergebnis ungepackten Dezimalformats konvertieren. Bei dieser Operation wird ein einzelnes 32 Bit, oder ein Wort gepacktes Dezimalergebnis in ein 64 Bit oder zwei Wort, ungepacktes Dezimalformat durch das Einfügen von Zonenfeldern konvertiert.
Wie oben beschrieben, werden zwei parallele Datenpfade für den Informationstransfer vom FR-Bus 20337 in MULTRF 20350 zur Verfügung gestellt. Der erste Pfad geht direkt vom FR-Bus 20337, und der zweite Pfad geht über den Multiplexer für ungepackte Dezimale (UPDM) 25718 von MULTRM 20334. Der direkte Pfad wird für 32 Bits Informationen, die die Bits 0 bis 23 und die Bits 56 bis 63 des FR-Busses 20337 umfassen, benutzt. Der Datenpfad über UPDM 25718 kann entweder die Bits 24 bis 55 des FR-Busses 20337, die mit einem ersten Eingang von UPDM 25718 verbunden sind, benutzen, oder die Bits 40 bis 55, die mit einem zweiten Eingang von UPDM 25718 verbunden sind. Gleitkommazahlen einfacher Genauigkeit sind 32 Bit-Zahlen plus zwei oder mehr Schutzbits und werden daher in MULTRF 20350 über die Bits 0 bis 23 des direkten Pfades in MULTRF 20350 und durch den ersten Eingang (Bits 24 bis 55) von UPDM 25718 geschrieben. Gleitkommazahlen doppelter Genauigkeit sind fünf Bits breit plus Schutzbits und benutzen daher den direkten Pfad in MULTRF 20350 und den Pfad über den ersten Eingang von UPDM 25718. Die Bits 56 bis 63 des direkten Pfades werden für die Schutzbits von Gleitkommazahlen doppelter Genauigkeit benutzt. Sowohl Ganzzahlen als auch gepackte Dezimalzahlen benutzen die Bits 24 bis 55 des FR-Busses 20337 und werden daher in MULTRF 20350 über den ersten Eingang von UPDM 25718 geschrieben. Wie oben beschrieben, werden die Bits 0 bis 23 dieser Operanden durch Vorzeichenerweiterung aufgefüllt.

a.a.a. Behältergrößenüberprüfung

Wie oben festgestellt, hat MULTRM 20334 einen Eingang von CONSIZE 20352. Wie unten im Zusammenhang mit TSTINT 20320 beschrieben wird, führt CONSIZE 20352 eine "Behältergrößen"-Überprüfung bei jedem Zurückspeichern von Ergebnissen von EU 10122 nach MEM 10112 durch. CONSIZE 20352 vergleicht die Anzahl der signifikanten Bits in einem Ergebnis, das zurückgespeichert werden soll, mit dem logischen Beschreiber, der den Adreßraum von MEM 10112 beschreibt, wohin jenes Ergebnis geschrieben werden soll. Wo sich wiederholende Schreiboperationen nach MEM 10112 erforderlich sind, um ein Ergebnis in MEM 10112 zu transferieren, d. h. bei Zeichenkettentransfers, kann die Information über die Behältergröße von CONSIZE 20352 durch den Behältergrößentreiber (CONSIZED) 25720 und MULTRM 20334 gelesen und in MULTRF 20350 geschrieben werden. Dies erlaubt EU 10122, indem es die in MULTRM 20350 gespeicherte Information über die Behältergröße benutzt, während eines Zeichenkettentransfers eines Ergebnisses von EU 10122 nach MEM 10112 kontinuierliche Behältergrößenüberprüfungen durchzuführen. Darüber hinaus kann, wie eben beschrieben wird, die Information über die Behältergröße von CONSIZE 20352 zum JPD-Bus 10144 gelesen werden.

b.b.b. Endergebnisausgabenvervielfacher 20324

Indem wir schließlich auf FROM 20324 Bezug nehmen, so wird FROM 20324, wie oben beschrieben wurde, dazu benutzt, im allgemeinen die Ergebnisse von arithmetischen Operationen von EU 10122 auf den JPD-Bus 10142 zu transferieren für den Transfer zu MEM 10112 oder FU 10120. Wie in Fig. 257 angezeigt, umfaßt FROM 20324 den 24 Bit Endergebnisbustreiber (FRBD) 25722 und den Ergebnisbustreiber (RBR) 25724. Der Eingang von FRBD 25722 ist mit dem FR-Bus 20337 verbunden und erlaubt es Daten, die auf ihm erscheinen, auf den JPD-Bus 10142 transferiert zu werden. Insbesondere wird FRBD 25722 dazu benutzt, die 24 Bit-Mantissenfelder von Gleitkommaergebnissen einfacher Genauigkeit auf den JPD-Bus 10142 parallel mit einem entsprechenden Exponentenfeld von EXP 20316 zu transferieren. Der RBR 25724-Eingang ist mit dem RSLT- Bus 20388 verbunden und ermöglicht, daß die Ausgabe von UPDM 25718 auf den JPD- Bus 10142 transferiert werden kann. RBR 25724, der RSLT-Bus 20388 und UPDM 25718 werden im allgemeinen dazu benutzt, die Endergebnisse von EU 10122-Operationen vom Ausgang von MULT 20314 auf den JPD-Bus 10142 zu transferieren. Die Endergebnisse, die auf diesem Datenpfad transferiert werden, beinhalten ganzzahlige, gepackte und ungepackte Dezimalergebnisse und die Mantissenfelder von Gleitkommaergebnissen doppelter Genauigkeit. Sowohl ungepackte Dezimalzahlen als auch die Mantissenfelder der Gleitkommazahlen doppelter Genauigkeit umfassen zwei 32 Bit-Worte und werden daher auf den JPD-Bus 10142 in zwei sequentiellen Transferoperationen transferiert.
Nachdem die Struktur und der Betrieb der Speicherelemente und die Eingangs- und Ausgangsschaltkreise von MULT 20314 beschrieben wurden, wird im folgenden die arithmetische Operationslogik von MULT 20314 beschrieben.

4. Prüfungs- und Schnittstellenlogik 20320 (Fig. 260-268)

Wie oben beschrieben, beinhaltet TSTINT 20320 CONSIZE 20352, ECPT 20328, TSTCOND 20384 und INTRPT 20388. CONSIZE 20352 führt, wie oben beschrieben wurde, Operationen für die Überprüfung der "Behältergröße" durch, wenn Ergebnisse von EU 10122-Operationen in MEM 10112 geschrieben werden sollen. Das heißt, CONSIZE 20352 vergleicht die Größe oder Anzahl der signifikanten Bits eines EU 101 22-Ergebnisses mit der Speicherkapazität oder Behältergröße der MEM 10112-Speicherstelle, auf die das EU 10122-Ergebnis geschrieben werden soll. Wie in Fig. 203 gezeigt, empfängt CONSIZE 20352 eine erste Eingabe, d. h. Ergebnisse von EU 10122-Operationen, vom FR-Bus 20337. Ein zweiter Eingang von CONSIZE 20352 ist mit dem LENGTH-Bus 20226 verbunden, um Längenfelder von logischen Beschreibern zu empfangen, die die Speicherstelle von MEM 10112 identifizieren, in die jene EU 10122-Ergebnisse geschrieben werden sollen. CONSIZE 20352 beinhaltet logische Schaltkreise, z. B. eine Kombination aus nur-Lesespeicher und feldprogrammierbaren logischen Vektoren, um die Ergebnisse von EU 10122, die auf dem FR-Bus 20337 erscheinen, zu untersuchen, und um die Anzahl von Datenbits in jenen Ergebnissen zu bestimmen. CONSIZE 20352 vergleicht die Größe des EU 10122-Ergebnisses mit dem Längenfeld des logischen Beschreibers, und sorgt für eine Alarmausgabe für ECPT 20328, das unten beschrieben wird, insbesondere dann, wenn die Ergebnisgröße die Länge des logischen Beschreibers übersteigt.
TSTCOND 20384, das oben beschrieben wurde und das unten weiter beschrieben wird, ist ein Schnittstellenschaltkreis zwischen FU 10120 und EU 10122. TSTCOND 20384 erlaubt es FU 10120, Resultate von bestimmten Prüfoperationen zu spezifizieren und zu untersuchen, die von EU 10122 hinsichtlich EU 10122-Operationen durchgeführt wurden.
ECPT 20328 überwacht bestimmte EU 10122-Operationen und stellt Ausgaben zur Verfügung, die anzeigen, wenn bestimmte "Ausnahmen" aufgetreten sind. Diese Ausnahmen beinhalten versuchte Divisionen durch Null, Gleitkommaexponenten-Unter- oder Überläufe und Größenfehler bei Ganzzahlbehältern.
INPRPT 20388 ist wieder eine Schnittstelle zwischen EU 10122 und FU 10120, die es FU 10120 erlaubt, EU 10122-Operationen zu unterbrechen. INTRPT 20388 erlaubt es FU 10120, EU 10122 so zu steuern, daß es bestimmte Operationen ausführt und damit bei der Verwaltung bestimmter FU 10120-Ereignisse, die oben beschrieben wurden, unterstützt.
Der Betrieb von CONSIZE 20352, ECPT 20328, TSTCOND 20384, INTRPT 20388 und anderen Merkmalen der Schnittstelle zwischen EU 10122 und FU 10120 werden in der folgenden Beschreibung des Betriebs jener Schnittstelle und des Betriebs bestimmter EU 10122-interner Mechanismen, wie z. B. die FU 10120-Stapelspeichermechanismen, beschrieben.

a.a. FU 10120/EU 10122-Schnittstelle

Wie oben beschrieben, sind EU 10122 und FU 10120 asynchrone Prozessoren, von denen beide unter ihrer eigenen Mikrocodesteuerung arbeiten. EU 10122 und FU 10120 arbeiten gleichzeitig und unabhängig voneinander, aber sie werden gekoppelt und ihren Operationen durch Schnittstellensignale, die unten beschrieben werden, koordiniert. Sollte EU 10122 nicht imstande sein, sofort auf eine Anforderung von FU 10120 zu antworten, bleibt FU 10120 im Leerlaufbetrieb bis EU 10122 verfügbar wird; sollte umgekehrt EU 10122 keine Operanden oder Operationsanforderungen von FU 10120 empfangen oder vorliegen haben, verbleibt EU 10122 im Leerlaufzustand bis Operanden und Operationsanforderungen von FU 10120 empfangen werden.
Beim Normalbetrieb manipuliert EU 10122 Operanden unter der Steuerung von FU 10120, das wiederum unter der Steuerung der SOPs eines Benutzerprogramms arbeitet. Wenn FU 10120 eine arithmetische oder logische Manipulation eines Operanden erfordert, setzt FU 10120 einen Befehl, d. h. einen Ausführungseinheitsaufteilungszeiger (EUDP) an EU 10122 ab. Wie oben beschrieben, ist ein EUDP im Grunde genommen eine Anfangsadresse in EUSITT 20344. Ein EUDP identifiziert die Startlokation einer EU 10122- Mikrobefehlsabfolge, die die angeforderte Operation mit den Operanden durchführt. Die Operanden werden von MEM 10112 unter der Kontrolle von FU 10120 geholt und, wie beschrieben, in OPB 20322 transferiert. Jene Operanden werden dann von OPB 20322 durch EU 10122 aufgerufen und in MULT 20314 und EXP 20316, wie oben beschrieben, transferiert. Nachdem die angeforderte Operation beendet ist, wird FU 10120 benachrichtigt, daß ein Ergebnis fertig ist. An diesem Punkt kann FU 10120 bestimmte Prüfbedingungen abfragen, z. B. durch TSTCOND 20384, z. B. ob ein ganzzahliges oder Dezimalübertragsbit gesetzt ist, oder ob ein Mantissenvorzeichenbit gesetzt oder zurückgesetzt ist. Diese Prüfoperation wird von FU 10120 für bedingtes Verzweigen und die Synchronisation der FU 10120- und EU 10122-Operationen benutzt. Die Ausnahmenüberprüfung durch EXPT 20328 wird auch zu diesem Zeitpunkt durchgeführt. Die Ausnahmenüberprüfung bestimmt z. B., ob eine Division durch Null versucht wurde, oder ob ein Behältergrößenfehler aufgetreten ist. Im allgemeinen wird FU 10120 nicht über Ausnahmenfehler informiert, bis FU 10120 eine Ausnahmenüberprüfung anfordert. Nachdem die Ergebnisse von EU 10122 in FU 10120 oder MEM 10112 transferiert wurden, geht EU 10122 in Leerlaufbetrieb über, bis eine nächste Operation von FU 10120 angefordert wird.
Nachdem kurz der Gesamtschnittstellenbetrieb zwischen FU 10120 und EU 10122 besprochen wurde, wird der Betrieb jener Schnittstelle, der als Quittungsbetrieb bezeichnet wird, im folgenden genauer beschrieben. Im allgemeinen kann der Quittungsbetrieb zwischen EU 10122 und FU 10120 während des Normalbetriebs so betrachtet werden, daß er in sechs Operationen unterteilt werden kann. Diese Operationen können z. B. Laden von COMQ 20342, Laden von OPB 20322, Zurückspeichern oder Transferieren eines Ergebnisses von EU 10122 nach FU 10120 oder MEM 10112, die Durchführung von Prüfbedingungen, die Prüfung von Ausnahmen und EU 10122-Leerlaufbetrieb beinhalten. Der Quittungsbetrieb zwischen FU 10120 und EU 10122 wird im folgenden für jede dieser Operationsklassen in der obigen Reihenfolge beschrieben.

a.a.a. Laden der Befehlswarteschlange 20342 (Fig. 260)

In Fig. 260 wird eine schematische Darstellung der Schnittstelle zwischen EU 10122 und FU 10120 hinsichtlich des Ladens von COMQ 20342 gezeigt. Während des normalen SOP-gesteuerten JP 10114-Betriebes werden die acht Bit Operations (OP)-Codes vom Befehlsstrom, wie oben beschrieben, analysiert und mit der Dialektinformation verkettet, um EUSDT 20266, wie auch oben beschrieben wurde, zu adressieren. EUSDT 20266 stellt entsprechende Adressen, d. h. EUDPs für EUSITT 20344 zur Verfügung.
Die Dialektinformation spezifiziert die momentan ausgeführte S-Sprache und konsequenterweise die Gruppe von Mikrobefehlsabfolgen, die in EUSITT 20344 für jene S-Sprache verfügbar sind. Wie oben beschrieben, kann FU 10120 vier S-Sprachen-Dialekte mit bis zu 256 EU 10122-Mikrobefehlsabfolgen pro Dialekt spezifizieren oder acht Dialekte mit bis zu 128 Mikrobefehlsabfolgen pro Dialekt.
Von EUSDT 20266 zur Verfügung gestellte EUDPs umfassen ein neun Bit-Adressenfeld, ein zwei Bit-Operandenfeld und ein ein Bit-Kennzeichenfeld, wie oben beschrieben wurde. Das Adressenfeld ist die Startadresse einer Mikrobefehlsabfolge in EUSITT 20344, und EU 10122 führt die von jener Mikrobefehlsabfolge gesteuerte Operation durch. EUSITT 20344 fordert elf Bits des Adressenfeldes an und das neun Bit-Adressenfeld der EUDPs werden in ein elf Bit-Adressenfeld durch Linksausrichtung und Nullenauffüllung zusammengefügt.
FU 10120 kann auch jede beliebige von EU 10122 mikrobefehlsgesteuerte Operation vom JPD-Bus 10142 absetzen oder auswählen. Solche EUDPs werden vom JPD-Bus 10142 zum Dateneingang von EUSITT 20344 gebracht und direkt zu mCRD 20346 durchgereicht. Bevor ein EUDP vom JPD-Bus 10142 zur Verfügung gestellt werden kann, stellt FU 10120 jedoch eine Prüfoperation zur Verfügung, indem es jenen EUDP mit einer Liste von legalen oder erlaubten EUSITT 20344-Adressen vergleicht, die in MEM 10112 gespeichert ist. Ein Fehler wird angezeigt, falls ein EUDP durch den JPD-Bus 10142 zur Verfügung gestellt wird und keine legale EUSITT 20344-Adresse ist. Andererseits kann FU 10120 praktisch ein EUDP oder EUSITT 20344-Adressen von einem Literalfeld in einem FU 10120-Mikrobefehlswort zur Verfügung stellen. Ein solches Literalfeld eines FU 10120-Mikrobefehlswortes kann praktisch als SOP in EUSDT 20266 benutzt werden.
Der Quittungsbetrieb zwischen EU 10122 und FU 10120 während der COMQ 20243- Ladeoperationen kann, wie in Fig. 260 angezeigt, vor sich gehen. Ein zwölf Bit EUDP kann auf den EUDIS-Bus 20206 plaziert und das Steuersignal Befehlswarteschlange laden (LDCMQ) aufgeprägt werden. Falls COMQ 20342 voll ist, setzt EU 10122 das Steuersignal Befehl-halten (CMDHOLD) ab, das FU 10120 dazu veranlaßt, im Zustand M0 zu verbleiben, bis es Platz in COMQ 20342 gibt. Wie oben beschrieben, umfaßt COMQ 20342 zwei Zweiwortpuffer, von denen ein Puffer für den normalen SOP-Betrieb und der andere für die Steuerung von FU 10120 und den Betrieb der EU 10122-internen Mechanismen gebraucht wird.
Die EUDPs werden in COMQ 20342 geladen, wenn die Zeitsignale M1CPT und M1 aufgeprägt werden. Wenn ein gerade im COMQ 20342 transferierter EUDP eine Gleitkommaoperation doppelter Genauigkeit betrifft, so wird das Steuersignal Doppelte- Genauigkeit-setzen (SETDP) aufgeprägt. SETDP wird zur Steuerung von OPB 20322 benutzt, und weil Gleitkommazahloperationen einfacher und doppelter Genauigkeit sonst denselben SOP benutzen und sich so auf dieselbe EUSITT 20344-Mikrobefehlsabfolge beziehen würden.
An diesem Punkt wurde ein EUDP in COMQ 20342 geladen und wird durch EUCL 20310, wie oben beschrieben, dekodiert, um den Betrieb von FU 10120 zu steuern. Jeder spezielle EUDP wird durch die EUSITT 20344-Mikrobefehlsabfolge jenes EUDPs gelöscht, nachdem die angeforderte Mikrobefehlsabfolge ausgeführt worden ist.

b.b.b. Laden des Operandenpuffers 20320 (Fig. 261)

In Fig. 261 wird eine diagrammartige Darstellung der Schnittstelle und des Quittungsbetriebes zwischen EU 10122, FU 10120 und MEM 10112 für das Laden von OPB 20322 gezeigt. Das Steuersignal Volle-Warteschlange-löschen (CLQF) von EU 10122 muß durch EU 10122 aufgeprägt werden, bevor FU 10120 eine Anforderung an MEM 10112 für einen Operanden, der nach EU 10122 transferiert werden soll, initiiert. CLQF löscht die "EU 10122's OPB 20322 voll"-Bedingung in FU 10120. CLQF zeigt daher an, daß es in OPB 20322 Platz gibt, um Operanden zu empfangen. Falls FU 10122 in einer "EU 10122's OPB 20322 voll"-Bedingung ist, und ein weiterer Operand zu EU 10122 transferiert werden soll, bleibt FU 10120 im Zustand M1 bis CLQF aufgeprägt wird.
Beim Beginn der Ausführung eines bestimmten SOPs kann FU 10120 zwei Operanden nach OPB 20322 transferieren, ohne daß die Bedingung "EU 10122's OPB 20322 voll" auftritt. Das kommt daher, weil EU 10122 beim Beginn der Ausführung eines SOPs im Leerlaufzustand ist und allgemein sofort einen ersten Operanden von OPB 20322 herunterlädt, bevor ein zweiter Operand ankommt.
Das Steuersignal Jobprozessoroperand (JPOP), das von FU 10120 zur Verfügung gestellt wird, darf nicht aufgeprägt sein, wenn Operanden von MEM 10112 durch den MOD-Bus 10144 nach OPB 20322 transferiert werden sollen. Das ist der Normalzustand für JPOP. Falls JPOP aufgeprägt ist, so wird OPB 20322 mit Daten vom JPD-Bus 10142 geladen. Die Daten werden vom JPD-Bus 10142 durch die Steuersignale M1CPT und JPOP in OPB 20322 eingeblendet. Von MEM 10112 gelesene Operanden werden jedoch in OPB 20322 über den MOD-Bus 10144 transferiert, wenn MEM 10112 DAVEB aufprägt, um anzuzeigen, daß gültige Daten von MEM 10112 auf dem MOD-Bus 10144 verfügbar sind. DAVEB wird auch benutzt, um Daten auf dem MOD-Bus 10144 in OPB 20322 einzublenden. Falls das Steuersignal ZFILL von MEM 10112 zu diesem Zeitpunkt aufgeprägt wird, so wird ZFILL während Ganzzahloperandenoperationen interpretiert, um anzuzeigen, daß jene Operanden ohne Vorzeichen sind und links mit Nullen aufgefüllt werden sollen, anstatt mit einem Vorzeichen erweitert zu werden. Wenn Daten vom JPD-Bus 10142 anstatt von MEM 10112 zur Verfügung gestellt werden, d. h. wenn JPOP aufgeprägt ist, kann das Bit 11 des gegenwärtigen EUDP dazu benutzt werden, die gleiche Funktion wie ZFILL während des Ladens von OPB 20322 vom MOD-Bus 10144 auszuführen.
Das Laden von OPB 20322 wird teilweise durch die Bits 9 und 10 der von FU 10120 durch den EUDIS-Bus 20206 zur Verfügung gestellten EUDPs kontrolliert. Bit 9 zeigt die Länge eines ersten Operanden, während Bit 10 die Länge eines zweiten Operanden anzeigt. Die Operandenlänge bestimmt zusammen mit dem im Adreßbereich eines EUDP spezifizierten Operandentypen, wie ein bestimmter Operand von OPB 20322 heruntergeladen und in MULT 20314 und EXP 20316 transferiert wird.
An diesem Punkt sind sowohl COMQ 20342 als auch OPB 20322 mit EUDPs bzw. Operanden geladen worden. Es sollte bemerkt werden, daß Operanden im allgemeinen nicht in OPB 20322 transferiert werden, bevor nicht ein entsprechender EUDP in COMQ 20342 geladen wurde. Operanden und EUDPs können jedoch gleichzeitig in EU 10122 transferiert werden. Falls andere Operanden für eine bestimmte Operation erforderlich sind, so werden jene Operanden in OPB 20322, wie oben beschrieben, geladen.

c.c.c. Zurückspeichern (Fig. 262)

In Fig. 262 wird die diagrammartige Darstellung eines Zurückspeicherns oder eines Transfers von Ergebnissen von EU 10122 nach MEM 10112 und der dabei durchgeführte Quittungsbetrieb gezeigt. Wenn ein Endergebnis einer EU 10122-Operation verfügbar ist, prägt EU 10122 das Steuersignal Daten-fertig (DRDY) auf. FU 10120 antwortet darauf mit dem Steuersignal Transfer zum JPD-Bus 10142 (XJPD), das das Ergebnis von EU 10122 auf den JPD-Bus 10142 schaltet. Im Normalbetrieb, d. h. der Ausführung von SOPs, veranlaßt FU 10120, daß das Ergebnis von EU 10122 an einen Zielort in MEM 10112 zurückgespeichert wird, wie es vom von FU 10120 zur Verfügung gestellten physikalischen Beschreiber ausgewählt wurde. Alternativ dazu kann ein Ergebnis in FU 10120 32 Bit- oder ein Wort-weise transferiert werden.
FU 10120 kann, wie oben beschrieben und weiter unten beschrieben wird, während des Rückspeicherns von Ergebnissen EU 10122 Prüfbedingungen untersuchen. FU 10120 erzeugt das Steuersignal Transfer-vollständig (XFRC), sobald die Rückspeicheroperation vollendet ist. XFRC zeigt EU 10122 auch an, daß die Ergebnisse und Prüfbedingungen von EU 10122 durch FU 10120 akzeptiert worden sind, so daß EU 10122 diese Ergebnisse und Prüfbedingungen nicht mehr länger aufprägen muß.

d.d.d. Prüfbedingungen (Fig. 263)

In Fig. 263 wird eine diagrammartige Darstellung der Überprüfung der EU 10122- Prüfbedingungen durch FU 10120 mit dem darin enthaltenen Quittungsbetrieb gezeigt. Wie oben beschrieben, werden Prüfergebnisse, die bestimmte Zustände und Operationen von EU 10122 anzeigen, gesammelt und in TSTCOND 20384 gespeichert, und können durch FU 10120 untersucht werden. Wenn DRDY von EU 10122 aufgeprägt wird, kann FU 10120 z. B. eine von acht zu prüfenden EU 10122-Bedingungen auswählen, ebenso wie Ergebnisse, wie oben beschrieben, zu transferieren. Die EU 10122-Bedingungen, die von FU 10120 getestet werden können, werden unten aufgelistet und beschrieben. Solche Bedingungen wie, ob ein Endergebnis positiv, negativ oder Null ist, können überprüft werden, um die bedingte Verzweigung von FU 10120-Operationen, die oben beschrieben wurden, zu erleichtern. FU 10120 spezifiziert eine zu überprüfende Bedingung durch Prüfbedingungsauswahlsignale (TEST (2-4)). FU 10120 prägt das Steuersignal EU- Prüfung-aktivieren (EUTESTEN) EU 10122 auf, um die ausgewählte Testbedingung zu schalten. Jene ausgewählte Prüfbedingung gelangt dann als Datensignal Prüfbedingung (TC) von EU 10122 nach FU 10120. Eine TC, die logisch 1 ist, kann z. B. anzeigen, daß die ausgewählte Bedingung falsch ist, während eine TC, die logisch 0 ist, anzeigen kann, daß die ausgewählte Bedingung wahr ist. FU 10120 zeigt durch die Aufprägung des Steuersignals XFRC an, daß FU 10120 die angeforderte Prüfbedingung erfaßt hat, und daß die Prüfbedingung nicht mehr länger von EU 10122 aufgeprägt werden muß.

e.e.e. Ausnahmenüberprüfung (Fig. 264)

In Fig. 264 wird eine diagrammartige Darstellung der Ausnahmenüberprüfung von EU 10122-Ausnahmen durch FU 10120 und der darin enthaltene Quittungsbetrieb gezeigt. Wie oben beschrieben, kann jeder beliebige EU 10122-Ausnahmezustand durch FU 10120 überprüft werden, wenn FU 10120 ein Zurückspeichern der EU 10122-Ergebnisse initiiert. Die Ausnahmenüberprüfung kann z. B. eine versuchte Division durch Null aufdecken, Gleitkommaexponenten-Überlauf oder -Unterlauf, oder einen Behältergrößenfehler. Eine versuchte Division durch Null oder ein Überlauf oder Unterlauf von Gleitkommazahlen kann vor dem Rückspeichern, d. h. ohne bestimmte Anforderung durch FU 10120, überprüft werden.
Wie oben beschrieben, wird ein Behältergrößenfehler durch CONSIZE 20352 aufgedeckt, indem es die Ergebnislänge mit der Größe des Zielortbehälters in MEM 10112 vergleicht. Die Behältergrößenausnahmenüberprüfung passiert während des Rückspeicherns der EU 10122-Ergebnisse, d. h. während FU 10120 sich im Zustand SB befindet. Die Behältergrößenüberprüfung wird automatisch durch die Hardware von EU 10122, d. h. durch CONSIZE 20352, durchgeführt, aber nur bei Ergebnissen, die kleiner sind als 33 Bits. Die Größenüberprüfung von größeren Ergebnissen, d. h. größeren ganzzahligen und BCD- Ergebnissen, wird durch ein Mikrocodeprogramm durchgeführt, das die Ausgabe von CONSIZE 20352 benutzt, da der Transfer solcher größeren Ergebnisse als Zeichenkettentransfer ausgeführt wird. Es ist unnötig, Behältergrößenüberprüfungen für Gleitkommaergebnisse einfacher oder doppelter Genauigkeit durchzuführen, weil diese Datentypen immer entweder 32 oder 64 Bits besetzen. Die Zielortbehältergröße wird von CONSIZE 20352 über den LENGTH-Bus 20226 zur Verfügung gestellt.
Das Steuersignal Länge für Speicher-AOn oder Zufallssignale (LMAONRS) wird von Fu 10120 vom Typenfeld des logischen Beschreibers, der einem bestimmten EU 10122- Ergebnis entspricht, erzeugt. LMAONRS zeigt an, daß der Datentyp des Ergebnisses ein Ganzzahlwert ohne Vorzeichen ist. LMAONRS bestimmt die Art und Weise, in der eine angeforderte Behältergröße des EU 10122-Ergebnisses bestimmt wird. Nachdem diese Information von LMAONRS empfangen wurde, bestimmt EU 10122, ob die Zielortbehältergröße in MEM 10112 ausreichend groß ist, um das EU 10122-Ergebnis aufzunehmen. Falls die Zielortbehältergröße nicht groß genug ist, wird ein Behältergößenfehler von CONSIZE 20352 oder durch eine EU 10122-Mikrobefehlsabfolge aufgedeckt.
Behältergrößenfehler werden genau so wie Divisionen durch Null und Exponentenüberläufe oder -unterläufe FU 10120 signalisiert, wenn FU 10120 das Steuersignal Größenüberprüfung (CKSIZE) aufprägt. Zu diesem Zeitpunkt prägt EU 10122 das Steuersignal Ausnahme (EXCPT) auf, wenn irgendeiner der obigen Fehler aufgetreten ist. Wenn ein Fehler aufgetreten ist, so ergibt sich eine Ereignisanforderung für FU 10120. Wenn eine Ereignisanforderung durch FU 10120 bedient wird, kann FU 10120 EU 10122 unterbrechen und EU 10122 mit einem Mikrobefehlsprogramm versorgen, das jenen Ausnahmezustand auf den JPD-Bus 10142 transferiert. Wenn ein Behältergrößenfehler jene Ausnahmezustand verursacht hat, kann EU 10122 die angeforderte Behältergröße FU 10120 über den JPD-Bus 10142 vermitteln.

f.f.f. Leerlaufprogramm

Wenn eine gegenwärtige EU 10122-Operation schließlich beendet ist, geht EU 10122 in eine Leerlaufschleife in einem Mikrobefehlsprogramm. Falls nötig, kann FU 10120 das Steuersignal Ausführungseinheit-abbrechen (EUABORT) aufprägen, um EU 10122 in die Leerlaufschleife des Mikrobefehlsprogrammes zu bringen, bis EU 10122 für weitere Operationen benötigt wird.

g.g.g. EU 10122-Stapelspeichermechanismen (Fig. 265, 266, 267)

Wie oben beschrieben, kann EU 10122 zwei Operationsklassen durchführen. Erstens kann EU 10122 arithmetische Operationen bei der Ausführung von den SOPs eines Benutzerprogrammes durchführen. Zweitens kann EU 10122 als arithmetischer Rechner arbeiten, der den Betrieb der FU 10120-internen Mechanismen und Operationen, die als Kernoperationen bezeichnet werden, unterstützt.
Bei Kernoperationen agiert EU 10122 als arithmetischer Rechner für FU 10120 während der Erzeugung von Adressen, des Transfers von Adressen oder anderer Kernfunktionen. Während der Kernbetriebsart führt EU 10122 Mikrobefehlsabfolgen auf Anforderung von Kernmikrobefehlsabfolgen von FU 10120, und nicht auf Anforderung eines SOPs aus. Im allgemeinen sind diese Kernoperationen unerläßlich für den Betrieb von JP 10114. FU 10120 kann EU 10122-Operationen, die SOPs betreffen, unterbrechen und EU 10122- Mikrobefehlsabfolgen initiieren, um Kernoperationen durchzuführen.
Wenn sie unterbrochen wurde, sichert EU 10122 ihren gegenwärtigen Betriebszustand in einem 1-Ebenen-tiefen Stapelspeicher ab. EU 10122 kann dann aus jenem Bereich von COMQ 20342, der zum Empfangen und Abspeichern von EUDPs benutzt wird, die FU 10120's und EU 10122's interne oder Kernoperationen betreffen, zu empfangen und zu speichern. Wenn FU 10120 Kernoperationen von EU 10122 anfordert, transferiert sie im allgemeinen Operanden über den JPD-Bus 10142 zu OPB 20322 und empfängt die Endergebnisse von EU 10122 durch den JPD-Bus 10142. Operanden können auch über den MOD-Bus 10144 EU 10122 zur Verfügung gestellt werden. Nachdem EU 10122 die angeforderte Kernoperation beendet hat, lädt sie ihren Betriebszustand von ihrem internen Stapelspeicher zurück und Fahrt mit dem Normalbetrieb von dem Punkt an fort, an dem der Normalbetrieb unterbrochen wurde.
Sollte eine andere Unterbrechung von FU 10120 auftreten, während eine frühere Unterbrechung ausgeführt wird, schiebt EU 10122 den Zustand und die Daten der ersten Unterbrechung zu MEM 10112. EU 10122 fordert den FU 10120-Speicherzustand und die Daten der ersten Unterbrechung in MEM 10112 an, indem es ein "EU 10122-Stapelspeicherüberlauf"-Ereignis anfordert. EU 10122' s "Normal"-Zustand, d. h. der Zustand und die Daten, die zur gegenwärtig von EU 10122 ausgeführten Operation zum Zeitpunkt des Auftretens der ersten Unterbrechung gehören, werden in einem EU 10122-internen Stapelspeicher gespeichert und verbleiben dort. Dann beginnt EU 10122, die zweite Unterbrechung auszuführen. Wenn EU 10122 die Operationen für die zweite Unterbrechung beendet hat, wird der Zustand der ersten Unterbrechung von MEM 10112 zurückgeladen, indem EU 10122 ein "EU 10122-Stapelspeicherunterlauf"-Ereignis bei FU 10120 anfordert. EU 10122 vollendet dann die Ausführung der ersten Unterbrechung und lädt den Zustand des Normalbetriebs zurück und nimmt die Ausführung des Normalbetriebs wieder auf, d. h. die Operationen, die vor der ersten Unterbrechung ausgeführt wurden.
EU 10122 ist dadurch imstande, Unterbrechungen von FU 10120 während zweier Umstände zu verwalten. Der erste Unterbrechungsumstand umfaßt Unterbrechungen, die während des Normalbetriebs auftreten, d. h. während der Ausführung von SOPs von Benutzerprogrammen. Der zweite Umstand tritt auf, wenn Unterbrechungen während Kernoperationen passieren, d. h. während der Ausführung von Mikrobefehlsabfolgen zur Verwaltung von Unterbrechungen. Der Betrieb von EU 10122 wird unten für beide Umstände in der obigen Reilienfolge beschrieben.
In Fig. 265 wird eine diagrammartige Darstellung der Stapelspeichermechanismen von EU 10122, die oben beschrieben wurden, gezeigt. Jene Bereiche der Stapelspeichermechanismen von EU 10122, die sich innerhalb EU 10122's befinden, umfassen die gegenwärtigen Zustandsregister (EUCSRs) 26510 von EU 10122 und den internen Stapelspeicher (EUIS) 26512 von EU 10122. EUCSR 26510 umfaßt interne Register von EU 10122, die Daten und den Zustand des gegenwärtigen Betriebs von EU 10122 enthalten. EUCSR 26510 wird z. B. mCRD 20346, die Register von TSTINT 20320 und die oben beschriebenen Register innerhalb MULT 20314 und EXP 20316 umfassen.
Der Zustand und die Daten, die in EUCSR 26510 enthalten sind, ist der der Operation, die augenblicklich von EU 10122 ausgeführt wird. Dieser aktuelle Zustand kann z. B. der eines augenblicklich von EU 10122 ausgeführten SOPs, oder der einer Unterbrechung sein, z. B. einer vierten Unterbrechung einer geschachtelten Abfolge von Unterbrechungen, die von FU 10120 angefordert wurden.
EUIS 26512 umfaßt bestimmte Register von MULTBF 20350 und EXPRF 20380. EUIS 26512 wird dazu benutzt, um den gegenwärtigen Zustand einer augenblicklich von EU 10122 ausgeführten SOP-Operation, die unterbrochen wurde, zu speichern und zu sichern. Der Zustand und die Daten jener SOP-Operation bleiben in EUIS 26512, ohne Rücksicht auf die Anzahl der Unterbrechungen, die in einer geschachtelten Abfolge von von FU 10120 angeforderten Unterbrechungen auftreten können, gespeichert. Der Zustand und die Daten der unterbrochenen SOP-Operation wird von EUIS 26512 zu EUCSR 26510 zurückgegeben, wenn alle Unterbrechungen beendet worden sind.
Der letzte Bereich des Stapelspeichermechanismus von EU 10122 ist jener Bereich des internen Stapelspeichers (EUES) 26514 von EU 10122, der sich in MEM 10112 befindet. EUES 26514 umfaßt bestimmte MEM 10112-Adreßlokatioben, die dazu benutzt werden, um den Zustand und die Daten von aufeinanderfolgenden Unterbrechungsoperationen geschachtelter Unterbrechungsabfolgen zu speichern. Das heißt, wenn eine Abfolge von vier Unterbrechungen durch FU 10120 angefordert wird, so befinden sich der Zustand und die Daten der vierten Unterbrechung in EUCSR 26510, während der Zustand und die Daten der ersten, zweiten und dritten Unterbrechung in Folge in EUES 26514 transferiert wurden. In dieser Hinsicht ist der Betrieb der Stapelspeichermechanismen von EU 10122, wie er oben beschrieben wurde, z. B. dem von MIS 10368 und SS 10336, die oben im Zusammenhang mit der Fig. 103 beschrieben wurden, ähnlich.
Wie oben beschrieben, kann eine Unterbrechung von EU 10122 durch FU 10120 entweder während des Normalbetriebs von EU 10122, d. h. während der Ausführung von SOPs durch EU 10122, angefordert werden, oder während EU 10122 eine vorherige von FU 10120 angeforderte Unterbrechung ausführt. Der Betrieb von EU 10122 und FU 10120 beim Auftreten einer Unterbrechung während des Normalbetriebs von EU 10122 wird als nächstes unten beschrieben.
In Fig. 266 wird eine diagrammartige Darstellung des Quittungsbetriebs zwischen EU 10122 und FU 10120 während einer Unterbrechung von EU 10122, während EU 10122 im Normalbetrieb arbeitet, gezeigt und es sollte darauf in Verbindung mit Fig. 265 Bezug genommen werden. Während der folgenden Diskussionen werden die Unterbrechungen der EU 10122-Operationen durch FU 10120 als Nano-Unterbrechungen bezeichnet, um sie von den Unterbrechungen, die intern in FU 10120 sind, zu unterscheiden.
FU 10120 unterbricht den Normalbetrieb von EU 10122, indem es während des Zustands M0 des FU 10120-Betriebes das Steuersignal Nano-Unterbrechung (NINTP) aufprägt. NINTP kann durch EU 10122 während bestimmter kritischer EU 10122-Operationen, wie z. B. arithmetischer Operationen, maskiert werden. Wenn NINTP von EU 10122 maskiert wird, bleibt FU 10120 im Zustand MW, bis EU 10122 die Unterbrechung bestätigt.
Beim Empfang von NINTP von FU 10120 transferiert EU 10122 den Zustand und die Daten der gegenwärtigen SOP-Operation von EUCSR 26510 zu EUIS 26512. EU 10122 prägt dann das Steuersignal Nano-Unterbrechung-bestätigen (NIACK) für FU 10120 auf, um die Verfügbarkeit von EU 10122, eine Nano-Unterbrechung annehmen zu können, zu bestätigen. FU 10120 tritt dann in den Zustand M1 ein und plaziert einen EUDP auf den EUDIS-Bus 20206. Das Laden von COMQ 20342 vollzieht sich dann wie oben beschrieben, indem EU 10122 Nano-Unterbrechungs-EUDPs in die geeigneten Register von COMQ 20342 lädt. COMQ 20342 wird wie oben beschrieben geladen und, falls JPOP aufgeprägt ist, werden Daten vom JPD-Bus 10142 nach OPB 20322 transferiert. Falls JPOP nicht aufgeprägt ist, werden die Daten vom MOD-Bus 10144 nach OPB 20322 transferiert. EU 10122 fährt dann damit fort, die angeforderte Nano-Unterbrechungsoperation auszuführen, und das Zurückspeichern der Ergebnisse und die Überprüfung der Prüfbedingungen vollzieht sich, wie oben für den EU 10122-Normalbetrieb beschrieben. Im allgemeinen wird eine Ausnahmenüberprüfung nicht durchgeführt. Wenn EU 10122 die Ausführung der Nano-Unterbrechungsoperation beendet hat, transferiert EU 10122 den Zustand und die Daten der unterbrochenen SOP-Operation von EUIS 26512 zu EUCSR 26510 und nimmt die Ausführung jenes SOP wieder auf. An diesem Punkt prägt EU 10122 das Steuersignal Nano-Unterbrechungsfalle-aktivieren (NITE) auf. NITE wird von FU 10120 empfangen und überprüft, um das Ende der Nano-Unterbrechungsverarbeitung anzuzeigen.
In Fig. 267 wird eine diagrammartige Darstellung der Schnittstellen zwischen EU 10122, FU 10120 und MEM 10112 während verschachtelter oder sequentieller EU 10122- Unterbrechungen für Kernoperationen und der darin enthaltene Quittungsbetrieb gezeigt. Für die folgende Diskussion sei angenommen, daß EU 10122 bereits eine Nano-Unterbrechung für eine Kernoperation verarbeitet, die von FU 10120 zu EU 10122 abgesetzt wurde. FU 10120 kann dann eine zweite, dritte oder vierte Nano-Unterbrechung zu EU 10122 für eine weitere Kernoperation absetzen. FU 10120 prägt NINTP auf, um eine Nano-Unterbrechung von EU 10122 anzufordern. EU 10122's normaler Betriebszustand und die Daten einer vorher ausführenden SOP-Operation wurden in EUIS 26512 gespeichert und verbleiben darin. Der gegenwärtige Zustand und die Daten der gegenwärtig ausführenden Nano-Unterbrechungsoperation in EUCSR 26510 werden zu EUES 26514 in MEM 10112 transferiert, um die Initiierung von hängenden Nano-Unterbrechungen zu ermöglichen. EU 10122 prägt zu diesem Zeitpunkt NIACK und das Steuersignal Ausführungseinheitsereignis (EXEVT) auf. EXEVT zu FU 10120 informiert FU 10120, daß ein EU 10122-Ereignis aufgetreten ist, wobei speziell in diesem Falle EXEVT die FU 10120-Bedienung eines EU 10122-Stapelspeicherüberlaufs anfordert. FU 10120 wird dadurch veranlaßt, eine "EU 10122-Stapelspeicherüberlaufs"-Ereignismanagermikrobefehlsabfolge zu aktivieren. Dieser Manager transferiert den gegenwärtigen Zustand und die Daten der unterbrochenen Nano-Unterbrechung, die vorher in EU 10122 ausführte, in EUES 26514. Der Zustand und die Daten der unterbrochenen Nano-Unterbrechung wird nach EUES 26514 32 Bit-weise transferiert. FU 10120 prägt die Steuersignale XJPD auf, um jedes dieser Zustands- und Datenworte auf den JPD-Bus 10142 zu schalten und steuert diesen Transfer dieser Worte in EUES 26514.
Die Verarbeitung neuer Nano-Unterbrechungen vollführt sich, wie oben im Zusammenhang mit den Unterbrechungen beschrieben, die während des Normalbetriebs auftreten. Wenn irgendeine nachfolgende Nano-Unterbrechung auftritt, wird sie in der gleichen Weise wie eben beschrieben verwaltet; FU 10120 signalisiert eine Nao-Unterbrechung an FU 10120, der gegenwärtige EU 10122-Zustand und die Daten werden durch FU 10120 in EUES 26514 gesichert, und die neue Nano-Unterbrechung wird bearbeitet. Nachdem eine verschachtelte Nano-Unterbrechung, d. h. eine Nano-Unterbrechung einer Abfolge von Nano-Unterbrechungen, bedient wurde, prägt EU 10122 das Steuersignal EU 10122-Falle (ETRAP) für Fu 10120 auf, um einen Transfer des vorherigen Nano-Unterbrechungszustandes und der Daten von EUES 26514 zu EUCSR 26510 anzufordern. FU 10120 findet jenen vorherigen Nano-Unterbrechungszustand und die Daten von EUES 26514 über den MOD-Bus 10144 und transferiert jene Daten und den Zustand auf den JPD-Bus 10142. Dieser Zustand und die Daten werden 32 Bit-weise durch JPOP von FU 10120 zurückgegeben und in EU 10122 eingeblendet. Dann wird die Verarbeitung jener früheren Unterbrechung wieder aufgenommen. Die Bedienung jener aufeinander folgenden früheren Nano-Unterbrechungen geht so lange weiter, bis alle früheren Nano-Unterbrechungen bedient worden sind. Der Originalzustand und die Daten von EU 10122, d. h. jene der SOP-Operation, die anfangs unterbrochen wurde, wird dann von EUIS 26512 zu EUCSR 26510 zurückgegeben und die Ausführung jenes SOP wird wieder aufgenommen. Jetzt prägt EU 10122 NITE auf, um das Ende der EU 10122-Kernoperationen hinsichtlich der Nano-Unterbrechungen anzuzeigen.
Nachdem die Struktur und der Betrieb von EU 10122, FU 10120 und MEM 10112 hinsichtlich der Bedienung der Kernoperations-Nano-Unterbrechungen durch EU 10122 beschrieben wurden, wird als nächstes das Laden von EUSITT 20344 von EU 10122 mit Mikrobefehlsabfolgen beschrieben.

h.h.h. Laden der Ausführungseinheits-S-Interpreter-Tabelle 20344 (Fig. 268)

In Fig. 268 wird eine diagrammartige Darstellung der Schnittstelle und des Quittungsbetriebs zwischen EU 10122, FU 10120, MEM 10112 und DP 10118 während des Ladens von Mikrobefehlen in EUSITT 20344 gezeigt. Wie oben beschrieben, enthält EUSITT 20344 alle Mikrobefehle, die für die Steuerung von EU 10122 bei der Ausführung von Kern-Nano-Unterbrechungsoperationen und der Ausführung von arithmetischen Operationen als Antwort auf SOPs von Benutzerprogrammen, benötigt werden. EUSITT 20344 kann Mikrobefehlsabfolgen für das Interpretieren der arithmetischen SOPs eines Benutzerprogramms für z. B. bis zu vier verschiedenen S-Sprachen-Dialekten abspeichern. Im allgemeinen ist für die meisten Anforderungen eine Speicherkapazität von Mikrobefehlsabfolgen für arithmetische Operationen von bis zu vier S-Sprachen-Dialekten ausreichend, so daß EUSITT 20344 nur bei der Initialisierung des CS 10110-Betriebs mit Mikrobefehlsabfolgen geladen werden muß. Sollten Mikrobefehlsabfolgen für arithmetische Operationen von mehr als vier S-Sprachen-Dialekten erforderlich werden, so können jene Mikrobefehlsabfolgen in EUSITT 20344 in der unten beschriebenen Weise geladen werden.
Wie oben beschrieben, ist ein Bereich der in EUSITT 20344 gespeicherten Mikrobefehle in nur-Lesespeichern enthalten und von daher permanent in EUSITT 20344 verfügbar. Permanent in EUSITT 20344 gespeicherte Mikrobefehlsabfolgen sind z. B. jene, die zur Ausführung von Kernoperationen erforderlich sind. Permanent in EUSITT 20344 gespeicherte Mikrobefehlsabfolgen beinhalten jene, die dazu benötigt werden, beim Schreiben anderer EU 10122-Mikrobefehlsabfolgen in EUSITT 20344 nach Bedarf zu helfen. Bestimmte Mikrobefehlsabfolgen werden in Speicher freien Zugriffs gespeichert, der als beschreibbarer Steuerspeicher (WCS)-Bereich von EUSITT 20344 bezeichnet wird, und beinhalten diese zur Interpretation arithmetischer Operations-SOPs verschiedener S- Sprachen-Dialekte.
Das Schreiben von Mikrobefehlsabfolgen in EU 10122 wird dadurch initialisiert, daß EU 10122 in einen Leerlaufzustand gebracht wird. Die Initialisierung von EU 10122 wird durch die Aufprägung des Steuersignals EUABORT von FU 10120 oder durch die Aufprägung des Steuersignals Löschen (CLEAR) von DP 10118 beendet. Entweder EUABORT oder CLEAR löschen die gegenwärtige Operation von EU 10122 und zwingen EU 10122 in den Leerlaufzustand, in dem EU 10122 auf weitere von FU 10120 zur Verfügung gestellte EUDPs wartet. FU 10120 setzt dann über den EUDIS-Bus 20206 für EU 10122 einen EUDP ab, der das Laden von EUSITT 20344 initiiert. Ein EUDP zum Laden von EUSITT 20344 spezifiziert die Anfangsadresse einer zweistufigen Mikrobefehlsabfolge im PROM-Bereich von EUSITT 20344. Diese zweistufige Mikrobefehlsabfolge lädt zuerst Nullen in SCAG 25536, das, wie oben beschrieben, Lese- und Schreibadressen für EUSITT 20344 zur Verfügung stellt. Die EUSITT 20344-Lademikrobefehlsabfolge liest dann einen Mikrobefehl von EUSITT 20344 zu mCRD 20346. Dieser Mikrobefehl spezifiziert Bedingungen für den Quittungsbetrieb mit FU 10120, so daß das Laden von EUSITT 20344 beginnen kann. Jetzt und mit diesem Mikrobefehlswort prägt EU 10122 das Steuersignal DRDY für FU 10120 auf, um anzuzeigen, daß EU 10122 bereit ist, EUDPs von FU 10120 für das direkte Laden von EUSITT 20344 zu empfangen. Dieser anfängliche Mikrobefehl erzeugt auch ein Schreibaktivierungssteuersignal für den WCS-Bereich von EUSITT 20344, verhindert das Laden von mCRD 20346 von EUSITT 20344 und verhindert normale Ladeoperationen von NXTR 25540 und SCAG 25536. Dieser erste Mikrobefehl veranlaßt auch NASS 25526, Adreßeingaben von SCAG 25536 zu empfangen und veranlaßt FU 10120, NITE aufzuprägen, um Nano-Unterbrechungen von FU 10120 zu demaskieren.
FU 10120 erzeugt dann eine Leseanforderung für MEM 10112, und MEM 10112 transferiert ein erstes 32 Bit-Wort eines EU 10122-Mikrobefehlswortes auf den JPD-Bus 10142. Jedes dieser 32 Bit-Worte von MEM 10112 umfaßt eine Hälfte eines 64 Bit- Mikrobefehlswortes von EU 10122. Wenn FU 10120 DRDY von EU 10122 empfängt, erzeugt FU 10120 das Steuersignal beschreibbaren Steuerspeicher laden (LDWCS). LDWCS transferiert wiederum ein 32 Bit-Wort auf dem JPD-Bus 10142 in eine erste Adresse des WCS-Bereichs von EUSITT 20344. Ein nächstes 32 Bit-Halbwort eines EU 10122-Mikrobefehlswortes wird dann von MEM 10112 über den JPD-Bus 10142 gelesen und in die zweite Hälfte jener ersten Adresse innerhalb des WCS-Bereichs von EUSITT 20344 transferiert. Die Adresse in SCAG 25536 wird dann inkrementiert, um eine nächste Adresse innerhalb EUSITT 20344 auszuwählen, und der eben beschriebene Prozeß wird automatisch wiederholt einschließlich der Erzeugung von DRDY und LDWCS, bis das Laden von EUSITT 20344 abgeschlossen ist.
Nachdem das Laden von EUSITT 20344 abgeschlossen ist, wird der Ladeprozeß beendet, wenn FU 10120 NINTP aufprägt oder DP 10118 das Steuersignal Laden-beendet (LOADCR) aufprägt. Entweder NINTP oder LOADCR befreit NAG 20340 von der Betriebssteuerung, um es EU 10122 zu ermöglichen, den Normalbetrieb wieder aufzunehmen.
Die obigen Beschreibungen haben die Struktur und den Betrieb von EU 10122 einschließlich folgendem beschrieben: die Ausführung verschiedener arithmetischer Operationen unter Benutzung verschiedener Operandenformate; der Betrieb von EU 10122, FU 10120 und MEM 10112 hinsichtlich des Quittungsbetriebs; das Laden von EUDPs und Operanden; das Rückspeichern von Ergebnissen; die Überprüfung von Prüfbedingungen und Ausnahmen; die EU 10122-Stapelspeichermechanismen während normaler und während Kernoperationen; und das Laden von EU 10122-Mikrobefehlsabfolgen in EUSITT 20344. Als nächstes werden IOS 10116 und DP 10118 in dieser Reihenfolge beschrieben.

D. I/O-System 10116 (Fig. 204, 206, 269)

In Fig. 204 wird ein Ausschnitt aus einem Blockdiagramm von IOS 10116 gezeigt. Wie oben beschrieben, arbeitet IOS 10116 als Schnittstelle zwischen CS 10110 und der Außenwelt, z. B. ED 10124. Eine Hauptfunktion von IOS 10116 ist der Datentransfer zwischen CS 10110, d. h. MEM 10112 und der Außenwelt. Zusätzlich zur Durchführung von Datentransfers steuert IOS 10116 den Zugang zwischen verschiedenen Datenquellen und Senken von ED 10124 und MEM 10112. Wie oben beschrieben, adressiert IOS 10116 direkt den physikalischen Adreßraum von MEM 10112, um Daten in MEM 10112 zu schreiben oder von dort zu lesen. Dabei führt IOS 10116 auch Adreßübersetzungen durch, eine Abbildungsoperation, die zum Transfer von Daten zwischen MEM 10112's physikalischem Adreßraum und den Adreßräumen der Datenquellen und Senken in ED 10124 erforderlich ist.
Wie in Fig. 204 gezeigt, beinhaltet IOS 10116 den Datenschieber (DMOVR) 20410, den Eingabe/Ausgabe-Steuerprozessor (IOCP) 20412 und ein oder mehrere Datenkanalgeräte.
IOS 10116's Datenkanalgeräte können den ECLIPSE-Burst-Multiplexerkanal (EBMC) 20414, den NOVA-Datenkanal (NDC) 20416 und andere Datenkanalgeräte beinhalten, wie sie für eine spezielle Konfiguration eines CS 10110-Systems erforderlich sind. IOCP 20412 steuert und dirigiert den Datentransfer zwischen MEM 10112 und ED 10124 und steuert und dirigiert die Abbildung der Adressen zwischen ED 10124 und MEM 10112's physikalischem Adreßraum. IOCP 20412 kann z. B. aus einem ganz gewöhnlichen Computer bestehen, wie z. B. ein ECLIPSE M600-Computer, der Data General Corporation von Westboro, Massachusetts.
EBMC 20414 und NDC 20416 umfassen Datenkanäle, durch die Daten zwischen ED 10124 und IOS 10116 transferiert werden. EBMC 20414 und NDC 20416 führen aktuelle Datentransfers zu und von ED 10124 unter der Kontrolle von IOCP 20412 durch und führen die Abbildung der ED 10124-Adressen in MEM 10112's physikalische Adressen auch unter der Steuerung von IOCP 20412 durch. EBMC 20414 und NDC 20416 können z. B. aus einem ECLIPSE-Burst-Multiplexerdatenkanal und einem NOVA-Datenkanal bestehen, die auch von der Data General Corporation von Westboro, Massachusetts, verfügbar sind.
DMOVR 20410 umfaßt IOS 10116's Schnittstelle zu MEM 10112. DMOVR 20410 ist der Pfad, durch den Daten und Adressen zwischen EBMC 20414 und NDC 20416 und MEM 10112 transferiert werden. Darüber hinaus steuert DMOVR 20410 den Zugang zwischen EBMC 20414, NDC 20416 und anderen IOS 10116-Datenkanälen und MEM 10112.
ED 10124 kann, wie in Fig. 204 gezeigt, aus einer oder mehreren Datensenken und -quellen bestehen. Die ED 10124-Datensenken und -quellen können kommerziell verfügbare Festplatteneinheiten, Zeilendrucker, Nachrichtenlaufwerke, Bandeinheiten und andere Computersysteme, die andere CS 10110-Systeme beinhalten, umfassen. Im allgemeinen kann ED 10124 alle solche Datengeräte beinhalten, sobald sie eine allgemeine Schnittstelle mit einem Computersystem besitzen.

a. Struktur des I/O-Systems 10116 (Fig. 204)

Sich zuerst auf die Gesamtstruktur von IOS 10116 beziehend, so sind die Dateneingänge und Ausgänge des Kanaladapters und des Steuerschaltkreises des ECLIPSE-Burst-Multiplexers und der Steuerschaltkreis (BMCAC) 20418 von EBMC 20414 mit dem bidirektionalen BMC-Adreß- und Datenbus (BMCAD) 20420 verbunden. Der BMCAD-Bus 20420 wiederum ist mit den Daten und Adreßein- und -ausgängen der Datensenken und -quellen von ED 10124 verbunden.
In ähnlicher Weise sind die Daten und Adreßein- und -ausgänge der Steuerschaltkreise des NOVA-Datenkanaladapters (NDCAC) 20422 in NDC 20416 mit dem bidirektionalen NOVA-Datenkanaladreß- und -daten (NDCAD)-Bus 20424 verbunden. Der NDCAD-Bus 20224 ist wiederum mit den Adressen- und Datenein- und -ausgängen der Datenquellen und -senken von ED 10124 verbunden. Der BMCAD-Bus 20420 und der NDCAD-Bus 20224 sind Pfade für den Transfer von Daten und Adressen zwischen Datensenken und -quellen von ED 10124 und IOS 10116's Datenkanälen und können nach Bedarf erweitert werden, so daß sie andere IOS 10116-Datenkanalgeräte und andere Datensenken- und -quellgeräte von ED 10124 umfassen.
Innerhalb EBMC 20414 ist der bidirektionale Dateneingang und -ausgang von BMCAC 20418 mit dem bidirektionalen Eingang und Ausgang des BMC-Datenpuffers (BMCDB) 20426 verbunden. Die Datenein- und -ausgänge von BMCDB 20426 sind mit dem Datenschieber-Ausgangsdatenbus (DMOD) 20428 und dem Datenschieber-Eingangsdatenbus (DMID) 20430 verbunden. Die Adreßausgänge von BMCAC 20418 sind mit den Adreßeingängen der Burst-Multiplexer-Kanaladressenübersetzungskarte (BMCATM) 20432 verbunden, und die Adreßausgänge von BMCATM 20432 sind mit dem DMID-Bus 20430 verbunden. Ein bidirektionaler Steuereingang und -ausgang von BMCATM 20432 ist mit einem bidirektionalen IO-Kontrollprozessor-Steuerbus (IOCPC) 20434 verbunden.
Indem wir uns auf NDC 20416 beziehen, so sind die Datenein- und -ausgänge von NDCAC 20422, wie in Fig. 204 gezeigt, mit dem DMOD-Bus 20428 bzw. dem DMID- Bus 20430 verbunden. Die Adreßausgänge von NDCAC 20422 sind mit den Adreßeingängen der NOVA-Datenkanal-Adreßübersetzungskarte (NDCATM) 20436 verbunden. Die Adreßausgänge von NDCATM 20436 sind wiederum mit dem DMID-Bus 20430 verbunden. Ein bidirektionaler Steuerein- und -ausgang von NDCATM 20436 ist mit dem IOCPC-Bus 20434 verbunden.
Indem wir uns auf IOCP 20412 beziehen, so ist ein bidirektionaler Steuerein- und -ausgang von IOCP 20412 mit dem IOCPC-Bus 20434 verbunden. Der Adreß- und Datenausgang von IOCP 20412 ist mit dem NDCAD-Bus 20424 verbunden. Ein Adressenausgang der IOCP-Adressenübersetzungskarte (IOCPATM) 20438 innerhalb IOCP 20412 ist mit dem DMID-Bus 20430 verbunden. Die Datenein- und -ausgänge von IOCP 20412 sind mit dem DMOD-Bus 20428 bzw. dem DMID-Bus 20430 verbunden. Ein bidirektionaler Steuerein- und -ausgang von IOCP 20412 ist mit einem bidirektionalen Steuerein- und -ausgang von DMOVR 20410 verbunden.
Indem wir uns schließlich auf DMOVR 20410 beziehen, so umfaßt DMOVR 20410 den Eingabedatenpuffer (IDB) 20440, den Ausgabedatenpuffer (ODB) 20442 und die Prioritätenauflösung und -steuerung (PRC) 20444. Ein Daten- und Adreßeingang von IDB 20440 ist mit dem DMID-Bus 20430 verbunden. Ein Daten- und Adreßausgang von IDB 20440 ist mit dem IOM-Bus 10130 und mit MEM 10112 verbunden. Ein Datenausgang von ODB 20442 ist mit dem MIO-Bus 10129 von MEM 10112 verbunden, und ein Datenausgang von ODB 20442 ist mit dem DMOD-Bus 20428 verbunden. Die bidirektionalen Steuerein- und -ausgänge von IDB 20440 und ODB 20442 sind mit den bidirektionalen Steuerein- und -ausgängen von PRC 20444 verbunden. Ein bidirektionaler Steuerein- und -ausgang von PRC 20444 ist mit einem bidirektionalen Steuerein- und -ausgang von IOCP 20412, wie oben beschrieben, verbunden.
Noch ein bidirektionaler Steuerein- und -ausgang von PRC 20444 ist mit dem IOMC-Bus 10131 in Hin- und Rückrichtung, und damit mit einem Steuereingang und -ausgang von MEM 10112 verbunden. Nachdem die Gesamtstruktur von IOS 10116 beschrieben wurde, wird als nächstes der Betrieb von IOS 10116 beschrieben.

b. Betrieb des I/O-Systems 10116 (Fig. 269)

1. Datenkanalgeräte

Indem wir zuerst auf EBMC 20414 Bezug nehmen, so empfängt BMCAC 20418 Daten und Adressen von ED 10124 über den BMCAD-Bus 20420. BMCAC 20418 transferiert die Daten in BMCDB 20426, wo die Daten für die weitere Übertragung nach MEM 10112 über DMOVR 20410, wie unten beschrieben wird, gehalten werden. BMCRC 20418 transferiert von ED 10124 empfangene Adressen nach BMCATM 20432. BMCATM 20432 beinhaltet Adreßabbildungsinformationen, die die ED 10124-Adressen mit den MEM 10112-physikalischen Adressen korrelieren. BMCATM 20432 stellt daher MEM 10112 physikalische Adressen zur Verfügung, die den durch BMCRC 20418 zur Verfügung gestellten ED 10124-Adressen entsprechen.
Wenn, wie unten beschrieben wird, EBMC 20414 Zugang zu MEM 10112 erteilt wird, um Daten in MEM 10112 zu schreiben, so werden die in BMCDB 20426 gespeicherten Daten und ihre entsprechenden Adressen von BMCATM 20432 auf den DMID-Bus 20430 nach DMOVR 20410 transferiert. Wie unten beschrieben wird, schreibt dann DMOVR 20410 jene Daten in jene physikalische Adreßlokationen von MEM 10112. Wenn Daten von MEM 10112 nach ED 10124 gelesen werden sollen, so werden Daten durch DMOVR 20410 auf dem DMOD-Bus 20428 zur Verfügung gestellt und in BMCDB 20426 transferiert. BMCAC 20418 liest dann diese Daten von BMCDB 20426 und transferiert sie auf den BMCAD-Bus 20420 nach ED 10124. Während des Transfers von Daten von MEM 10112 nach ED 10124 stellt MEM 10112 keine Adressen zur Verfügung, die in ED 10124 übersetzt werden sollen, um jene Daten zu begleiten. Statt dessen werden jene Adressen von BMCAC 20418 erzeugt und zur Verfügung gestellt.
NDC 20416 arbeitet in einer ähnlichen Weise wie EBMC 20414, außer daß jene Datenein- und -ausgaben von NDCAC 20422 nicht durch ein BMCDB 20426 zwischengespeichert werden.
Wie oben beschrieben, hat MEM 10112 die Fähigkeit, Blocktransfers durchzuführen, d. h. daß es sequentiell Transfers von vier 32 Bit-Worten gleichzeitig durchführen kann. Im allgemeinen werden solche Transfers durch EBMC 20414 durchgeführt und werden durch BMCDB 20426 zwischengespeichert. Das heißt, BMCDB 20426 ermöglicht es, daß einzelne 32 Bit-Worte von ED 10124 durch EBMC 20414 empfangen werden können und darin gespeichert werden können, bis ein vier Wortblock empfangen worden ist. Jener Block kann dann nach MEM 10112 transferiert werden. In ähnlicher Weise kann ein Block von MEM 10112 empfangen werden, in BMCDB 20426 gespeichert und ein Wortweise nach ED 10124 transferiert werden. Im Gegensatz dazu kann NDC 20416 im allgemeinen nur für Einzelworttransfers benutzt werden.
Wie in Fig. 204 angezeigt, enthält EBMC 20414, NDC 20416 und jedes Datenkanalgerät von IOS 10116 jeweils eine individuelle Adreßübersetzungskarte, z. B. BMCATM 20432 in EBMC 20414 und NDCATM 20436 in NDC 20416. Die darin gespeicherten Adreßübersetzungskarten werden praktisch durch IOCP 20412 für jedes Datenkanalgerät konstruiert und gesteuert. IOS 10116 kann dadurch eine individuelle und separate Adreßübersetzungskarte für jedes IOS 10116-Datenkanalgerät zur Verfügung stellen. Dies ermöglicht es IOS 10116, zu garantieren, daß die jeweils zwei Datenkanalgeräte oder zwei Gruppen von Datensenken oder -quellen in ED 10124 sich gegenseitig stören, indem sie in einem gemeinsamen Bereich des physikalischen Adreßraums von MEM 10112 hineinschreiben und damit Daten zerstören. Andererseits kann IOS 10116 Adreßübersetzungskarten für zwei oder mehrere Datenkanalgeräte erzeugen, bei denen jene Karten einen gemeinsamen oder überlappenden Bereich des physikalischen Adreßraums von MEM 10112 teilen. Dies ermöglicht, daß in MEM 10112 gespeicherte Daten zwischen den IOS 10116-Datenkanalgeräten durch MEM 10112 transferiert werden können und daher zwischen verschiedenen Datensenken- und Datenquellengeräten von ED 10124 transferiert werden können. Zum Beispiel schreiben eine erste ED 10124-Datenquelle und ein erster IOS 10116-Datenkanal Arbeitsdaten in eine spezielle Fläche des Adreßraums von MEM 10112. Die Ergebnisse der CS 10110-Operationen mit jenen Daten können dann in einen gemeinsamen Bereich jenes ersten Geräts und eines zweiten Datengeräts geschrieben werden und aus MEM 10112 zu einer zweiten ED 10124-Datensenke durch jenes zweite Datenkanalgerät gelesen werden. Die individuelle Zuordnung der Datenkanalgeräte von IOS 10116 stellt dadurch eine totale Flexibilität bei der Aufteilung oder gemeinsamen Teilung des Adreßraumes von MEM 10112 durch IOS 10116 zur Verfügung.

2. I/O-Steuerprozessor 20412

Wie oben beschrieben, ist IOCP 20412 ein gewöhnlicher Computer, dessen Hauptfunktion die Gesamtsteuerung und Kontrolle der Datentransfers zwischen MEM 10112 und ED 10124 ist. IOCP 20412 steuert die Zuordnung von Adressen zwischen IOS 10116's Datenkanalgeräten und dem Adreßraum von MEM 10112. In dieser Hinsicht erzeugt IOCP 20412 Adreßübersetzungskarten für die Datenkanalgeräte wie EBMC 20414 und NDC 20416 von IOS 10116. IOCP 20412 lädt diese Adreßübersetzungskarten in z. B. BMCATM 20432 von EBMC 20414 und NDCATM 20436 und NDC 20416 über den IOCPC-Bus 20434 und steuert diese. IOCP 20412 stellt auch bestimmte Steuerfunktionen für DMOVR 20410, wie in Fig. 204 angezeigt, zur Verfügung. Zusätzlich zu diesen Funktionen hat IOCP 20412 auch Daten- und Adreßein- und -ausgänge. Diese Daten- und Adreßein- und -ausgaben können z. B. dazu benutzt werden, Informationen von IOCP zu erhalten, die von IOCP dazu benutzt werden, die Zuordnung und Steuerung von Adressen zwischen IOS 10116's Datenkanalgeräten und MEM 10112 zu erzeugen und zu steuern. Diese Daten- und Adreßein- und -ausgänge erlauben es IOCP 20412 auch, teilweise als Datenkanalgerät zu arbeiten. Wie oben beschrieben, hat IOCP 20412 Daten- und Adreßein- und -ausgänge, die mit dem DMID-Bus 20430 und dem DMOD-Bus 20428 in beiden Richtungen verbunden sind. IOCP 20412 hat daher Zugang zu Daten, die zwischen ED 10124 und MEM 10112 gerade transferiert werden und somit IOCP 20412 mit einem direkten Zugang auf MEM 10112's Adreßraum versorgen. Darüber hinaus wird IOCP 20412 mit Steuer- und Adreßausgaben für den NDCAD-Bus 20424 versorgt, die IOCP 20412 eine Teilkontrolle bestimmter Datenquellen- und Datensenkengeräte in ED 10124 ermöglichen.

3. Datenschieber 20410 (Fig. 269)

a.a. Eingangsdatenpuffer 20440 und Ausgangsdatenpuffer 20442

Wie oben beschrieben, umfaßt DMOVR 20410 eine Schnittstelle zwischen den Datenkanälen von IOS 10116 und MEM 10112. DMOVR 20410 führt den tatsächlichen Datentransfer zwischen den Datenkanalgeräten von IOS 10116 und MEM 10112 durch und steuert den Zugang zwischen den Datenkanalgeräten von IOS 10116 und MEM 10112. IDB 20440 und ODB 20442 sind Daten- und Adreßpuffer, die einen asynchronen Transfer von Daten zwischen IOS 10116 und MEM 10112 ermöglichen. Das heißt, ODB 20442 kann Daten von MEM 10112 empfangen, sobald jene Daten verfügbar werden, und sie dann so lange halten, bis ein IOS 10116-Datenkanalgerät, z. B. EBMC 20414, bereit ist, jene Daten zu empfangen. IDB 20440 empfängt Daten und physikalische Adressen von MEM 10112 von den Datenkanalgeräten von IOS 10116. IDB 20440 hält jene Daten und Adressen für die nachfolgende Übertragung zu MEM 10112, wenn MEM 10112 bereit ist, diese Daten und Adressen zu empfangen. IDB 20440 kann z. B. einen Burst oder eine Abfolge von Daten von EBMC 20414, oder einzelne Datenworte von NDC 20416 empfangen und jene Daten nachfolgend MEM 10112 als Blocktransfer oder vier Wortweise, wie oben beschrieben wurde, zur Verfügung stellen. In ähnlicher Weise kann ODB 20442 einen oder mehrere Blocktransfers oder Daten von ODB 20442 empfangen und jene Daten nachfolgend NDC als Einzelworte oder DMID 20430 als Datenburst zur Verfügung stellen. Darüber hinaus darf, wie oben beschrieben, ein Blocktransfer von MEM 10112 nicht als vier sequentielle Worte erscheinen. In solchen Fällen empfängt ODP 20442 die vier Worte eines Blocktransfers, wie sie auf dem MIO-Bus 10129 erscheinen, und stellt jene Worte für den nachfolgenden Transfer nach ED 10124 in einem Block, der die vier aufeinander folgenden Worte umfaßt.
Der Datentransfer über IDB 20440 und ODB 20442 wird von PRC 20444 gesteuert, der Steuersignale mit IOCP 20412 austauscht und, wie oben beschrieben, eine Schnittstelle zu MEM 10112 durch den IOMC-Bus 10131 besitzt.

b.b. Prioritätenerkennung und Steuerung 20444 (Fig. 269)

Wie oben beschrieben, steuert PRC den Zugang zwischen den Datenkanalgeräten von IOS 10116 und MEM 10112. Diese Operation wird durch einen Ringzuteilungs-Zugangsgenerator (RGAG) innerhalb PRC 20444 durchgeführt.
In Fig. 270 wird eine diagrammartige Darstellung des RGAG von PRC 20444 gezeigt. Im allgemeinen besteht PRC 20444's RGAG aus einem Rinzuteilungs-Codegenerator (RGCG) 26910 und einem oder mehreren Datenkanalanforderungskomparatoren. In Fig. 269 wird RGAG von PRC 20444 gezeigt als folgendes beinhaltend: den ECLIPSE Burst-Multiplexer-Kanalanforderungskomparator (EBMCRC) 26912, den NOVA-Datenkanalanforderungskomparator (NDCRC) 26914, den Datenkanalgerät-X-Anforderungskomparator (DCDXRC) 26916 und den Datenkanalgerät-Z-Anforderungskomparator (DCDZRC) 26918. PRC 20444's RGAG kann mehr oder weniger Anforderungskomparatoren beinhalten, je nachdem, wie es durch die Anzahl der Datenkanalgeräte innerhalb eines bestimmten IOS 10116 erforderlich ist.
Wie in Fig. 269 angezeigt, sind die Anforderungszuteilungscode (RGC)-Ausgänge von RGCG 26910 parallel mit den ersten Eingängen von EBMCRC 26912, NDCRC 26914, DCDXRC 26916 und DCDZRC 26918 verbunden. Die zweiten Eingänge von EBMCRC 26912, NDCRC 26914, DCDXRC 26916 und DCDZRC 26918 sind mit anderen Bereichen von PRC 20444 verbunden und empfangen Anzeigeinformationen, daß EBMC 20414 bzw. NDC 20416, DCDX oder DCDZ eine Anforderung für lesenden oder schreibenden Zugriff auf MEM 10112 abgesetzt hat.
Die Anforderungszuteilungsausgänge (GRANT) vom EBMCRC 26912, NDCRC 26914, DCDXRC 26916 und DCDZRC 26918 sind wiederum mit anderen Bereichen der PRC 20444 Schaltkreise verbunden, um anzuzeigen, wann ein lesender oder schreibender Zugriff auf MEM 10112 zugeteilt wurde auf Antwort auf eine Anforderung durch ein bestimmtes Datenkanalgerät von IOS 10116. Wenn die Anzeige einer solchen Zuteilung jenen anderen Bereichen von PRC 20444 zur Verfügung gestellt wird, fährt PRC 20444 damit fort, geeignete Steuersignale für MEM 10112 über den oben beschriebenen IOMC- Bus 10131 zu IDB 20440 und ODB 20442 und zu IOCP 20412 zu erzeugen. Die PRC 20444 Steuersignale initiieren jene Lese- oder Schreibanforderung an jenes IOS 10116- Datenkanalgerät. Die Zuteilungsausgaben von EBMCRC 26912, NDCRC 26914, DCDXRC 26916 und DCDZRC 26918 werden auch als Eingaben für RGCG 26910 zur Verfügung gestellt, um, wie unten weiter beschrieben wird, anzuzeigen, wann ein spezieller IOS 10116 Zugang zu MEM 10112 angefordert und ihn zugeteilt bekommen hat.
Wie in Fig. 269, eine diagrammartige Figur von RGCG 26910, gezeigt, erzeugt RGCG eine wiederholte Abfolge eindeutiger RGCs. Hier angedeutet als numerische Ziffern 0 bis 15. Jedes RGC identifiziert oder definiert eine bestimmte Zeitspalte, während der ein IOS 10116-Datenkanalgerät Zugang zu MEM 10112 zugeteilt werden kann. Bestimmte RGCs werden praktisch bestimmten IOS 10116-Datenkanalgeräten zugeordnet. Jedes solches Datenkanalgerät kann Zugang zu MEM 10112 während der ihm zugewiesenen und durch ein RGC identifizierten Zeitspalten anfordern. Zum Beispiel wird EBMC 20414 so gezeigt, daß ihm Zugang zu MEM 10112 gewährt wird, während jener Zugangsspalten, die durch die RGCs 0, 2, 4, 6, 8, 10, 12 und 14 identifiziert werden. Laut Darstellung wird NDC Zugang zu MEM 10112 während der RGC-Spalten 3, 7, 11 und 15 gewährt. DCDX wird Zugang während der Spalten 1 und 9 und DCDZ während der RGC-Spalten 5 und 13 gewährt.
Wie oben beschrieben, erzeugt RGCG die RGCs 0 bis 15 in einer sich wiederholenden Abfolge. Während des Auftretens eines bestimmten RGCs untersucht jeder Anforderungskomparator des RGAG von PRC 20444 jenes RGC, um zu bestimmen, ob sein assoziiertes Datenkanalgerät Zugang während jenes RGC-Spaltes gewährt wird, und ob jenes assoziierte Datenkanalgerät Zugang zu MEM 10112 angefordert hat. Falls jenes zugeordnete Datenkanalgerät Zugang während jenes RGC-Spaltes gewährt wird und Zugang angefordert hat, so wird jenem Datenkanalgerät Zugang gewährt, wie es durch die GRANT-Ausgabe jenes Anforderungskomparators angezeigt wird. Die GRANT-Ausgabe des Anforderungskomparators wird auch als Eingabe für RGCG 26910 zur Verfügung gestellt, um RGCG 26910 anzuzeigen, daß Zugang während jenes RGC-Spaltes gewährt wurde.
Wenn ein bestimmtes Datenkanalgerät während jenes RGC-Spaltes keinen Zugang gefordert und auch keinen zugeteilt bekommen hat, geht RGCG 26910 direkt zum nächsten RGC-Spalt. Im nächsten RGC-Spalt bestimmt RGAG von PRC 20444 wieder, ob ein bestimmtes Datenkanalgerät Zugang gewährt hat, währenddem jene Spalte eine Anforderung abgesetzt hat, und wird Zugang gewähren, falls eine solche Anforderung gemacht wurde. Falls nicht, macht RGCG 26910 direkt mit dem nächsten RGC-Spalt weiter und so fort. Auf diese Weise garantiert PRC 20444's RGAG, daß jedem Datenkanalgerät von IOS 10116 Zugang zu MEM 10112 ohne unbegründete Verzögerung gewährt wird. Darüber hinaus verhindert PRC 20444's RGAG, daß ein einzelnes oder mehr als ein Datenkanalgerät monopolartigen Zugang zu MEM 10112 gewinnt. Wie oben beschrieben, wird jedem Datenkanalgerät Zugang zu MEM 10112 mindestens einmal während einer Abfolge der RGCs gewährt. Gleichzeitig überspringt PRC 20444's RGAG praktisch automatisch jene Datenkanalgeräte, die keinen Zugang zu MEM 10112 angefordert haben, indem es keinen Aufenthalt in einem bestimmten RGC gibt, in dem keine Zugangsanforderung an MEM 10112 aufgetreten ist. Auf diese Weise stellt PRC 20444's RGAG praktisch häufigeren Zugriff jenen Datenkanalgeräten, innerhalb eines gegebenen Zeitintervalls, die am aktivsten sind, zur Verfügung. Darüber hinaus können die bestimmten IOS 10116-Datenkanalgeräten zugeordneten RGCs nach Bedarf neu zugeordnet werden, um ein bestimmtes CS 10110 den Datenein- und -ausgabeanforderungen einer bestimmten CS 10110-Konfiguration anzupassen. Das heißt, falls EBMC 20414 weniger Zugang zu MEM 10112 verlangen sollte als NDC 20416, so könnten bestimmte RGCs von EBMC 20414 zu NDC 20416 zugeordnet werden. Der Zugang der IOS 10116- Datenkanalgeräte auf MEM 10112 kann daher nach Bedarf optimiert werden.
Nachdem die Struktur und der Betrieb von IOS 10116 beschrieben wurden, werden im folgenden die Struktur und der Betrieb von DP 10118 beschrieben.

E. Diagnoseprozessor 10118 (Fig. 101, 205)

Mit Bezug auf Fig. 101 ist DP 10118, wie oben beschrieben, mit IOS 10116, MEM 10112, FU 10120 und EU 10122 über den DP-Bus 10138 verbunden. DP 10118 ist auch über den DPIO-Bus 10136 mit der Außenwelt und insbesondere mit DU 10134 verbunden. Zusätzlich zur Durchführung von Diagnose- und Fehlerüberwachungs- und Korrekturoperationen, arbeitet DP 10118 teilweise, um Steuer- und Ausgabefunktionen zur Verfügung zu stellen, die es einem Bedienungsmann erlauben, mit CS 10110 in Verbindung zu treten. DU 10134 kann z. B. ein CRT und eine Tastatur oder einen Fernschreiber umfassen, und versorgt einen Bediener des CS 10110 mit allen Steuer- und Display- Funktionen, die normalerweise von einem Steuerpult zur Verfügung gestellt werden, d. h. einer Konsole, die Schalter und Lämpchen beinhaltet. Zum Beispiel erlaubt es DU 10134 über DP 10118 einem Bedienungsmann, die Steuerung des CS 10110 für Zwecke wie Systeminitialisierung und Systemstart, die Ausführung von Diagnoseprozessen, Fehlerüberwachung und Fehleridentifizierung, und Steuerung der Ausführung von Programmen, auszuführen. Wie weiter unten beschrieben wird, werden diese Funktionen über die DP 10118-Schnittstellen mit IOS 10116, MEM 10112, FU 10120 und EU 10122 realisiert.
DP 10118 ist ein ganz normales Computersystem, z. B. ein NOVA-4-Computer der Data General Corporation von Westboro, Massachusetts. Die Schnittstelle von DP 10118 und DU 10134 und der wechselseitige Betrieb von DP 10118 und DU 10134 werden einem normalen Fachmann auf diesem Gebiet sofort einleuchten. DP 10118's Schnittstelle und Betrieb mit IOS 10116, MEM 10112, FU 10120 und EU 10122 werden im folgenden beschrieben werden.
DP 10118, der als Computer allgemeiner Verwendung speziell programmiert ist, um die obigen Funktionen auszuführen, hat, wie unten beschrieben wird, Lese- und Schreibzugriff auf Register von IOS 10116, MEM 10112, FU 10120 und EU 10122 über den DP-Bus 10138. DP 10118 kann direkt Daten von jenen Registern lesen und direkt Daten auf jene Register schreiben. Wie unten beschrieben wird, sind diese Register Daten- und Befehlsregister und sind vollständige Teile des CS 10110-Schaltkreises während des Normalbetriebs von CS 10110. Der Zugang auf diese Register erlaubt es dadurch DP 10118, den Betrieb von CS 10110 direkt zu steuern oder zu beeinflussen. Darüber hinaus stellt DP 10118, wie unten auch beschrieben werden wird, im allgemeinen sämtliche Systemtaktsignale allen Bereichen der CS 10110-Schaltkreise zur Verfügung und kann den Betrieb jener Schaltkreise durch die Steuerung dieser Systemtaktsignale kontrollieren.
Hinsichtlich der DP 10118-Funktionen, kann man sich CS 10110 aufgeteilt in Gruppen von funktionsmäßig zueinander gehörenden Elementen, z. B. DESP 20210 in FU 10120, denken. DP 10118 erhält Zugang auf die Register dieser Gruppen und die Steuerung der Systemtakte darin über Abtastketten-Schaltkreise, wie unten beschrieben wird. Im allgemeinen hat DP 10118 ein oder mehrere Abtastketten-Schaltkreise für jedes Hauptfunktionssubelement von CS 10110.
In Fig. 205 wird eine diagrammartige Darstellung von DP 10118 und eine typische Abtastkette von DP 16118 gezeigt. Wie dort gezeigt, beinhaltet DP 10118 eine zentrale Prozessoreinheit allgemeiner Verwendung oder ein Computer (DPCPU) 27010. Eine erste Schnittstelle von DPCPU 27010 mit DU 10134 geht über den DPIO-Bus 10136. DPCPU 27010 und DU 10134 tauschen Daten und Steuersignale über den DPIO-Bus 10136 so aus, daß sie die Operationen von DPCPU 27010 steuern und die Ergebnisse jener Operationen über DU 10134 anzeigen können.
Mit DPCPU 27010 verbunden ist der Taktgenerator (CLKG) 27012. CLKG 27012 erzeugt im allgemeinen alle Taktsignale, die innerhalb CS 10110 benutzt werden.
DPCPU 27010 und CLKG 27012 sind mit den verschiedenen Abtastketten-Schaltkreisen von CS 10110 über den DP-Bus 10138 verbunden. Wie oben beschrieben, kann CS 10110 eine oder mehrere Abtastketten für jedes Hauptsubelement von CS 10110 beinhalten. Eine solche Abtastkette, z. B. die DESP 20210-Abtastkette (DESPSC) 27014, wird in Fig. 205 illustriert.
Die Schnittstelle zwischen DPCPU 27010 und CLKG 27012 und z. B. DESPSC 27014 wird durch den DP-Bus 10138 zur Verfügung gestellt. Wie in Fig. 205 gezeigt, enthält DESPSC 27014 die Abtastketten-Taktschaltungen (SCCG) 27016 und ein oder mehrere Abtastkettenregister (SCRs) 27018 bis 27024.
SCCG 27016 empfängt Taktsignale von CLKG 27012 und Steuersignale von DPCPU 27010 über den DP-Bus 10138. SCCG 27016 wiederum stellt die geeigneten Taktsignale für die verschiedenen Register und Schaltkreise von z. B. DESP 20210 zur Verfügung. Die von DPCPU 27010 für SCCG 27016 zur Verfügung gestellten Taktsteuersignale steuern oder schalten die verschiedenen Taktsignale zu diesen Registern und Kreisen von DESP 20210, und erlauben damit praktisch DPCPU 27010, DESP 20210 zu steuern.
Die SCRs 27018 bis 27024 umfassen verschiedene Register innerhalb DESP 20210. Zum Beispiel können die SCRs 27018 bis 27024 die Ausgabepufferregister von AONGRF 20232, OFFGRF 20234, LENGRF 20236, die Ausgaberegister von OFFALU 20242 und LENALU 20252 und die Register innerhalb OFFMUX 20240 und BIAS 20246 beinhalten. Solche Register werden in der vorliegenden Beschreibung, wie oben beschrieben, durch Pfeile angedeutet, die an die Enden jener Register angehängt sind, wobei ein erster Pfeil eine Eingabe, und ein zweiter Pfeil eine Ausgabe bedeutet. Bei normalen, wie oben beschriebenen CS 10110-Operationen, arbeiten die SCRs 27018 bis 27024 als Parallelrein-und Parallel-raus-Pufferregister, durch die Daten und Befehle transferiert werden. Die SCRs 27018 bis 27024 sind auch imstande, als Schieberegister zu arbeiten und, wie in Fig. 205 angedeutet, sind miteinander verbunden, einen einzigen Schieberegisterkreis zu bilden, der einen Eingang von DPCPU 27010 und einen Ausgang nach DPCPU 27010 besitzt. Die Steuereingaben für die SCRs 27018 bis 27024 von DPCPU 27010 steuern den Betrieb der SCRs 27018 bis 27024, d. h. steuern, ob diese Register als Parallel-rein/Parallel-raus-Register oder als Schieberegister der Abtastkette von DESPSC 27014 arbeiten sollen. Die Schieberegisterabtastkette, die die SCRs 27018 bis 27024 umfaßt, erlaubt es DPCPU 27010, die Inhalte der SCRs 27018 bis 27024 durch das Verschieben der Inhalte dieser Register in DPCPU 27010, zu lesen. Umgekehrt kann DPCPU 27010 in die SCRs 27018 bis 27024 schreiben, indem es die durch DPCPU 27010 erzeugte Information von DPCPU 27010 und durch die Schieberegisterabtastkette in ausgewählte Lokationen innerhalb der SCRs 27018 bis 27024 schiebt.
Die Abtastketten-Taktgenerator-Schaltkreise und die Abtastkettenregister jedes Abtastketten-Schaltkreises innerhalb CS 10110 erlauben es dadurch DP 10118, den Betrieb jedes Hauptsubelementes von CS 10110 zu steuern. Zum Beispiel, um Informationen von den Abtastkettenregistern darin zu lesen, und um Informationen in jene Abtastkettenregister zu schreiben, wie es für die Diagnose, Überwachung und Steuerung der Funktionen notwendig ist.
Nachdem die Struktur und der Betrieb jedes Hauptelementes von CS 10110 einschließlich MEM 10112, FU 10120, EU 10122, IOS 10116 und DP 10118 beschrieben wurden, werden im folgenden bestimmte Operationen von insbesondere FU 10120 beschrieben. Die folgenden Beschreibungen werden weiter Betriebsmerkmale von JP 10114 und insbesondere von FU 10120 enthüllen, dadurch daß bestimmte Operationen darin genauer beschrieben werden, und die Mikrocodesteuerung von JP 10114 genauer beschrieben wird.

F. Struktur und Betrieb der CS 10110-Mikromaschine (Fig. 270 bis 274)

a. Einführung

Die vorherigen Beschreibungen haben die Hardware-Strukturen und den Betrieb von FU 10120 und EU 10122 dargestellt. Die folgende Beschreibung beschreibt, wie die Geräte in FU 10120 und bestimmte EU 10122-Geräte zusammen als ein mikroprogrammierbarer Computer funktionieren, der von nun an als FU-Mikromaschine bezeichnet werden soll. Die FU-Mikromaschine führt zwei Aufgaben durch: sie interpretiert SINs, und sie antwortet auf bestimmte Signale, die von Geräten in FU 10120, EU 10122, MEM 10112 und IOS 10116 erzeugt werden. Die Signale, auf die die FU-Mikromaschine antwortet, werden als Ereignissignale bezeichnet. Was Struktur und Betrieb betrifft, so wird die FU- Mikromaschine durch folgendes gekennzeichnet:
- Register und ALUs, die spezialisiert sind auf die Behandlung von logischen Beschreibern.
- Register, die als Stapelspeicher zum Aufruf von Mikroprogrammen (Mikrobefehlsabfolgen) organisiert sind.
- Mechanismen, die Mikroprogrammaufrufe durch Ereignissignale einer Hardware ermöglichen.
- Mechanismen, die es ermöglichen, daß ein aufgerufenes Mikroprogramm entweder zu dem Mikrobefehl zurückkehrt, der auf den Aufruf folgt, oder zu dem Mikrobefehl, der sich durch den Aufruf ergibt.
- Mechanismen, die es erlauben, Inhalte von Stapelspeicherregistern nach MEM 10112 zu transferieren, und somit einen virtuellen Mikrostapelspeicher unbegrenzter Größe kreieren.
- Mechanismen, die eine Antwort auf ein Ereignissignal innerhalb einer vorhersagbaren Zeitspanne garantieren.
- Die Unterteilung der die Mikromaschine umfassenden Geräte in zwei Gruppen: jene Geräte, die durch jeden Mikrocode benutzt werden können, und jene, die nur durch den KOS (Kernbetriebssystem, wie oben beschrieben)-Mikrocode benutzt werden können.
Diese Geräte und Mechanismen ermöglichen es, daß die FU-Mikromaschine auf zwei Arten benutzt werden kann: als eine virtuelle Mikromaschine und als eine Überwachungsmikromaschine. Beide Mikromaschinenarten benutzen dieselben Geräte in FU 10120, aber führen verschiedene Funktionen durch und haben verschiedene logische Eigenschaften. Wenn in der folgenden Diskussion gesagt wird, daß die FU-Mikromaschine als virtuelle Mikromaschine gebraucht wird, so sagt man, daß sie sich im virtuellen Modus befindet, und wenn sie als Überwachungsmikromaschine benutzt wird, sagt man, daß sie sich im Überwachungsmodus befindet. Beide Modi werden hier eingeführt und später genauer erklärt.
Wenn die FU-Mikromaschine im virtuellen Modus benutzt wird, so hat sie folgende Eigenschaften: - Sie läuft auf einem tatsächlich unbegrenzten Mikromaschinen-Stapelspeicher, der zu einem Prozeß 610 gehört.
- Sie kann auf jede beliebige Anzahl von Ereignissignalen im M0-Zyklus (Zustand eines einzelnen Mikrobefehls) antworten.
- Ein Seitenfehler kann beim Aufruf eines beliebigen Mikroprogrammes oder bei einer Rückkehr von einem beliebigen Mikroprogramm auftreten.
- Wenn sich die FU-Mikromaschine im virtuellen Modus befindet, kann kein Mikroprogramm beendet werden, d. h. seine Ausführung in einer vorhersagbaren Zeitspanne beenden oder sie überhaupt beenden.
- Sie führt einen Prozeß 610 aus.
Die letzten vier Eigenschaften sind Folgerungen aus der ersten: Ereignissignale resultieren in Aufrufen, und weil der Mikromaschinen-Stapelspeicher unbegrenzt ist, gibt es keine Begrenzung für die Anzahl der Aufrufe. Der unbegrenzte Mikromaschinen-Stapelspeicher wird dadurch realisiert, daß Mikromaschinenstapelspeicherrahmen auf den Sicherheitsstapelspeicher 10336 plaziert werden, der zu einem Prozeß 610 gehört; daher läuft die virtuelle Mikromaschine immer auf einen Mikromaschinenstapelspeicher, der zu einem Prozeß 610 gehört. Und weiter, falls ein Aufruf eines Mikroprogrammes oder eine Rückkehr von einem Mikroprogramm es erforderlich macht, Mikromaschinenrahmen vom Sicherheitsstapelspeicher 10336 zur FU-Mikromaschine zu transferieren, kann ein Seitenfehler resultieren, und der Prozeß 610, der das Mikroprogramm ausführt, kann von JP 10114 entfernt werden, wodurch er die zur Ausführung des Mikroprogrammes benötigte Zeitspanne unvorhersagbar macht. In der Tat, falls ein Prozeß 610 gestoppt oder getötet wird, kann die Ausführung des Mikroprogrammes nie zu Ende gehen. Wie in den folgenden Beschreibungen klar wird, ist der virtuelle Prozessor 612 das Mittel, wodurch die virtuelle Mikromaschine Zugang auf den Mikromaschinen-Stapelspeicher eines Prozesses 610 gewinnt.
Wenn sie sich im Überwachungsmodus befindet, hat die FU-Mikromaschine folgende Eigenschaften:
- Sie hat einen Mikromaschinen-Stapelspeicher fester Größe, der Stapelspeicher ist immer der FU-Mikromaschine verfügbar und ist nicht mit einem Prozeß 610 verbunden.
- Sie kann nur auf eine feste Anzahl von Ereignissen während des M0-Zyklusses eines einzelnen Mikrobefehls antworten.
- Im Überwachungsmodus verursacht der Aufruf eines Mikroprogrammes oder die Rückkehr von einem Mikroprogramm keinen Seitenfehler.
- Mikroprogramme, die auf der FU-Mikromaschine im Überwachungsmodus ablaufen, kommen garantiert zum Ende, es sei denn, sie führen eine Aktion aus, die sie veranlaßt, sich von JP 10114 zu lösen.
- Mikroprogramme, die im Überwachungsmodus ausführen, brauchen keine Funktionen für einen Prozeß 610 durchführen.
Wieder sind die verbleibenden Eigenschaften Folgerungen aus der ersten: Weil der Überwachungsmikromaschinen-Stapelspeicher nur eine feste Größe hat, ist die Anzahl der Ereignisse, auf die die Überwachungsmikromaschine antworten kann, begrenzt; und weiter, da der Stapelspeicher immer direkt für die Mikromaschine verfügbar ist, verursachen Mikroprogrammaufrufe und Rückkehren keine Seitenfehler, und Mikroprogramme, die im Überwachungsmodus laufen, gehen bis zum Ende, es sei denn, sie führen eine Aktion durch, die sie veranlaßt, sich von JP 10114 zu lösen. Schließlich ist der Stapelspeicher der Überwachungsmikromaschine nicht mit einem Sicherheitsstapelspeicher 10336 eines Prozesses 610 verbunden und daher kann die Überwachungsmikromaschine sowohl Funktionen für Prozesse 610 als auch Funktionen (die nicht mit einem Prozeß 610 verbunden sind, zum Beispiel) wie das Binden und Entfernen von virtuellen Prozessoren 612 von JP 10114, ausführen.
Die folgende Beschreibung gibt als erstes einen Überblick über die Geräte, aus denen die Mikromaschine besteht, setzt sich mit Beschreibungen von Aufrufen auf der Mikromaschine und der Programmierung der Mikromaschine fort und schließt mit detaillierten Diskussionen des virtuellen und des Überwachungsmodus und einem Überblick über die Beziehungen zwischen der Mikromaschine und CS 10110-Untersystemen. Die Art und Weise, in der die Mikromaschine spezifische Operationen wie z. B. SIN-Analyse, Namenserkennung oder Adressenübersetzung durchführt, kann in vorherigen Beschreibungen der CS 10110-Komponenten gefunden werden, die die Mikromaschine gebraucht, um ihre Operationen durchzuführen.

b. Überblick über die in der FU-Mikromaschine enthaltenen Geräte (Fig. 270)

Fig. 270 stellt einen Überblick über die Geräte dar, die in der Mikromaschine enthalten sind. Fig. 270 basiert auf Fig. 201, aber wurde vereinfacht, um die Klarheit in der Diskussion zu verbessern. Geräte und Unterteilungen der Mikromaschine, die in Fig. 201 vorkommen, haben die Nummern, die ihnen in jener Figur gegeben sind. Wenn ein Gerät in Fig. 270 in zwei Unterteilungen vorkommt, so wird er von jenen Unterteilungen geteilt.
Fig. 270 hat vier Hauptunterteilungen. Drei von ihnen sind von Fig. 201: FUCTL 20214, die die Geräte enthält, die bei der Auswahl des nächsten Mikrobefehls, der von der Mikromaschine ausgeführt werden soll, gebraucht werden, DESP 20210, das die Stapelspeicher- und globalen Register und ALUs für die Beschreiberverarbeitung enthält; und MEMINT 20212, das die Geräte enthält, die Namen in logische Beschreiber und die logischen Beschreiber in physikalische Beschreiber übersetzen. Die vierte Unterteilung, die EU-Schnittstelle 27007, stellt jene Bereiche von EU 10122 dar, die vom FU 10120- Mikrocode manipuliert werden können.
Fig. 270 unterteilt FUCTL 20214 und MEMINT 20212 weiter. FUCTL hat vier Unterteilungen:
- I-Stromleser 27001, der die Geräte enthält, die dazu benutzt werden, SINs zu erhalten und diese in SOPs und Namen zu analysieren.
- SOP-Dekodierer 27003, der SOPs in Lokationen im FU-Mikrocode (FUSITT 11012), und in manchen Fällen in EU-Mikrocode (FUSITT 20344) übersetzt, der den Mikrocode enthält, der die entsprechenden SINs ausführt.
- Mikrocodeadressierung 27013, die die Lokation des nächsten Mikrobefehls bestimmt, der in FUSITT 11012 ausgeführt werden soll.
- Registeradressierung 27011, die die Geräte enthält, die Adressen für GRF 10354-Register erzeugen.
MEMINT 20212 hat auch drei Unterteilungen:
- Namensübersetzungseinheit 27015, die die Geräte enthält, die die Übersetzung von Namen in logische Beschreiber beschleunigen.
- Speicherreferenzeneinheit 27017, die die Geräte enthält, die die Übersetzung von logischen Beschreibern in physikalische Beschreiber beschleunigen.
- Schutzeinheit 27019, die die Geräte enthält, die einfache Zugangsprüfungen auf mit logischen Beschreibern gemachte Speicherreferenzen beschleunigen.
Fig. 270 vereinfacht auch die Busstruktur von Fig. 202, indem es den LENGTH-Bus 20226, den OFFSET-Bus 20228 und den AONR-Bus 20230 in eine einzige Struktur, den Beschreiberbus (DB) 27021 vereint. Darüber hinaus wurden die internen Busverbindungen auf jene reduziert, die notwendig sind, um den logischen Betrieb der Mikromaschine zu erklären. Die folgende Diskussion beschreibt erst jene Geräte, die von den meisten Mikrocode, der auf FU 10120 ausgeführt wird, benutzt werden, und beschreibt dann Geräte, die bei der Ausführung von besonderen Funktionen wie z. B. Namensübersetzung oder Schutzüberprüfung gebraucht werden.

1. Vom meisten Mikrocode genutzte Geräte

Die Unterteilungen der Mikromaschine, die die Geräte enthalten, die vom meisten Mikrocode benutzt werden, sind die Mikrocodeadressierung 27013, die Registeradressierung 27011, DESP 20210 und die EU-Schnittstelle 27007. Darüber hinaus benutzt der meiste Mikrocode den MOD-Bus 10144, den JPD-Bus 10142 und den DB-Bus 27021. Die Diskussion beginnt mit den Bussen und beschreibt dann die anderen Geräte in der obigen Reihenfolge.

a.a. MOD-Bus 10144 JPD-Bus 10142 und DB-Bus 27021

Der MOD-Bus 10144 ist der einzige Pfad, durch den Daten von MEM 10112 erhalten werden können. Daten auf dem MOD-Bus 10144 können als ihre Zielbestimmung den Befehlsstromleser 27001, DESP 20210 oder die EU-Schnittstelle 27007 haben. Im ersten Fall bestehen die Daten auf dem MOD-Bus 10144 aus SINs; im zweiten sind es Daten, die von FU 10120 verarbeitet werden sollen, und im dritten sind es Daten, die von EU 10122 verarbeitet werden sollen. In der vorliegenden Verkörperung sind Daten, die von FU 10120 verarbeitet werden sollen, allgemeine Daten, die für den internen Gebrauch in FU 10120, z. B. im Namenszwischenspeicher 10226, bestimmt sind. Daten, die von EU 10122 verarbeitet werden sollen, sind allgemein Operanden, die durch Namen und SINs repräsentiert werden.
Der JPD-Bus 10142 wird auf zweierlei Art benutzt: Er ist der Pfad, auf dem Daten nach MEM 10112 zurückkehren, nachdem sie durch JP 10114 verarbeitet wurden, und ist der Pfad, auf dem andere Daten als logische Beschreiber zwischen den Unterteilungen der Mikromaschine bewegt werden. Wenn z. B. CS 10110 initialisiert wird, werden die Mikrobefehle, die in FUSITT 11012 geladen werden, von MEM 10112 zu DESOP 20210 über den MOD-Bus 10144 transferiert und von DESP 20210 nach FUSITT 11012 über den JPD-Bus 10142.
DB 27021 ist der Pfad, auf dem logische Beschreiber in der Mikromaschine transferiert werden. DB 27021 verbindet die Namensübersetzungseinheit 27015, DESP 20210, die Schutzeinheit 27019 und die Speicherreferenzeinheit 27017. In typischer Weise wird ein logischer Beschreiber von der Namensübersetzungseinheit 27015 erhalten, in einem Register in DESP 20210 plaziert und dann der Schutzeinheit 27019 und der Speicherreferenzeneinheit 27017 vorgestellt, wann immer eine Referenz gemacht wird, die einen logischen Beschreiber benutzt. DB 27021 wird jedoch auch dazu benutzt, Zwischenspeichereingaben, die in DESP 20210 erzeugt wurden, zu ATU 10228, den Namensspeicher 10226 und zum Schutzzwischenspeicher 10234 zu übertragen.

b.b. Mikrocodeadressierung

Wie hier besprochen wird, umfaßt die Mikrocodeadressierung folgende Geräte: die Zeitmeßgeräte 20296, die Ereignislogik 20284, RCWS 10358, BRCASE 20278, mPC 20276, MCW0 20292, MCW1 20290, SITTNAG 20286 und FUSITT 11012. Alle diese Geräte wurden schon genau beschrieben, und sie werden hier nur insoweit diskutiert, als sie die Mikrocodeadressierung beeinflussen. Andere in Fig. 202 enthaltene Geräte, die Zustandsregister 20294, den Wiederholungszähler 20280 und PNREG 20282 sind für die Mikrocodeadressierung nicht direkt relevant und werden hier nicht besprochen.
Wie schon genau beschrieben wurde, werden die Geräte in der Mikrocodeadressierung 27013 vom JPD-Bus 10142 geladen. Die von diesen Geräten und von FUSDT 11010 zur Verfügung gestellten Mikrocodeadressen werden unter den Geräten und nach FUSITT 11012 durch den CSADR-Bus 20204 übertragen. Es gibt sechs Wege, auf denen die nächste Mikrocodeadresse erhalten werden kann:
- Am häufigsten wird der Wert in mPC 20276 um 1 durch eine spezielle ALU in mPC 20276 inkrementiert, woraus sich die Adresse des Mikrobefehls, der dem gegenwärtigen Mikrobefehl folgt, ergibt.
- Wenn ein Mikrobefehl einen Aufruf eines Mikroprogrammes oder einer Verzweigung spezifiziert, enthält der Mikrobefehl ein Literal, daß eine ALU in BRCASE 20278 zu dem Wert in mPC 20276 addiert, um die Lokation des nächsten Mikrobefehls zu erhalten.
- Wenn ein Mikrobefehl den Gebrauch eines Casewertes spezifiziert, um die Lokation des nächsten Mikrobefehls auszurechnen, so addiert BRCASE 20278 einen von DESP 20210 errechneten Wert auf den Wert in mPC 20276. Der von DESP 20210 berechnete Wert kann aus einem Feld eines logischen Beschreibers gewonnen werden, und ermöglicht es somit der Mikromaschine, auf der Basis von im logischen Beschreiber enthaltenen Typinformationen zu verschiedenen Stellen im Mikrocode zu verzweigen. Nach der Rückkehr von der Ausführung eines Mikroprogrammes wird die Stelle, an der die Ausführung des Mikroprogrammes, in dem der Aufruf stattfand, fortzusetzen ist, von RCWS 10358 erhalten.
- Beim Beginn der Ausführung eines SIN wird die Lokation, an dem der Mikrocode für den SIN beginnt, vom SOP des SIN durch FUSDT 11010 erhalten.
- Bestimmte Hardwaresignale verursachen Aufrufe von Mikroprogrammen. Es gibt zwei Klassen solcher Signale: Ereignissignale, die die Ereignislogik 20284 in Aufrufe bestimmter Mikroprogramme überführt, und JAM-Signale, die direkt in Lokationen im Mikrocode übersetzt werden.
Die Adressen, die, wie oben beschrieben, erhalten werden, werden zu SITTNAG 20286 übertragen, das eine der Adressen als Lokation für den nächsten auszuführenden Mikrobefehl auswählt und die Lokation zu FUSITT 11012 überträgt. Sobald die Lokation zu FUSITT 11012 übertragen wurde, wird sie auch in mPC 20276 gespeichert. Alle Adressen, außer jenen für Staus, werden zu SITTNAG 20286 über den CSADR-Bus 20204 transferiert. Die aus JAM-Signalen erhaltenen Adressen werden über separate Linien zu SITTNAG 20286 transferiert.
Wie unten genauer erklärt werden wird, sind Pushing und Popping der Mikromaschinen- Stapelspeicherrahmen und das Sichern des Zustandes, der in MCW1 20290 enthalten ist, auch in Mikroprogrammaufrufen und Rückkehren involviert.
Die Registeradressierung 27011 steuert den Zugang zu den Mikromaschinenregistern, die in GRF 10354 enthalten sind. Wie unten genauer erklärt werden wird, enthält GRF 10354 sowohl Register, die für den Mikromaschinen-Stapelspeicher benutzt werden, als auch globale Register, d. h. Register, die immer für alle Mikroprogramme zugangbar sind. Die Register werden in Rahmen gruppiert, und einzelne Register werden durch die Rahmennummer und die Registernummer adressiert. Die Registeradressierung 27011 erlaubt eine Adressierung jedes beliebigen Rahmens und Registers in den GRs 10360 von GRF 10354, aber erlaubt die Adressierung von Registern nur in drei Rahmen der SRs 10362: der gegenwärtige (obere) Rahmen, der vorherige Rahmen (d. h. der Rahmen, der dem oberen Rahmen vorangeht) und der untere Rahmen, d. h. der unterste Rahmen im Stapelspeicher einer virtuellen Mikromaschine, der noch in GRF 10354 enthalten ist. Die von der Registeradressierung 27011 zur Verfügung gestellten Werte werden in MCW0 20292 gespeichert. Wie in der folgenden Diskussion der Mikroprogrammaufrufe erklärt wird, werden der gegenwärtige und vorangehende Rahmen bei jedem Aufruf um eins inkrementiert und bei jeder Rückkehr um eins dekrementiert.

c.c. Beschreiberprozessor 20210 (Fig. 271)

DESP 20210 ist ein Satz von Geräten zur Speicherung und Bearbeitung von logischen Beschreibern. Die interne Struktur der verarbeitenden Geräte von DESP 20210 wurde bereits genau beschrieben; in der jetzigen Diskussion geht es hauptsächlich um die Struktur und die Inhalte von GRF 10354. In einer gegenwärtigen Verkörperung von CS 10110 enthält GRF 10354 256 Register. Jedes Register kann einen einzelnen logischen Beschreiber enthalten. Fig. 271 illustriert einen logischen Beschreiber 27116 genau. In einer vorliegenden Verkörperung von CS 10110 hat ein logischer Beschreiber 27116 vier Hauptfelder:
- Das RS-Feld 27101, das verschiedene Kennzeichen enthält, die unten genau beschrieben werden.
- Das AON-Feld 27111, das den AON-Bereich der Adresse des Datenausdrucks enthält, der durch den logischen Beschreiber 27116 repräsentiert wird.
- Das OFF-Feld 27113, das den Abstandsbereich der Adresse des Datenausdrucks enthält, der durch den logischen Beschreiber 27116 repräsentiert wird.
- Das LEN-Feld 27115, das die Läne des Datenausdrucks enthält, der durch den logischen Beschreiber 27116 repräsentiert wird.
Das RS-Feld 27101 hat folgende Unterfelder:
- Das RTD-Feld 27103 und das WTD-Feld 27105 können durch Mikrocode gesetzt werden, um bestimmte für Fehlersuchprogramme durch CS 10110 vorgesehene Ereignissignale zu deaktivieren. Wegen Einzelheiten siehe eine folgende Beschreibung der Fehlersuchhilfen in CS 10110.
- Das FIU-Feld 27107 enthält zwei Bits. Die Felder werden aus Informationen im Namenstabelleneingang gesetzt, der dazu benutzt wird, den logischen Beschreiber 27116 zu konstruieren. Die Bits bestimmen, wie die durch den logischen Beschreiber 27116 spezifizierten Daten ausgerichtet und aufgefüllt werden müssen, wenn sie von MEM 10112 geholt werden.
- Die vier Bits des TYPE-Feldes 27109 werden auch aus dem Namenstabelleneingang erhalten, der dazu benutzt wird, den logischen Beschreiber 27116 zu konstruieren. Die Besetzung der Felder ist von S-Sprache zu S-Sprache verschieden und wird dazu benutzt, S-Sprachen-spezifische Typinformationen zum S- Interpreter-Mikrocode der S-Sprache zu überbringen.
Die vier Felder eines logischen Beschreibers 27116 sind in drei separat zugangbaren Feldern eines GRF 10354-Registers enthalten: eines enthält das RS-Feld 127101 und das AON-Feld 27111, eines das OFF-Feld 27113 und eines das LEN-Feld 27115. Zusätzlich kann auf jedes GRF 10354-Register als Ganzes zugegriffen werden. GRF 10354 ist weiter in 32 Rahmen mit jeweils acht Registern unterteilt. Ein einzelnes GRF 10354-Register wird durch seine Rahmennummer und seine Registernummer innerhalb des Rahmens adressiert. In einer vorhandenen Verkörperung des CS 10110 gehört die Hälfte der Rahmen in GRF 10354 zu den SRs 10362 und werden für die Mikromaschinen-Stapelspeicher benutzt, und die andere Hälfte gehört zu den GRs 10360 zur Speicherung "globaler Information". In den SRs 10362 enthält jeder GRF 10354-Rahmen Informationen, die zu einem einzigen Aufruf eines Mikroprogrammes gehören. Wie oben erklärt, erlaubt die Registeradressierung 27011 nur drei GRF 10354-Rahmen im Stapelspeicher 10362 der SRs zu adressieren, nämlich den gegenwärtigen oberen Rahmen im Stapelzwischenspeicher, den vorherigen Rahmen und den unteren Rahmen. Auf Register wird zugegriffen, indem eine dieser drei Rahmennummern und eine Registernummer spezifiziert wird.
Die globale Information, die in den GRs 10360 enthalten ist, sind Informationen, die nicht mit einem einzelnen Aufruf verbunden sind. Es gibt drei weite Kategorien globaler Information:
- Informationen, die zu dem Prozeß 610 gehören, dessen virtueller Prozessor 612 gegenwärtig an JP 10114 gebunden ist. In diesen Informationen enthalten sind die gegenwärtigen Werte der ABPs des Prozesses 610 und der Zeiger, die KOS benutzt, um die Stapelspeicher des Prozesses 610 zu verwalten.
- Informationen, die für den Betrieb von KOS erforderlich sind. In dieser Information enthalten sind solche Ausdrücke wie Zeiger auf KOS-Datenbasen, die feste Lokationen in MEM 10112 belegen.
- Konstanten, d. h. feste Werte, die für bestimmte, häufig durchgeführte Operationen in FU 10120 benötigt werden.
Die verbleibenden Register sind für Mikroprogrammierer als temporäre Speicherflächen für Daten verfügbar, die nicht in Stapelspeicherrahmen eines Mikroprogrammes gespeichert werden können. Zum Beispiel werden Daten, die von mehreren Mikroprogrammen gemeinsam benutzt werden, am besten in einem GR 10360 plaziert. Die Adressierung von Registern in den GRs 10360 von GRF 10354 erfordert zwei Werte: einen Wert zwischen 0 und 15, um den Rahmen zu bestimmen, und einen anderen Wert zwischen 0 und 7, um das Register in dem Rahmen zu bestimmen.
Wie oben genau beschrieben wurde, enthält jede der drei Komponenten AONP 20216, OFFP 20218 und LENP 20220 von DESP 20210 auch ALUs, Register und Logik, die es erlaubt, daß Operationen auf einzelnen Feldern der GRF 10354-Register ausgeführt werden. Insbesondere enthält OFFP 20218 OFFALU 20242, die als 32 Bit arithmetische und logische Einheit für allgemeine Zwecke verwendet werden kann. OFFALU 20242 kann weiter als Quelle und Zielort für den JPD-Bus 10142, als Abstandsbereich von DB 27021, und der NAME-Bus 20224 kann als Zielort für den MOD-Bus 10144 dienen. Daraus folgend kann OFFALU 20242 dazu verwendet werden, Operationen mit Daten auf diesen Bussen auszuführen und Daten von einem Bus zu einem anderen zu transferieren. Wenn z. B. ein SIN einen in einer Adreßberechnung benutzten Literalwert enthält, so wird der Literalwert über den NAME-Bus 20224 zu OFFALU 20242 transferiert, damit gearbeitet und über den Abstandsbereich von DB 27021 ausgegeben.

d.d. EU 10122-Schnittstelle

FU 10120 bestimmt, welche Operation EU 10122 ausführen soll, mit welchen Operanden sie diese ausführen soll, und wenn sie beendet ist, was mit den Operanden zu tun ist. FU 10120 kann zwei Geräte in EU 10122 als Zielorte für Daten und ein Gerät als Quelle für Daten benutzen. Die Zielorte sind COMQ 20342 und OPB 20322. COMQ 20342 empfängt die Lokation in EUSITT 20344 für den Mikrocode, der für die von FU 10120 gewünschte Operation auszuführen ist. COMQ 20342 kann die Lokation im Mikrocode entweder von einem FU 10120-Mikroprogramm oder vom SOP eines SINs empfangen. Im ersten Fall wird die Lokation über den JPD-Bus 10142 übertragen, und im zweiten Fall wird sie von EUSDT 20266 erhalten und über den EUDIS-Bus 20206 transferiert. OPB 20322 empfängt die Operanden, mit denen die Operation ausgeführt werden soll. Wenn die Operanden direkt von MEM 10112 kommen, werden sie zu OPB 20322 über den MOD-Bus 10144 transferiert; wenn sie von Registern oder Geräten in FU 10120 kommen, werden sie über den JPD-Bus 10142 transferiert.
Das Ergebnisregister 27013 ist eine Quelle für Daten. Nachdem EU 10122 eine Operation beendet hat, erhält FU 10120 das Ergebnis aus dem Ergebnisregister 27013. FU 10120 kann dann das Ergebnis in MEM 10112 oder in irgendeinem Gerät plazieren, das vom JPD-Bus 10142 zugänglich ist.

2. Spezialisierte Mikromaschinengeräte

Jede der spezialisierten Gerätegruppen dient einem Untersystem von CS 10110. Der I- Stromleser 27001 ist Teil des S-Interpreter-Untersystems, die Namensübersetzungseinheit 27015 ist Teil des Namensinterpreter-Untersystems, die Speicherreferenzeneinheit 27017 ist Teil des virtuellen Speichermanagementsystems und die Schutzeinheit 27019 ist Teil des Zugangskontrollsystems. Hier werden diese Geräte nur im Zusammenhang mit der Mikromaschine erklärt; für ein vollständiges Verständnis ihrer Funktionen innerhalb der Untersysteme, zu denen sie gehören, siehe die Beschreibungen der Untersysteme.

.a. I-Stromleser 27001

Der I-Stromleser 27001 liest und analysiert einen Strom von SINs (I-Strom genannt) von einem Prozedurobjekt 604, 606, 608. Der I-Strom besteht aus SOPs (Operationscodes, Namen und Literalen). Wie oben erwähnt, hat der in der gegenwärtigen Verkörperung von CS 10110 von einer gegebenen Prozedur 602 gelesene I-Strom ein festes Format: die SOPs sind acht Bits lang, und die Namen und Literale haben eine einzelne Länge. Abhängig von der Prozedur kann die Länge 8, 12 oder 16 Bits betragen. Der I-Stromleser 27001 analysiert den I-Strom, indem er ihn in die ihn konstituierenden SOPs und Namen aufbricht und die SOPs und Namen an geeignete Stellen der Mikromaschine weiterreicht. Der I-Stromleser 27001 enthält zwei Gerätegruppen:
- die PC-Werte 27006, die aus drei Registern bestehen, die Lokationen im I-Strom enthalten. Wenn sie zu ABP PBP dazu addiert werden, spezifizieren die in diesen Registern enthaltenen Werte-Lokationen im Prozedurobjekt 901, das die gerade ausgeführte Prozedur 602 enthält. CPC 20270 enthält die Lokation des gerade interpretierten SOPs oder Namens; IPC 20272 enthält die Lokation des Anfangs des gegenwärtig ausgeführten SINs; EPC 20274 schließlich ist nur am Beginn der Ausführung eines SIN von Interesse; dann enthält es die Lokation des zuletzt ausgeführten SIN.
- Die Analysiereinheit 27005, die aus INSTB 20262, PARSER 20264 und PREF 20260 besteht. Die Mikromaschine benutzt PREF 20260, um logische Beschreiber 27116 für den I-Strom zu kreieren, die dann auf den DB-Bus 27021 plaziert und bei logischen Speicherreferenzen benutzt werden. Die von diesen Referenzen zurückkommenden Daten werden in INSTB 20262 plaziert und vom PARSER 20264 analysiert.
SOPs, Namen und Literale, die vom PARSER 20264 erhalten werden, werden auf dem NAME-Bus 20224 plaziert, der PARSER 20264, den SOP-Dekodierer 27003, die Namensübersetzungsweinheit 27015 und OFFALU 20242 miteinander verbindet.

b.b. SOP-Dekodierer 27003

Der SOP-Dekodierer 27003 dekodiert SOPs in Lokationen im Mikrocode von FU 10120 und EU 10122. Der SOP-Dekodierer 27003 umfaßt FUSDT 11010, EUSDT 20266, das Dialektregister (RDIAL) 24212 und LOPDCODE 24210. FUSDT 11010 besteht weiterhin aus FUDISP 24218 und FALG 24220. Die Art und Weise, in der diese Geräte die in den SINs enthaltenen SOPs in Lokationen in FUSITT 11012 und EUSITT 20344 übersetzen, wurde oben beschrieben.

c.c. Namensübersetzungseinheit 27015

Die Namensübersetzungseinheit 27015 beschleunigt die Übersetzung von Namen in logische Beschreiber 27116. Diese Operation wird Namenserkennung genannt. Sie umfaßt zwei Komponenten: NC 10226 und die Namensfalle 20254. NC 10226 enthält Kopien von Informationen aus der Namenstabelle 10350 des Prozedurobjektes 604 und ermöglicht es daher, Namen in logische Beschreiber 27116 zu übersetzen, ohne auf die Namenstabelle 10350 Bezug zu nehmen. Wenn ein Name der Namensübersetzungseinheit 27015 vorgestellt wird, wird er in die Namensfalle 20254 für die weitere Benutzung für die Namensübersetzungseinheit 27015, falls erforderlich, geschoben. Wie später genauer erklärt wird, beginnt in der vorliegenden Verkörperung die Namensübersetzung immer mit der Vorstellung eines Namens bei NC 10226. Falls der Name bereits übersetzt worden ist, kann die Information, die notwendig ist, um seinen logischen Beschreiber 27116 zu konstruieren, in NC 10226 enthalten sein. Wenn es für den Namen in NC 10226 keine Information gibt, so erhält der Namenserkennungsmikrocode den Namen von der Namensfalle 20254, benutzt die Information aus der Namenstabelle 10350 für die zur Übersetzung des Namens ausgeführte Prozedur, plaziert die erforderliche Information in NC 10226 und versucht die Übersetzung aufs neue. Bei erfolgreicher Übersetzung wird aus der Information im Namenszwischenspeicher 10115 ein logischer Beschreiber 27116 hergestellt, der dem Namen entspricht, auf den DB-Bus 27021 plaziert und in ein GRF 10354-Register geladen.

d.d. Speicherreferenzeneinheit 27017

Die Speicherreferenzeneinheit 27017 führt Speicherreferenzen durch, indem sie logische Beschreiber 27116 benutzt. Die Speicherreferenzeneinheit 27017 erhält einen Befehl für MEM 10112 und einen logischen Beschreiber 27116, der die Daten beschreibt, mit denen der Befehl ausgeführt werden soll. Im Falle einer Schreiboperation empfängt die Speicherreferenzeneinheit 27017 auch die Daten, die über den JPD-Bus 10142 geschrieben werden sollen. Die Speicherreferenzeneinheit 27017 übersetzt den logischen Beschreiber 27116 in einen physikalischen Beschreiber und transferiert den physikalischen Beschreiber und den Befehl über den PD-Bus 10146 zu MEM 10112. Eine Speicherreferenzeneinheit 27017 hat vier Komponenten: ATU 10228, die Kopien von Informationen aus den KOS-virtuellen Managementsystemtabellen enthält und dadurch die Übersetzung des logischen Beschreibers in einen physikalischen Beschreiber beschleunigt; die Beschreiberfalle 20256, die die logischen Beschreiber 27116 fängt, die Befehlsfalle 27018, die Speicherbefehle fängt; und die Datenfalle 20258, die die Daten für Schreiboperationen fängt. Wenn eine logische Speicherreferenz gemacht wird, wird ein logischer Beschreiber 27116 über den DB-Bus 27021 ATU 10228 vorgestellt, und zur gleichen Zeit werden der logische Beschreiber 27116 und der Speicherbefehl in der Beschreiberfalle 20256 und der Befehlsfalle 27018 gefangen. Bei Schreiboperationen werden die zu schreibenden Daten in der Datenfalle 20258 gefangen. Wenn die zur Bildung des physikalischen Beschreibers erforderliche Information in ATU 10228 vorhanden ist, wird der physikalische Beschreiber zu MNEM 10112 über den PD-Bus 10146 transferiert. Wenn die zur Bildung des physikalischen Beschreibers notwendige Information nicht in ATU 10228 vorhanden ist, ruft ein Ereignissignal von ATU 10228 ein Mikroprogramm auf, das den logischen Beschreiber 27116 aus der Beschreiberfalle 20256 heraussucht und die in den KOS-virtuellen Speichermanagementsystemtabellen enthaltene Information dazu benutzt, eine Eingabe in ATU 10228 für den logischen Beschreiber 27116 zu machen. Bei der Rückkehr des Mikroprogrammes wird die logische Speicherreferenz unter Benutzung des logischen Beschreibers 27116 aus der Beschreiberfalle 20256, des Speicherbefehls aus der Befehlsfalle 27018 und bei Schreiboperationen mit den Daten aus der Datenfalle 20258 wiederholt. Wie bei der Diskussion des virtuellen Speichermanagements genauer beschrieben werden wird, verursacht eine logische Speicherreferenz einen Seitenfehler, wenn die Daten, die von einer logischen Speicherreferenz referenziert werden, nicht in MEM 10112 vorhanden sind.

e.e. Die Schutzeinheit 27019

Bei jeder logischen Speicherreferenz prüft die Schutzeinheit 27019, ob das die Referenz ausführende Subjekt die Zugangsrechte besitzt, die es ihm erlauben, die Aktion durchzuführen, die durch den Speicherbefehl auf das referenzierte Objekt spezifiziert wird. Wenn das Subjekt nicht die erforderlichen Zugangsrechte besitzt, veranlaßt ein Signal aus der Schutzeinheit 27019 MEM 10112, die logische Speicherreferenz abzubrechen. Die Schutzeinheit 27019 besteht aus dem Schutzzwischenspeicher 10234, der Kopien von Informationen aus den KOS-Zugangskontrollsystemtabellen enthält, und beschleunigt damit die Schutzüberprüfung, und teilt gemeinsam mit der Speicherreferenzeneinheit 27017 die Beschreiberfalle 20256, die Befehlsfalle 27018 und die Datenfalle 20258. Wenn eine logische Speicherreferenz gemacht wird, werden die AON- und die Abstandsbereiche des logischen Beschreibers dem Schutzzwischenspeicher 10234 vorgestellt. Wenn der Schutzzwischenspeicher 10234 Schutzinformationen für das von dem AON und dem Abstand spezifizierte Objekt enthält, und das Subjekt, das die Speicherreferenz durchführt, die erforderlichen Zugangsrechte besitzt, kann die Speicherreferenz weitergehen; wenn der Schutzzwischenspeicher 10234 Schutzinformationen enthält, und das Subjekt nicht die erforderlichen Zugangsrechte besitzt, bricht ein Signal vom Schutzzwischenspeicher 10234 die Speicherreferenz ab. Wenn der Schutzzwischenspeicher 10234 die angeforderte Zugangsinformation nicht enthält, bricht ein Signal vom Schutzzwischenspeicher 10234 die Speicherreferenz ab und ruft ein Mikroprogramm auf, das die Zugangsinformationen aus den KOS-Zugangskontrollsystemtabellen besorgt, und plaziert sie im Schutzzwischenspeicher 10234. Wenn der Schutzzwischenspeicher 10234 fertig ist, wird der Speicherzugriff wiederholt, wobei der logische Beschreiber aus der Beschreiberfalle 20256, der Speicherbefehl aus der Befehlsfalle 27018, und im Fall von Schreiboperationen die Daten in der Datenfalle 20258 benutzt werden.

f.f. KOS-Mikromaschinengeräte

Wie in der obigen Einführung zur Mikromaschine erwähnt wurde, kann man die Geräte, aus denen die Mikromaschine besteht, in zwei Klassen unterteilen: jene, die jeder beliebige für die Mikromaschine geschriebene Mikrocode manipulieren kann, und jene, die ausschließlich durch KOS-Mikrocode manipuliert werden können. Die letztere Klasse besteht aus bestimmten Registern in den GRs 10360 von GRF 10354, dem unteren Rahmen des Bereichs des Zwischenspeichers der virtuellen Mikromaschine im Zwischenspeicherbereich (Zwischenspeicherregister 10362) von GRF 10354, und die Geräte, die in der Schutzeinheit 27019 und der Speicherreferenzeneinheit 27017 enthalten sind. Weil die Schutzeinheit 27019 und die Speicherreferenzeneinheit 27017 nur durch KOS-Mikrocode manipuliert werden darf, darf nicht KOS-Mikrocode die Beschreiberfalle 20256 oder die Befehlsfalle 27018 nicht als Quelle oder Zielort benutzen, darf keine Register in ATU 10228 oder im Schutzzwischenspeicher 10234 laden oder ungültig machen und darf keine physikalische Speicherreferenzen durchführen, d. h. Speicherreferenzen, die physikalische Beschreiber direkt auf den PD-Bus 10146 plazieren, anstatt logische Beschreiber der Speicherreferenzeneinheit 27017 und der Schutzeinheit 27019 vorzustellen. In ähnlicher Weise darf nicht KOS-Mikrocode keine KOS-Register in den GRs 10360 von GRF 1035, oder den unteren Rahmen des Zwischenspeicherbereichs von GRF 10354 spezifizieren, wenn er GRF 10354-Register adressiert. Weiterhin darf nur KOS-Mikrocode in Verkörperungen, die ein dynamisches Laden von FUSITT 11012 erlauben, die Geräte manipulieren, die für das dynamische Laden vorgesehen sind.
In einer vorliegenden Verkörperung des CS 10110 wird die Unterscheidung zwischen KOS-Geräten und -Registern und Geräten und Registern, die allen Mikroprogrammen zugänglich sind, vom Mikroprogrammverknüpfer verwaltet. Der Mikroprogrammverknüpfer überprüft alle Mikrocodes auf Mikrobefehle, die Geräte in der Schutzeinheit 27019 oder der Speicherreferenzeneinheit 27017 manipulieren, oder die GRF 10354- Register adressieren, die für KOS-Gebrauch reserviert sind. Es ist jedoch für die Mikromaschine charakteristisch, daß KOS-Geräte logisch und physikalisch von Geräten getrennt sind, auf die alle Mikroprogramme Zugang haben; daraus ergibt sich, daß andere Verkörperungen von CS 10110-Hardware Geräte benutzen können, um Nicht-KOS- Mikroprogramme daran zu hindern, KOS-Geräte zu manipulieren.

c. Mikromaschinen-Stapelspeicher und Mikroprogrammaufrufe und -rückkehr (Fig. 272, 273)

1. Mikromaschinen-Stapelspeicher (Fig. 272)

Wie oben erwähnt, ist die FU-Mikromaschine eine Stapelspeicher-Mikromaschine. Die Eigenschaften des Stapelspeichers der FU-Mikromaschine hängen davon ab, ob die FU- Mikromaschine sich im virtuellen oder im Überwachungsmodus befindet. Im virtuellen Modus hat der Zwischenspeicher der Mikromaschine wirklich unbegrenzte Größe; wenn er mehr Rahmen als innerhalb FU 10120 erlaubt ist, enthält, so sind die oberen Rahmen in GRF 10354 und die verbleibenden Rahmen sind im Sicherheitsstapelspeicher 10336, der zu dem Prozeß 610 gehört, der von der FU-Mikromaschine ausgeführt wird. Im folgenden wird der Mikromaschinenzwischenspeicher im virtuellen Modus virtueller Mikromaschinen-Stapelspeicher genannt. Im Überwachungsmodus hält der Mikromaschinen-Stapelspeicher einen festen Betrag an Speicherkapazität; in einer vorliegenden Verkörperung des CS 10110 ist der Mikromaschinen-Stapelspeicher im Überwachungsmodus vollständig im Stapelspeicherbereich, den SRs 10362 von GRF 10354, enthalten; in anderen Verkörperungen des CS 10110 kann der Mikromaschinen-Stapelspeicher im Überwachungsmodus ganz oder teilweise in einer Speicherfläche von MEM 10112 enthalten sein, die eine feste Größe und eine feste Stelle besitzt, die der Überwachungsmikromaschine bekannt ist. In noch anderen Verkörperungen des CS 10110 kann der Überwachungsmodus Mikromaschinen-Stapelspeicher eine flexible Tiefe besitzen, ähnlich wie beim virtuellen Mikromaschinen-Stapelspeicher. In beiden Modi können Mikroprogramme außer bestimmten KOS Mikroprogrammen, die Zustandssicherungs- und Zurückspeicheroperationen ausführen, nur auf zwei Rahmen des GRF 10354 Stapelspeichers zugreifen: der Rahmen, auf dem das Mikroprogramm arbeitet, gegenwärtiger Rahmen genannt, und der Rahmen, auf dem das das Mikroprogramm aufrufende Programm arbeitet, vorhergehender Rahmen genannt. KOS-Mikroprogramme, die Zustandssicherungs- und Zurückspeicheroperationen ausführen, können zusätzlich auf den unteren Rahmen jenes Bereichs des virtuellen Mikromaschinen-Stapelspeichers zugreifen, der in GRF 10354 enthalten ist.
Fig. 272 stellt Stapelspeicher für die FU-Mikromaschine dar. Die Bereiche des Mikromaschinen-Stapelspeichers, die in FU enthalten sind, befinden sich in den SRs 10362 (von GRF 10354) und in RCWS 10358. Jedes Register von RCWS 10358 ist permanent mit einem GRF-Rahmen in den SRs von GRF 10354 verbunden, und die RCWS 10358- Register und der GRF-Rahmen zusammen können einen Rahmen des Mikromaschinen- Stapelspeichers enthalten. Wie oben beschrieben, enthält jedes Register von GRF 10354 drei Felder: eines für eine AON- oder eine andere Information, eines für einen Abstand und eines für eine Länge. Wie in Fig. 251 illustriert, enthält jedes Register in RCWS 10358 vier Felder:
- Ein 1-Bit-Feld, das den Wert des Zustandscoderegisters in MCW1 20290 enthält, zu dem Zeitpunkt, an dem der Aufruf, der den nächsten Rahmen kreierte, stattfand.
- Ein Feld, das anzeigt, welche Ereignissignale zu dem Zeitpunkt warteten, als der Aufruf, zu dem die RCWS-Register gehören, ein anderes Mikroprogramm aufgerufen hat.
- Ein Kennzeichen, das anzeigt, ob der zum Zeitpunkt des Aufrufs ausgeführte Mikrobefehl der erste Mikrobefehl in einem SIN war.
- Die Adresse, an der die Ausführung des aufrufenden Mikroprogrammes fortgesetzt werden soll.
Der Gebrauch dieser Felder wird in der folgenden Diskussion klar werden.
Der für die Mikromaschinen-Stapelspeicher in den SRs 10362 und RCWS 10358 verfügbare Raum wird in zwei Teile unterteilt: die Rahmen 27205, die für MOS 10370 reserviert sind, und die Rahmen 27206, die für MIS 27203 verfügbar sind. Die Rahmen 27206 dürfen keine MIS-Rahmen 27203 beinhalten oder teilweise oder vollständig von MIS- Rahmen 27203 besetzt werden. Der Raum, der keine MIS-Rahmen enthält, sind die freien Rahmen 27207. Die Größe des für die Überwachungsmikromaschinen-Stapelspeicherrahmen 27205 reservierten Raumes ist festgelegt, und die Räume 27203, 27205 und 27207 kommen immer in dieser Reihenfolge. Die Registeradressierung 27011 verwaltet die Adressierung im Stapelspeicherbereich 27201 von GRF 10354 und RCWS 10358 so, daß die Werte für die Lokationen des gegenwärtigen, vorangegangenen und unteren Rahmens, die die Register in RCWS 10358 oder die Rahmen im Stapelspeicherbereich 27201 spezifizieren, automatisch "umgebrochen" werden, wenn sie über den größten durch die Größe der Register erlaubten Indexwert hinaus inkrementiert oder unter den kleinsten Indexwert hinaus dekrementiert werden. So können, obwohl die Räume 27203, 27205 und 27207 immer in derselben relativen Reihenfolge stehen, ihre GRF 10354-Rahmen und RCWS-Register irgendwo im Stapelspeicherbereich 27201 und RCWS 10358 liegen.

2. Mikroprogrammaufrufe und -rückkehr

In CS 10110 können Mikroprogramme durch andere Mikroprogramme oder durch Signale von der CS 10110-Hardware aufgerufen werden. Die Methoden des Aufrufes außer Mikroprogrammaufrufen und Rückkehr ähneln den Aufrufen von und einer Rückkehr von Prozeduren, die in Hochsprachen geschrieben wurden. Im folgenden werden die allgemeinen Prinzipien der Aufrufe von Mikroprogrammen und von Rückkehr diskutiert, und danach die spezifischen Methoden, durch die Mikroprogramme in CS 10110 aufgerufen werden können. Die Unterschiede zwischen Aufrufen im Überwachungsmodus und Aufrufen im virtuellen Modus werden in den folgenden Diskussionen der beiden Modi erklärt.
Das Mikroprogramm, das augenblicklich ausgeführt wird, läuft auf dem Rahmen, der durch den gegenwärtigen Zeiger 27215 spezifiziert wird. Wenn ein Aufruf auftritt, entweder weil das ausführende Mikroprogramm einen Aufruf durchführt oder weil ein Signal, das einen Aufruf veranlaßt, aufgetreten ist, macht die Hardware von JP 10114 drei Dinge:
- Er speichert die Zustandsinformation für das aufrufende Mikroprogramm in dem RCWS 10358-Register, das mit dem gegenwärtigen Rahmen verbunden ist. Die Zustandsinformation beinhaltet die Lokation, an der die Ausführung des aufrufenden Mikroprogrammes wieder aufgenommen wird, wie auch andere Zustandsinformationen.
- Er inkrementiert den gegenwärtigen Zeiger 27215 und den vorangegangenen Zeiger 27213, und stellt dadurch einen Rahmen für den neuen Aufruf zur Verfügung.
- Er beginnt, den ersten Befehl des neu aufgerufenen Mikroprogrammes auszuführen.
Weil das frisch aufgerufene Mikroprogramm Zugang zu den Registern des Rahmens des aufrufenden Mikroprogrammes hat, kann das aufrufende Mikroprogramm "Argumente" an das aufgerufene Mikroprogramm übergeben, indem es Werte in Register in seinen von dem aufgerufenen Mikroprogramm benutzten Rahmen plaziert. Das rufende Mikroprogramm kann jedoch nicht spezifizieren, welche Register "Argumente" eines Aufrufes besitzen, daher muß das aufgerufene Mikroprogramm wissen, welche Register des vorherigen Rahmens durch das aufrufende Mikroprogramm benutzt wurden. Da die einzigen "Argumente", auf die ein Mikroprogramm Zugang hat, die in dem vorhergehenden Rahmen sind, kann ein Mikroprogramm Argumente, die es von seinem Aufrufer bekam, einem Mikroprogramm, was es aufruft, nur so weitergeben, indem es die Argumente des Rahmens seines Aufrufers in seinen eigenen Rahmen kopiert, der dann der vorherige Rahmen des frisch aufgerufenen Mikroprogrammes wird.
Die Rückkehr ist das Gegenteil vom obigen: Der gegenwärtige Zeiger 27215 und der vorangegangene Zeiger 27213 werden dekrementiert, somit wird der Rahmen der beendeten Unterprogrammausführung "weggeschoben" und zum Rahmen des Aufrufers zurückgekehrt. Der Aufrufer nimmt dann die Ausführung an der im RCWS 10358- Register spezifizierten Lokation wieder auf und benutzt dabei den in RCWS 10358 abgespeicherten Zustand. Der gesicherte Zustand beinhaltet den Wert des Zustandscodes in MCW1 20290 zum Zeitpunkt des Aufrufs und Kennzeichen, die verschiedene hängende Ereignisse bezeichnen. Das Zustandscodefeld in MCW1 20290 wird auf den abgespeicherten Wert gesetzt, und die Kennzeichen der hängenden Ereignisse können Ereignisse hervorrufen, wie es unten genauer beschrieben wird.

3. Mittel der aufrufenden Mikroprogramme

In der Mikromaschine können Invokationen entweder durch Befehle in Mikrobefehlen oder durch Hardwaresignale erzeugt werden. Im folgenden werden durch Befehle in Mikrobefehlen erzeugte Invokationen Aufrufe genannt, während die durch Hardwaresignale erzeugten Ereignisinvokationen und Staus genannt werden. Invokationen werden weiter durch die Lokation voneinander unterschieden, an die sie zurückkehren. Aufrufe und Staus kehren zu dem Mikrobefehl zurück, der dem Mikrobefehl folgt, in dem die Invokation auftritt; Ereignisinvokationen kehren zu jenem Mikrobefehl zurück, der dann wiederholt wird.
Hinsichtlich der Implementierung sind die verschiedenen Rückkehrlokationen eine Folge des Punktes im Mikromaschinenzyklus, an dem Aufrufe, Staus und Ereignislokationen eine Rückkehrlokation speichern und die Kontrolle dem gerufenen Programm übergeben. Bei Aufrufen und Staus werden diese Operationen im M1-Zyklus durchgeführt; bei Ereignisinvokationen andererseits veranlaßt das Ereignissignal während des M0-Zyklus, daß auf den M0-Zyklus ein MA-Zyklus anstelle eines M1-Zyklus folgt, und die Operationen werden im MA-Zyklus durchgeführt. Im M1-Zyklus wird der Wert in mPC 20276 inkrementiert; im MA-Zyklus wird er nicht inkrementiert. Konsequenterweise ist der in RCWS 10358 gespeicherte Rückkehrwert bei einem Aufruf oder Stau der inkrementierte Wert von mPC 20276, während der bei einer Ereignisinvokation gespeicherte Rückkehrwert der nicht inkrementierte Wert von mPC 20276 ist. Die folgende Diskussion beschäftigt sich zuerst mit Aufrufen und Staus und danach mit Ereignisinvokationen.
Ein Call-Befehl in einem Mikrobefehl enthält einen Literalwert, der den Abstand vom Mikrobefehl, der den Call enthält, an dem die Ausführung nach dem Call fortgeführt werden muß. Wenn der Mikrobefehl mit dem Call-Befehl im Mikromaschinenzyklus M1 ausgeführt wird, addiert BRCASE 20278 den im Befehl enthaltenen Abstand zum aktuellen Wert in mPC 20276 dazu, um die Lokation des aufgerufenen Mikroprogrammes zu erhalten und setzt SITTNAG 20286, um die von BRCASE 20278 zur Verfügung gestellte Lokation als Lokation für den nächsten Mikrobefehl auszuwählen. Dann inkrementiert der Call-Befehl mPC 20276 und speichert den inkrementierten Wert von mPC 20276 im RCWS 10358-Register, das mit dem gegenwärtigen Rahmen in den SRS 10362 assoziiert ist und inkrementiert den gegenwärtigen Zeiger 27215 und den vorherigen Zeiger 27213, um einen neuen Rahmen in den SRs 10362 zur Verfügung zu stellen. Der Stau arbeitet exakt wie der Call, außer daß ein Hardwaresignal während des Mikromaschinenzyklus M1 die mit der Invokation verbundenen Aktionen verursacht und stellt die Lokation des aufgerufenen Mikroprogrammes direkt SITTNAG 20286 zur Verfügung.
Bei Ereignissen veranlaßt die Ereignislogik 20284, daß eine Invokation während des Zyklus M0 auftritt und stellt die Lokation des aufgerufenen Mikroprogrammes über CSADR 20299 zur Verfügung. Da das Ereignis während des Zyklus M0 auftritt, ist die in RCWS 10358b gespeicherte Lokation der nicht inkrementierte Wert von mPC 20276, und SITTNAG 20286 wählt die von der Ereignislogik 20284 zur Verfügung gestellte Lokation als Lokation für den nächsten Mikrobefehl aus. Da die Rückkehr von einem Ereignis bewirkt, daß der Mikrobefehl, während dem das Ereignis auftrat, wieder ausgeführt wird, kann man sagen, daß der Mikrobefehl und das zu ihm zugehörige Mikroprogramm sich des Auftretens des Ereignisses nicht "bewußt" sind. Der einzige Unterschied zwischen der Ausführung eines Mikrobefehls, währenddessen ein Ereignis auftritt, und der Ausführung desselben Mikrobefehls ohne das Auftreten des Ereignisses, ist die für die Ausführung benötigte Zeitspanne.

4. Das Auftreten von Ereignisinvokationen (Fig. 273)

Wie oben beschrieben, werden Ereignisinvokationen durch die Ereignislogik 20284 erzeugt. Die Lokation im Mikrocode, zu der die Ereignislogik 20284 die Steuerung transferiert, wird durch folgendes bestimmt:
- Die Operation, die von FU 10120 begonnen wurde. Bestimmte Ereignisinvokationen können nur am Beginn bestimmter FU 10120-Operationen auftreten.
- Der Zustand der Ereignissignalleitungen von der Hardware und internen Registern in der Ereignislogik 20284.
- Der Zustand bestimmter über MCW1 20290 sichtbare Register. Manche dieser Register aktivieren Ereignisse und andere maskieren Ereignisse. Manche der Register, die Ereignisse aktivieren, werden durch Ereignissignale gesetzt, und andere durch das Mikroprogramm.
- Das Setzen bestimmter Bits in dem RCWS 10358-Register, welches zu dem Mikromaschinenrahmen für die Invokation gehört, zu dem zurückgekehrt wird - bei der Rückkehr von Invokationen von Mikroprogrammen.
Mikroprogramme können diese Mechanismen dazu benutzen, Ereignissignale zu deaktivieren und die Ereignisinvokation von einem Ereignissignal für einen einzelnen Mikrobefehl oder eine undefinierte Periode zu verzögern, und FU 10120 benutzt sie, um bestimmte Ereignisinvokationen, die aus bestimmten Ereignissignalen resultieren, automatisch zu verzögern. Wenn man die traditionelle Programmierterminologie benutzt, so erlauben die Mechanismen eine differenzierte Maskierung der Ereignissignale. Ein Ereignissignal kann explizit für einen einzigen Mikrobefehl maskiert werden, es kann für eine Abfolge von Mikrobefehlen maskiert werden, es kann automatisch maskiert werden, bis eine bestimmte Operation auftritt, oder es kann automatisch für eine bestimmte maximale Zeitspanne maskiert werden. Ereignissignale, die während ihrer Maskierung auftreten, sind nicht verloren. In manchen Fällen fährt das Ereignissignal fort, bis es bedient wird; in anderen Fällen wird ein Register gesetzt, um die Tatsache zu speichern, daß dieses Ereignissignal aufgetreten ist. Wenn das Ereignissignal unmaskiert ist, veranlaßt das gesetzte Register, daß das Ereignissignal wieder auftritt. In manchen Fällen schließlich wird das Ereignissignal nicht gespeichert, aber es tritt wieder auf, wenn der Mikrobefehl, der es verursacht hat, wiederholt wird.
Im folgenden werden zuerst die Beziehung zwischen FU 10120-Operationen und Ereignissignalen vorgestellt, danach eine detaillierte Diskussion der Aktivierungsregister in MCW1 20290 und den Bits in den RCWS 10358-Registern, die die Ereignisinvokationen steuern.
FU 10120 ermöglicht es, daß Ereignisinvokationen, die sich aus Ereignissignalen ergeben, für einen einzelnen Mikrobefehl blockiert werden; es verzögert auch bestimmte Ereignisinvokationen für bestimmte Ereignissignale bis zum ersten Mikrobefehl eines anderen SIN. Andere Ereignissignale treten nur am Anfang eines SIN auf, am Anfang einer Namensraumauflösungs- oder -auswertungsoperation, oder am Anfang einer logischen Speicherreferenz.
Ereignisinvokationen können um einen einzelnen Mikrobefehl verzögert werden, indem ein Feld des Mikrobefehls selbst gesetzt wird. Das Setzen dieses Feldes verzögert fast alle Ereignisinvokationen und stellt dadurch sicher, daß eine Ereignisinvokation nicht während des M0-Zyklus des Mikrobefehls auftritt.
Mit der Fehlersuche in Verbindung stehende Ereignissignale treten am Anfang bestimmter Mikromaschinenoperationen auf. Solche Ereignissignale werden Ablaufverfolgungs- Ereignissignale genannt. Wie im einzelnen bei der Diskussion des Fehlersuchprogrammes erklärt wird, können Ablaufverfolgungs-Ereignissignale beim ersten Mikrobefehl eines SIN, am Anfang einer Auswertungs- oder Auflösungsoperation, am Anfang einer logischen Speicherreferenz oder am Anfang eines Mikrobefehls auftreten. IPM-Unterbrechungssignale und Intervallzeitmeßgerät-Überlaufereignissignale werden automatisch bis zum Beginn des nächsten SIN oder bis eine maximale Zeitspanne abgelaufen ist, maskiert, was immer zuerst auftritt. Die hier involvierten Mechanismen werden genau in der Diskussion der Unterbrechungsverwaltung in der FU 10120-Mikromaschine erklärt.
Indem wir uns nun den Registern zuwenden, die dazu benutzt werden, Ereignissignale zu maskieren und zu aktivieren, so ist Fig. 273 eine Darstellung der maskierenden und aktivierenden Register in MCW1 20290 und des Feldes in den RCWS 10358-Registern, das die Ereignisinvokationen steuert. Anfangend mit den Registern in MCW1 20290, so gibt es drei Register, die die Ereignisinvokationen steuern: das Ereignis-Maskierungsregister (EM) 27301, das Ereignis-Warteregister (EP) 27309 und das Ablaufverfolgungs- Aktivierungsregister (TE) 27319. Die Bits in EM 27301 maskieren bestimmte Ereignissignale, solange sie gesetzt sind; die Bits im EP-Register 27309 zeichnen das Auftreten bestimmter Ereignissignale auf, während dem sie maskiert werden; wenn die Bits im TE- Register 27319 gesetzt sind, so treten Ablaufverfolgungs-Ereignissignale vor bestimmten FU 10120-Operationen auf.
EM 27301 enthält drei ein Bit-Felder: das asynchrone Maskierungsfeld 27303, das Überwachungsmaskierungsfeld 27305 und das Ablaufverfolgungs-Ereignismaskierungsfeld 27307. Wie bei der Besprechung der FU 10120-Hardware genau erklärt wurde, stellen diese Bits eine Rangfolge der Ereignismaskierungen auf. Wenn das asynchrone Maskierungsfeld 27303 gesetzt ist, werden nur zwei Ereignissignale maskiert: das, das sich aus einem Überlauf des EGGTMR 25412 ergibt, und das, das sich aus einem Überlauf des Stapelspeichers von EU 10122 ergibt. Wenn das Überwachungsmaskierungsfeld 27305 gesetzt ist, werden diese Ereignisse maskiert, und darüber hinaus wird das Ereignissignal für den FU-Stapelspeicher-Überlauf maskiert. Wie später genau erklärt wird, führt die FU-Mikromaschine im Überwachungsmodus aus, wenn das FU 10120-Stapelspeicher- Überlaufereignissignal maskiert ist. Wenn das Ablaufverfolgungs-Ereignismaskierungsfeld 27307 gesetzt ist, werden zusätzlich zu den obigen Signalen die Ablaufverfolgungsfallen- Ereignissignale maskiert. Jedes dieser Felder in EM 27301 kann einzeln gesetzt und durch das Mikroprogramm gelöscht werden.
Vier Ereignissignale setzen Felder in EP 27309: das EGGTMR 25412-Ablaufsignal setzt das ET-Feld 27311, das INTTMR 25410-Ablaufsignal setzt das IT-Feld 27313, das nicht fatale Speicherfehlersignal setzt das ME-Feld 27315 und das Zwischenprozeß-Nachrichtensignal setzt das IPM-Feld 27317. Die Ereignisinvokationen für all diese Ereignissignale außer dem Eieruhr-Ablaufsignal treten am Anfang eines SIN auf; in diesen Fällen enthalten die Felder in EP 27309 die Tatsache, daß das Ereignissignal bis zu diesem Zeitpunkt aufgetreten ist; die Ereignisinvokation für das Eieruhr-Ablaufsignal tritt nach dem Signal auf, sobald es das Setzen der Maskierungsbits in EM 27301 erlaubt. Das Bit im ET-Feld 27311 enthält die Tatsache des Eieruhr-Ablaufsignals, bis die Maskierung es erlaubt, daß die Ereignisinvokation auftreten kann. Alle Felder in EP 27309 außer dem MB-Feld 27315 können durch Mikrocode zurückgesetzt werden . . Die durch die Ereignisse aufgerufenen Mikroprogramme müssen die geeigneten Felder zurücksetzen; sonst werden sie wieder aufgerufen, wenn sie zurückkehren. Das ME-Feld 27315 wird automatisch zurückgesetzt, wenn der Speicherfehler bedient wurde.
Das TE-Registerfeld 27319 aktiviert die Ablaufverfolgung. Jedes Bit in dem Register aktiviert eine Art von Ablaufverfolgungs-Ereignissignal, wenn es gesetzt ist. Abhängig von der Art der Ablaufverfolgung tritt das Ablaufverfolgungs-Ereignissignal auf am Anfang eines SIN, am Anfang einer Auflösungs- oder Auswertungsoperation, am Anfang einer logischen Speicherreferenz oder am Anfang eines Mikrobefehls. Für weitere Einzelheiten siehe die folgende Beschreibung der Fehlersuche.
Indem wir uns nun den in RCWS 10358 enthaltenen Registern zuwenden, so enthält jedes RCWS-Register 27322 acht Felder, die die Ereignissignale steuern. Das erste Feld ist das FM-Feld 27323. Das FM-Feld 27323 enthält den Wert eines Registers in der Ereignislogik 20284, wenn die Invokation, zu der das RCWS-Register 27322 gehört, auftritt. Das Register in der Ereignislogik 20284 wird nur dann gesetzt, wenn der augenblicklich ausgeführte Mikrobefehl der erste Mikrobefehl eines SIN ist. Daher wird das FM-Feld 27323 nur in den RCWS-Registern 27322 gesetzt, die zu Ereignisinvokationen gehören, die im M0-Zyklus des ersten Mikrobefehls eines SIN auftreten, d. h. am Beginn eines SIN. Der Wert des Registers in der Ereignislogik 20284 wird im FM-Feld 27323 gesichert, weil mehrere Ereignisinvokationen am Beginn eines einzelnen SIN auftreten können. Die Ereignisinvokationen treten in der Reihenfolge ihrer Priorität auf: wenn die mit der höchsten Priorität zurückkehrt, veranlaßt die Tatsache, daß das FM-Feld 27323 gesetzt ist, daß das Register in der Ereignislogik 20284 wieder auf den Zustand gesetzt wird, den es beim ersten Mikrobefehl eines SIN hat. Der so gesetzte Registerzustand veranlaßt, daß die nächste Ereignisinvokation, die beim Beginn des SIN auftreten muß, stattfindet. Nachdem alle solche Invokationen beendet sind, tritt der erste Mikrobefehl in seinen M1-Zyklus ein und setzt das Register in der Ereignislogik 20284 zurück. In seinem zurückgesetzten Zustand verhindert das Register, daß irgendeine Ereignisinvokation, die nur am Beginn eines SIN auftreten kann, auftritt. Es wird wieder beim Beginn des nächsten SIN gesetzt.
Die verbleibenden Felder im RCWS-Register 27322, die die Ereignisinvokationen steuern, sind die Felder im Rückkehrsignalfeld 27331. Diese Felder erlauben es, daß die Information, daß ein Ereignissignal aufgetreten ist, über Ereignisinvokationen hinweg gespeichert wird, bis die Ereignisinvokation des Ereignissignals stattfindet. Wenn eine Invokation auftritt, werden diese Felder durch die Ereignislogik 20284 gesetzt. Bei der Rückkehr von der Invokation sind die Werte der Felder Eingaben in die Ereignislogik 20284 und erzeugen dadurch Ereignissignale. Das Ereignissignal mit der höchsten Priorität ergibt eine Ereignisinvokation, und die verbleibenden Ereignissignale setzen Felder im Rückkehrsignalfeld 27331, das zu dem RCWS-Register 27322 gehört, das wiederum zu der Invokation, die eben ausgeführt wird, gehört, wenn das Ereignissignal auftritt. Da die Felder im Rückkehrsignalfeld 27330 Eingaben für die Ereignislogik 20284 sind, muß der als Folge von Ereignissignalen aufgerufene Mikrocode, der eines dieser Felder setzt, das Feld selbst zurücksetzen. Sonst resultiert die Rückkehr von dem Mikrocode einfach eine wiederholte Invokation des Mikrocodes.
Die sieben Felder im Rückkehrsignalfeld 27330 haben folgende Bedeutung:
- Wenn das EG-Feld 27333 gesetzt ist, erzeugte eine EU 10122-Aufteilungsoperation eine illegale Lokation im EU 10122-Mikrocode EUSITT 20344.
- Wenn das NT-Feld 27335, das ST-Feld 27341, das T-Feld 27343 oder das mB- Feld 27345 gesetzt ist, ist ein Ablaufverfolgungssignal aufgetreten. Diese werden genauer bei der Besprechung der Fehlersuche erklärt.
- Wenn das ES-Feld 27337 gesetzt ist, ist eine EU 10122-Rückspeicherausnahme aufgetreten, d. h. ein Fehler trat auf, als EU 10122 versuchte, das Ergebnis einer Operation in MEM 10112 abzuspeichern.
- Wenn das MRR-Feld 27339 gesetzt ist, ist eine Bedingung wie ein ATU 10228- Fehler oder ein Schutzzwischenspeicher 10234-Fehler aufgetreten, und es ist notwendig, eine Speicherreferenz wiederholt zu versuchen.

d. Virtuelle Mikromaschinen und die Überwachungs-Mikromaschine

Wie oben beschrieben, kann der auf eine FU 10120-Mikromaschine ausgeführte Mikrocode entweder im Überwachungsmodus oder im virtuellen Modus ablaufen. In diesem Bereich der Diskussion werden die unterschiedlichen Merkmale und Anwendungen der beiden Modi genau erklärt.

1. Virtueller Modus

Wie oben erwähnt, ist das Hauptunterscheidungsmerkmal zwischen virtuellem Modus und Überwachungsmodus- MIS 10368. Die Tatsache, daß MIS 10368 tatsächlich unbegrenzte Größe hat, hat folgende Konsequenzen für Mikroprogramme, die im virtuellen Modus ausführen.
- Ein Aufruf eines Mikroprogrammes, das im virtuellen Modus ausführt, kann weitere Aufrufe unbegrenzter Tiefe zur Folge haben.
- Jeder Aufruf oder jede Rückkehr von einem Mikroprogramm, das im virtuellen Modus ausführt, kann einen Seitenfehler verursachen.
Die FU-Mikromaschine befindet sich im virtuellen Modus, wenn alle Bits im Ereignismaskierungsbereich von MCW1 20290 gelöscht sind. In diesem Zustand werden keine aktivierten Ereignissignale maskiert, und Ereignisaufrufe können in jedem beliebigen Mikrobefehl auftreten, der diese nicht maskiert.
Da Aufrufe im virtuellen Modus bis zu einer beliebigen Tiefe stattfinden können, können Mikroprogramme, die in diesem Modus arbeiten, rekursiv sein. Solche rekursiven Mikroprogramme sind für die Interpretation von Namen besonders nützlich. Oft enthält der Namenstabelleneingang für einen Namen, wie oben beschrieben, Namen, die andere Namen auflösen, und der unbegrenzte Stapelspeicher der virtuellen Mikromaschine erlaubt den Gebrauch von rekursiven Namenserkennungsmikroprogrammen in solchen Situationen. Rekursive Mikroprogramme können auch für komplexe SINs, wie Aufrufe, benutzt werden.
Da Invokationen bis zu jeder beliebigen Tiefe auftreten können, kann jede beliebige Anzahl von Ereignissen auftreten, während einer Mikroprogramm im Überwachungsmodus ausführt. Dies wiederum vereinfacht die Ereignisverwaltung sehr. Wenn ein Ereignissignal auftritt, währenddessen ein Ereignis mit einer gegebenen Priorität bearbeitet wird, und das gerade signalisierte Ereignis eine höhere Priorität als das gerade abgearbeitete Ereignis besitzt, so ist das Ergebnis einfach die Invokation des Bearbeiters des neuen Ereignisses. So entspricht die Reihenfolge, in der der Ereignisbearbeiter zum Ende kommt, exakt den Prioritäten ihrer Ereignisse: die mit der höchsten werden zuerst beendet.
Ein Seitenfehler kann bei jeder im virtuellen Modus ausgeführten Mikroinvokation oder Rückkehr auftreten, weil eine Invokation im virtuellen Modus, die auftritt, wenn es keine freien Rahmen 27207 auf den SRs 10362 gibt, ein Ereignissignal erzeugt, das ein Mikroprogramm aufruft, das im Überwachungsmodus läuft. Das Mikroprogramm transferiert MIS-Rahmen 27203 von GRF 10354 zum Sicherheitsstapelspeicher 10336 in MEM 10112, und der Transfer kann einen Seitenfehler verursachen. In ähnlicher Weise tritt, wenn eine Mikrorückkehr vom letzten Rahmen auf den MIS-Rahmen 27203 auf den SRs 10362 stattfindet, ein Ereignissignal auf, das ein Mikroprogramm aufruft, das zusätzliche Rahmen vom Sicherheitsstapelspeicher 10336 zu GRF 10354 transferiert, und dieser Transfer kann auch einen Seitenfehler verursachen.
Die Tatsache, daß Seitenfehler bei Mikroaufrufen oder einer Mikrorückkehr im virtuellen Modus auftreten können, hat zwei wichtige Konsequenzen: Mikroprogramme, die keine Seitenfehler außer denen, die selbst durch das Mikroprogramm erzeugt werden, tolerieren können, können nicht im virtuellen Modus ausführen, und weil unerwartete Seitenfehler die Ausführung unbestimmt werden lassen, können Mikroprogramme, die sich beenden müssen, nicht im virtuellen Modus ausführen. Wenn z. B. das Mikroprogramm, das Seitenfehler behandelt, im virtuellen Modus ausführen würde, könnte sein Aufruf einen Seitenfehler verursachen, der dazu führen würde, daß das Mikroprogramm wieder aufgerufen werden würde, was wiederum einen neuen Seitenfehler verursachen würde usw. in einer unendlichen Rekursionsreihe.

2. Überwachungsmikromaschine

Wie oben beschrieben, ist das wesentliche Merkmal des Überwachungsmodus MOS 10370. In einer vorliegenden Verkörperung des CS 10110 hat dieser Stapelspeicher eine feste Minimalgröße und befindet sich immer in den GRF-Registern 10354. Die Natur von MOS 10370 hat vier Konsequenzen für Mikroprogramme, die im Überwachungsmodus ablaufen:
- Wenn die Mikromaschine sich im Überwachungsmodus befindet, ist die Tiefe der Aufrufe begrenzt; rekursive Mikroprogramme können daher nicht im Überwachungsmodus ausführen, und Ereignisinvokationen müssen begrenzt werden.
- Invokationen von Mikroprogrammen oder eine Rückkehr von Mikroprogrammen im Überwachungsmodus resultieren nie in Seitenfehlern.
- Mikroprogramme, die im Überwachungsmodus ablaufen, beenden sich garantiert, wenn sie nicht den Prozeß 610 abbrechen, den sie ausführen, oder einen Aufruf einer Software durchführen.
- Wenn die Mikromaschine im Überwachungsmodus ausführt, kommt sie garantiert in den virtuellen Modus innerhalb einer vernünftigen Zeitspanne zurück, entweder weil ein im Überwachungsmodus ausführendes Mikroprogramm sich beendet hat, oder weil das Mikroprogramm den Prozeß 610, den es ausführt, abgebrochen hat, oder weil es einen Aufruf von Software gemacht hat. Das Ergebnis ist in beiden Fällen die Ausführung einer neuen Abfolge von SOPs und daher eine Rückkehr in den virtuellen Modus.
In einer gegenwärtigen Verkörperung des CS 10110 befindet sich die FU-Mikromaschine im Überwachungsmodus, wenn eine Kombination von Maskierungsbits in MCW1 20290 gesetzt ist, das in einer Maskierung des FU-Stapelspeicher-Überlaufereignisses und des Eieruhr-Überlaufereignisses resultiert. Wie oben beschrieben, werden diese Ereignisse maskiert, wenn die Felder 27303, 27305 oder 27307 gesetzt sind. Diese Ereignisse und die Konsequenzen aus ihrer Maskierung werden unten genauer erklärt.
Das Ereignissignal für das FU-Stapelspeicher-Überlaufereignis tritt bei Mikroinvokationen auf, für die es keinen verfügbaren Platz in den MIS-Rahmen 27203 gibt. Wenn das Ereignissignal nicht maskiert ist, veranlaßt es die Invokation eines Mikroprogrammes, das die MIS-Rahmen von den MIS-Rahmen 27203 auf den Sicherheitsstapelspeicher 10336 eines Prozesses 601 schiebt. Wenn das FU-Stapelspeicher-Überlaufereignis maskiert ist, sind alle Rahmen in den SRs 10362 der GRs 10360 verfügbar für Mikroprogrammaufrufe, und Mikroprogrammaufrufe werden nicht in Seitenfehlern resultieren, aber falls die Kapazität der SRs 10362 überschritten wird, hört FU 10120 mit dem Betrieb auf.
Das Eieruhr-Überlaufereignissignal tritt auf, wenn EGGTMR 25412 abläuft. Wie später genauer erklärt wird, stellt EGGTMR 25412 sicher, daß ein Intervallzeitmeßgerätablauf eine Interprozessornachricht oder ein nicht fataler Speicherfehler von JP 10114 innerhalb eines vernünftigen Zeitintervalls bedient wird. Wenn ein Ereignissignal des Intervallzeitmeßgerätablaufs oder ein Interprozessornachrichten-Ereignissignal zu einem Zeitpunkt auftritt, bei dem es für die FU-Mikromaschine uneffizient wäre, das Ereignis abzuarbeiten, beginnt EGGTMR 25412 zu laufen. Wenn EGGTMR 25412 abgelaufen ist, wird das Ereignis bearbeitet, es sei denn, die Mikromaschine befindet sich im Überwachungsmodus. Wenn das EGGTMR 25412-Ablaufereignissignal auftritt; während die FU- Mikromaschine sich im Überwachungsmodus befindet, d. h. während das Ereignis maskiert ist, so setzt das Ereignissignal das Feld 27311 in MCW1 20290. Wenn die FU-Mikromaschine in den virtuellen Modus umkehrt, d. h. wenn alle Ereignismaskierungsbits in MCW1 20290 gelöscht werden, tritt das EGGTMR 25412-Ablaufereignis auf, und die Ereignisbearbeiter für den Ablauf des Intervallzeitmeßgerätes und/oder der Interprozessornachricht werden durch die Ereignislogik 20284 aufgerufen.

e. Unterbrechungs- und Fehlerbehandlung

1. Allgemeine Grundsätze

Jedes Computersystem muß dazu imstande sein, mit Ereignissen umzugehen, die die normale Ausführung eines Programmes unterbrechen. Solche Ereignisse werden allgemein in zwei Klassen unterteilt: Fehler und Unterbrechungen. Ein Fehler tritt als eine Folge des Versuchs auf, einen Maschinenbefehl auszuführen, und sein Auftreten ist daher synchron mit dem Maschinenbefehl. Typische Fehler sind Gleitkomma-Überlauffehler und Seitenfehler. Ein Gleitkomma-Überlauffehler tritt auf, wenn ein Maschinenbefehl es versucht, eine Gleitkomma-arithmetische Operation durchzuführen, und das Ergebnis den Kapazitätsbereich der Gleitkomma-Hardware von CS 10110, d. h. EU 10122, übersteigt. Ein Seitenfehler tritt auf, wenn ein Maschinenbefehl in einem Computersystem mit virtuellem Speicher es versucht, Daten zu referenzieren, die momentan nicht im Hauptspeicher des Computersystems, d. h. MEM 10112, verfügbar sind. Da Fehler mit der Ausführung von Maschinenbefehlen synchron sind und in manchen Fällen das Ergebnis der Ausführung eines spezifischen Maschinenbefehls sind, ist ihr Auftreten bis zu einem gewissen Grad vorhersagbar.
Das Auftreten einer Unterbrechung ist nicht vorhersagbar. Eine Unterbrechung tritt als Folge einer vom Computersystem durchgeführten Handlung auf, die keine direkte Verbindung zu der Ausführung eines Maschinenbefehls vom Computersystem hat. Zum Beispiel tritt eine I/O-Unterbrechung auf, wenn durch ein I/O-Gerät (IOS 10116) übertragene Daten die zentrale Prozessoreinheit (FU 10120), ohne Rücksicht auf den gerade ausgeführten Maschinenbefehl in der zentralen Prozessoreinheit, erreichen.
In konventionellen Systemen wurden Unterbrechungen und Fehler folgendermaßen bearbeitet: wenn eine Unterbrechung oder ein Fehler auftritt, so erkennt das Computersystem das Auftreten, bevor es den nächsten Maschinenbefehl ausführt, und führt ein Unterbrechungsbearbeitung-Mikroprogramm oder eine Prozedur 602 anstelle des nächsten Maschinenbefehls aus. Wenn die Unterbrechung oder der Fehler nicht durch den Prozeß 610, in dem er auftritt, bearbeitet werden kann, so resultiert die Unterbrechung oder der Fehler in einem Prozeßaustausch. Wenn das Unterbrechungsbearbeitungsprogramm beendet ist, kann der Prozeß 610, der fehlerhaft war oder der unterbrochen wurde, der CPU zurückgegeben werden, falls er entfernt worden war und der nächste Maschinenbefehl ausgeführt wurde.
Während die obige Methode mit Fehlern gut zurecht kommt, verursacht die Tatsache, daß Unterbrechungen asynchron sind, mehrere Probleme:
- Maschinenbefehle können keinen undefinierten Zeitbetrag für ihre Ausführung beanspruchen, weil Unterbrechungen nicht bearbeitet werden können, bis der Maschinenbefehl, während dem sie auftreten, beendet ist.
- Es muß möglich sein, einen Prozeß 610 jederzeit von der CPU zu entfernen, weil das Auftreten einer Unterbrechung nicht vorhersagbar ist. Diese Forderung erschwert das Prozeßmanagement sehr.
Die für die Unterbrechungs- und Fehlerbearbeitung verwendete Methode in einer vorliegenden Verkörperung des CS 10110 wird unten beschrieben.

2. Behandlung von Hardware-Unterbrechungen und -Fehlern in CS 10110

In CS 10110 gibt es zwei Ebenen von Unterbrechungen: die, die vollständig durch Software kreiert und behandelt werden, und die, die durch Hardware-Signale kreiert werden. Die erste Klasse von Unterbrechungen wurde in der Besprechung der Prozesse 610 behandelt; die letztere, Hardware-Unterbrechung genannt, wird unten beschrieben.
In CS 10110 beginnen Hardware-Unterbrechungen und Fehler als Aufrufe von Mikroprogrammen in FU 10120. Die Aufrufe können das Ergebnis von Ereignissignalen sein oder durch Mikroprogramme gemacht werden. Wenn z. B. IOS 10116 Daten in MEM 10112 für JP 10114 plaziert, resultiert ein Interprozessor-Nachrichtenereignissignal, und das Signal verursacht den Aufruf eines Unterbrechungsbearbeitungsmikrocodes für die Interprozessornachricht. Andererseits beginnt ein Seitenfehler mit einem Aufruf von Seitenfehlermikrocode durch LAT-Mikrocode. Die Aktionen, die vom Mikrocode unternommen werden, der beginnt, den Fehler oder die Unterbrechung zu bearbeiten, hängen davon ab, ob der Fehler oder die Unterbrechung durch den Prozeß 610 bearbeitet wird, der gerade ausgeführt wurde, als der Fehler oder das Ereignis auftrat, oder durch einen besonderen KOS-Prozeß 610.
Im ersten Fall kann der Ereignismikrocode einen Mikrocode zu Software-Aufruf zu einer Hochsprachenprozedur durchführen, die das Ereignis bearbeitet. Ein Beispiel für ein Ereignis, das auf diese Weise bearbeitet wird, ist ein Gleitkomma-Überlauf: wenn der FU 10120-Mikrocode bestimmt, daß ein Gleitkomma-Überlauf aufgetreten ist, so ruft er Mikrocode auf, der eine Gleitkomma-Überlaufprozedur aufrufen kann, die durch die Hochsprache zur Verfügung gestellt wurde, deren S-Sprache gerade ausgeführt wurde, als der Überlauf auftrat. In anderen Verkörperungen des CS 10110 kann die Überlaufprozedur auch im Mikrocode sein.
Im zweiten Fall stellt der Mikrocode, der den Fehler oder die Unterbrechung bearbeitet, Informationen in Tabellen, die durch einen KOS-Prozeß 610, der den Fehler oder die Unterbrechung bearbeitet, benutzt wird, und veranlaßt dann den KOS-Prozeß 610, zu einem späteren Zeitpunkt abzulaufen, indem er einen Ereigniszähler hochzählt, der vom Prozeß 610 erwartet wird. Ereigniszähler und die Operationen mit ihnen werden genauer in einer folgenden Beschreibung der Prozesse 610 erklärt. Da die Tabellen und Ereigniszähler, die vom Mikrocode manipuliert werden, immer in MEM 10112 vorhanden sind, verursachen diese Operationen keine Seitenfehler und können im Überwachungsmodus durchgeführt werden. Wenn z. B. IOS 10116 ein IPM-Ereignissignal zu JP 10114 überträgt, nachdem IOS 10116 Daten in MEM 10112 geladen hat, ruft das Ereignis, das aus dem Ereignissignal resultiert, Mikrocode auf, der eine Warteschlange untersucht, die Nachrichten von IOS 10116 enthält. Die Nachrichten in der Warteschlange enthalten Ereigniszählerlokationen, und der Mikrocode, der die Warteschlange untersucht, zählt diese Ereigniszähler hoch und veranlaßt dadurch, daß die Prozesse 610, die auf die von der I/O-Operation zurückgegebenen Daten gewartet haben, die Ausführung wieder beginnen.

3. Der Überwachungsmodus, differenzierte Maskierung und Hardware-Unterbrechungsbearbeitung

Der Überwachungsmodus und die differenziellen Maskierungseigenschaften der FU 10120- Mikromaschine ermöglichen eine Methode der Hardware-Unterbrechungsbearbeitung, die zwei Probleme löst, die mit der konventionellen Hardware-Unterbrechungsbearbeitung verbunden sind: eine Unterbrechung kann in einer vorhersagbaren Zeitspanne ohne Rücksicht auf die Zeitspanne, die erforderlich ist, eine SIN auszuführen, bearbeitet werden, und falls der Mikrocode, der die Unterbrechung bearbeitet, im Überwachungsmodus ausführt, kann die Unterbrechung jederzeit ohne vorhersagbare Folgen bearbeitet werden. Es gibt zwei Quellen für Hardware-Unterbrechungen in CS 10110: eine Interprozessornachricht (IPM) und ein Intervallzeitmeßgerät 25410-Ablauf. Ein IPM tritt auf, wenn IOS 10116 eine I/O-Aufgabe für JP 10114 beendet und die Beendigung der Aufgabe über den IOJP-Bus 10132 signalisiert. Ein Intervallzeitmeßgerät-Ablauf tritt auf, wenn ein vorher gesetzter Zeitpunkt, an dem CS 10110 irgendeine Aktion unternehmen muß, erreicht wird. Zum Beispiel kann ein gegebener Prozeß 610 die Zeitdauer begrenzt haben, in der er auf JP 10114 ausführen kann. Wie in einer folgenden Beschreibung der Prozeßsynchronisation erklärt wird, setzt das virtuelle Prozessormanagementsystem das Intervallzeitmeßgerät 25412 so, daß es abläuft, wenn der Prozeß 610 seine gesamte ihm zur Verfügung stehende Zeit verbraucht hat.
Sowohl IPMs als auch Intervallzeitmeßgerät-Abläufe beginnen als Ereignissignale. Die sofortige Auswirkung des Ereignissignals ist, daß ein Bit im EP-Feld 27309 von MCW1 gesetzt wird. Grundsätzlich kann das gesetzte Bit den Aufruf des Ereignismikrocodes für das Ereignis im nächsten M0-Zyklus verursachen, in dem die FU 10120-Mikromaschine im virtuellen Modus ist. Weil im Überwachungsmodus laufende Mikroprogramme sicherstellen, daß die Mikromaschine in den virtuellen Modus innerhalb einer vernünftigen Zeitspanne zurückkehrt, und die Ereignisinvokation auftritt, wenn dies passiert, ist es sichergestellt, daß das Ereignis in einer vernünftigen Zeitspanne bedient wird. Die Mikroprogramme, die von den Ereignissen aufgerufen werden, führen selbst im Überwachungsmodus aus und stellen dadurch sicher, daß keine Seitenfehler auftreten, wenn sie ausführen, und daß der Prozeß 610, der auf JP 10114 läuft, wenn die Hardware-Unterbrechung auftritt, nicht von JP 10114 entfernt werden braucht.
Während Hardware-Unterbrechungen grundsätzlich, wie oben beschrieben, bedient werden, machen es Effizienzüberlegungen erforderlich, daß möglichst viele Hardware- Unterbrechungen bedient werden, wenn die Größe des Stapelspeichers der FU-Mikromaschine minimal ist, d. h. am Beginn der Ausführung eines SINs. Dieses Erfordernis wird durch EGGTMR 25412 und das ET-Kennzeichen 27311 in MCW1 20290 erreicht. Wie oben beschrieben, wird das Feld 27317 bzw. 27313 in MCW1 20290 gesetzt, wenn eine IPM-Unterbrechung oder eine Intervallzeitmeßgerät 25410-Ablaufunterbrechung auftritt. Wenn die Ausführung des gegenwärtigen SINs beendet ist, bevor EGGTMR 25412 abläuft, veranlaßt das gesetzte Feld in MCW1 20290, daß die Ereignisinvokationen des Intervallzeitmeßgerätablaufs oder der Interprozessornachricht beim ersten Mikrobefehl des nächsten SIN auftreten. Wenn andererseits die Ausführung des gegenwärtigen SIN nicht beendet ist, bevor EGGTMR 25412 abläuft, verursacht der Eieruhr-Ablauf ein Ereignissignal. Das sofortige Ergebnis dieses Signals ist das Setzen des ET-Bits 27311 in MCW1 20290, und das Setzen des ET-Bits 27311 wiederum veranlaßt eine Ereignisinvokation des Intervallzeitmeßgerät-Ablaufs und/oder eine IPM-Ereignisinvokation beim nächsten M0- Zyklus stattfindet, während die Mikromaschine sich im virtuellen Modus befindet. Der obige Mechanismus stellt dadurch sicher, daß die meisten Hardware-Unterbrechungen am Beginn eines SIN bearbeitet werden, aber diese Hardware-Unterbrechungen werden immer innerhalb einer bestimmten Zeitspanne bearbeitet, unabhängig von der Zeitspanne, die dazu benötigt wird, eine SIN auszuführen.

g. FU-Mikromaschine und CS 10110-Untersysteme

Die Untersysteme von CS 10110, wie das Objekt-Untersystem, das Prozeß-Untersystem, das S-Interpreter-Untersystem und das Namensinterpreter-Untersystem werden alle oder teilweise in der Mikromaschine implementiert. Die Beschreibung der Mikromaschine schließt deshalb mit einem Überblick über die Beziehungen zwischen diesen Untersystemen und der Mikromaschine. Oben wurden genaue Beschreibungen des Betriebs der Untersysteme vorgestellt.
Die Untersysteme lassen sich in drei Hauptgruppen aufteilen: Die KOS-Untersysteme, das Namensinterpreter-Untersystem und das S-Interpreter-Untersystem. Die Beziehung zwischen diesen dreien ist zu einem gewissen Grad hierarchisch: die KOS-Untersysteme stellen die von dem Namensinterpreter-Untersystem benötigte Umgebung zur Verfügung, und das Namensinterpreter-Untersystem stellt die vom S-Interpreter-Untersystem benötigte Umgebung zur Verfügung. Zum Beispiel interpretiert das S-Interpreter-Untersystem SINs, die aus SOPs und Namen bestehen; das Namensinterpreter-Untersystem übersetzt die Namen in logische Beschreiber, indem es Werte benutzt, die ABPs genannt werden, um die in den logischen Beschreibern sich befindenden Lokationen zu berechnen. Die KOS- Untersysteme berechnen die Werte der ABPs, übersetzen logische Beschreiber 27116 in physikalische MEM 10112-Adressen und überprüfen, ob ein Prozeß 610 Zugangsrechte auf ein Objekt besitzt, das er referenziert.
In einer gegenwärtigen Verkörperung von CS 10110 sind das Namensinterpreter-Subsystem und das S-Interpreter-Subsystem beide vollständig in der Mikromaschine implementiert; in anderen Verkörperungen könnten sie in Hochsprachen oder in Hardware implementiert sein. Die KOS-Untersysteme sind sowohl in der Mikromaschine als auch in Hochsprachenprogrammen implementiert. In anderen Verkörperungen des CS 10110 können die KOS-Untersysteme vollständig im Mikrocode oder in Hochsprachenprogrammen verkörpert sein. Bestimmte Hochsprachenprogramme können in jedem beliebigen Prozeß 610 ausführen, während andere nur durch besondere KOS-Prozesse 610 ausgeführt werden können. Die KOS-Untersysteme unterscheiden sich auch von anderen in der Weise, in der ein Benutzer Zugang hat: das S-Interpreter-Untersystem und das Namensinterpreter-Untersystem greifen beide nur ins Geschehen ein, wenn SINs ausgeführt werden; die Untersysteme sind nicht direkt dem Benutzer des Systems sichtbar. Bereiche des KOS-Untersystems können andererseits explizit in Hochsprachenprogrammen aufgerufen werden. Zum Beispiel kann ein Aufruf in einem Hochsprachenprogramm KOS dazu veranlassen, einen Prozeß 610 an einen virtuellen Prozessor 612 zu binden.
Das folgende listet zunächst die von den Untersystemen durchgeführten Funktionen auf und setzt dann die Untersysteme in Beziehung zum Überwachungs- und virtuellen Mikromaschinenmodus und spezifischen Mikromaschinengeräten. Die KOS-Untersysteme führen folgende Funktionen durch:
- Virtuelles Speichermanagement;
- Virtuelles Prozessormanagement;
- Interprozessor-Kommunikation;
- Zugangskontrolle;
- Objektmanagement; und
- Prozeßmanagement.
Der Namensinterpreter führt folgende Funktionen durch:
- Holen und Analysieren von SOPs und
- das Interpretieren von Namen.
Der S-Interpreter schließlich teilt die SOPs auf, d. h. er lokalisiert den FU 10120- und EU 10122-Mikrocode, der die Operation ausführt, die einem gegebenen SOP für eine gegebene S-Sprache entspricht.
Von diesen Untersystemen führen der S-Interpreter, der Namensinterpreter und die Mikrocode-Komponenten der Untersysteme des KOS-Prozeß- und Objektmanagers auf der virtuellen Mikromaschine aus; die Mikrocode-Komponenten der verbleibenden KOS- Untersysteme führen in der Überwachungsmikromaschine aus. Wie bei der Besprechung dieser Untersysteme erkannt werden wird, können Untersysteme, die auf der virtuellen Mikromaschine ausführen, Seitenfehler verursachen, und können daher Daten referenzieren, die irgendwo im Speicher liegen können; Untersysteme, die in der Überwachungsmikromaschine ausführen, dürfen keine Seitenfehler verursachen, und die Datenbasen, die diese Untersysteme manipulieren, müssen daher immer an bekannten Lokationen in MEM 10112 vorhanden sein.
Die Beziehung zwischen Untersystemen und den FFU 10120-Mikromaschinengeräten ist folgende: Mikrocode für alle Untersysteme benutzt DESP 20210, die Mikrocodeadressierung 27013 und die Registeradressierung 27011, und kann die EU-Schnittstelle 27007 benutzen. Der S-Interpreter-Mikrocode benutzt den SOP-Dekodierer 27003, und der Namensinterpreter-Mikrocode benutzt den Befehlsstromleser 27001, die Analyseeinheit 27005 und die Namensübersetzungseinheit 27015. Der KOS-Mikrocode für das virtuelle Speichermanagement benutzt die Speicherreferenzeneinheit 27017, und der Schutzmikrocode benutzt die Schutzeinheit 27019.
Nachdem die Struktur und der Betrieb der wichtigsten Untersysteme von CS 10110, MEM 10112, FU 10120, EU 10122, IOS 10116 und DP 10118 und die CS 10110-Mikromaschine genau beschrieben wurden, wird der CS 10110-Betrieb als nächstes genauer beschrieben. Zuerst wird der Betrieb des CS 10110-Namensraum-, S-Interpreter- und Zeigersystems beschrieben. Darauf wird der Betrieb von CS 10110 noch genauer hinsichtlich des CS 10110-Kernbetriebssystems beschrieben.

3. Adreßraum S-Interpreter und Zeiger (Fig. 301 bis 307, 274)

Die vorangegangenen Kapitel haben einen Überblick über CS 10110 dargestellt, seine Hardware im Detail untersucht und erklärt, wie die FU 10120-Hardware als eine Mikromaschine funktioniert, die die Aktivitäten anderer CS 10110-Komponenten steuert. In den verbleibenden Bereichen der Spezifikation werden die Mittel vorgestellt, durch die bestimmte Schlüsselmerkmale von CS 10110 implementiert werden, die die Hardware, die Mikromaschine, Tabellen im Speicher und Hochsprachenprogramme benutzen. Das gegenwärtige Kapitel stellt drei dieser Merkmale vor: das Zeigerauflösungssystem, den Adreßraum und die S-Interpreter.
Das Zeigerauflösungssystem übersetzt Zeiger, d. h. Datenausdrücke, die Lokationsinformationen beinhalten, in UID-Abstandsadressen. Der Adreßraum hat drei Hauptfunktionen:
- Er lokalisiert die SINs und holt sie vom CS 10110-Speicher in FU 10120.
- Er analysiert die SINs in die SOPs und Namen.
- Er übersetzt Namen in logische Beschreiber 27116 oder Werte.
Die S-Interpreter dekodieren S-Operationen, die vom Adreßraum empfangen werden, in Lokationen im Mikrocode, der in FUSITT 11012 und EUSITT 20344 enthalten ist, und führen dann diesen Mikrocode aus. Falls die S-Operationen Operanden benötigen, benutzen die S-Interpreter den Adreßraum, um die Operanden in logische Beschreiber 27116 oder in Werte zu übersetzen, wie es von den Operationen verlangt wird.
Da der Adreßraum vom Zeigerauflösungssystem abhängt, und die S-Interpreter vom Adreßraum abhängen, beginnt die Diskussion der Systeme mit den Zeigern und beschäftigt sich dann mit dem Adreßraum und den S-Interpretern.

A. Zeiger und Zeigerauflösung (Fig. 301, 302)

Ein Zeiger ist ein Datenausdruck, der eine Adresse repräsentiert, d. h. in CS 10110 eine UID-Abstandsadresse. CS 10110 hat zwei große Zeigerklassen: aufgelöste Zeiger und nicht aufgelöste Zeiger. Aufgelöste Zeiger sind Zeiger, deren Werte sofort als UID- Abstandsadressen interpretiert werden können; nicht aufgelöste Zeiger sind Zeiger, deren Werte durch Hochsprachenprogramme oder Mikrocodeprogramme interpretiert werden müssen, damit sich UID-Abstandsadressen ergeben. Die Handlung, einen nicht aufgelösten Zeiger zu interpretieren, wird Auflösung genannt. Da die Art und Weise, in der nicht aufgelöste Zeiger aufgelöst werden, durch ein von einem Systembenutzer geschriebenes Hochsprachenprogramm bestimmt werden kann, stellen nicht aufgelöste Zeiger ein Mittel dar, durch das die Systembenutzer eigene Zeigertypen definieren können.
Sowohl aufgelöste als auch nicht aufgelöste Zeiger haben Unterklassen. Die Unterklassen der aufgelösten Zeiger sind UID-Zeiger und auf Objekte bezogene Zeiger. UID-Zeiger beinhalten eine UID und einen Abstand, und können daher jede beliebige CS 10110- Adresse repräsentieren; objektbezogene Zeiger beinhalten nur einen Abstand; die UID der Adresse wird als dieselbe angenommen wie die des Objektes, das den objektbezogenen Zeiger beinhaltet. Ein objektbezogener Zeiger kann daher nur Adressen in dem Objekt darstellen, das den Zeiger enthält.
Die Unterklassen der nicht aufgelösten Zeiger sind einfache nicht aufgelöste Zeiger und assoziative Zeiger. Der Unterschied zwischen beiden Arten von nicht aufgelösten Zeigern ist die Art und Weise, in der sie aufgelöst werden. Einfache nicht aufgelöste Zeiger werden immer durch Hochsprachenprogramme aufgelöst, während assoziative Zeiger beim ersten Mal, wenn sie benutzt werden, in einen Prozeß 610 und einen Bereich durch Hochsprachenprogramme aufgelöst werden, aber nachfolgend mit Hilfe einer Tabelle aufgelöst werden, die "assoziierte Adressentabelle" (AAT) genannt wird. Diese Tabelle ist für Mikrocode zugänglich und assoziative Zeiger können daher schneller aufgelöst werden als einfache nicht aufgelöste Zeiger.
Die folgende Diskussion erklärt zuerst die von allen CS 10110 benutzten Formate und erklärt danach, wie Zeiger in FU 10120 verarbeitet werden.

a. Zeigerformate (Fig. 301)

Fig. 301 stellt einen CS 10110-Zeiger dar. Die Fig. hat zwei Teile: eine Darstellung des allgemeinen Zeigerformats 30101, der einen Überblick über die Felder gibt, die in allen CS 10110-Zeigern erscheinen, und eine detaillierte Darstellung des Kennzeichen- und Formatfeldes 30105, die die Informationen enthalten, durch die die Arten der CS 10110- Zeiger unterschieden werden können.
Indem wir uns zunächst dem allgemeinen Zeigerformat 30101 zuwenden, enthalten alle CS 10110-Zeiger 128 Bits und werden in drei Hauptfelder unterteilt:
- Das Abstandsfeld 30103 enthält den Abstandsbereich einer UID-Abstandsadresse in aufgelösten Zeigern und in assoziativen Zeigern; bei anderen nicht aufgelösten Zeigern kann es einen Abstand von einem Punkt in einem Objekt enthalten, oder eine andere Information, die vom Benutzer definiert wurde.
- Das Kennzeichen- und Formatfeld 30105 enthält Kennzeichen- und Formatcodes, die die verschiedenen Arten der Zeiger unterscheiden. Diese Kennzeichen- und Formatcodes werden im folgenden genauer erklärt.
- Das UID-Feld 30115 enthält eine UID bei UID-Zeigern und in manchen assoziativen Zeigern; bei objektbezogenen Zeigern und anderen assoziativen Zeigern ist seine Bedeutung undefiniert, und bei einfachen nicht aufgelösten Zeigern kann es vom Benutzer definierte Informationen beinhalten.
Das Kennzeichen- und Formatfeld 30105 enthält vier Unterfelder:
- Die Felder 30107 und 30111 sind reserviert und müssen auf 0 gesetzt werden.
- Das NR-Feld 30109 zeigt an, ob ein Zeiger aufgelöst oder nicht aufgelöst ist. Bei aufgelösten Zeigern wird das Feld auf 0 gesetzt, und bei nicht aufgelösten Feldern wird es auf 1 gesetzt.
- Das Formatcodefeld 30113 zeigt die Art der aufgelösten oder nicht aufgelösten Zeiger an. Die Formatcodes für die vorliegende Verkörperung werden unten erklärt.
Die Werte des Formatcodefelds 30113 können im Bereich von 0 bis 31 variieren. Wenn das Formatcodefeld 30113 den Wert 0 besitzt, ist der Zeiger ein Nullzeiger, d. h. ein Zeiger, der weder direkt noch indirekt eine Adresse anzeigt. Die Bedeutungen der anderen Formatcodes hängen vom Wert des NR-Feldes 30109 ab: NR-Feld-Wert Formatcode-Wert Bedeutung UID-Zeiger Objektbezogener Zeiger alle anderen Codes illegal UID-assoziativer Zeiger Objektbezogener, assoziativer Zeiger einfache nicht aufgelöste Zeiger
Wie in der obigen Tabelle angezeigt, hat die gegenwärtige Verkörperung zwei Arten von assoziativen Zeigern, die UID-assoziativen Zeiger und die objektbezogenen assoziativen Zeiger. Ein UID-assoziativer Zeiger enthält wie ein UID-Zeiger eine UID und einen Abstand, und wie ein objektbezogener Zeiger, enthält ein objektbezogener assoziativer Zeiger einen Abstand und nimmt den Wert der UID von dem Objekt, zu dem er gehört. Jedoch werden, wie später genauer beschrieben wird, die UID und der Abstand, den die assoziativen Zeiger enthalten oder repräsentieren, nicht als Adressen benutzt. Statt dessen werden die UID und der Abstand als Kennzeichen benutzt, um Eingänge im AAT zu lokalisieren, das einen assoziativen Zeiger mit einem aufgelösten Zeiger in Verbindung bringt.

b. Zeiger in FU 10120 (Fig. 302)

Wenn ein Zeiger als Adresse in FU 10120 benutzt wird, muß die Adreßinformation im Zeiger in einen logischen Beschreiber 27116 übersetzt werden, der aus einem AON-Feld, einem Abstandsfeld und einem Längenfeld von 0 besteht; wenn ein logischer Beschreiber 27116 in FU 10120 dazu benutzt wird, einen Zeigerwert im Speicher zu bilden, muß die AON in eine UID zurückverwandelt werden. Die erste Umwandlung wird eine Zeiger nach Beschreiber-Umwandlung genannt, und die zweite eine Beschreiber nach Zeiger- Umwandlung. Beide Umwandlungen werden durch in FU 10120 ausgeführte Mikrocodes durchgeführt.
Es hängt von der Art des Zeigers ab, was alles bei der Übersetzung involviert ist: Wenn der Zeiger ein UID-Zeiger ist, muß die UID in eine AON übersetzt werden; wenn der Zeiger ein objektbezogener Zeiger ist, ist die zum Holen des Zeigers benötigte AON die AON des Zeigers und von daher ist keine Übersetzung notwendig. Wenn der Zeiger ein nicht aufgelöster Zeiger ist, muß er zuerst in einen aufgelösten Zeiger und dann in einen logischen Beschreiber 27116 übersetzt werden. Wenn der Zeiger assoziativ ist, kann die Übersetzung in einen aufgelösten Zeiger durch ATT durchgeführt werden.
Wenn in der vorliegenden Verkörperung ein anderer FU 10120-Mikrocode einen Zeiger nach Beschreiber-Mikrocode aufruft, übergibt der rufende Mikrocode den logischen Beschreiber 27116 für die Lokation des Zeigers, der übersetzt werden soll, als ein Argument an den Mikrocode für die Übersetzung Zeiger nach Beschreiber. Der Zeiger nach Beschreiber-Mikrocode gibt einen logischen Beschreiber 27116 zurück, der aus dem Wert des Zeigers an der Lokation erzeugt wurde, die durch den logischen Beschreiber 27116 spezifiziert wurde, den der Zeiger nach Beschreiber-'Mikrocode als Argument empfangen hat.
Der Zeiger nach Beschreiber-Mikrocode benutzt erst den logischen Beschreiber 27116, der ihm als Argument übergeben wurde, den Wert des Abstandsfeldes 30103 vom Speicher zu holen. Er speichert dann den Abstand des logischen Beschreibers 27116 in dem zu OFFALU 20242 gehörenden Ausgaberegister und plaziert den Wert des Abstandsfeldes 30103 des Zeigers im Abstandsfeld des logischen Beschreibers 27116, den er als Argument empfangen hat. Der Zeiger nach Beschreiber-Mikrocode speichert dann den logischen Beschreiber 27116, der die Lokation des Zeigers anzeigt, indem er die AON und den Abstand (von OFFALU 20242 erhalten) des logischen Beschreibers 27116 in einem Register im GRF 10350-Rahmen speichert, der vom Aufruf des Zeiger nach Beschreiber-Mikrocodes benutzt wird. Als nächstes addiert der Mikrocode 40 zu dem in OFFALU 20242 gespeicherten Abstand, und erhält dadurch die Adresse des NR-Feldes 30109, und benutzt diese Adresse, das NR-Feld 30109 und das Formatcodefeld 30113 zu holen und zu lesen. Der Verlauf der weiteren Verarbeitung wird durch die Werte dieser Felder bestimmt. Wenn das NR-Feld 30109 einen aufgelösten Zeiger anzeigt, gibt es vier Fälle, wie sie durch den Wert des Formatcodefeldes 30113 bestimmt werden:
- Formatcodefeld = 0: Der Zeiger ist ein Nullzeiger.
- Formatcodefeld = 1: Der Zeiger ist ein UID-Zeiger.
- Formatcodefeld = 2: Der Zeiger ist ein Zwischenobjektzeiger.
- Irgendein anderer Wert des Formatcodefeldes: Der Zeiger ist ungültig.
Im ersten Fall setzt der Mikrocode alle Felder des Argumentes auf 0; im zweiten holt er den Wert des UID-Feldes 30115 vom Speicher und ruft LAR-Mikrocode (bei der Diskussion von Objekten erklärt) auf, der die UID in die damit verbundene AON übersetzt. Die AON wird dann in das AON-Feld des Arguments geladen. Im dritten Fall stimmen die AONs des logischen Beschreibers 27116 für die Lokation des Zeigers und die AON des Zeigers überein, daher enthält das Argument bereits den übersetzten Zeiger. Im vierten Fall führt der Mikrocode einen Aufruf einer Zeigerfehler bearbeitenden Prozedur 602 aus, die ungültige Zeigerfehler bearbeitet, indem er den gespeicherten logischen Beschreiber 27116 für den Zeiger als Argument übergibt. Die Prozedur 602, die den Fehler verarbeitet, muß einen aufgelösten Zeiger an den Mikrocode zurückgeben, der ihn dann in einen logischen Beschreiber 27116, wie oben beschrieben, konvertiert.

c. Beschreiber nach Zeiger-Umwandlung

Die Beschreiber nach Zeiger-Umwandlung ist das Gegenteil der Zeiger nach Beschreiber- Umwandlung mit aufgelösten Zeigern. Die Operation muß immer dann durchgeführt werden, wenn ein aufgelöster Zeiger von einem FU 10120-Register in MEM 10112 geschoben wird. Die Operation braucht zwei Argumente: einen logischen Beschreiber 27116, der die Adresse spezifiziert, an die der Zeiger geschrieben werden soll, und einen logischen Beschreiber 27116, dessen AON- und Abstandsfeld die im Zeiger enthaltene Lokation spezifizieren. Es gibt zwei Fälle: Zwischenobjektzeiger und UID-Zeiger. Beide Zeigerarten haben Werte im Abstandsfeld 30103, daher schreibt der Beschreiber nach Zeiger-Mikrocode zuerst den Abstand des zweiten Arguments an die durch den logischen Beschreiber 27116 des ersten Arguments spezifizierte Stelle. Der nächste Schritt ist zu bestimmen, ob der Zeiger ein Zwischenobjektzeiger oder ein UID-Zeiger ist. Dafür vergleicht der Mikrocode die AONs der Argumente. Wenn sie dieselben sind, zeigt der Zeiger auf eine Lokation in dem Objekt, das ihn enthält, und ist daher ein Innerobjektzeiger. Da das UID-Feld 30115 eines Innerobjektzeigers bedeutungslos ist, verbleibt als einzig durchzuführender Schritt für Innerobjektzeiger, die Kennzeichen und das Formatfeld 30105 auf die Binärdarstellung von 2 zu setzen, das alle Bits außer Bit 46 auf 0 setzt, und daher den Zeiger als einen aufgelösten Innerobjektzeiger identifiziert.
Bei UID-Zeigern setzt der Beschreiber nach Zeiger-Mikrocode die Kennzeichen und das Formatfeld 30105 auf 1, identifiziert damit den Zeiger als einen aufgelösten UID-Zeiger und ruft ein KOS LAR-Mikroprogramm auf (bei der Diskussion von Objekten genauer erklärt), das die AON des ersten Arguments in eine UID umwandelt, und plaziert die sich ergebende UID in den gegenwärtigen Rahmen. Wenn das Mikroprogramm zur Umwandlung von KOS AON in UID zurückkehrt, schreibt der Beschreiber nach Zeiger- Mikrocode die UID in das UID-Feld 30115 des umgewandelten Zeigers.

B. Adreßraum und die S-Interpreter (Fig. 303 bis 307)

Der Adreßraum und die S-Interpreter interpretieren beide die in den Prozedurobjekten 608 enthaltenen Informationen. Konsequenterweise beginnt die Diskussion dieser Komponenten von CS 10110 mit einem Überblick über jene Teile des Prozedurobjekts 606, die für den Adreßraum und die S-Interpreter relevant sind, und erklärt darauf den Adreßraum und die S-Interpreter genauer.

a. Überblick über Prozedurobjekt 606 (Fig. 303)

Fig. 303 stellt jene Bereiche des Prozedurobjekts 608 dar. Fig. 303 dehnt die in Fig. 103 enthaltene Information aus; Felder, die in beiden Figuren vorkommen, haben die Nummern von Fig. 103. Bereiche des Prozedurobjekts 608, die hier nicht besprochen werden, werden später bei der Diskussion der Aufrufe und der Rückkehr behandelt. Der wichtigste Teil eines Prozedurobjekts 608 für diese Systeme ist der Prozedurenumgebungsbeschreiber (PED) 30303. Der PED 30303 einer Prozedur 602 enthält die vom Adreßraum und den S- Interpretern benötigten Informationen, um den Code von Prozedur 602 zu lokalisieren und zu analysieren und ihre Namen zu interpretieren. Es können mehrere Prozeduren 602 in einem Prozedurobjekt 608 einen PED 30303 teilen. Wie bei der Diskussion der Aufrufe noch klar werden wird, beeinflußt die Tatsache, daß eine Prozedur 602 einen PED 30303 mit der Prozedur 602, die sie aufruft, teilt, die Weise, in der der Aufruf ausgeführt wird.
Die Felder von PED 30303, die für die vorliegende Diskussion wichtig sind, sind drei Felder im Kopf 30304: Das K-Feld 30305, das LN-Feld 30307 und das SIP-Feld 30309, und drei der verbleibenden Felder: das NTP-Feld 30311, das SDPP-Feld 30313 und das PBP-Feld 30315.
- Das K-Feld 30305 zeigt an, ob die Namen in den SINs der Prozeduren 602, die PED 30303 teilen, 8, 12 oder 16 Bits besitzen.
- Das LN-Feld 30307 enthält den Namen mit dem größten Index in der Namenstabelle 10350 der Prozedur 602.
- Das SIP-Feld 30309 ist ein UID-Zeiger auf das Objekt, das den S-Interpreter für die S-Sprache der Prozedur 602 enthält.
- Das NTP-Feld 30311 ist ein objektbezogener Zeiger auf den Anfang der Namenstabelle 10350 der Prozedur 602.
- Das SDPP-Feld 30313 ist ein Zeiger, der in die Lokation von statischen Daten aufgelöst wird, die von den Prozeduren 602, zu denen PED 30303 gehört, benutzt werden, wenn eine der Prozeduren 602 durch einen gegebenen Prozeß 610 aufgerufen wird. Der SDPP entsprechende aufgelöste Zeiger ist der SDP ABP.
- Das PBP-Feld 30315 enthält den PBP ABP für Aufrufe von Prozeduren 602, zu denen PED 30303 gehört. Der PBP ABP wird dazu benutzt, Lokationen innerhalb des Prozedurobjekts 608 zu berechnen.
Andere Interessengebiete im Prozedurobjekt 608 sind die Literale 30301 und der statische Datenprototyp (SDPR) 30317. Die Literale 30301 enthalten Literalwerte, d. h. Werte in Prozedur 602, die zur Kompilierzeit bekannt sind, und die sich während der Programmausführung nicht verändern. SDPR 30317 kann folgendes enthalten: Zeiger auf externe Programme und auf statische Daten, die in anderen Objekten enthalten sind, die für die Kreierung von statischen Daten für eine Prozedur 602 erforderlichen Informationen, und in manchen Fällen die statischen Daten selbst. Die Zeiger in SDPR 30317 können entweder aufgelöst oder nicht aufgelöst sein.
In der vorliegenden Verkörperung ist die Programmverknüpferfläche 30323 auch von Bedeutung. Die Programmverknüpferfläche 30323 enthält Informationen, die es ermöglichen, die in Prozedurobjekt 608 enthaltenen nicht aufgelösten Zeiger aufzulösen. Andere nicht aufgelöste Zeiger als SDPP 30313 im Prozedurobjekt 608 enthalten sämtlich Lokationen in der Programmverknüpferfläche 30323, und die spezifizierte Lokation enthält die benötigte Information, um den Zeiger aufzulösen.
Fig. 303 enthält Pfeile, die die Lokationen in Prozedurobjekt 608 zeigen, auf die vom NTP-Feld 30311, dem SDPP-Feld 30313 und dem PBP-Feld 30315 gezeigt wird. Das NTP-Feld 30311 zeigt auf den Anfang der Namenstabellen 10350, und daher kann der Namenstabelleneingang eines Namens lokalisiert werden, indem der Wert des Namens zum NTP-Feld 30311 dazu addiert wird. Das PBP-Feld 30315 zeigt auf den Anfang der Literale 30301, und dementsprechend können die Lokationen der Literale und die Lokationen der SINs als Abstände vom Wert des PBP-Feldes 30315 ausgedrückt werden. Das SDPP-Feld 30313 zeigt auf den Anfang von SDPR 30317. Wie bei der Diskussion der Aufrufe noch genauer erklärt wird, wird SDP ABP, wenn eine Prozedur 602 statische Daten hat, vom SDPP-Feld 30313 abgeleitet.

b. Adreßraum

Die Adreßraumkomponente von CS 10110 lokalisiert die SINs, die zu einer Prozedur gehören, und holt sie vom Speicher nach FU 10120, analysiert die SINs in SOPs und Namen, und führt Auflösungs- und Auswerteoperationen mit Namen durch. Die Auflöseoperation übersetzt einen Namen in einen logischen Beschreiber 27116 für die durch den Namen repräsentierten Daten, während die Auswerteoperation die Daten selbst erhält. Die Auswerteoperation führt dies durch, indem sie eine Auflöseoperation durchführt, und dann den resultierenden logischen Beschreiber 27116 benutzt, um die Daten zu holen. Da die Auswerte- und Auflöseoperationen die kompliziertesten sind, beginnt die Diskussion mit ihnen.

1. Namensauflösung und -auswertung

Die Namensauflösung und -auswertung übersetzt Namen in logische Beschreiber 27116 mit Hilfe von in den NTEs der Namen enthaltenen Informationen, und die NTEs definieren Lokationen in Form von architektonischen Basisregistern. Daher beschreibt die folgende Diskussion zuerst die Namenstabelleneingänge und architektonischen Basiszeiger und dann die Mittel, durch die der Adreßraum die in den Namenstabelleneingängen und architektonischen Basiszeigern enthaltenen Information in logische Beschreiber 27116 übersetzt.

2. Die Namenstabelle (Fig. 304)

Wie oben erwähnt, sind die Namenstabellen 10350 in Prozedurobjekten 608 enthalten. Die Namenstabellen 10350 enthalten die benötigte Information, um Namen in logische Beschreiber 27116 für die Operanden, die durch diese Namen repräsentiert werden, zu übersetzen. Jeder Name hat als seinen Wert die Nummer eines Namenstabelleneintrags. Der Namenstabelleneintrag eines Namens wird lokalisiert, indem man den Wert des Namens mit der Größe eines kurzen Namenstabelleneintrags multipliziert und das Produkt zu dem Wert im NTP-Feld 30311 des PED 30303 addiert, das zur Prozedur 602 gehört, die den SIN enthält.
Der Namenstabelleneintrag enthält Information über die Länge und den Typ des Datenausdrucks, der durch den Namen spezifiziert wird, und stellt die Lokation des Datenausdrucks als Entfernung von einer bekannten Lokation, die Basis genannt wird, dar. Die Basis kann eine Lokation sein, die durch ein ABP, durch einen anderen Namen oder einen Zeiger spezifiziert wird. Im letzten Fall kann die Lokation des Zeigers als ABP oder als Name spezifiziert werden.
Fig. 304 ist eine genaue Darstellung eines Namenstabelleneintrags (NTE) 30401. Es gibt zwei Arten von NTEs 30401: kurze NTEs 30403 und lange NTEs 30405. Kurze NTEs 30403 enthalten 64 Bits; lange NTEs 30405 enthalten 128 Bits. Namen, die Scalar- Datenausdrücke repräsentieren, deren Entfernungen mit 16 Bits ausgedrückt werden kann, haben kurze NTEs 30403; Namen, die Scalar-Datenausdrücke repräsentieren, deren Entfernungen mehr als 16 Bits erfordern, und Namen, die Vektorelemente repräsentieren, haben lange NTEs 30405.
Ein kurzes NTE 30403 hat vier Hauptfelder, von denen jedes 16 Bits lang ist:
- Das Kennzeichen- und Formatfeld 30407 enthält Kennzeichen und Formatinformationen, die spezifizieren, wie der Adreßraum NTE 30401 interpretieren soll.
- Das Basisfeld 30425 zeigt die Basis an, zu der die Entfernung addiert werden muß, um die Lokation der durch den Namen repräsentierten Daten zu erhalten. Das Basisfeld 30425 kann die Lokation auf vier Arten darstellen: durch einen ABP, durch einen Namen, durch einen Zeiger, der durch einen ABP lokalisiert wird, und durch einen Zeiger, der durch einen Namen lokalisiert wird.
- Das Längenfeld 30435 stellt die Länge der Daten dar. Die Länge kann ein literaler Wert oder ein Name sein. Wenn es ein Name ist, kann der Name in eine Lokation aufgelöst werden, die die Länge des Datenausdrucks enthält.
- Das Entfernungsfeld 30437 enthält die Entfernung vom Anfang der Daten von der Basis, die durch das Feld 30425 spezifiziert wurde. Die Entfernung ist ein vorzeichenbehafteter ganzzahliger Wert.
Lange NTEs 30405 haben vier zusätzliche Felder, von denen jedes 16 Bits lang ist: zwei der Felder, das Indexnamensfeld 30441 und das IES-Feld 30445, werden nur in NTEs 30401 für Namen benutzt, die Vektoren darstellen.
- Das Entfernungs-Ausdehnungsfeld 30439 wird bei allen langen NTEs 30405 benutzt. Wenn der Wert der Entfernung im Feld 30437 kleiner ist als 16 Bits, so enthält das Entfernungs-Ausdehnungsfeld 30439 Vorzeichenbits, d. h. die Bits im Feld werden auf 0 gesetzt, wenn die Entfernung positiv ist, und auf 1, wenn die Entfernung negativ ist. Wenn der Entfernungswert mehr als 16 Bits hat, enthält das Entfernungs-Ausdehnungsfeld 30439 sowohl die signifikantesten Bits des Entfernungswertes als auch Vorzeichenbits.
- Das Indexnamenfeld 30441 enthält einen Namen, der einen Wert repräsentiert, der dazu benutzt wird, ein Element eines Vektors zu indizieren.
- Das Feld 30443 ist reserviert.
- Das IES-Feld 30445 enthält einen Namen oder Literal, das die Größe eines Elementes in einem Vektor spezifiziert. Der Wert, der durch dieses Feld dargestellt wird, wird zusammen mit dem durch das Indexnamenfeld 30441 dargestellten Namen dazu benutzt, ein Element eines Vektors zu lokalisieren.
Wie aus Obigem ersichtlich wird, können die folgenden Felder Namen enthalten: das Basisfeld 30425, das Längenfeld 30435, das Indexnamenfeld 30441 und das IES-Feld 30445.
Zwei Felder in NTE 30401 erfordern eine weitere Betrachtung: das Kennzeichen- und Formatfeld 30407 und das Basisfeld 30425. Das Kennzeichen- und Formatfeld 30407 hat drei Unterfelder: das Kennzeichenfeld 30408, das FM-Feld 30421 und das Typenfeld 30423. Indem wir uns zuerst dem Kennzeichenfeld 30408 zuwenden, so zeigen die sechs Kennzeichen im Feld an, wie der Adreßraum NTE 30401 interpretieren soll. Wenn die Kennzeichen gesetzt sind, haben sie folgende Bedeutungen:
- Das lange NTE-Kennzeichen 30409: NTE 30401 ist ein langes NTE 30405.
- Die Länge ist ein Namenskennzeichen 30411: das Längenfeld 30435 enthält einen Namen.
- Basis ist ein Namenskennzeichen 30413: das Basisfeld 30425 enthält einen Namen anstatt der Nummer eines ABP.
- Indirektes Basiskennzeichen 30415: das Basisfeld 30425 repräsentiert einen Zeiger, und die durch NTE 30401 dargestellte Lokation muß berechnet werden, indem man den Wert des Zeigers nimmt und den im Entfernungsfeld 30437 enthaltenen Wert und das Entfernungs-Ausdehnungsfeld 30439 zum Abstand des Zeigers dazu addiert.
- Das Vektorkennzeichen 30417: NTE 30401 stellt einen Vektor dar.
- IES ist ein Namenskennzeichen 30419: das IES-Feld 30445 enthält einen Namen, der einen IES-Wert repräsentiert.
Mehrere dieser Kennzeichen können in einem gegebenen NTE 30401 gesetzt werden. Zum Beispiel würde ein Eintrag für ein Vektorelement, das über einen Zeiger auf den Vektor referenziert wurde, der wiederum durch einen Namen repräsentiert wurde und dessen IES- Wert durch einen Namen repräsentiert wurde, die Kennzeichen 30409, 30413, 30415, 30417 und 30419 gesetzt haben.
Das FM-Feld 30421 zeigt an, wie die durch den Namen repräsentierten Daten formatiert werden müssen, wenn sie aus dem Speicher geholt werden. Der Wert des FM-Feldes 30421 ist im FIU-Feld 27107 des logischen Beschreibers 27116 plaziert, das von NTE 30401 erzeugt wurde. Die zwei Bits erlauben vier Möglichkeiten:
Einstellung Bedeutung 00 rechts ausrichten, mit Nullen auffüllen
01 rechts ausrichten, mit Vorzeichen auffüllen
10 links ausrichten, mit Nullen auffüllen
11 links ausrichten, mit ASCII-Leerzeichen auffüllen
Die vier Bits im Typenfeld 30423 werden von den Compilern für sprachenspezifische Typeninformation benötigt. Der Wert des Typenfeldes 30423 wird in das Typenfeld 27109 des logischen Beschreibers 27116 plaziert, der von NTE 30401 erzeugt wurde.
Im Basisfeld 30425 kann es entweder sein, daß die Basis ein ABP-Format 30427 ist, oder daß die Basis ein Namensformat 30432 ist. Die Art und Weise, in der das Basisfeld 30425 interpretiert wird, hängt davon ab, ob die Einstellung der Basis ein Namenskennzeichen 30413 oder ein indirektes Basiskennzeichen 30415 ist. Es gibt vier Möglichkeiten: Feldeinstellung Bedeutung Basis ist ein Name Indirekte Basis Das ABP-Format lokalisiert die Basis direkt. Das ABP-Format lokalisiert einen Zeiger, der die Basis ist. Die Basis ist ein Name. Das Format lokalisiert die Basis, wenn der Name aufgelöst wird. Die Basis ist ein. Das Format lokalisiert einen Zeiger, wenn der Name aufgelöst wird, und der Zeiger ist die Basis.
Wie in der obigen Tabelle angedeutet, wird das Basisfeld 30425 so interpretiert, daß die Basis ein ABP-Format 30427 ist, wenn das Kennzeichen 30411 Basis ist ein Name nicht gesetzt ist. Wenn die Basis ein ABP-Format 30427 ist, hat das Basisfeld 30425 zwei Unterfelder: das ABP-Feld 30429 und das Zeigerlokalisiererfeld 30431. Das letzte Feld hat nur dann eine Bedeutung, wenn das indirekte Basiskennzeichen 30415 gesetzt ist. Das ABP-Feld 30429 ist ein zwei Bit-Code, der den ABP anzeigt. Die Einstellungen und ihre Bedeutung sind folgende:
Einstellungen ABP 00 FP
01 nicht gebraucht
10 SDP
11 PBP
Die ABPs werden unten diskutiert. Wenn das indirekte Basiskennzeichen 30415 auf 1 gesetzt ist, und das Kennzeichen 30413 Basis ist ein Name auf 0 gesetzt ist, so werden die verbleibenden 14 Bits des Basisfeldes im ABP-Format als Zeigerlokalisiererfeld 30413 interpretiert. Wenn es so interpretiert wird, enthält das Zeigerlokalisiererfeld 30413 einen vorzeichenbehafteten Ganzzahlwert, der, nachdem er mit 128 multipliziert wurde, die Entfernung eines Zeigers von dem im ABP-Feld 30429 spezifizierten ABP ergibt. Der Wert dieses Zeigers ist dann die Basis, zu der die Entfernung addiert wird.
Das Basisfeld 30425 wird interpretiert, als daß es das Format 30432 Basis ist ein Name hat, wenn das Kennzeichen 30413 Basis ist ein Name auf 1 gesetzt ist. Im Basis ist ein Name-Format 30432 enthält das Basisfeld 30425 einen Namen. Wenn das indirekte Basis- Kennzeichen 30415 nicht gesetzt ist, wird der Name aufgelöst, um eine Basis zu ergeben. Wenn das indirekte Basis-Kennzeichen 30415 gesetzt ist, wird der Name ausgewertet, so daß er einen Zeigerwert ergibt, und jener Zeigerwert ist die Basis.

3. Architektonische Basiszeiger (Fig. 305, 306)

Wenn das Basis ist ein Name-Kennzeichen 30413, das zu einem NTE 30401 gehört, nicht gesetzt ist, spezifiziert das Basisfeld 30425 einen von drei ABPs in CS 10110:
- PBP spezifiziert eine Lokation im Prozedurobjekt 608, zu der die Entfernungen addiert werden können, um die Lokationen der Literale und SINs zu erhalten.
- SDP spezifiziert eine Lokation in einem statischen Datenblock für einen Aufruf einer Prozedur 602, zu der die Entfernungen addiert werden können, um die Lokationen von statischen Daten und Verkettungszeigern zu Prozeduren 602 zu erhalten, die in anderen Prozedurobjekten 608 enthalten sind, und statischen Daten zu erhalten.
- FP spezifiziert eine Lokation in dem MAS-Rahmen, der zum gegenwärtigen Aufruf der Prozedur 602 gehört, zu dem die Entfernungen addiert werden können, um die Lokation von lokalen Daten und Verkettungszeigern zu Argumenten zu erhalten.
Jedesmal wenn ein Prozeß 610 eine Prozedur 602 aufruft, speichert der Aufruf-Mikrocode die gegenwärtigen Werte der ABPs auf dem Sicherheitsstapelspeicher 10336, berechnet die Werte der ABPs für einen neuen Aufruf und plaziert die resultierenden logischen Beschreiber 27116 in FU 10120-Registern, wo sie für den Adreßraum-Mikrocode verfügbar sind.
Der Aufruf-Mikrocode berechnet die ABPs folgendermaßen: PBP wird direkt aus dem PBP-Feld 30315 in PED 30303 erhalten, das zu der gerade ausgeführten Prozedur 602 gehört. Was sonst noch dazu benötigt wird, ihn in einen logischen Beschreiber 27116 zu stecken, ist die Addition der AON für die UID des Prozedurobjekts 608. SDP wird erhalten, indem man mit dem SDPP-Feld 30313 eine Zeiger nach Beschreiber-Übersetzung durchführt. FP wird schließlich durch den Bereich des Aufruf-Mikrocodes zur Verfügung gestellt, der den neuen MAS 502-Rahmen für den Aufruf erzeugt. Wie bei der Diskussion des Aufrufs genauer beschrieben wird, kopiert der Aufruf-Mikrocode die Verkettungszeiger auf die aktuellen Argumente des Aufrufs auf MAS 502, setzt FP so, daß es auf die dem letzten aktuellen Argument folgende Lokation zeigt und allokiert dann Speicher für die lokalen Daten des Aufrufs. Positive Entfernungen von FP spezifizieren so Lokationen in den lokalen Daten, während negative Abstände Verkettungszeiger spezifizieren.

a.a. Auflösung und Auswerten von Namen (Fig. 305)

Die Hauptoperationen, die vom Adreßraum durchgeführt werden, sind Namen aufzulösen und sie auszuwerten. Ein Name ist aufgelöst, wenn der Adreßraum die ABPs und die im NTE 30401 des Namens enthaltene Information benutzt hat, um einen logischen Beschreiber 27116 für den Namen zu erzeugen; ein Name ist ausgewertet, wenn der Adreßraum den Namen aufgelöst hat, den resultierenden logischen Beschreiber 27116 für den Namen dem Speicher vorgestellt hat und den Wert der durch den Namen repräsentierten Daten vom Speicher erhalten hat.
Die Auflöseoperation hat drei Teile, die in jeder beliebigen Reihenfolge durchgeführt werden können:
- Das Erhalten der Basis vom Basisfeld 30425 des NTE 30401 des Namens.
- Das Erhalten der Entfernung.
- Das Erhalten der Länge vom Längenfeld 30435.
Das Erhalten der Länge ist die einfachste der Operationen: wenn das Länge in einem Namen-Kennzeichen 30411 gesetzt ist, so ist die Länge der Wert, der durch die Auswertung des im Längenfeld 30435 enthaltenen Namens gewonnen wird; sonst enthält das Längenfeld 30435 einen Literalwert, und die Länge ist der Wert jenes Literals.
Es gibt vier Möglichkeiten, die Basis auszurechnen. Welche davon benutzt wird, hängt von den Einstellungen der Basis ist ein Name-Kennzeichen 30413 und indirekte Basis- Kennzeichen 30415 ab:
- Beide Kennzeichen 0: der ABP, der im ABP-Feld 30429 spezifiziert wird, ist die Basis.
- Das Basis ist ein Name-Kennzeichen 30413 0 und das indirekte Basis-Kennzeichen 30415 1: die Basis ist die Lokation, die im durch das ABP-Feld 30429 und das Zeigerlokalisiererfeld 30431 spezifizierten Zeiger enthalten ist.
- Das Basis ist ein Name-Kennzeichen 30413 1 und das indirekte Basis-Kennzeichen 30415 0: die Basis ist die Lokation, die durch die Auflösung des Namens im Basisfeld 30425 erhalten wird.
- Beide Kennzeichen 1: die Basis ist die Lokation, die durch die Auswertung des Namens im Basisfeld 30425 erhalten wird.
Die Art und Weise, in der der Adreßraum die Entfernung berechnet, hängt davon ab, ob NTE 30401 einen skalaren Datenausdruck oder einen Vektordatenausdruck darstellt. Im ersten Fall addiert der Adreßraum den im Entfernungsfeld 30437 enthaltenen Wert und das Entfernungs-Ausdehnungsfeld 30439 zu der Lokation, die als Basis erhalten wurde; im zweiten Fall wertet der Adreßraum das Indexnamensfeld 30441 und das IES-Feld 30445 aus, multipliziert die beiden resultierenden Werte miteinander und addiert das Produkt zu dem Wert im Entfernungsfeld 30437, um die Entfernung zu erhalten.
Wenn irgendein Feld eines NTE 30401 einen Namen enthält, so erhält der Adreßraum den Wert oder die Lokation, die durch den Namen dargestellt wird, indem er auf ihn wie gefordert eine Auflösungs- oder Auswerteoperation durchführt. Wie bei der Diskussion der NTEs 30401 erwähnt, zeigen die Kennzeichen im Kennzeichenfeld 30408 an, welche Felder eines NTE 30401 Namen enthalten. Weil der NTE 30401 für einen in einem anderen NTE 30401 benutzten Namen selbst Namen enthalten kann, führt der Adreßraum die Auflöse- und Auswerteoperationen rekursiv aus.

b.b. Implementierung der Namensauswertung und Namensauflösung in CS 10110

In der vorliegenden Verkörperung werden die Namensauswerte- und Namensauflöseoperationen durch FU 10120-Mikrocode Auswerte- und Auflösebefehle durchgeführt. Beide Befehle erfordern zwei Informationen: ein Register im gegenwärtigen Rahmen des SR- Bereichs 10362 von GRF 10354, um den durch die Operation erzeugten logischen Beschreiber 27116 zu empfangen und die Quelle des Namens, der aufgelöst oder ausgewertet werden soll. Sowohl die Auflöse- als auch die Auswerteoperation kann zwischen drei Quellen auswählen: der Analysierer 20264, die Namensfalle 20254 und die niedrigsignifikanten 16 Bits des Ausgaberegisters für OFFALU 20242. Das Auflösen kann die Register 0, 1 oder 2 des gegenwärtigen Rahmens für den logischen Beschreiber 27116 spezifizieren, und das Auswerten kann die Register 0 oder 1 des gegenwärtigen Rahmens spezifizieren. Am Ende der Auflöseoperation befindet sich der logische Beschreiber 27116 für die durch den Namen repräsentierten Daten im spezifizierten SR 10362-Register, und am Ende der Auswerteoperation befindet sich der logische Beschreiber 27116 im spezifizierten SR 10362-Register, und der Wert der Daten wurde über den MOD-Bus 10144 zum OPB 20322 von EU 10122 transferiert.
Die Ausführung sowohl des Auflöse- als auch des Auswertebefehls beginnt immer mit der Vorstellung des Namens zum Namenszwischenspeicher 10226. Der dem Namenszwischenspeicher 10226 vorgestellte Name wird in die Namensfalle 20254 weitergeschoben, wo er für nachfolgenden Gebrauch durch den Namensauflöse-Mikrocode verfügbar ist.
Wenn es einen Eingang für den Namen im Namenszwischenspeicher 10226 gibt, tritt ein Namenszwischenspeichertreffer auf. Wenn Namen mit NTEs 30401 drei Bedingungen erfüllen, so ist der Eingang für den Namenszwischenspeicher 10226 für den Namen ein logischer Beschreiber 27116 für den durch den Namen repräsentierten Datenausdruck. Die Bedingungen sind die folgenden:
- NTE 30401 enthält keinen Namen.
- Das Längenfeld des NTE 30401 spezifiziert eine Länge kleiner gleich 256 Bits.
- Wenn das Basis ist indirekt-Kennzeichen 30415 gesetzt ist, muß das Zeigerentfernungsfeld 30431 einen negativen Wert haben, der anzeigt, daß die Basis ein Verkettungszeiger ist.
Der logische Beschreiber 27116 kann in diesem Fall zwischengespeichert werden, weil weder die Lokation noch die Länge der durch den Namen repräsentierten Daten sich während der Lebensdauer des Aufrufs der Prozedur 602, zu der der Name gehört, ändern können. Wenn der Eingang des Namenszwischenspeichers 10226 für den Namen ein logischer Beschreiber 27116 ist, so veranlaßt der Treffer, daß der Namenszwischenspeicher 10226 den logischen Beschreiber 27116 in dem spezifizierten SR 10362-Register plaziert. In allen anderen Fällen enthält der Eingang des Namenszwischenspeichers 10226 für den Namen keinen logischen Beschreiber 27116, und ein Treffer veranlaßt, daß der Namenszwischenspeicher 10226 ein JAM-Signal aussendet. Das JAM-Signal ruft Mikrocode auf, der die im Namenszwischenspeicher 10226 gespeicherte Information dazu benutzt, den logischen Beschreiber 27116 für den durch den Namen repräsentierten Datenausdruck zu konstruieren. JAMs werden unten genau beschrieben.
Wenn es keinen Eingang für den Namen im Namenszwischenspeicher 10226 gibt, tritt ein Namenszwischenspeicherfehler auf, und der Namenszwischenspeicher 10226 sendet ein Zwischenspeicherfehler-JAM-Signal aus. Das Namensauflöse-Mikroprogramm, das durch das Zwischenspeicherfehler-JAM-Signal aufgerufen wurde, konstruiert aus dem NTE 30401 des Namens einen Eingang im Namenszwischenspeicher 10226, indem er DESP 20210 von FU 10120 dazu benutzt, die notwendigen Berechnungen durchzuführen. Wenn dies beendet ist, hinterläßt der Zwischenspeicherfehler-Mikrocode einen logischen Beschreiber 27116 für den Namen im spezifizierten SR 10362-Register und kehrt zurück.
Die Auflöseoperation ist vorbei, wenn der logische Beschreiber 27116 im spezifizierten GRF 10354-Register plaziert ist; die Auswerteoperation geht weiter, indem der logische Beschreiber 27116 der Speicherreferenzeneinheit 27017 vorgestellt wird, die die durch den logischen Beschreiber 27116 repräsentierten Daten aus dem Speicher liest und sie auf OPB 20322 plaziert. Die Speicherreferenz kann Schutzzwischenspeicher 10234-Fehler und ATU 10228-Fehler ergeben, genauso wie Schutzfehler und Seitenfehler, aber diese werden durch Ereignissignale bearbeitet und sind daher für die Auswerteoperation unsichtbar.
Der Namenszwischenspeicher 10226 erzeugt 15 verschiedene JAM-Signale. Das Signal, daß durch ein JAM erzeugt wird, hängt von folgendem ab: ob die Operation eine Auflöse- oder eine Auswerteoperation ist, in welches Register der logische Beschreiber 27116 zu plazieren ist, ob ein Fehler auftrat, und im Falle eines Treffers, welches Register im Eingang des Namenszwischenspeichers 10226 für den Namen zuletzt geladen wurde. Aus der Sicht für das Verhalten des Mikrocodes, der durch JAM aufgerufen wird, sind die beiden letzten Faktoren die wichtigsten. Ihre Beziehung zum Mikrocode wird unten genau erklärt.
In der vorliegenden Verkörperung werden alle Einträge im Namenzwischenspeicher 10226 ungültig gemacht, wenn eine Prozedur 602 eine andere Prozedur 602 aufruft. Die Ungültigmachung ist erforderlich, weil Aufrufe immer den Wert von FP verändern und auch die Werte von SDP und PBP verändern können, wodurch sie die Bedeutung der NTEs 30401, die die Entfernungen von den ABPs benutzen, verändern. Es werden Einträge für Namen in der aufgerufenen Prozedur 602 erzeugt und in den Namenszwischenspeicher 10226 geladen, wenn die Namen ausgewertet oder aufgelöst werden und ein Zwischenspeicherfehler auftritt.
Die folgende Diskussion stellt zuerst den Namenszwischenspeicher 10226 vor, wie er dem Mikroprogrammierer erscheint, und erklärt dann genau, wie der Namenszwischenspeicher 10226 benutzt wird, um Namen auszuwerten und aufzulösen, wie er geladen wird, und wie er gelöscht wird.

c.c. Eingänge des Namenszwischenspeichers 10226 (Fig. 306)

Die Struktur und das physikalische Aussehen des Namenszwischenspeichers 10226 wurde in der Diskussion der FU 10120-Hardware vorgestellt; hier wird die logische Struktur der Eingänge des Namenszwischenspeichers 10226 vorgestellt, wie sie dem Mikroprogrammierer erscheint. Für den Mikroprogrammierer erscheint der Namenszwischenspeicher 10226 als ein Gerät, das, wenn ihm ein Name auf dem NAME-Bus 20224 vorgestellt wird, den Mikroprogrammierer immer mit einem Eingang für den Namenszwischenspeicher 10226 für Namen versorgt, der aus vier Registern besteht. Der Mikroprogrammierer kann aus jedem beliebigen der vier Register lesen oder dorthin schreiben. Wenn der Mikroprogrammierer die vier Register beschreibt, hängt die vom Namenszwischenspeicher 10226 unternommene Aktion davon ab, welches der Register als letztes geladen wurde, wenn ein Treffer bei einem Namen auftritt, der mit den vier Registern assoziiert ist. Die Mittel, durch die der Namenszwischenspeicher 10226 einen Namen mit den vier Registern assoziiert, und die Mittel, durch die der Namenszwischenspeicher 10226 Register zur Verfügung stellt, wenn er voll ist, sind für den Mikroprogrammierer unsichtbar.
Fig. 306 verdeutlicht den Namenszwischenspeichereintrag 30601 für einen Namen. Die vier Register 30602 im Namenszwischenspeichereintrag 30601 sind von 0 bis 3 durchnumeriert, und jedes Register 30602 hat ein AON-, Offset- und Längenfeld, wie jene in den GRF 10354-Registern, außer daß manche Kennzeichenbits in den AON-Feldern in dem GRF 10354-Register nicht in den Registerfeldern 30602 beinhaltet sind, und daß das Längenfeld in Register 30602 acht Bits lang ist. Wie auch bei GRF 10354-Registern, kann der Mikroprogrammierer auf einzelne Felder des Registers 30602 oder auf das gesamte Register 30602 schreibend oder lesend zugreifen. Der Namenszwischenspeichereintrag 30601 ist über DB 27021 mit DESP 20210 verbunden, und daher können die Inhalte eines GRF 10354-Registers von einem Register 30602 erhalten oder dorthin transferiert werden, oder umgekehrt. Wenn die Inhalte eines Registers 30602 zu einem GRF 10354-Register transferiert wurden, können die Inhalte verarbeitet werden, indem OFFALU 20242 und andere arithmetisch-logische Geräte in DESP 20210 benutzt werden.

d.d. Treffer des Namenszwischenspeichers 10226

Wenn ein Name dem Namenszwischenspeicher 10226 vorgestellt wird, und der Namenszwischenspeicher 10226 einen Namenszwischenspeichereintrag 30601 hat, der Informationen über den Namen enthält, tritt ein Namenszwischenspeichertreffer auf. Bei einem Treffer lädt die Hardware des Namenszwischenspeichers 10226 immer die Inhalte der Register 30602 0 des Namens des Namenszwischenspeichereingangs 30601 in das GRF 10354-Register, das durch den Auflöse- oder Auswerte-Mikrobefehl spezifiziert wurde.
Zusätzlich kann ein Treffer einen Aufruf von Mikrocode über ein JAM ergeben:
- Das JAM kann speziellen Mikrocode für die Auflösung von Namen von Vektorelementen aufrufen, deren NTEs 30401 bestimmte Hardware-Beschleunigungen der Indexberechnungen ermöglichen.
- Das JAM kann einen allgemeinen Namensauflöse-Mikrocode aufrufen, der einen logischen Beschreiber aus den Inhalten des Namenszwischenspeichereintrags 30601 erzeugt.
Ob ein Treffer ein JAM erzeugt, und die Art von JAM, die er erzeugt, werden durch das letzte Register 30602 bestimmt, das geladen werden muß, wenn der Namenszwischenspeichereintrag 30601 durch einen Namenszwischenspeicherfehler-Mikrocode erzeugt wurde. Wenn das Register 30602 0 das letzte war, welches geladen wurde, tritt kein JAM auf; wenn Register 30602 1 als letztes geladen wurde, tritt der JAM für besondere Vektornamenauflösung auf; wenn das Register 30602 2 oder 3 als letztes geladen wurde, tritt der JAM für allgemeine Namensauflösung auf.
Wie aus Obigem geschlossen werden kann, definiert die Hardware des Namenszwischenspeichers 10226 die Art und Weise, in der die Namenszwischenspeichereinträge 30601 für die ersten beiden Fälle geladen werden. Im ersten Fall muß das Namenszwischenspeicherregister 30602 0 den logischen Beschreiber 27116 für die Daten des Namens beinhalten. Wie bereits erwähnt, muß daher das NTE 30401 des Namens die Daten beschreiben, deren Lokation und Länge nicht während des Aufrufs variieren kann und deren Länge kleiner gleich 256 Bits ist. Die Namenszwischenspeicher 10226-Hardware bestimmt auch die Form von Namenszwischenspeichereinträgen 30601 für zwischenspeicherbare Vektoren. Ein zwischenspeicherbarer Vektor NTE 30401 ist ein Vektor NTE 30401, der die folgenden Bedingungen erfüllt:
- Der einzige Name, der im Vektor NTE 30401 enthalten ist, ist im Indexnamenfeld 30441.
- Der NTE 30401 des Indexnamens erfüllt die Bedingungen für scalare NTEs 30401, für die logische Beschreiber 27116 zwischengespeichert werden können.
- Der Wert im IES-Feld 30445 ist nicht größer als 128 und eine Zweierpotenz.
- Sonst erfüllt der Vektor NTE 30401 die Bedingungen für skalare NTEs 30401, für die logische Beschreiber 27116 zwischengespeichert werden können.
In der gegenwärtigen Verkörperung benutzt der zwischenspeicherbare Vektoreintrag die Register 0, 1 und 2 des Namenszwischenspeichereintrags 30601 für den Namen: Register Inhalte OFFSET LENGTH Logischer Beschreiber 27116 für den Indexnamen. IES-Zweierpotenz nicht gebraucht Logischer Beschreiber 27116 für den Vektor.
Wenn ein Treffer für diesen Eintragstyp auftritt, macht das resultierende JAM-Signal zweierlei: es ruft den zwischenspeicherbaren Vektorauflöse-Mikrocode auf, und es veranlaßt, daß der logische Beschreiber 27116 des Indexnamens der Speicherreferenzeinheit 27017 für eine Leseoperation vorgestellt wird, die den Wert der durch den Indexnamen repräsentierten Daten einem Akkumulator in OFFALU 20242 zurückgibt. Das zwischenspeicherbare Vektorauflöse-Mikroprogramm benutzt dann den Namen, der den in die Namensfalle 20254 geschobene JAM verursacht hat, um das Register 30602 2 des Namenszwischenspeichereintrags 30601 für den Namen zu lokalisieren, schreibt die Inhalte des Registers 30602 2 in das GRF-Register, das durch den Auflöse- oder Auswertemikrobefehl spezifiziert wurde, bildet das Produkt des IES-Wertes mit dem Indexwert, indem es den Indexwert so oft links verschiebt, wie es der IES-Exponent in Register 30602 1 angibt, addiert das Ergebnis zum Abstandsfeld des GRF 10354-Registers, das den logischen Beschreiber 27116 des Vektors enthält, und erhält so den logischen Beschreiber 27116 für das gewünschte Vektorelement und kehrt zurück.
Für die anderen Fälle wird die Art und Weise, in der die Namenszwischenspeichereinträge 30601 geladen und verarbeitet werden, um logische Beschreiber 27116 zu erhalten, durch den Mikroprogrammierer bestimmt. Das JAM-Signal, das resultiert, wenn ein Namenszwischenspeichereintrag 30601 weder ein logischer Beschreiber 27116 noch ein zwischenspeicherbarer Vektoreintrag ist, ruft lediglich ein Mikroprogramm auf. Das Mikroprogramm benutzt den in die Namensfalle 20254 geschobenen Namen, um den Namenszwischenspeichereintrag 30601 des Namens zu lokalisieren und liest dann Kennzeichenwerte im Namenszwischenspeichereintrag 30601, um zu bestimmen, wie die Information im Namenszwischenspeichereintrag 30601 übersetzt werden muß in einen logischen Beschreiber 27116. Die Inhalte der Namenszwischenspeichereinträge 30601 für die anderen Fälle haben zwei allgemeine Formen: eine für NTEs 30401, wobei das Basis ist indirekt-Kennzeichen 30415 gesetzt ist, und eine für NTEs, in denen es nicht gesetzt ist. Die erste allgemeine Form sieht folgendermaßen aus: Register Inhalt OFFSET LENGTH Kennzeichen/Länge unbenutzt Indexname/IES Datenentfernung von der durch den Zeiger spezifizierten Lokation
Das Register 30602 0 enthält die AON des ABP. Das Abstandsfeld des Registers 30602 0 enthält zwei Ausdrücke: das Kennzeichen, das das Kennzeichenfeld 30408 von NTE 30401 zusammen mit anderen Informationen enthält, und das bestimmt, wie der Namensauflöse-Mikrocode die Inhalte des Namenszwischenspeichereintrags 30601 und einen Wert oder Namen für die Länge des Datenausdrucks enthält. Register 30602 1 wird nur benutzt, wenn der Name einen Datenausdruck in einem Vektor repräsentiert. Es enthält dann den Namen vom Indexfeld 30441 und den Namen oder Wert vom IES-Feld 30445. Das Abstandsfeld des Registers 30602 3 enthält die Summe des Abstandes, der vom ABP des NTE 30401 angezeigt wird und von der Entfernung, die durch NTE 30401 angezeigt wird.
Das zweite Format, das für NTEs 30401 benutzt wird, deren Basen von Zeigern oder durch Namensauflösung erhalten wird, sieht folgendermaßen aus: Register Inhalt OFFSET LENGTH Kennzeichen/Länge unbenutzt Indexname/IES FM und Typenbits/Basisfeld Datenentfernung von der Lokation, die durch Zeiger oder Namen spezifiziert wurde
In dieser Form muß die Lokation der Basis entweder durch Auswerten eines Zeigers oder durch Auflösen eines Namens erhalten werden. Also gibt es kein Feld, das die AON der Basis spezifiziert. Sonst haben die Register 30602 0 und 1 die gleichen Inhalte wie im vorherigen Format. In Register 30602 2 enthält das Abstandsfeld das FM-Feld 30421 und das Typenfeld 30423 und das Basisfeld 30425 des Namenstabelleneingangs 30401. Das Abstandsfeld von Register 30602 2 enthält den Wert der Entfernungsfelder 30437 und 30429 des Namenstabelleneintrags 30401.
Wie bei Namenstabelleneinträgen 30401 muß der Index durch einen Namen repräsentiert werden und Länge, IES und Basis können durch Namen repräsentiert werden. Wenn ein Feld eines Namenszwischenspeichereintrags 30601 einen Namen enthält, so zeigt ein Kennzeichen dies an, und der Namensauflöse-Mikrocode führt eine Auswerte- oder Auflöseoperation mit ihm durch, wie es erforderlich ist, um den Wert oder die Lokation, die durch den Namen dargestellt wird, zu erhalten.
Der Mikrocode, der Namenszwischenspeichereinträge 30601 der eben beschriebenen Typen auflöst, benutzt die allgemeinen Algorithmen, die in der Diskussion der Namenstabelleneinträge 30401 beschrieben wurden, und wird deshalb hier nicht weiter diskutiert.

e.e. Fehler des Namenszwischenspeichers 10226

Wenn ein Name dem Namenszwischenspeicher 10226 vorgestellt wird, und es keinen Namenszwischenspeichereintrag 30601 für den Namen gibt, so tritt ein Namenszwischenspeicherfehler auf. Bei einem Fehler sendet die Hardware des Namenszwischenspeichers 10226 ein JAM-Signal aus, das Namenszwischenspeicherfehler-Mikrocode aufruft. Der Mikrocode erhält den Namen, der den Fehler verursachte, von der Namensfalle 20254 und lokalisiert das NTE 30401 des Namens, indem er den Namen zum Wert von NTP 36311 von PED 30303 für die Prozedur 602, die gerade ausgeführt wird, dazu addiert. Wie später noch genauer erklärt wird, plaziert der Aufruf-Mikrocode, wenn eine Prozedur 602 aufgerufen wird, die AON und den Abstand, die die Lokation des NTP spezifizieren, in ein Register in den GRs 10360. Indem er die in dem NTE 30401 des Namens enthaltene Information benutzt, löst der Zwischenspeicherfehler-Mikrocode den Namen auf und konstruiert einen Namenszwischenspeichereintrag 30601 für ihn. Wie oben beschrieben, bestimmt der Mikrocode die Methode, mit der er den Namen auflöst und die Form des Namenszwischenspeichereintrags 30601 des Namens durch das Lesen des Kennzeichenfeldes 30408 im NTE 30401 des Namens. Da die Beschreibungen der Auflöseoperation, der Mikromaschine, des Namenszwischenspeichers 10226 und der Formate der Namenszwischenspeichereinträge 30601 ausreichend sind, um Fachleuten auf diesem Gebiet ein Verständnis der Operationen, die vom Zwischenspeicherfehler-Mikrocode durchgeführt werden, zu ermöglichen, wird keine weitere Beschreibung des Mikrocodes zur Verfügung gestellt.

f.f. Löschen des Namenszwischenspeichers 10226

Wie in der Diskussion der Hardware des Namenszwischenspeichers 10226 beschrieben wurde, existieren Hardware-Ressourcen, namentlich VALS 24068, die es ermöglichen, daß Namenszwischenspeichereinträge 30601 ungültig gemacht werden können. Einträge in den Namenszwischenspeicher 30601 können einzeln ungültig gemacht werden oder alle Einträge im Namenszwischenspeicher 10226 können durch einen einzigen Mikrobefehl ungültig gemacht werden. Die letztere Operation wird Löschen des Namenszwischenspeichers genannt. In der gegenwärtigen Verkörperung muß der Namenszwischenspeicher 10226 gelöscht werden, wenn der Prozeß 601, dessen virtueller Prozessor 612 an JP 10114 gebunden ist, einen Aufruf oder eine Rückkehr ausführt, und immer wenn ein virtueller Prozessor 612NO von JP 10114 gelöst wird. Das Löschen bei Aufrufen und Rückkehren ist notwendig, weil Aufrufe und Rückkehren die Werte der ABPs und anderer Zeiger, die beim Auflösen von Namen benötigt werden, sich ändern. Ein Aufruf erzeugt mindestens einen neuen MAS-Rahmen 10412, und eine Rückkehr kehrt zu dem vorherigen Rahmen 10412 zurück, wodurch der Wert von FP geändert wird. Wenn die gerufene Prozedur 602 einen unterschiedlichen PED 30303, bezogen auf den der rufenden Prozedur 602, hat, so kann der Aufruf oder die Rückkehr auch PBP, SDP und NTP verändern. Das Löschen ist notwendig, wenn ein virtueller Prozessor 612 von JP 10114 gelöst wird, weil ein virtueller Prozessor 612, der als nächstes an JP 101144 gebunden wird, an einen anderen Prozeß 610 gebunden wird, und er kann daher keine Informationen benutzen, die zu dem Prozeß 610 gehören, der an den vorherigen virtuellen Prozessor 612 gebunden war.

g.g. Ergreifen dem I-Stromes

Wie in der Diskussion der FU 10120-Hardware erklärt wurde, werden die SINs vom Speicher durch den Voraufnehmer 20260 geholt. PREF 20260 enthält einen logischen Beschreiber 27116 für eine Lokation im Code 10344, der zur Prozedur 602 gehört, die augenblicklich ausgeführt wird. Bei jedem M0-Zyklus kann PREF 20260 den logischen Beschreiber 27116 auf DB 27021 plazieren, die Speicherreferenzeneinheit 27017 dazu veranlassen, 32 Bits an der Lokation zu holen, die durch den logischen Beschreiber 27116 spezifiziert wurde, und sie in INSTB 20262 zu schreiben. Wenn INSTB 20262 voll ist, hört PREF 20260 auf, SINs zu holen, bis Adreßraum-Analysieroperationen, die unten beschrieben werden, einen Teil der Inhalte von INSTB 20262 verarbeitet haben, und dadurch Platz für mehr SINs geschaffen haben.
Die Aufnahmeoperation ist automatisch und erfordert eine Intervention vom Adreßraum nur dann, wenn ein SIN eine Verzweigung erzeugt, d. h. sie verursacht, daß der nächste SIN, der auszuführen ist, ein anderer SIN ist als der, der unmittelbar dem gegenwärtigen SIN folgt. Bei einer Verzweigung muß der Adreßraum PREF 20260 mit der Lokation des nächsten SIN, der ausgeführt werden soll, laden, und PREF 20260 dazu veranlassen, die Aufnahme der SINs an jener Lokation zu beginnen. Die Operation, die das tut, wird durch den Mikrobefehl Voraufnahme_für_Verzweigung_laden spezifiziert. Der Mikrobefehl spezifiziert eine Quelle für einen logischen Beschreiber 27116 und transferiert jenen logischen Beschreiber 27116 über DB 27021 zu PRFF 20260. Nachdem PREF 20260 auf diese Weise geladen wurde, beginnt er, SINs an dieser spezifizierten Lokation aufzunehmen. Da alle SINs, die noch in INSTB 20262 sind, durch diese Verzweigungsoperation bedeutungslos geworden sind, werden die ersten SINs, die in INSTB 20262 geladen werden, einfach über die vorherigen Inhalte von INSTB 20262 geschrieben. Fig. 274 enthält ein Beispiel des Gebrauchs des Befehls Voraufnehmer_für_Verzweigung_ laden.

h.h. Analysieren des I-Stromes

Der I-Strom, wie er von MEM 10112 geholt und in INSTB 20262 gespeichert wird, ist eine Abfolge von SOPs und Namen. Wie bereits erwähnt, hat der I-Strom ein festes Format: in der gegenwärtigen Verkörperung sind SOPs immer acht Bits lang, und Namen können 8, 12 oder 16 Bits lang sein. Die Länge der in einer gegebenen Prozedur benutzten Namen ist fest und wird durch den Wert im K-Feld 30305 in PED 30303 der Prozedur 602 angezeigt. Die Analysieroperationen erhalten die SOPs und Namen vom I-Strom und plazieren sie auf dem NAME-Bus 20224. Die SOPs werden über diesen Bus zu den Geräten im SOP-Dekodierer 27003 transferiert, während die Namen zur Namensfalle 20254 und zum Namenszwischenspeicher 10226 für Auflöse- und Auswerteoperationen, wie oben beschrieben, transferiert werden. Weil die Analysieroperationen SOPs und Namen erhalten, aktualisieren sie auch die drei Programmzähler CPC 20270, EPC 20274 und IPC 20272. Die Werte in diesen drei Zählern sind Abstände vom PBP, die auf Lokationen im Code 10344 zeigen, der zu der gerade ausgeführten Prozedur 602 gehört. CPC 20270 zeigt auf die gerade analysierte I-Stromsilbe, daher wird er bei jeder Analysieroperation aktualisiert. EPC 20274 zeigt auf den Anfang des letzten von JP 10114 ausgeführten SIN, und IPC 20272 zeigt auf den Anfang des gegenwärtigen SIN, also werden diese Programmzähler nur am Beginn der Ausführung eines SIN, d. h. wenn ein SOP analysiert wird, verändert.
Wie in der Diskussion der FU 10120-Hardware beschrieben, besteht in der gegenwärtigen Implementierung das Analysieren physikalisch aus dem Lesen von 8 oder 16 Datenbits von einer Lokation in INSTB 20262, die durch einen Zeiger für INSTB 20262 identifiziert wird, der nur für die Hardware zugänglich ist. Wenn die Daten gelesen sind, inkrementiert die Hardware den Zeiger um die Anzahl der gelesenen Bits, bricht um und kehrt zum Anfang von INSTB 20262 zurück, falls sie sein Ende erreicht. Zum selben Zeitpunkt, an dem die Hardware den Zähler inkrementiert, inkrementiert sie CPC 20270 um die gleiche Anzahl Bits. Wie oben erwähnt, enthält CPC 20270 den Abstand vom PBP des augenblicklich analysierten SOP oder Namens, und koordiniert so das Lesen von INSTB 20262 mit dem Lesen des Codes 10344 der Prozedur 602.
Die Anzahl der gelesenen Bits hängt davon ab, ob der Analysierer 20264 ein SOP oder einen Namen liest, und im letzten Fall von der für den Namen spezifizierten Silbengröße. Die Silbengröße ist in CSSR 24112 enthalten. Bei einem Aufruf einer Prozedur 602, die einen anderen PED 30303 hat als der der aufrufenden Prozedur, lädt der Aufruf-Mikrocode den im K-Feld 30305 enthaltenen Wert in CSSR 24112.
Die Analysieroperationen des Adreßraums werden durch verschiedene Mikrobefehle zur Analyse von SOPs und Namen durchgeführt. Es gibt einen einzigen Mikrobefehl zur Analyse von S-Operationen: parse_op_stage. Der Mikrobefehl erhält die nächsten acht Bits von INSTB 20262, plaziert die Bits auf den NAME-Bus 20224 und schiebt sie in das LOPCODE-Register 24212. Er aktualisiert auch EPC 20274 und IPC 20272, wie es am Anfang eines SIN erforderlich ist: EPC 20274 wird auf den alten Wert von IPC 20272 gesetzt, und IPC 20272 wird auf CPC 20270's Wert gesetzt. Am Ende der Operation wird CPC 20270 um 8 inkrementiert. Da die Analyse eines SOP immer als erste Operation bei der Interpretation eines SIN auftritt, ist der parse_op_stage-Befehl allgemein mit einem Abrufverteilen-Befehl verbunden. Wie weiter unten erklärt wird, interpretiert der letztere Befehl die S-Operation als eine Adresse in FDISP 24218, und FDISP 24218 erzeugt wiederum eine Adresse in FUSITT 11012. Die letztere Adresse ist die Lokation des Anfangs des SIN-Mikrocodes für den SIN.
Es gibt zwei Mikrobefehle zur Analyse von Namen: parse_k_load_epc und parse_k_ dispatch_ebox. Beide Befehle erhalten eine Anzahl von Bits von INSTB 20262 und plazieren sie auf dem NAME-Bus 20214. Bei beiden Mikrobefehlen bestimmt die Silbengröße K, die in CSSR 24112 gespeichert ist, die Anzahl der Bits, die von INSTB 20262 erhalten wird. Beide Befehle inkrementieren CPC um den in CSSR 24112 gespeicherten Wert. Darüber hinaus setzt parse_k_load_epc EPC auf den Wert von IPC, während parse_k_ dispatch_ebox auch EU 10122 aufteilt, d. h. er interpretiert den in LOPCODE 24210 gespeicherten SOP als eine Adresse in EDISP 24222, das wiederum eine Adresse in EU EUSITT 20344 enthält. Die EU EUSITT 20344-Adresse wird über den EUDIS-Bus 20206 nach COMQ 20342 in EU 10122 übergeben.

c. Die S-Interpreter (Fig. 307)

CS 10110 weist SOPs keine festen Bedeutungen zu. Während alle SOPs 8 Bits lang sind, kann ein gegebener SOP in einer S-Sprache eine Bedeutung haben und eine völlig andere in einer anderen S-Sprache. Die Semantik der S-Operationen der S-Sprache wird vollständig durch den S-Interpreter für die S-Sprache bestimmt. Daher muß CS 10110, um eine S-Operation korrekt zu interpretieren, wissen, welcher S-Interpreter zu benutzen ist. Der S-Interpreter wird durch einen UID-Zeiger mit dem Abstand 0 im SIP-Feld 30309 des PED 30303 für die Prozedur 602, die CS 10110 augenblicklich ausführt, identifiziert. In der gegenwärtigen Verkörperung ist die UID die UID eines Mikrocodeobjektes, das FU 10120-Mikrocode enthält. Wenn in FUSITT 11012 geladen, interpretiert der Mikrocode die SOPs so, wie sie durch die S-Sprache definiert sind, zu der der SOP gehört. In anderen Verkörperungen kann die UID die UID eines Prozedurobjektes 608 sein, das Prozeduren 602 enthält, die die SOPs der S-Sprache interpretieren, und in weiteren kann der S-Interpreter in einem PROM enthalten sein, und die S-Interpreter-UID darf kein Objekt spezifizieren, sondern nur dazu benutzt werden, den S-Interpreter zu identifizieren.
Wenn eine Prozedur 602 einen SIN auf JP 10114 ausführt, muß CS 10110 den Wert des SIP-Zeigers 30309 für die Prozedur 602 und den SOP der S-Instruktion in eine Lokation im Mikrocode oder im Hochsprachencode, aus dem der S-Interpreter besteht, übersetzen. Die durch die Übersetzung gewonnene Lokation ist der Anfang des Mikrocodes oder Hochsprachencodes, der den SIN implementiert. Die Übersetzung eines SOP zusammen mit einem SIP-Zeiger 30309 in eine Lokation im S-Interpreter wird Aufteilung genannt. Aufteilung in der gegenwärtigen Verkörperung involviert zwei Hauptkomponenten: eine Tabelle im Speicher, die den Wert des SIP-Zeigers 30309 in einen kleinen ganzzahligen Wert, der Dialektnummer genannt wird, übersetzt, und der S-Operations-Dekodierbereich 27003 der FU 10120-Mikromaschine. Die folgende Diskussion stellt erst die Tabelle vor und erklärt, wie ein SIP-Zeiger 30309 in eine Dialektnummer übersetzt wird, und erklärt dann, wie die Dialektnummer und der SOP zusammen in Lokationen in FUSITT 11012 und EUSITT 20344 übersetzt werden.

1. Übersetzung eines SIP in eine Dialektnummer (Fig. 307)

In der gegenwärtigen Verkörperung werden alle S-Interpreter in CS 10110 in FUSITT 11012 geladen, wenn CS 10110 seinen Betrieb beginnt, und jeder S-Interpreter wird immer an derselben Stelle plaziert. Welcher S-Interpreter benutzt wird, um eine S-Sprache zu interpretieren, wird durch einen im Dialektregister RDIAL 24212 gespeicherten Wert bestimmt. Daher muß in der gegenwärtigen Verkörperung ein Aufruf einer Prozedur 602, deren S-Interpreter sich von dem der rufenden Prozedur 602 unterscheidet, den in dem SIP-Felder 30309 enthaltenen UID-Zeiger in eine Dialektnummer übersetzen.
Fig. 307 stellt die Tabelle und den Mikrocode dar, der diese Übersetzung in der gegenwärtigen Verkörperung durchführt. Die S-Interpreter-Übersetzungstabelle (STT) 30701 ist eine Tabelle, die durch kleine AONs indiziert wird. Jeder STT-Eintrag (STTE) 30703 hat zwei Felder: ein AON-Feld 20705 und ein Dialektnummernfeld 30709. Das Dialektnummernfeld 30709 enthält die Dialektnummer für das S-Interpreterobjekt, dessen AON im AON-Feld 30705 ist.
Wenn CS 10110 seinen Betrieb aufnimmt, wird jedes S-Interpreterobjekt aktiv geschaltet und es wird ihm eine ausreichend kleine AON zugeteilt, die als Index in STT 30701 dient. Durch Konvention wird einem gegebenen S-Interpreterobjekt immer die gleiche AON und die gleiche Dialektnummer zugeordnet. Die AON wird in das AON-Feld 30705 von STTE 30703 plaziert, und durch die AON indiziert, und die Dialektnummer wird in das Dialektnummernfeld 30709 plaziert. Da die S-Interpreterobjekte aktiv geschaltet werden, werden diese AONs niemals anderen Objekten wieder zugeordnet.
Bei einem Aufruf, der einen neuen S-Interpreter erfordert, erhält der Aufruf-Mikrocode den neuen SIP vom SIP-Feld 30309, ruft den KOS LAR-Mikrocode auf, um seine UID in seine AON zu übersetzen, benutzt die AON, um STTE 30703 des S-Interpreters zu lokalisieren und plaziert den Wert des Dialektnummernfeldes 30709 in RDIAL 21242.
Andere Verkörperungen können es erlauben, daß S-Interpreter in FUSITT 11012 zu einem anderen Zeitpunkt als bei der Systeminitialisierung geladen werden und ermöglichen, daß die S-Interpreter verschiedene Lokationen in FUSITT 11012 zu verschiedenen Zeitpunkten besetzen. In diesen Verkörperungen kann STT 30701 in einer ähnlichen Weise implementiert werden wie die Implementierungen von AST 10914 oder MHT 10716 in der gegenwärtigen Verkörperung.

2. Aufteilung

Aufteilung wird durch die Aufteilungsdateien 27004 erreicht. Diese Dateien übersetzen die von RDIAL 24212 zur Verfügung gestellten Werte und die SOP der gerade ausgeführten S-Instruktion in die Lokation des Mikrocodes für den SIN, der durch die S-Operation im S-Interpreter spezifiziert wird, der durch den Wert von RDIAL 24212 gekennzeichnet ist. Die gegenwärtige Verkörperung hat drei Aufteilungsdateien: FDISP 24218, FALG 24220 und EDISP 24222. FDISP 24218 und FALG 24220 übersetzen S-Operationen in Lokationen von Mikrocode, der auf FU 10120 ausführt; EDISP 24222 übersetzt S-Operationen in Lokationen von Mikrocode, der auf EU 10122 ausführt. Der Unterschied zwischen FDISP 24218 und FALG 24220 ist die Geschwindigkeit: FDISP 24218 kann einen SOP im selben Mikrobefehl übersetzen, der einen parse_op_stage-Befehl zum Laden des SOP in LOPCO- DE 24210 durchführt. FALG 24220 muß die Übersetzung in einem Zyklus durchführen, der dem, in dem SOP in LOPCODE 24210 geladen wird, folgt. Typischerweise ist die Lokation des ersten Bereichs des Mikrocode, um eine S-Operation durchzuführen, in einem FDISP 24218-Register enthalten, die Lokation der Bereiche, die später ausgeführt werden, ist in einem FALG 24220-Register enthalten, und die Lokation von Mikrocode für die S-Operation, die auf EU 10122 ausführt, ist in EDISP 24222 enthalten.
In der vorliegenden Verkörperung vollführen die Register die Übersetzung von S-Operationen zu einer Mikrocodelokation wie folgt wie bei der Diskussion der FU 10120- Hardware erwähnt, beinhaltet jede Aufteilungsdatei 1024 Register. Jedes Register kann eine Adresse in einem S-Interpreter enthalten. Wie später genauer sichtbar wird, kann die Adresse eine Adresse im Objekt eines S-Interpreters sein, oder sie kann eine Adresse in FUSITT 11012 oder EUSITT 20344 einer Kopie des an einer S-Interpreteradresse gespeicherten Mikrocodes sein. Die Register in den Aufteilungsdateien können in Untermengen von 128 oder 256 Register unterteilt sein. Jede Untermenge von Registern übersetzt die SOPs für eine einzelne S-Sprache in Lokationen im Mikrocode. Welche Register-Untermenge benutzt wird, um eine gegebene S-Operation zu interpretieren, wird durch den Wert von RDIAL 24212 entschieden; welches Register in der Untermenge benutzt wird, wird durch den Wert der S-Operation entschieden. Der in dem spezifizierten Register enthaltene Wert ist dann die Lokation des Mikrocodes, der die durch die S- Operation, in der durch RDIAL 24212 spezifizierten S-Sprache S-Instruktion ausführt.
Logisch gesehen enthält das Register, das durch den verketteten Wert adressiert wird, wiederum eine 15 Bit-Adresse, die die Lokation im S-Interpreter des ersten Mikrobefehls des Mikrocodes ist, der benutzt wird, die S-Instruktion auszuführen, die durch die S- Operation in der S-Sprache spezifiziert wurde, die durch die Inhalte von RDIAL 24212 spezifiziert wurde. Der in der gegenwärtigen Verkörperung durch die Adresse angesprochene Mikrocode kann in FUSITT 11012 und EUSITT 20344 geladen worden sein, oder er kann nur im Speicher verfügbar sein. Mikrocodeadressen, die in FUSITT 11012 und EUSITT 20344 liegen, sind nur 8 Bits lang. Daher ist der Mikrocode, der durch die Adresse spezifiziert wurde, im Speicher, wenn eine Aufteilungsdatei 27004 eine Adresse enthält, die mehr als 8 Bits erfordert. Wie bei der Diskussion der FU 10120-Hardware beschrieben, erzeugen Adressen, die länger als 8 Bits sind, ein Ereignissignal, und der durch das Ereignissignal aufgerufene Mikrocode holt den Mikrobefehl an der spezifizierten Adresse im S-Interpreter aus dem Speicher und lädt ihn in die Lokation 0 von FUSITT 11012. Der Ereignis-Mikrocode kehrt dann zurück und der Mikrobefehl an Lokation 0 wird ausgeführt. Wenn der nächste Mikrobefehl auch eine Adresse hat, die länger ist als 8 Bits, tritt das Ereignissignal wieder auf und der oben beschriebene Prozeß wiederholt sich.
Wie oben erwähnt, ist FDISP 24218 schneller als FALG 24220 Der Grund für den Geschwindigkeitsunterschied liegt darin, daß FDISP-Register nur 6 Bits zur Adressierung der S-Interpreter enthalten. Die gegenwärtige Verkörperung setzt voraus, daß sämtlicher durch FDISP 24218 adressierter Mikrocode in FUSITT 11012 enthalten ist. Sie verkettet zwei Null-Bits mit den sechs Bits im FDISP 24218-Register, um eine 8 Bit-Adresse für FUSITT 11012 zu erzeugen. Die FDISP 24218-Register können so die Lokation jedes vierten FUSITT 11012-Registers zwischen FUSITT-Register 256 und FUSITT-Register 448 enthalten. Der Mikrocode, der in diese Lokationen in FUSITT 11012 geladen wird, ist Mikrocode für Operationen, die beim Beginn des SIN durch viele verschiedene SINs durchgeführt werden. Zum Beispiel müssen alle SINs, die Operationen mit zwei Operanden durchführen und das Ergebnis einer Lokation zuordnen, die durch einen dritten Operanden spezifiziert wird, die ersten beiden Operanden analysieren und auswerten und den dritten Operanden analysieren und auswerten. Nur nachdem diese Operationen getan sind, werden SIN-spezifische Operationen durchgeführt. In der gegenwärtigen Verkörperung ist der Mikrocode, der die Operanden analysiert, auflöst und auswertet, in einem Teil von FUSITT 11012 enthalten, das von FDISP 24218 adressierbar ist.
Wie oben erwähnt, kann in der gegenwärtigen Verkörperung FUSITT 11012 und EUSITT 20344 nur geladen werden, wenn CS 10110 initialisiert ist. Der in FUSITT 11012 und EUSITT 20344 geladene Mikrocode wird durch den Mikroprogrammverknüpfer vom Mikrocode für die verschiedenen SINs erzeugt. Um einen effizienten Gebrauch von FUSITT 11012 und EUSITT 20344 zu erreichen, taucht der von verschiedenen S- Interpretern für Operationen geteilter Mikrocode nur einmal in FUSITT 11012 und EUSITT 20344 auf. Während die SINs in den verschiedenen S-Sprachen, die den Mikrocode teilen, verschiedene Register in FDISP 24218, FALG 24220 oder eventuell EDISP 24222 haben, beinhalten die Register für jede der S-Instruktionen dieselbe Lokation in FUSITT 11012 oder EUSITT 20344.

4. Das Kernbetriebssystem

A. Einführung

Viele der einzigartigen Eigenschatten des CS 10110 werden durch die Manipulation von Tabellen in MEM 10112 und die Sekundärspeicherung 10124 durch Programme erzeugt, die auf JP 10114 ausführen. Diese Programme und Tabellen zusammen machen das Kernbetriebssystem (KOS) aus. Nachdem die CS 10110-Komponenten und die Mittel, durch die sie bei der Ausführung eines Computerprogrammes kooperieren, beschrieben worden sind, stellt diese Spezifikation nun einen genauen Bericht des KOS und der Eigenscharten von CS 10110 dar, die es erzeugt. Die Diskussion beginnt mit einer allgemeinen Einführung in Betriebssysteme, präsentiert dann einen Überblick des CS 10110-Betriebssystems, einen Überblick über KOS, und detaillierte Diskussionen der Implementierung von Objekten, Zugangssteuerung und Prozessen 610.

a. Betriebssysteme (Fig. 401)

In CS 10110, wie in anderen Computersystemen auch, hat das Betriebssystem zwei Funktionen:
- Es steuert den Gebrauch der CS 10110-Ressourcen wie z. B. JP 10114, MEM 10112 und die Geräte in IOS 10116 durch Programme, die in CS 10110 ausgeführt werden.
- Es definiert, wie CS 10110-Ressourcen den Benutzern von CS 10110 erscheinen.
Die zweite Funktion ist eine Folge der ersten: Dadurch, daß es die Art und Weise steuert, in der ausführende Programme Systemressourcen benutzen, bestimmt das Betriebssystem tatsächlich, wie das System seinen Benutzern erscheint. Fig. 401 ist eine schematische Darstellung der Beziehungen zwischen dem Benutzer 40101, dem Betriebssystem 40102 und den Systemressourcen 40103. Wenn der Benutzer 40101 wünscht, eine Systemressource 40103 zu nutzen, fordert der Benutzer 40101 die Benutzung der Systemressource 40103 vom Betriebssystem 40102 an, und das Betriebssystem 40102 befiehlt wiederum CS 10110, die angeforderten Ressourcen 40103 zur Verfügung zu stellen. Wenn zum Beispiel ein Benutzer ein periphäres Gerät zu benutzen wünscht, so hat er es nicht direkt mit dem Gerät zu tun, sondern er ruft die Prozedur 602 des Betriebssystems 40102 auf, die das Gerät steuert. Während das Betriebssystem 40102 die komplizierten physikalischen Eigenschaften des Geräts bedenken muß, braucht das Benutzerprogramm, das das Gerät anforderte, nichts über die physikalischen Eigenschaften wissen, sondern muß nur wissen, welche Informationen die Prozedur 602 des Betriebssystems 40102 benötigt, um die vom Benutzerprogramm angeforderte Operation durchzuführen. Während zum Beispiel das periphäre Gerät fordern kann, daß ihm ein genaues Datenmuster vorgelegt wird, muß die Prozedur 602 des Betriebssystems 40102 nur die Daten selbst vom Benutzerprogramm fordern, und kann die Daten wie vom periphären Gerät gefordert, formatieren. So transformiert die Prozedur 602 des Betriebssystems 40102, die das periphäre Gerät steuert, eine komplizierte physikalische Schnittstelle zu dem Gerät in eine wesentlich einfachere logische Schnittstelle.

1. Vom Betriebssystem gesteuerte Ressourcen (Fig. 402)

Betriebssysteme 40102 steuern zwei Arten von Ressourcen: physikalische und virtuelle Ressourcen. Die physikalischen Ressourcen in der gegenwärtigen Verkörperung von CS 10110 sind JP 10114, IOS 10116 und die periphären Geräte, die mit IOS 10116, MEM 10112 und dem Sekundärspeicher 10124 assoziiert sind. Virtuelle Ressourcen sind Ressourcen, die das Betriebssystem selbst für die Benutzer von CS 10110 definiert. Wie oben erklärt wurde, definiert das Betriebssystem 40102 durch die Steuerung, wie CS 10110's Ressourcen genutzt werden, wie CS 10110 den Benutzern erscheint. Anstelle der physikalischen Ressourcen, die vom Betriebssystem 40102 gesteuert werden, sieht der Benutzer einen wesentlich einfacheren Satz virtueller Ressourcen. Die logische I/O- Geräte-Schnittstelle, die das Betriebssystem 40102 dem Benutzer für ein physikalisches I/O-Gerät gibt, ist solch eine virtuelle Ressource. Oft definiert ein Betriebssystem 40102 einen Satz virtueller Ressourcen und teilt die physikalischen Ressourcen unter diesen virtuellen Ressourcen auf. Zum Beispiel kann das Betriebssystem 40102 einen Satz virtueller Prozessoren 612 definieren, die einer kleineren Gruppe von physikalischen Prozessoren entsprechen, und einen Satz virtueller Speicher definieren, die einer kleineren Gruppe physikalischer Ressourcen entsprechen. Wenn ein Benutzer ein Programm ausführt, läuft es auf einem virtuellen Prozessor 612 und benutzt virtuellen Speicher. Für den Benutzer des virtuellen Prozessors und des virtuellen Speichers sieht es so aus, daß er alleinigen Zugang auf den physikalischen Prozessor und den physikalischen Speicher hat, aber tatsächlich teilt das Betriebssystem 40102 die physikalischen Prozessoren und Speicher unter den virtuellen Prozessoren 612 und den virtuellen Speichern auf.
Auch Betriebssystem 40102 benutzen virtuelle Ressourcen. Zum Beispiel kann der Speichermanagementbereich eines Betriebssystem 40102 I/O-Geräte benutzen; dann benutzt es die virtuellen I/O-Geräte, die durch den Bereich des Betriebssystems 40102 definiert werden, die die I/O-Geräte verwalten. Ein Teil des Betriebssystems 40102 kann auch virtuelle Ressourcen, die durch andere Teile des Betriebssystems 40102 definiert werden, neu definieren. Zum Beispiel kann ein Teil des Betriebssystems 40102 einen Satz einfacher virtueller I/O-Geräte definieren, und ein anderer Teil kann diese einfachen virtuellen I/O-Geräte dazu benutzen, einen Satz Benutzer-orientierter I/O-Geräte hoher Ebene zu definieren. Das Betriebssystem 40102 verwandelt so das physikalische CS 10110 in einer Rangfolge virtueller Ressourcen. Wie ein Benutzer von CS 10110 CS 10110 wahrnimmt, hängt vollständig von der Ebene ab, auf der er mit den virtuellen Ressourcen zu tun hat.
Die Gesamtheit, die die durch das Betriebssystem 40102 definierten Ressourcen nutzt, ist der Prozeß. Ein Prozeß 610 kann definiert werden als die Aktivität, die aus der Ausführung eines Programmes mit seinen Daten durch einen sequentiellen Prozessor resultiert. Wann immer ein Benutzer die Ausführung eines Programmes auf CS 10110 anfordert, erzeugt das Betriebssystem 40102 einen Prozeß 610, der dann die Prozeduren 602 ausführt, aus denen das Benutzerprogramm besteht. Physikalisch gesprochen ist ein Prozeß 610 ein Satz Datenbasen im Speicher, die den gegenwärtigen Zustand der Programmausführung enthalten, die der Prozeß repräsentiert. Das Betriebssystem 40102 veranlaßt den Prozeß 610, das Programm auszuführen, indem er dem Prozeß 610 Zugang zu den virtuellen Ressourcen gibt, die er zur Ausführung des Programmes erfordert, indem er den virtuellen Ressourcen Zugang zu jenen Bereichen des Zustandes des Prozesses 601 gibt, die sie zur Ausführung ihrer Operationen benötigen, und indem er diesen virtuellen Ressourcen Zugang zu den physikalischen Ressourcen gibt. Die temporäre Beziehung einer Ressource zu einer anderen oder eines Prozesses 610 zu einer Ressource wird binden genannt. Wenn ein Prozeß 610 Zugang zu einem gegebenen virtuellen Prozessor 612 hat, und der virtuelle Prozessor 612 Zugang zu dem Zustand von Prozeß 610 hat, so ist der Prozeß 610 an den virtuellen Prozessor 612 gebunden, und wenn der virtuelle Prozessor 612 Zugang zu JP 10114 hat, und der Zustand des virtuellen Prozessors 612 in die JP 10114 Register geladen werden, so ist der virtuelle Prozessor 612 an JP 10114 gebunden, und JP 10114 kann die SINs ausführen, die in den Prozeduren 602 in dem Programm enthalten sind, das durch den Prozeß 610 ausgeführt wird, und an den virtuellen Prozessor 612 gebunden ist. Binden und Lösen kann mehrere Male im Verlaut der Ausführung eines Programmes durch einen Prozeß 610 auftreten. Wenn z. B. ein Prozeß 610 eine Referenz auf Daten ausführt, und die Daten nicht in MEM 10112 vorhanden sind, dann löst das Betriebssystem 40102 den virtuellen Prozessor 612 des Prozesses 610 von JP 10114, bis die Daten in MEM 10112 verfügbar sind. Wenn die Daten während einer gewissen Zeit nicht verfügbar sind, oder wenn der Benutzer, für den Prozeß 610 das Programm ausführt, wünscht, die Ausführung des Programmes für eine Weile zu beendigen, so kann das Betriebssystem 40102 den Prozeß 610 von seinem virtuellen Prozessor 612 lösen. Der virtuelle Prozessor 612 ist dann für die Nutzung durch andere Prozesse 610 verfügbar.
Wie oben erwähnt, bedeutet der Bindeprozeß, daß einer ersten Ressource Zugang zu einer zweiten Ressource gegeben wird, und daß der Zustand der ersten Ressource in der zweiten Ressource benutzt wird. Um ein Binden und Lösen zu erlauben, verwaltet das Betriebssystem 40102 Datenbasen, die den gegenwärtigen Zustand jeder Ressource und jedes Prozesses 610 beinhalten. Als Zustand können die Informationen definiert werden, die das Betriebssystem braucht, um die Ressource zu nutzen oder den Prozeß 610 auszuführen. Der Zustand eines Zeilendruckers zum Beispiel kann Variablen sein, die anzeigen, ob der Zeilendrucker beschäftigt, frei, vom Netz oder kaputt ist. Der Zustand eines Prozesses 610 ist mannigfaltiger, weil er ausreichende Informationen beinhalten muß, die es dem Betriebssystem 40102 erlauben, einen Prozeß 610 an einen virtuellen Prozessor 612 zu binden, den Prozeß 610 eine Weile lang auszuführen, den Prozeß 610 zu lösen, und ihn dann wieder zu binden und die Ausführung an der Stelle fortzuführen, wo sie angehalten worden war. Der Zustand eines Prozesses 610 beinhaltet daher alle Daten, die vom Prozeß 610 bis zu dem Zeitpunkt benutzt wurden, an dem er von einem virtuellen Prozessor 612 gelöst wurde, zusammen mit Information darüber, ob der Prozeß 610 dazu bereit ist, wieder ausgeführt zu werden.
Fig. 402 zeigt die Beziehung zwischen Prozessen 610, virtuellen und physikalischen Ressourcen in einem Betriebssystem. Die Figur zeigt ein Mehrprozeß-Betriebssystem 40102, d. h. eines, das die CS 10110-Ressourcen unter verschiedenen Prozessen 610 aufteilen kann. Daher scheinen die Prozesse 610 gleichzeitig ausgeführt zu werden. Durchgezogene Pfeile in Fig. 402 zeigen ein Binden zwischen virtuellen Ressourcen oder zwischen virtuellen und physikalischen Ressourcen. Jeder Prozeß 610 wird durch das Betriebssystem 40102 erzeugt, um ein Benutzerprogramm auszuführen. Das Programm besteht aus Prozeduren 602, und der Prozeß 610 führt die Prozeduren 602 in der Reihenfolge aus, die vom Programm vorgeschrieben wird. Die Prozesse 610 werden von einer Komponente des Betriebssystems 40102, die Prozeßmanager genannt wird, erzeugt und verwaltet. Der Prozeßmanager 40203 führt einen Prozeß 610 aus, indem er ihn an einen virtuellen Prozessor 612 bindet. Es kann mehr Prozesse 610 als virtuelle Prozessoren 612 geben. In diesem Fall teilt das Betriebssystem die virtuellen Prozessoren 612 unter den Prozessen 610 auf.
Die virtuellen Prozessoren 612 werden durch eine andere Komponente des Betriebssystems 40102 erzeugt und zur Verfügung gestellt, nämlich dem virtuellen Prozessormanager 40205. Der virtuelle Prozeßmanager 40205 teilt auch JP 10114 unter den virtuellen Prozessoren 612 auf. Wenn ein virtueller Prozessor 612 lauffähig ist, bindet ihn der virtuelle Prozessormanager 40205 an JP 10114. Wenn der virtuelle Prozessor 612 nicht mehr länger laufen kann, oder wenn ein anderer virtueller Prozessor 612 JP 10114 benötigt, löst der virtuelle Prozeßmanager 40205 den laufenden virtuellen Prozessor von JP 10114 und bindet einen anderen virtuellen Prozessor 612 an ihn.
Virtuelle Prozessoren 612 benutzen virtuellen Speicher und I/O-Ressourcen, um Speicherzugriff und Ein- und Ausgabe durchzuführen. Der virtuelle Speicher 40206 wird durch den virtuellen Speichermanager 40207 erzeugt und verwaltet, und die virtuellen I/O-Geräte 40208 werden durch den virtuellen I/O-Manager 40209 erzeugt und verwaltet. Wie der virtuelle Prozeßmanager 40205 teilen die Komponenten 40207 und 40209 des Betriebssystems 40102 die physikalischen Ressourcen unter den virtuellen Ressourcen auf. Wie oben beschrieben, kann ein Satz virtueller Ressourcen einen anderen Satz benutzen. Eine Möglichkeit, wie das passieren kann, wird durch die unterbrochenen Pfeile in Fig. 402 gezeigt. Diese Pfeile zeigen ein Binden zwischen dem virtuellen Speicher 40206 und dem virtuellen I/O-Gerät 40208. Dieses Binden tritt auf, wenn ein virtueller Speicher 40206 eine Referenz auf Daten bearbeiten muß, die auf einem periphären Gerät wie zum Beispiel einem Diskettenlaufwerk sind. Für den Benutzer des virtuellen Speichers 40206 scheinen alle Daten in MEM 10112 zur Verfügung zu stehen. Tatsächlich aber sind die Daten auf dem periphären Gerät wie z. B. Laufwerke gespeichert, und werden in MEM 10112 nach Bedarf kopiert. Wenn ein Prozeß 610 Daten referenziert, die nicht in MEM 10112 kopiert worden sind, muß der virtuelle Speicher 40206 IOS 10116 benutzen, um die Daten in MEM 10112 zu kopieren. Um dies zu tun, benutzt ein virtuelles I/O-Gerät 40208, das vom virtuellen I/O-Manager 40209 zur Verfügung gestellt wird.

b. Das Betriebssystem in CS 10110

Aus Übersichtlichkeitsgründen wurde das Betriebssystem 40102 so beschrieben, als ob es außerhalb von CS 10110 existierte. Tatsächlich aber benutzt das Betriebssystem 40102 selbst die Ressourcen, die es steuert. In der vorliegenden Verkörperung sind Teile des Betriebssystems 40102 in JP 10114-Hardware-Geräten verkörpert, Teile sind im Mikrocode, der auf JP 10114 ausführt, und Teile in den Prozeduren 602 verkörpert. Diese Prozeduren 602 werden manchmal durch Prozesse 610, die Benutzerprogramme ausführen, aufgerufen, und manchmal durch besondere Betriebssystemsprozesse 610, die nur Operationen für das Betriebssystem 40102 ausführen.
Die Weise, in der die Komponenten des Betriebssystems 40102 zusammenspielen, kann durch die Art und Weise illustriert werden, in der CS 10110 einen Seitenfehler verarbeitet, d. h. eine Referenz auf Daten, die nicht in MEM 10112 verfügbar sind. Das erste Anzeichen dafür, daß es einen Seitenfehler geben könnte, ist ein ATU-Fehler-Ereignissignal. Dieses Ereignissignal wird durch ATU 10228 in FU 10120 erzeugt, wenn es keinen Eingang in ATU 10228 für einen logischen Beschreiber 27116 gibt, der bei der Lese- oder Schreiboperation benutzt wird. Das Ereignissignal ruft einen Betriebssystem 40102-Code auf, der eine Tabelle in MEM 10112 untersucht, um zu ermitteln, ob die durch den logischen Beschreiber 27116 beschriebenen Daten eine Kopie in MEM 10112 besitzen. Wenn die Tabelle anzeigt, daß es keine Kopie gibt, verständigt der Betriebssystem 40102-Mikrocode den virtuellen Speichermanagerprozeß 610 des Betriebssystems 40102 über die Tatsache des Seitenfehlers, und entfernt den virtuellen Prozessor 612, der an den Prozeß 610 gebunden ist, und der ausführte, als der Seitenfehler auftrat, von JP 10114. Eine gewisse Zeit später wird der virtuelle Speichermanagerprozeß 610 an JP 10114 gebunden. Die Prozeduren 602, die vom virtuellen Speichermanagerprozeß 610 ausgeführt werden, initiieren I/O-Operationen, die benötigt werden, um die gewünschten Daten im Sekundärspeicher 10124 zu lokalisieren, und kopieren sie in MEM 10112. Wenn die Daten in MEM 10112 verfügbar sind, ermöglicht es das Betriebssystem 40102, daß der virtuelle Prozessor 612, der an den Prozeß 610 gebunden war, der ausführte, als der Seitenfehler auftrat, zu JP 10114 zurückkehrt. Der virtuelle Prozessor 612 wiederholt die Speicherreferenz, die den Seitenfehler verursachte, und da die Daten nun in MEM 10112 sind, ist die Referenz erfolgreich und die Ausführung des Prozesses 610 geht weiter.

c. Erweitertes Betriebssystem und das Kernbetriebssystem (Fig. 403)

In CS 10110 besteht das Betriebssystem 40102 aus zwei Betriebssystemkomponenten, dem erweiterten Betriebssystem (EOS) und dem Kernbetriebssystem (KOS). Das KOS hat direkten Zugang zu den physikalischen Ressourcen. Es definiert einen Satz primitiver virtueller Ressourcen und teilt die physikalischen Ressourcen unter diesen primitiven virtuellen Ressourcen auf. Das EOS hat Zugang zu den primitiven virtuellen Ressourcen, die durch KOS definiert wurden, aber nicht zu den physikalischen Ressourcen. Das EOS definiert einen Satz virtueller Ressourcen auf Benutzerebene und teilt die primitiven virtuellen Ressourcen, die durch KOS definiert wurden, virtuellen Ressourcen auf Benutzerebene auf. Zum Beispiel versorgt KOS EOS mit Prozessen 610 und virtuellen Prozessoren 612 und bindet virtuelle Prozessoren 612 an JP 10114, aber EOS entscheidet, wann ein Prozeß 610 erzeugt werden muß, und wann ein Prozeß 610 an einen virtuellen Prozessor 612 gebunden werden muß.
Fig. 403 zeigt die Beziehungen zwischen einem Benutzerprozeß 610, EOS, KOS und den physikalischen Ressourcen in CS 10110. Fig. 403 zeigt drei Schnittstellenebenen zwischen dem ausführenden Benutzerprozeß 610 und JP 10114. Die höchste Schnittstellenebene ist die Prozedurenebene 40302. Auf dieser Ebene tritt der Prozeß 610 mit CS 10110 in Wechselwirkung, indem er die Prozeduren 602 aufruft, die durch das Programm spezifiziert wurden, das der Prozeß 610 ausführt. Die Aufrufe können entweder Aufrufe von Benutzerprozeduren 40306 oder Aufrufe von EOS-Prozeduren 40307 sein. Wenn der Prozeß 610 eine Prozedur 602 ausführt, erzeugt der Prozeß 610 einen Strom von SINs. Dieser Strom enthält zwei Arten von SINs, S-Sprachen-SINs 40310 und KOS-SINs 40311. Beide Arten von SINs interagieren mit CS 10110 auf der nächsten Schnittstellenebene, der Schnittstelle 40309 auf SIN-Ebene. SINs 40310 und 40311 werden vom Mikrocode 40312 und 40313 interpretiert, und die Mikrobefehle 40315 interagieren mit CS 10110 auf der untersten Schnittstellenebene, der JP 10114-Schnittstelle 40316. Wie bereits bei der Diskussion der FU 10120-Mikromaschine erklärt wurde, resultieren bestimmte Zustände in JP 10114 in Ereignissignalen 40314, die Mikroprogramme im S-Interpreter-Mikrocode 40312 oder KOS-Mikrocode 40313 aufrufen. Nur die Schnittstelle 40302 auf Prozedurenebene und die Schnittstelle 40309 auf SIN-Ebene sind den Benutzern sichtbar. Die Schnittstelle 40309 auf Prozedurenebene erscheint als Aufrufe in Benutzerprozeduren 602 oder als Anweisungen in Benutzerprozeduren 602, die einen Compiler in Aufrufe auf EOS-Prozeduren 602 übersetzt. Die Schnittstelle 40309 auf SIN-Ebene erscheint als Namenstabellen 10335 und SINs in Prozedurobjekten 608, die durch Compiler erzeugt werden.
Wie Fig. 403 anzeigt, existiert EOS nur auf der prozeduralen Ebene 40302, während KOS auf der prozeduralen Ebene 40302, der SIN-Ebene 40304 und innerhalb des Mikrocodes unter der SIN-Ebene 40309 existiert. Der einzige Bereich des Betriebssystems, der direkt den Benutzerprozessen 610 zur Verfügung steht, sind die EOS-Prozeduren 40307. Die EOS-Prozeduren 40307 wiederum rufen KOS-Prozeduren 40308 auf. In vielen Fällen enthält eine EOS-Prozedur 40307 nicht mehr als einen Aufruf einer KOS-Prozedur 40308.
Die Benutzerprozeduren 40306, die EOS-Prozeduren 40307 und die KOS-Prozeduren 40308 enthalten alle S-Sprachen-SINs 40310. Darüber hinaus können nur KOS-Prozeduren 40308 besondere KOS-SINs 40311 enthalten. Die besonderen KOS-SINs 40311 steuern Funktionen, die den EOS-Prozeduren 40307 oder den Benutzerprozeduren 40306 nicht verfügbar sind, und daher dürfen KOS-SINs 40311 nicht in Prozeduren 40306 oder 40307 vorkommen. Die S-Sprachen-SINs 40310 werden vom S-Interpreter-Mikrocode 40312 interpretiert, während die KOS-SINs 40311 vom KOS-Mikrocode 40313 interpretiert werden. Der KOS-Mikrocode 40313 kann auch von S-Interpreter-Mikrocode 40313 aufgerufen werden. Abhängig von Hardware-Zustände, die Ereignissignale 40314 erzeugen, können die Signale 40314 die Ausführung von entweder S-Interpreter-Mikrocode 40312 oder KOS-Mikrocode 40313 verursachen.
Fig. 403 zeigt das System, wie es einen Benutzerprozeß 610 ausführt. Es gibt zusätzlich besondere Prozesse 610, die für den Gebrauch für KOS und EOS vorbehalten sind. Diese Prozesse 610 arbeiten wie Benutzerprozesse 610, aber sie führen Betriebssystemfunktionen wie Prozeßmanagement und virtuelles Speichermanagement aus. Mit einer Ausnahme rufen EOS-Prozesse 610 EOS-Prozeduren 40307 und KOS-Prozeduren 40308 auf, während KOS-Prozesse 610 nur KOS-Prozeduren 40308 aufrufen. Die Ausnahme ist der Beginn der Ausführung eines Prozesses 610: KOS führt KOS-Ebenenfunktionen durch, die benötigt werden, die Ausführung eines Prozesses 610 zu beginnen, und ruft dann EOS auf. EOS führt die erforderlichen EOS-Ebenenfunktionen durch und ruft dann die erste Benutzerprozedur 40306 in dem Programm auf, das der Prozeß 610 ausführt.
Eine Beschreibung dessen, wie KOS Seitenfehler verarbeitet, kann zur Erläuterung dienen, wie die Teile des Systems auf JP 10114-, SIN- und Prozedurenebene zusammenarbeiten. Ein Seitenfehler tritt auf, wenn ein Prozeß 610 einen Datenausdruck referenziert, der keine Kopie in MEM 10112 besitzt. Der Seitenfehler beginnt als Ereignissignal von ATU 10228. Das Ereignissignal ruft ein Mikroprogramm im KOS-Mikrocode 40313 auf. Wenn das Mikroprogramm bestätigt, daß der referenzierte Datenausdruck nicht in MEM 10112 ist, so zeichnet es die Tatsache des Seitenfehlers in einigen KOS-Tabellen in MEM 10112 auf und ruft ein anderes KOS-Mikroprogramm auf, das den virtuellen Prozessor 612, der an den Prozeß 610 gebunden ist, der den Seitenfehler verursachte, von JP 10114 löst, und ermöglicht es einem anderen virtuellen Prozessor 612 eines anderen Prozesses 610, zu laufen. Einige Zeit nach dem Seitenfehler läuft ein besonderer Betriebssystemprozeß 610, der virtuelle Speichermanagerprozeß 610, und führt KOS-Prozeduren 40309 aus. Der virtuelle Speichermanagerprozeß 610 initiiert die I/O-Operation, die die Daten aus dem Sekundärspeicher 10124 in MEM 10112 liest. Wenn IOS 10116 die Operation beendet hat, kann der Prozeß 610, der den Seitenfehler verursachte, wieder laufen und der virtuelle Speichermanagerprozeß 610 führt eine Operation durch, die bewirkt, daß der virtuelle Prozessor 612 des Prozesses 610 wieder an JP 10114 gebunden wird. Wenn der Prozeß 610 seine Ausführung wieder aufnimmt, versucht er wieder, die Daten zu referenzieren. Die Daten befinden sich nun in MEM 10112 und daher tritt der Seitenfehler nicht mehr auf.
Die Einteilung des Betriebssystems 40102 in einer hierarchischen Verbindung stehenden Betriebssysteme ist für CS 10110 kennzeichnend. Mehrere Vorteile werden durch eine solche Unterteilung erreicht:
- Jedes einzelne der beiden Betriebssysteme ist einfacher, als es ein einziges Betriebssystem wäre. EOS kann sich hauptsächlich mit Aufgaben der Ressourcen- Allokation und virtuellen Ressourcen höherer Ebene beschäftigen, während KOS sich mit den virtuellen Ressourcen auf unterer Ebene und der Steuerung der Hardware beschäftigt.
- Da jedes Betriebssystem einfacher ist, ist es einfacher zu überprüfen, daß die Komponenten jedes Betriebssystems korrekt arbeiten, und die beiden Systeme sind daher zuverlässiger als es ein einzelnes System wäre.
- Die Unterteilung des Betriebssystems 40102 macht es einfacher, verschiedene Verkörperungen von CS 10110 zu implementieren. Nur die von EOS zur Verfügung gestellte Schnittstelle ist dem Benutzer sichtbar, und daher kann die Benutzerschnittstelle zum System ausgewechselt werden, ohne daß KOS geändert werden muß. Ein einziges CS 10110 kann sogar mehrere EOSs haben, und daher verschiedene Schnittstellen verschiedenen Benutzern präsentieren. In ähnlicher Weise beeinflussen Änderungen in der Hardware die Implementierung des KOS, aber nicht die Schnittstelle, die KOS EOS zur Verfügung stellt. Ein gegebenes EOS kann daher auf mehr als einer Verkörperung von CS 10110 laufen.
- Ein geteiltes Betriebssystem ist sicherer als ein einziges Betriebssystem. Der physikalische Zugang zu JP 10114 wird ausschließlich durch KOS zur Verfügung gestellt, und daher kann KOS sicherstellen,daß Benutzer nur die Ressourcen manipulieren können, zu denen sie Zugangsrechte besitzen.
Alle CS 10110s haben durch KOS definierte virtuelle Ressourcen, während die durch EOS definierten Ressourcen von einem CS 10110 zu einem anderen variieren, und dies sogar innerhalb eines CS 10110s tun können. Daher betrifft der Rest der Diskussion KOS.
Die Beziehungen zwischen KOS und dem Rest von CS 10110 werden durch vier Grundsätze bestimmt:
- Nur das KOS hat Zugang zu den Ressourcen, die es steuert. EOS-Benutzeraufrufe können dazu führen, daß EOS KOS aufruft und S-Sprachen-SINs können dazu führen, daß es Aufrufe von KOS-Mikrocode-Programmen gibt, aber weder EOS noch Benutzerprogramme können direkt die durch KOS gesteuerten Ressourcen manipulieren.
- Das KOS ist passiv. Es antwortet auf Aufrufe von EOS, auf Mikrocode-Aufrufe und auf Ereignissignale, aber es initiiert keinerlei Aktionen für sich selbst.
- Das KOS ist allen Systembenutzern unsichtbar außer EOS. KOS beeinflußt nicht das logische Verhalten eines Prozesses 610 und ist den Benutzern nur hinsichtlich der Geschwindigkeit wahrnehmbar, mit der ein Prozeß 610 im CS 10110 arbeitet.
Wie oben beschrieben, verwaltet KOS sowohl physikalische als auch virtuelle Ressourcen. Die physikalischen Ressourcen und manche der virtuellen Ressourcen sind nur innerhalb KOS sichtbar. Andere virtuelle Ressourcen werden EOS zur Verfügung gestellt. Jede virtuelle Ressource hat zwei Hauptteile: einen Satz Datenbasen, die den Zustand der virtuellen Ressourcen beinhalten, und einen Satz von Programmen, die die virtuelle Ressource manipulieren. Der Satz Programme für eine virtuelle Ressource wird der Manager der Ressource genannt. Die Programme können KOS-Prozeduren 40308 oder KOS-Mikrocode 40313 sein. Wie erwähnt, benutzt KOS in manchen Fällen separate Prozesse 610, um die Ressourcen zu verwalten.
Was den Gegenstand dieser Spezifikation angeht, so kann man die von KOS verwalteten Ressourcen in zwei Hauptgruppen unterteilen: die, die mit Objekten assoziiert sind, und die, die mit Prozessen 610 assoziiert sind. Im folgenden werden zuerst die Ressourcen, die mit Objekten assoziiert sind, und dann die mit Prozessen 610 assoziiert sind, besprochen.

B. Objekte und Objektmanagement (Fig. 404)

Die virtuellen Ressourcen, Objekte genannt, werden durch KOS definiert und durch EOS und KOS manipuliert. Objekte, wie sie von EOS gesehen werden, haben fünf Eigenschalten:
- Eine einzige UID, die das Objekt während seiner gesamten Lebensdauer identifiziert und spezifiziert, zu welcher logischen Allokationseinheit (LAU) das Objekt gehört.
- Einen Satz von Attributen, die das Objekt beschreiben und den Zugang zu ihm begrenzen.
- Bit-adressierbare Inhalte. In der vorliegenden Verkörperung können die Inhalte im Bereich 0 bis (2³²) - 1 lang sein. Jedes Bit in den Inhalten kann durch einen Abstand adressiert werden.
- Objekte können erzeugt werden.
- Objekte können zerstört werden.
Sämtliche Daten und Prozeduren 602 in einem CS 10110 sind in Objekten enthalten. Jeder Prozeß 610, der auf CS 10110 ausführt, kann eine UID-Abstandsadresse benutzen, um zu versuchen, Zugang auf Daten oder Prozeduren 602 in bestimmten Objekten auf jedem beliebigen CS 10110 zu gewinnen, das für das CS 10110, auf dem der Prozeß 610 ausführt, zugänglich ist. Die Objekte, auf die so durch jeden beliebigen Prozeß 610 zugegriffen werden kann, sind die, die UIDs besitzen, die garantiert für alle vorliegenden und zukünftigen CS 10110 eindeutig sind. Objekte mit solchen eindeutigen UIDs bilden so einen einzigen Adreßraum, der mindestens potentiell für jeden anderen Prozeß 610 verfügbar ist, der auf jeder beliebigen CS 10110 ausführt. Wie später genauer erklärt wird, hängt die Frage, ob ein Prozeß 610 tatsächlich Zugang zu einem Objekt in diesem einzigen Adreßraum hat, davon ab, ob der Prozeß 610 Zugangsrechte auf das Objekt besitzt. Auf andere Objekte, deren UIDs nicht eindeutig sind, kann nur durch Prozesse 610 zugegriffen werden, die auf CS 10110 oder Gruppen von CS 10110 laufen, für die die nicht eindeutige UID tatsächlich eindeutig ist. Es haben nie zwei Objekte, die für eine CS 10110 zu einem gegebenen Zeitpunkt zugänglich sind, zwei identische UIDs.
Die folgende Diskussion der Objekte beschäftigt sich zuerst mit den Objekten, wie sie direkt durch EOS und indirekt durch Benutzerprogramme gesehen werden, und dann mit den Objekten, wie sie KOS erscheinen.
Fig. 404 verdeutlicht, wie die Objekte EOS erscheinen. Das Objekt hat drei Teile: die UID 40401, die Attribute 40404 und die Inhalte 40406. Die Inhalte des Objekts befinden sich in einer logischen Allokationseinheit (LAU) 40405. Die UID 40401 hat zwei Teile: einen LAU-Identifizierer (LAUID) 40402, der anzeigt, auf welcher LAU 40405 das Objekt ist, und die Objektseriennummer (OSN) 40403, die das Objekt in der LAU 40405 spezifiziert.
Das EOS kann ein Objekt in einer LAU 40405 erzeugen, und wenn es die UID 40401 des Objektes besitzt, kann es dieses zerstören. Darüber hinaus kann EOS die Attribute 40404 des Objektes lesen und verändern. Jeder beliebige Prozeß 610, der auf einem CS 10110 ausführt, kann Informationen in einem Objekt referenzieren, indem er die UID 40401 des Objektes spezifiziert und das Bit im Objekt, an dem die Information anfängt. In der höchsten Ebene bestehen die Adressen in CS 10110 daher aus einer UID 40401, die ein Objekt spezifiziert, und einem Abstand, der die Anzahl Bits in das Objekt bestimmt, an dem die Information anfängt. Wie unten genauer erklärt wird, übersetzt KOS solche UID- Abstandsadressen in Zwischenformen, die AON-Abstandsadressen genannt werden, für den Gebrauch in JP 10114, und in Seitennummern-Entfernungsadressen zur Benutzung zur Referenzierung von Information, die in MEM 10112 kopiert wurde.
Die physikalische Implementierung und Manipulation der Objekte ist ausschließlich KOS vorbehalten. Zum Beispiel werden Objekte und ihre Attribute tatsächlich im Sekundärspeicher 10124 gespeichert. Wenn ein Programm einen Bereich eines Objektes referenziert, kopiert KOS diesen Bereich des Objektes vom Sekundärspeicher 10124 in MEM 10112, und wenn der Bereich in MEM 10112 geändert wird, so aktualisiert es die Kopie des Objektes im Sekundärspeicher 10124. EOS und Benutzerprogramme können die Lokation eines Objektes im Sekundarspeicher 10124 oder die Lokation der Kopie eines Bereiches eines Objektes in MEM 10112 nicht steuern, und können deshalb nur über KOS auf das Objekt zugreifen.
Während EOS die physikalische Implementierung eines Objektes nicht steuern kann, kann es KOS mit Informationen versorgen, die es KOS erlauben, die Objekte effektiver zu verwalten. Solche Informationen werden Hinweise genannt. Zum Beispiel kopiert KOS allgemein einen Bereich eines Objektes nur dann in MEM 10112, wenn ein Prozeß 610 Informationen in dem Objekt referenziert. EEOS jedoch plant den Ablauf der Ausführung des Prozesses 610 und kann daher vorhersagen, daß bestimmte Objekte in naher Zukunft benötigt werden. EOS kann diese Information KOS übergeben, und KOS kann diese Information benutzen, um zu entscheiden, welche Bereiche des Objektes in MEM 10112 zu kopieren sind.

a. Objekte und Benutzerprogramme (Fig. 405)

Wie oben beschrieben, manipulieren Benutzerprogramme Objekte, aber die Objekte sind im allgemeinen nicht den Benutzerprogrammen sichtbar. Statt dessen benutzen Benutzerprogramme Symbole wie Variablennamen oder andere Referenzen, um sich auf Daten zu beziehen, die in Objekten gespeichert sind, oder Dateinamen, um sich auf die Objekte selbst zu beziehen. Die Diskussion des Adreßraums hat bereits verdeutlicht, wie die CS 10110-Compiler Variablennamen, die in Anweisungen in den Prozeduren 602 auftauchen, in Namen, d. h. Indizes der NTEs 30401 übersetzen, wie der Namensauflöse-Mikrocode NTE 30401 in logische Beschreiber 27116 auflöst und wie ATU 10228 die logischen Beschreiber 27116 in Lokationen in MEM 10112 übersetzt, die die Kopien der Bereiche der Objekte enthalten, in denen die durch die Variablen repräsentierten Daten sich befinden.
Die Übersetzung von Dateinamen in UIDs 40401 wird durch EOS durchgeführt. EOS verwaltet eine Dateinamen-Übersetzungstabelle, die eine Beziehung zwischen den Systempfeilnamen - Pfadname genannt - und der UID 40401 des Objektes aufstellt, daß die Daten der Datei enthält, und verbindet so den Pfadnamen mit dem Objekt. Ein Pfadname ist eine Abfolge von ASCII-Zeichen, die eine Datei für einen Benutzer von CS 10110 identifiziert. Jeder Pfadname in einem gegebenen CS 10110 muß eindeutig sein. Fig. 405 zeigt die Dateinamens-Übersetzungstabelle. Sich auf jene Figur beziehend, benutzt EOS die Dateinamens-Übersetzungstabelle 40503, wenn ein Benutzer einen Pfadnamen 40501 an EOS übergibt, um den Pfadnamen 40501 in eine UID 40401 für ein Objekt 40504 zu übersetzen, das die Datei beinhaltet. Ein Objekt in CS 10110 kann so auf zwei Arten identifiziert werden: durch seine UID 40401 oder durch den Pfadnamen 40501. Während ein Objekt nur eine einzige UID 40401 während seiner gesamten Lebensdauer besitzt, kann das Objekt viele Pfadnamen 40501 haben. Alles was zur Veränderung des Pfadnamens 40501 eines Objektes benötigt wird, ist die Ersetzung eines Pfadnamens 40501 durch einen anderen in dem Eintrag 40502 des Objektes in der Dateinamens-Übersetzungstabelle 40503. Eine Folgerung aus der Tatsache, daß ein Objekt während seiner Lebensdauer verschiedene Pfadnamen 40501 haben kann, ist, daß wenn ein Programm einen Pfadnamen 40501 zur Identifizierung eines Objektes benutzt, der Benutzer des CS 10110 das Programm veranlassen kann, ein anderes Objekt zu verarbeiten, indem er dem Objekt, das vorher den Pfadnamen 40501 hatte, der im Programm auftaucht, einen neuen Pfadnamen 40501 gibt, und dem nächsten zu verarbeitenden Objekt den Pfadnamen 40501 gibt, der im Programm auftaucht.
In der gegenwärtigen Verkörperung kann ein Objekt nur eine einzelne Datei enthalten, und daher bezieht sich ein Pfadname 40501 immer auf ein ganzes Objekt. In anderen Verkörperungen kann sich ein Pfadname 40501 auf einen Bereich eines Objektes beziehen, und in solchen Verkörperungen assoziiert die Dateinamen-Übersetzungstabelle 40503 einen Pfadnamen 40501 mit einer UID-Abstandsadresse, die den Anfang der Datei spezifiziert.

b. UIDs 40401 (Fig. 406)

UIDs 40401 können Objekte und andere Einheiten in CS 10110 identifizieren. Jede Einheit, die durch eine UID 40401 identifiziert wurde, hat nur eine einzige UID während ihres gesamten Lebens. Fig. 406 ist eine genaue Darstellung der UID 40401 eines CS 10110. Die UID 40401 ist 80 Bits lang und hat zwei Felder. Das Feld 40402 ist 32 Bits lang und ist der logische Allokationseinheiten-Identifizierer (LAUID). Er spezifiziert LAU 40405, die das Objekt enthält. LAUID 40402 wird weiter in zwei Unterfelder unterteilt: die LAU-Gruppennummer (LAUGN) 40607 und die LAU-Seriennummer (LAUSN) 40605. LAUGN 40607 spezifiziert eine Gruppe von LAUs 40465 und LAUSN 40605 spezifiziert eine LAU 40405 in dieser Gruppe. Käufer eines CS 10110 können LAUGNs 40607 vom Hersteller erhalten. Der Hersteller garantiert, daß er die dem Käufer gegebene LAUGN 40607 keinem anderen CS 10110 zuordnen wird, und daher können die LAUGNs 40607 dazu benutzt werden, eindeutige UIDs 40401 zu bilden, die für alle CS 10110 eindeutig sind. Das Feld 40604 ist 48 Bits lang und stellt die Objektseriennummer (OSN) dar. Es spezifiziert das Objekt in LAU 40405.
UIDs 40401 werden von KOS-Prozeduren 602 erzeugt. Es gibt zwei solche Prozeduren 602, eine erzeugt UIDs 40401, die Objekte identifizieren, und eine andere, die UIDs 40401 erzeugen, die andere Einheiten in CS 10110 identifizieren. Die erste Prozedur 602 wird Objekt UID-erzeugen genannt, und die letztere nicht Objekt UID-erzeugen. Die Objekt UID-erzeugen-Prozedur 602 wird nur durch die KOS-Prozedur 602 Objekterzeugen aufgerufen. Die Prozedur 602 versorgt die Prozedur 602 Objekt UID-erzeugen mit einem LAUID 40402, und die Objekt UID-erzeugen-Prozedur 602 gibt eine UID 40401 für das Objekt zurück. In der gegenwärtigen Verkörperung wird die UID 40401 gebildet, indem der gegenwärtige architektonische Takt genommen wird, der in einer Lokation in MEM 10112 enthalten ist, und damit eine OSN 40403 aus dem gegenwärtigen Wert des architektonischen Taktes gebildet wird, und indem die OSN 40403 mit dem LAUID 40402 verkettet wird.
Die nicht Objekt UID-erzeugen-Prozedur 602 kann durch EOS aufgerufen werden, um eine UID 40401 zur Verfügung zu stellen, die kein Objekt spezifiziert. Nicht Objekt-UIDs 40401 können in CS 10110 überall dort benutzt werden, wo ein eindeutiges Kennzeichen erforderlich ist. Zum Beispiel haben, wie später noch genauer erklärt wird, alle virtuellen Prozessoren 612, die für CS 10110 verfügbar sind, nicht Ojekt-UIDs 40401. Alle solche nicht Objekt-UIDs 40401 haben eine einzelne LAUSN 40607, und daher braucht EOS nur eine LAUGN 40605 als Argument zur Verfügung stellen. Die nicht Objekt UID-erzeuge-Prozedur 602 verkettet LAUGN 40605 mit der speziellen LAUSN 40607, und der so erzeugte LAUID 40402 mit einer OSN 40403, die vom architektonischen Systemtakt erhalten wird. In anderen Verkörperungen können OSNs 40403 sowohl für Objekt- als auch für nicht Objekt-UIDs 40401 durch andere Mittel erzeugt werden, wie z. B. Zähler.
CS 10110 hat auch eine besondere UID 40401, die die Null-UID 40401 genannt wird. Die Null-UID 40401 enthält nur Null-Bits und wird in Situationen verwendet, die einen UID- Wert erfordern, der keine Einheit in CS 10110 darstellen kann.

c. Objektattribute

Was ein Programm mit einem Objekt tun kann, wird durch die Attribute 40404 des Objekts bestimmt. Es gibt zwei Arten von Attributen 40404: die Objektattribute und die Steuerattribute. Die Objektattribute beschreiben die Inhalte des Objekts. Die Steuerattribute steuern den Zugang auf das Objekt. Objekte können Attribute 40404 besitzen, obwohl sie keine Inhalte 40406 haben, und in manchen Fällen können Objekte nur für ihre Attribute 40404 existieren.
Im Zusammenhang mit dem Gegenstand dieser Diskussion gibt es zwei Arten von Objektattributen: das Größenattribut und das Typenattribut.
Das Größenattribut eines Objektes zeigt die Anzahl von Bits an, die das Objekt gegenwärtig enthält. Bei jeder Referenz zu den Inhalten 40406 stellt KOS sicher, daß die Daten, auf die zugegriffen wird, nicht über das Ende des Objektes hinausgehen. Wenn sie es tun, wird die Referenz abgebrochen.
Die Typenattribute zeigen an, welche Art von Information das Objekt enthält, und wie diese Information benutzt werden kann. Es gibt drei Kategorien von Typenattributen: die primitiven Typenattribute, die erweiterten Typenattribute und das Ausführungsbereichs- Attribut. Das primitive Typenattribut eines Objektes zeigt an, ob das Objekt ein Datenobjekt, ein Prozedurobjekt 608, ein erweiterter Typenmanager oder ein S-Interpreter ist. Wie man aus ihren Namen schließen kann, enthalten Datenobjekte Daten und Prozedurobjekte 608 enthalten Prozeduren 602. Die erweiterten Typenmanager (ETMs) sind besondere Typen von Prozedurobjekten 608, deren Prozeduren 608 Operationen nur mit Objekten ausführen können, die erweiterte Typenobjekte genannt werden. Erweiterte Typenobjekte (ETOs) sind Objekte, die ein erweitertes Typenattribut zusätzlich zu ihrem primitiven Typenattribut besitzen; wegen Einzelheiten siehe die Diskussion des erweiterten Typenattributes unten. S-Interpreter sind Objekte, die Interpreter für S-Sprachen beinhalten. In der gegenwartigen Verkörperung bestehen die Interpreter aus Aufteilungstabellen und Mikrocode, aber in anderen Verkörperungen können Interpreter selbst in Hochsprachen geschrieben sein. Wie das Längenattribut, helfen die primitiven Typenattribute KOS, sicherzustellen, daß ein Programm ein Objekt korrekt benutzt. Wenn zum Beispiel KOS einen Aufruf einer Prozedur 602 ausführt, prüft es, ob das durch den Aufruf spezifizierte Objekt ein Prozedurobjekt ist. Wenn nicht, schlägt der Aufruf fehl.

d. Attribute und Zugangskontrolle

Die verbleibenden Objektattribute und die Steuerattribute sind sämtlich Teil des Zugangskontrollsystems von CS 10110. Das Zugangskontrollsystem wird später genauer diskutiert; hier wird es nur insoweit diskutiert, wie es erforderlich ist für die Diskussion der Objekte. In CS 10110 tritt ein Zugriff auf ein Objekt auf, wenn ein Prozeß 610 die in einem Prozedurobjekt 608 enthaltenen SINs aufnimmt, Daten von einem Objekt liest, Daten in ein Objekt schreibt oder in manchen Fällen, wenn ein Prozeß 610 die Kontrolle an eine Prozedur 602 übergibt. Das Zugangskontrollsystem prüft, ob ein Prozeß 610 das Recht besitzt, den Zugang durchzuführen, den es versucht. Es gibt zwei Arten von Zugang im CS 10110, der primitive Zugang und der erweiterte Zugang. Der primitive Zugang ist der Zugang, den das Zugangskontrollsystem bei jeder Referenz eines Objektes durch einen Prozeß 610 überprüft; der erweiterte Zugang ist ein Zugang, der nur auf Benutzeranforderung hin geprüft wird. Überprüfungen des primitiven Zugangs werden bei allen Objekten durchgeführt; Überprüfungen erweiterten Zugangs können nur bei ETOs durchgeführt werden, und sie können nur durch Prozeduren 602 durchgeführt werden, die in ETMs enthalten sind.
Die Hilfsmittel, durch die das Zugangskontrollsystem den Zugang eines Prozesses 610 auf ein Objekt überprüft, sind das Subjekt des Prozesses 610 und die Zugangskontroll-Listen (ACLs) des Objektes. Jeder Prozeß 610 hat ein Subjekt, das aus vier UIDs 40401 besteht. Diese UIDs 40401 spezifizieren folgendes:
- Den Benutzer, für den der Prozeß 610 kreiert wurde. Diese UID 40401 wird die Hauptkomponente des Subjektes genannt.
- Den Prozeß 610 selbst. Diese UID 40401 wird die Prozeßkomponente genannt.
- Den Bereich, in dem der Prozeß 610 gegenwärtig ausführt. Diese UID 40401 wird Bereichskomponente genannt.
- Eine Benutzer-definierte Untergruppe von Subjekten. Diese UID 40401 wird die Kennzeichenkomponente genannt.
Ein Bereich ist eine Gruppe von Objekten, auf die durch einen beliebigen Prozeß 610 potentiell zugegriffen werden kann, der eine Prozedur 602 in einem Prozedurobjekt 608 von einer Gruppe von Prozedurobjekten 608 oder in ETMs ausführt. Jedes Prozedurobjekt 608 oder ETM hat ein Ausführungsbereich (DOE)-Attribut. Dieses Attribut ist eine UID 40401, und während ein Prozeß 610 eine Prozedur 602 in jenem Prozedurobjekt 608 oder ETM ausführt, ist die UID 40401 des DOE-Attributs die Bereichskomponente im Subjekt eines Prozesses 610. Das DOE-Attribut definiert so eine Gruppe von Objekten, auf die durch einen Prozeß 610 zugegriffen werden kann, der Prozeduren 602 vom Prozedurobjekt 608 ausführt. Die Gruppe von Objekten wird der Bereich des Prozedurobjekts 608 genannt. Wie aus der obigen Definition sichtbar wird, kann sich die Bereichskomponente eines Subjektes bei jedem Aufruf oder jeder Rückkehr von einer Prozedur 602 ändern. Die Kennzeichenkomponente kann sich ändern, wann immer es der Benutzer wünscht. Die Hauptkomponente und die Prozeßkomponente andererseits ändert sich im Leben eines Prozesses 610 nicht.
Die ACLs, die die andere Hälfte des Zugangskontrollsystems ausmachen, sind Attribute von Objekten. Jede ACL besteht aus einer Reihe von Einträgen (ACLE), und jeder ACLE hat zwei Teile: eine Subjektschablone und einen Satz Zugangsprivilegien. Die Subjektschablone definiert eine Gruppe von Subjekten, und der Satz von Zugangsprivilegien definiert die Zugangsarten, die zu der Gruppe dazugehörige Subjekte auf das Objekt haben. Um zu prüfen, ob ein Zugang zu einem Objekt legal ist, untersucht KOS die ACLs. Es erlaubt den Zugriff nur dann, wenn es einen ACLE findet, dessen Subjektschablone zu dem gegenwärtigen Subjekt des Prozesses 610 paßt, daß den Zugriff zu machen wünscht, und dessen Zugangsprivilegien-Satz die Art des Zugangs beinhaltet, der vom Prozeß 610 gewünscht wird. Zum Beispiel kann ein Prozedurobjekt 608 eine ACL mit zwei Einträgen haben: einen, dessen Subjektschablone allen Subjekten Zugang gewährt, und dessen Zugangsprivilegien nur Ausführungszugang erlauben, und einen anderen, dessen Subjektschablone nur einem einzelnen Subjekt Zugang gewährt, und dessen Satz von Zugangsprivilegien Lese-, Schreib- und Ausführungszugriff erlaubt. Solch eine ACL erlaubt es einem beliebigen Benutzer von CS 10110, die Prozeduren 602 im Prozedurobjekt 608 auszuführen, aber nur ein spezifizierter Prozeß 610, der zu einem spezifizierten Benutzer gehört und eine spezifizierte Gruppe von Prozeduren 602 ausführt, darf die Prozeduren 602 in dem Prozedurobjekt 608 untersuchen oder verändern.
Es gibt zwei Arten von ACLs. Alle Objekte haben primitive Zugangskontroll-Listen (PACLs); ETOs können zusätzlich erweiterte Zugangskontroll-Listen (EACLs) haben. Der Subjektbereich des ACLE ist der gleiche in allen ACLs; die beiden Listenarten unterscheiden sich in der Zugangsart, die sie steuern. Der Zugang, der von der PACL gesteuert wird, wird durch KOS definiert und durch KOS bei jedem Versuch, einen solchen Zugang zu gewinnen, überprüft; der durch die EACL gesteuerte Zugang wird durch den Benutzer definiert und nur dann überprüft, wenn der Benutzer dies von KOS anfordert.

e. Implementation von Objekten

1. Einführung (Fig. 407 498)

Der Benutzer eines CS 10110 braucht sich nur um Objekte kümmern, wie sie eben beschrieben wurden. Damit ein Prozeß 610 ein Objekt referenzieren kann, muß die LAU 40405 des Objektes für das CS 10110 zugänglich sein, auf dem der Prozeß 610 läuft, der Prozeß 610 muß die UID 40401 des Objektes kennen und das gegenwärtige Subjekt des Prozesses 610 muß die Zugangsrechte besitzen, um auf das Objekt in der gewünschten Weise zugreifen zu können. Der Prozeß 610 braucht nicht wissen, wie die Inhalte 40406 des Objektes und die Attribute 40404 in CS 10110's physikalischen Geräten gespeichert sind und auch nicht die Methoden, die CS 10110 verwendet, um die Inhalte 40406 des Objektes und die Attribute 40404 dem Prozeß 610 zugänglich zu machen.
Das KOS andererseits muß die Objekte auf den physikalischen Geräten, aus denen CS 10110 besteht, implementieren. Dabei muß es zwei Sätze physikalischer Begrenzungen in Betracht ziehen:
- Logisch gesehen haben alle CS 10110's einen einzigen logischen Speicher, aber die physikalische Implementation des Speichers im System ist hierarchisch. Ein gegebenes CS 10110 hat schnellen Zugriff zu einem relativ kleinen MEM 10112, viel langsameren Zugriff zu einem relativ großen Bereich des langsamen Sekundärspeichers 10124, und sehr langsamen Zugriff auf LAUs 40405 auf anderen zugänglichen CS 10110s.
- UIDs 40401 und sogar Subjekte sind zu groß, um effizient auf den internen Datenpfaden und in den JP 10114-Registern verarbeitet zu werden.
Die Mittel, durch die KOS diese physikalischen Begrenzungen überwindet, variieren von Verkörperung zu Verkörperung. Hier werden zuerst ein Überblick und danach eine genaue Diskussion der Hilfsmittel gegeben, die in der gegenwärtigen Verkörperung benutzt werden.
Die physikalischen Begrenzungen des Speichers werden durch ein virtuelles Speichersystem überwunden. Das virtuelle Speichersystem erzeugt einen logischen Ein-Ebenen- Speicher, indem es automatisch Kopien jener Bereiche von Objekten, die durch ausführende Prozesse 610 benötigt werden, in MEM 10112 bringt, und automatisch geänderte Bereiche von Objekten von MEM 10112 zurück zum Sekundärspeicher 10124 kopiert. So verbleiben die Objekte hauptsächlich im Sekundärspeicher 10124, aber Kopien von Bereichen von ihnen werden in MEM 10112 verfügbar gemacht, wenn ein Prozeß 610 sie referenziert. Abgesehen davon, daß es Bereiche von Objekten in MEM 10112 nach Bedarf bringt, führt das virtuelle Speichersystem darüber Buch, wo in MEM 10112 die Bereiche lokalisiert sind, und wenn ein Prozeß 610 einen Bereich eines Objektes, der in MEM 10112 ist, referenziert, so übersetzt das virtuelle Speichersystem die Referenz in eine physikalische Lokation in MEM 10112.
JP 10114's Bedarf nach kleineren Objektidentifizierern und Subjektidentifizierern wird durch den Gebrauch von internen Identifizierern, den sogenannten aktiven Objektnummern (AONs) und den aktiven Subjektnummern (ASNs) innerhalb JP 10114 gedeckt. Jedesmal, wenn eine UID 40401 von MEM 10112 in die JP 10114-Register geschoben wird, wird es in eine AON übersetzt, und die umgekehrte Übersetzung findet jedesmal dann statt, wenn eine AON von den JP 10114-Registern zu MEM 10112 geschoben wird. In ähnlicher Weise werden die gegenwärtigen Subjekte des Prozesses 610, die an die virtuellen Prozessoren 612 gebunden sind, von vier UIDs 40401 in kleinere ganzzahlige ASNs übersetzt, und wenn der virtuelle Prozessor 612 an JP 10114 gebunden wird, wird die ASN für das Subjekt, das zu dem Prozeß 610 des virtuellen Prozessors 612 gehört, in ein JP 10114-Register plaziert. Die Übersetzungen von UID 40401 nach AON und umgekehrt und die von Subjekten in ASNs werden von KOS durchgeführt.
Wenn KOS UIDs 40401 in AONs und umgekehrt übersetzt, benutzt es AOT 10712. Ein AOT 10712-Eintrag (AOTE) für ein Objekt enthält die UID 40401 des Objektes, und der Index von AOTE in AOT 10712 ist die AON jenes Objektes. Daher kann KOS, bei gegebener AON eines Objektes AOT 10712 dazu benutzen, die UID 40401 des Objektes zu bestimmen, und bei gegebener UID 40401 eines Objektes kann KOS AOT 10712 dazu benutzen, die AON des Objektes zu bestimmen. Wenn das Objekt in jüngster Vergangenheit nicht referenziert wurde, ist es möglich, daß es keinen AOTE für das Objekt gibt, und daher keine AON für die UID 40401 des Objektes. Objekte, die keine AONs haben, werden inaktive Objekte genannt. Wenn bei einem Versuch, eine UID 40401 in eine AON umzuwandeln, herauskommt, daß das Objekt inaktiv ist, resultiert ein inaktives Objekt- Fehler und KOS muß das Objekt aktivieren, d. h. es muß dem Objekt eine AON zuweisen und einen AOTE für es machen.
KOS benutzt AST 10914, um Subjekte in ASNs zu übersetzen. Wenn das Subjekt eines Prozesses 610 sich ändert, stellt AST 10914 dem Prozeß 610 die ASN des neuen Subjektes zur Verfügung. Es kann vorkommen, daß ein Subjekt gegenwärtig keine mit ihm verbundene ASN besitzt. Solche Subjekte werden inaktive Subjekte genannt. Wenn ein Subjekt inaktiv ist, veranlaßt ein Versuch, das Subjekt in eine ASN zu übersetzen, KOS dazu, das Subjekt zu aktivieren, d. h. dem Subjekt eine ASN zuzuweisen, und einen Eingang für das Subjekt in AST 10914 herzustellen.
Um eine effiziente Programmausführung durch die Prozesse 610 zu erreichen, beschleunigt KOS die Informationen, die häufig bei der Ausführung der Prozesse 610 benutzt werden. Es gibt zwei Beschleunigungsstufen:
- Tabellen, die die Informationen enthalten, werden in MEM 10112 verdrahtet, d. h. das virtuelle Speichersystem benutzt den MEM 10112-Raum, der für die Tabellen reserviert ist, nie für andere Zwecke.
- Besondere Hardware-Geräte in JP 10114 enthalten Bereiche der Information in den Tabellen.
MHT 10716, AOT 10712 und AST 10914 sind Beispiele für die erste Beschleunigungsstufe. Wie oben schon erwähnt, sind diese Tabellen immer in MEM 10112 vorhanden. Die Adressenübersetzungseinheit (ATU) 10228 ist ein Beispiel für die zweite Stufe. Wie oben erklärt, ist ATU 10228 ein Hardware-Zwischenspeicher, der Kopien der am häufigsten gebrauchten MHT 10716-Eingänge enthält. Wie MHT 10716 übersetzt sie AON-Abstandsadressen in MEM 10112-Lokationen, die Kopien der Daten enthalten, auf die sich die UID-Abstandsadresse der entsprechenden AON-Abstandsadresse bezieht. ATU 10228 wird durch den KOS-logischen Adressenübersetzungs (LAT)-Mikrocode verwaltet.
Fig. 407 zeigt die Beziehungen zwischen ATU 10228, MEM 10112, MHT 10716 und KOS LAT-Mikrocode 40704. Wenn JP 10114 eine Speicherreferenz macht, übergibt er eine AON-Abstandsadresse 40705 an ATU 10228. Wenn ATU 10228 eine Kopie des Einganges von MHT 10716 für die Adresse 40705 enthält, so erzeugt sie sofort die entsprechende MEM 10112-Adresse 40706 und überträgt die Adresse nach MEM 10112. Wenn es keine Kopie gibt, erzeugt ATU 10228 ein ATU-Fehlerereignissignal, das LAT- Mikrocode 40704 in JP 10114 aufruft. Der LAT-Mikrocode 40704 erhält den MHT- Eingang, der der AON-Abstandsadresse von MHT 10716 entspricht, plaziert den Eingang in ATU 10228 und kehrt zurück. Dann wiederholt JP 10114 die Referenz. Diesmal gibt es einen Eingang für die Referenz, und ATU 10228 übersetzt die AON-Adresse in die Adresse der Kopie der Daten, die in MEM 10112 enthalten sind.
Die Beziehungen zwischen der KOS-Tabelle, Hardware-Zwischenspeicher und dem eben beschriebenen Mikrocode sind für die gegenwärtige Verkörperung von CS 10110 typisch. Die Tabelle (in diesem Fall MHT 10716) ist die Hauptinformationsquelle und wird vom virtuellen Speichermanagerprozeß verwaltet, während der Zwischenspeicher Bereiche der Tabelle beschleunigt und von KOS-Mikrocode verwaltet wird, der durch Ereignissignale vom Zwischenspeicher aufgerufen wird.
AOT 10712, AST 10914 und MHT 10716 teilen ein anderes Kennzeichen, das typisch ist für die gegenwärtige Verkörperung von CS 10110: die Tabellen sind so konstruiert, daß der Tabelleneingang, der die gewünschte Übersetzung durchführt, mit Hilfe einer Hash- Funktion und einer Hash-Tabelle lokalisiert werden kann. Die Hash-Funktion übersetzt die große UID 40401, das Subjekt oder die AON in eine kleine ganze Zahl. Diese ganze Zahl ist der Index des Eintrages in der Hash-Tabelle. Die Inhalte des Hash-Tabelleneintrages ist ein Index in AOT 10712, AST 10914 oder MHT 10716, wie es gerade der Fall ist, und diese Tabellen werden so verwaltet, daß der Eingang, der dem Index entspricht, der durch die Hash-Tabelle zur Verfügung gestellt wird, entweder der Eintrag ist, der die gewünschte Übersetzung durchführen kann, oder der Informationen enthält, die es KOS ermöglichen, den gewünschten Eintrag zu finden. Die Einträge in den Tabellen beinhalten weiterhin die Werte, die sie übersetzen. Daher kann KOS den Wert "hashen", den Eingang finden und dann überprüfen, ob der Eingang der für den gehashten Wert ist. Wenn er es nicht ist, kann KOS schnell von dem durch die Hash-Tabelle lokalisierten Eintrag zum korrekten Eintrag gehen.
Fig. 408 zeigt, wie Hashing in AST 10914 in der gegenwartigen Verkörperung arbeitet. In der gegenwärtigen Verkörperung ist das Subjekt 40801, d. h. die Hauptkomponente, Prozeßkomponente und Bereichskomponente des gegenwärtigen Subjektes Eingabe in die Hash-Funktion 40802. Die Hash-Funktion 40802 erzeugt den Index eines Eintrags in ASTHT 10710. Der ASTHT-Eingang 40504 wiederum enthält den Index eines Eintrags (ASTE) 40806 in AST 10914. Diese ASTE 40806-Indices sind ASNs. ASTE 40806 enthält die Haupt-, Prozeß- und Bereichskomponenten von Subjekten und ein Verbindungsfeld, das auf ASTE 40806 zeigt. ASTE 40806 hat 0 in seinem Verbindungsfeld stehen, was anzeigt, daß es die letzte Verbindung in der Kette von ASTEs ist, die mit ASTE 40806 anfängt. Wenn das Hashing eines Subjektes ASTE 40806 ergibt, vergleicht KOS das Subjekt in ASTE 40806 mit dem gehashten Subjekt; wenn sie identisch sind, ist der Index von ASTE 40806 in AST 10914 die ASN des Subjektes. Wenn sie nicht identisch sind, benutzt KOS die Verbindung in ASTE 40806, um ASTE 40806' zu finden. Es vergleicht das Subjekt in ASTE 40806' mit dem gehashten Subjekt. Wenn sie identisch sind, ist der AST-Index von ASTE 40806" die ASN des Subjekts; sonst ist ASTE 40806' der letzte Eingang in der Kette, und daher gibt es kein ASTE 40806 und keine ASN für das gehashte Subjekt.
Im folgenden werden wir die Implementation von Objekten in der gegenwärtigen Verkörperung im Detail diskutieren, indem wir mit der Implementation von Objekten im Sekundärspeicher 10124 beginnen und dann mit CS 10110's aktivem Objektmanagementsystem, dem Zugangskontrollsystem und dem virtuellen Speichersystem fortfahren.

2. Objekte im Sekundärspeicher 10124 (Fig. 409. 410)

Wie oben beschrieben, werden Objekte in LAUs 40405 gesammelt. Die Objekte, die zu einer LAU 40405 gehören, werden im Sekundärspeicher 10124 gespeichert. Jede LAU 40405 enthält ein Objekt, dessen Inhalte eine Tabelle sind, die logisches Allokationseinheitsverzeichnis (LAUD) genannt wird. Wie sein Name impliziert, ist das LAUD ein Verzeichnis der Objekte in LAU 40405. Jedes Objekt in LAU 40405 einschließlich des Objektes, das LAUD enthält, hat einen Eingang in LAUD. Fig. 409 zeigt die Beziehung zwischen Sekundarspeicher 10124, LAU 40405, LAUD und Objekten. LAU 40405 befindet sich in einer Reihe von Speichergeräten 40904. Das LAUD-Objekt 40902' in LAU 40405 enthält LAUD 40903. Zwei LAUDEs 40906 werden gezeigt. Eines enthält die Attribute des LAUD-Objekts 40902 und die Lokation seiner Inhalte, und das andere enthält die Attribute des LAUD-Objektes 40902', das LAUD 40903 und die Lokation seiner Inhalte enthält.
KOS benutzt eine Tabelle, die sogenannte aktive LAU-Tabelle (ALAUT), um das LAUD zu lokalisieren, das zu LAU 40405 gehört. Fig. 410 verdeutlicht die Beziehung zwischen ALAUT 41001, den ALAUT-Eingängen 41002, LAUs 40405 und LAUD-Objekten 40902'. Jedes für CS 10110 zugängliche LAU 40405 hat einen Eintrag (ALAUTE) 41002 in ALAUT 41001. ALAUTE 41002 für LAU 40405 beinhaltet LAUID 40402 von LAU 40405 und UID 40401 von LAU 40705's LAUD-Objekt 40902'. Daher kann KOS, bei gegebener UID 40401 eines Objektes, das LAUID 40402 einer UID 40401 benutzen, ALAUTE 41002 für LAU 40405 des Objektes zu lokalisieren, und kann ALAUTE 41002 dazu benutzen, LAUD 40903 von LAU 40405 zu lokalisieren. Wenn einmal LAUD 40903 gefunden wurde, stellt der OSN-Bereich 40402 der UID 40401 des Objektes das richtige LAUDE 40906 zur Verfügung, und LAUDE 40906 enthält die Attribute des Objektes und die Lokation seiner Inhalte.
LAUD 40903 und die Prozeduren 602, die es manipulieren, gehören zu einem Teil von KOS, dem sogenannten inaktiven Objektmanager. Die folgende Diskussion des inaktiven Objektmanagers beginnt mit der Art und Weise, in der die Inhalte eines Objektes im Sekundärspeicher 10124 dargestellt werden, diskutiert dann LAUD 40903 im Detail und schließt mit der Diskussion der Operationen, die von den Prozeduren 602 des inaktiven Objektmanagers durchgeführt werden.

a.a. Darstellung der Inhalte eines Objektes im Sekundärspeicher 10124

Im allgemeinen hängt die Weise, in der die Inhalte eines Objektes im Sekundärspeicher 10124 dargestellt werden, vollständig vom Sekundärspeicher 10124 ab. Wenn ein LAU 40405 aus Platten besteht, werden die Inhalte des Objektes in Plattenblöcken gespeichert. So lange wie KOS die Inhalte des Objektes lokalisieren kann, macht es keinen Unterschied, ob die Speicherung zusammenhängend oder nicht zusammenhängend ist.
In der gegenwärtigen Verkörperung werden die Inhalte der Objekte in Dateien gespeichert, die durch die auf IOS 10116 ausführenden Prozeduren des weiter entwickelten Data General Betriebssystems (AOS) erzeugt werden. Diese Prozeduren verwalten Dateien, die die Inhalte der Objekte für KOS beinhalten. In den zukünftigen CS 10110's wird die Darstellung der Inhalte von Objekten im Sekundärspeicher 10124 durch einen Bereich des KOS verwaltet werden.

b.b. LAUD 40903 (Fig. 411. 412)

Fig. 411 ist eine konzeptionelle Verdeutlichung des LAUD 40903. LAUD 40903 hat drei Teile: der LAUD-Kopf 41102, das Hauptverzeichnis 41105 und die LAUD-Einträge (LAUDEs) 40906. Der LAUD-Kopf 41102 und das Hauptverzeichnis 41105 besetzen feste Lokationen in LAUD 40903 und können daher von der UID 40401 des LAUD 40903 lokalisiert werden, die in ALAUT 41001 gegeben ist. Die Lokationen der LAUDEs 40906 sind nicht fest, aber der Eintrag für ein einzelnes Objekt kann vom Hauptverzeichnis 41105 aus lokalisiert werden.
Indem wir uns zuerst zum LAUD-Kopf 41102 wenden, so enthält der LAUD-Kopf 41102 LAUID 40402, das zu der LAU 40405 gehört, zu dem LAUD 40903 gehört, und OSN 40403 von LAUD 40903. Wie weiter unten noch genauer erklärt wird, kann KOS OSN 40403 benutzen, um LAUDE 40906 für LAUD 40903 zu finden.
Indem wir uns nun dem Hauptverzeichnis 41105 zuwenden, so übersetzt das Hauptverzeichnis 41105 die OSN 40403 eines Objekts in die Lokation des LAUDE 40906 des Objekts. Das Hauptverzeichnis 41105 enthält einen Eintrag 41108 für jedes Objekt in LAU 40505. Jeder Eintrag hat zwei Felder: das OSN-Feld 41106 und das Abstandsfeld 41107. Das OSN-Feld 41106 enthält die OSN 40403 für das Objekt, zu dem der Eintrag 41108 gehört; das Abstandsfeld 41107 enthält den Abstand des LAUDE 40906 in LAUD 40903. KOS ordnet Einträge 41108, indem es die OSN 40403 hochzählt und kann daher binäre Suchhilfsmittel benutzen, um den Eintrag 41108, der eine gegebene OSN 40403 enthält, zu finden. Sobald der Eintrag 41108 lokalisiert worden ist, ergibt das Abstandsfeld 41107 des Eintrags 41108 zusammen mit der OSN 40403 von LAUD 40903 die UID- Abstandsadresse des LAUDE 40906 des Objekts.
Sobald KOS die Lokation von LAUDE 40906 kennt, kann es die Attribute 40404 eines Objekts und die Lokation seiner Inhalte 40406 bestimmen. Fig. 411 gibt nur einen Überblick über die allgemeine Struktur von LAUDE 40906. LAUDE 40906 hat drei Komponenten: eine Feldergruppe fester Größe 41109, die es in jedem LAUDE 40906 gibt, und zwei Komponenten variabler Größe, die eine, 41139, enthält die Einträge, die zur PACL des Objektes gehören, und eine andere, 41141, die die EACL des Objektes enthält.
Wie die vorangegangenen Beschreibungen der Komponenten von LAUD implizieren, variiert die Anzahl der LAUDEs 40906 und der Einträge 41108 im Hauptverzeichnis mit der Anzahl der Objekte in LAU 40405. Weiter variiert der Speicherplatzbedarf für die EACL und PACL eines Objekts von Objekt zu Objekt. KOS geht mit diesem Problem so um, daß es freien Speicherplatz 41123 in jedes LAUD 40903 einfügt. Wenn ein Objekt kreiert wird, oder wenn die ACLs eines Objekts erweitert werden, erweitert der inaktive Objektmanager LAUD 40903 nur dann, wenn es keinen freien Speicherplatz 41123 gibt; wenn es freien Speicherplatz 41123 gibt, nimmt der Inaktive-Objektmanager den nötigen Platz vom freien Speicherplatz 41123; wenn ein Objekt gelöscht wird oder die ACLs eines Objekts gekürzt werden, gibt der Inaktive-Objektmanager den nicht benötigten Platz dem freien Speicherplatz 41123 zurück.
Fig. 412 ist eine genaue Darstellung eines einzelnen LAUDE 40906. Fig. 412 stellt jene Felder von LAUDE 40906 dar, die allen Verkörperungen von CS 10110 gemeinsam sind; Felder, die von Verkörperung zu Verkörperung verschieden sein können, werden ignoriert. Oben in Fig. 412 beginnend, enthält das Strukturversionsfeld 41209 Informationen, durch die KOS bestimmen kann, mit welcher Version von LAUDE 40906 es zu tun hat. Das Größenfeld 41211 enthält das Größenattribut des Objekts, zu dem LAUDE 40906 gehört. Das Größenattribut spezifiziert die Anzahl von gegenwärtig im Objekt enthaltenen Bits. Das Verriegelungsfeld 41213 ist ein KOS-Verriegelung. Wie genauer bei der Diskussion der Prozesse 610 erklärt wird, erlaubt das Verriegelungsfeld 41213 es nur einem Prozeß 610, zu einem bestimmten Zeitpunkt LAUDE 40906 zu lesen oder zu schreiben und hält daher einen Prozeß 610 davon ab, LAUD 40906 zu verändern, während ein anderer Prozeß 610 LAUDE 40906 gerade liest. Der Dateiidentifizierer 41215 enthält einen Systemidentifizierer für die Datei, die die Inhalte 40406 des Objekts enthält, zu dem LAUDE 40906 gehört. Die Form des Dateiidentifizierers 41215 kann von Verkörperung zu Verkörperung variieren; in der gegenwärtigen Verkörperung ist er ein AOS-System-Dateiidentifizierer. Das UID-Feld 41217 enthält die UID 40401, die zum Objekt von LAUDE 40906 gehört. Das primitive Typenfeld 41219 enthält einen Wert, der den primitiven Typen des Objekts spezifiziert. Das Objekt kann ein Datenobjekt, ein Prozedurobjekt 608, ein ETM oder ein S-Interpreter-Objekt sein: Das AON-Feld 41221 enthält nur dann einen gültigen Wert, wenn das Objekt von LAUDE 40906 aktiv ist, d. h. wenn es einen Eintrag in AOT 10712 hat. Das AON-Feld 41221 enthält dann die AON des Objekts. Wenn das Objekt ein ETO ist, so enthält das erweiterte Typenattributfeld 41223 die UID 40401 des ETM von ETO. Anderenfalls enthält einen NUll-UID 40401. In ähnlicher Weise enthält das Ausführungsbereichs-Attributfeld 41225, wenn das Objekt ein Prozedurobjekt 608 oder ein ETM ist, das Ausführungsbereichs-Attribut des Objekts.
Die verbleibenden Teile von LAUDE 40906 gehören zum Zugangskontrollsystem und werden in dieser Diskussion genau erklärt. Das Attributversions-Nummernfeld 41227 enthält einen Wert, der anzeigt, welche Version der ACLEs dieser LAUDE 40906 enthält, das PACL-Größenfeld 41229 und das ECAL-Größenfeld 41231 enthalten die Größen der jeweiligen ACLs, das PACL-Abstandsfeld 41233 und das EACL-Abstandsfeld 41235 enthalten die Abstände in LAUD 40903 zusätzlicher PACLEs 41139 und EACLEs 41141, und die festen PACLEs 41237 enthalten den Bereich der PACL, der immer in LAUDE 40906 enthalten ist.

3. Aktive Objekte (Fig. 413)

Ein aktives Objekt ist ein Objekt, dessen UID 40401 eine zugehörige AON besitzt. In der gegenwärtigen Verkörperung besitzt jedes CS 10110 einen Satz AONs. KOS assoziiert diese AONs mit UIDs 40401 derart, daß zu jedem beliebigen gegebenen Zeitpunkt eine AON in einem CS 10110 eine einzelne UID 40401 darstellt. Innerhalb FU 10120 werden die AONs dazu benutzt, die UIDs von CS 10110 darzustellen. In der gegenwartigen Verkörperung wird die AON durch 14 Bits dargestellt. Eine 112 Bit UID-Abstandsadresse (80 Bits für die UID 40401 und 32 für den Abstand) wird daher innerhalb FU 10120 durch einen 46 Bit AON-Abstandsadresse (14 Bits für die AON und 32 Bits für den Abstand) dargestellt.
Ein CS 10110 hat weit weniger AONs als es UIDs 40401 gibt. KOS teilt die AONs von CS 10110 unter den Objekten auf, die von CS 10110 referenziert werden, und benötigt daher sowohl AONs als auch UIDs 40401. Während eine gegebene AON nur eine einzelne UID 40401 zu einem beliebigen gegebenen Zeitpunkt repräsentiert, kann eine UID 40401 zu verschiedenen Zeitpunkten verschiedene zugehörige AONs besitzen.
Fig. 413 stellt eine konzeptionelle Darstellung der Beziehung zwischen AONs und UIDs 40401 dar. Jedes CS 10110 hat potentiellen Zugang zu 2&sup8;&sup0; UIDs 40401. Manche dieser UIDs jedoch stellen andere Einheiten als Objekte dar, und wiederum andere werden nie mit irgendeiner Einheit assoziiert. Jedes CS 10110 hat auch einen Satz von AONs 41303, über die es verfügen kann. In der gegenwärtigen Verkörperung kann dieser Satz bis zu 2¹&sup4;-Werte haben. Da-die AONs nur intern benutzt werden, kann jedes CS 10110 denselben Satz von AONs 41303 haben. Jede beliebige AON 41304 im Satz der AONs 41303 kann mit einer einzelnen UID 40401 im Satz der Objekt-UIDs 41301 assoziiert werden. Zu verschiedenen Zeitpunkten kann eine AON 41304 mit verschiedenen UIDs 40401 assoziiert werden.
Wie oben erwähnt, assoziiert KOS AONs 41304 mit UIDs 40401. Das macht es mittels der AOT 10712. Jeder AOT-Eintrag (AOTE) 41306 in AOT 10712 assoziiert eine UID 40401 mit einer AON 41304. Die AON 41304 ist der Index des AOTE 41306, der die UID 40401 enthält. So lange bis AOTE 41306 geändert wird, stellt AON 41304, die der Index des AOTE 41306 ist, der die UID 40401 enthält, die UID 40401 dar. AOT 10712 ermöglicht es auch, daß UIDs 40401 in AONs 41303 übersetzt werden, und umgekehrt. Fig. 413 verdeutlicht den Prozeß für eine UID-Abstandsadresse 41308 und eine AON- Abstandsadresse 41309. AOTE 41306 assoziiert die AON 41304 in der AON-Abstandsadresse 41309 mit der UID 40401 in der UID-Abstandsadresse 41308, und die Adressen 41308 und 41309 haben denselben Abstand 41307. Daher stellt die AON-Abstandsadresse 41309 einen UID-Abstandsadresse 41308 innerhalb von JP 10114 dar. Da beide Adressen den gleichen Abstand benutzen, kann die Adresse 41309 in einer Adresse 41308 übersetzt werden, indem die AON 41304 der Adresse 41309 in die UID 40401 der Adresse 41308 übersetzt wird, und die Adresse 41308 kann in die Adresse 41309 durch den umgekehrten Prozeß übersetzt werden. In beiden Fällen wird die Übersetzung durch ein sauberes Auffinden von AOTE 41306 durchgeführt.
Der Prozeß, durch den ein Objekt aktiv wird, wird Objektaktivierung genannt. Eine UID- Abstandsadresse 41308 kann nur dann in eine AON-Abnstandsadresse 41309 übersetzt werden, wenn das Objekt, zu dem die UID 40401 der UID-Abstandsadresse 41308 gehört aktiv ist. Wenn ein Prozeß 610 es versucht, eine solche Übersetzung unter Benutzung einer UID 40401, die zu einem inaktiven Objekt gehört, durchzuführen, tritt ein inaktives Objekt-Fehler auf. KOS bearbeitet den Fehler, indem es den Prozeß 601, der die Übersetzung versuchte, von JP 10114 löst, bis ein spezieller KOS-Prozeß, der vom Objektmanagerprozeß aufgerufen wurde, das Objekt aktiviert hat. Nachdem das Objekt aktiviert worden ist, kann der Prozeß 610 zu JP 10114 zurückkehren und die Übersetzung der UID 40401 in die AON 41304 zu Ende führen.
Der Bereich von KOS, der die aktiven Objekte verwaltet, wird aktiver Objektmanager (AOM) genannt. Teile des AOM sind Prozeduren 602, und andere Teile davon sind Mikrocodeprogramme. Die Hochsprachenkomponenten des AOM können nur durch KOS- Prozesse 610 aufgerufen werden. Der KOS aktive Objektmanagerprozeß 610 für die meisten Funktionen im Zusammenhang mit dem aktiven Objektmanagement durch.

a.a. UID 40401 in AON 41304-Übersetzungen

Im allgemeinen werden in CS 10110 in MEM 10112 und im Sekundarspeicher 10124 gespeicherte Adressen als UID-Abstandsadressen gespeichert. Die einzige Form von Adressen, die FU 10120 in einer Lokation in MEM 10112 übersetzen kann, ist die AON- Abstandsform. Daher muß jedesmal, wenn eine Adresse von MEM 10112 in ein FU 10120-Register geladen wird, die Adresse von einer UID-Abstandsadresse in eine AON- Abstandsadresse übersetzt werden. Die umgekehrte Übersetzung muß jedesmal durchgeführt werden, wenn eine Adresse von einem FU 10120-Register zurück in den Speicher geschrieben wird.
Solche Übersetzungen können jederzeit auftreten. Zum Beispiel führt ein laufender virtueller Prozessor 612 eine solche Übersetzung durch, wenn der Prozeß 610, der durch den virtuellen Prozessor 612 ausgeführt wird, eine indirekte Speicherreferenz ausführt. Eine indirekte Speicherreferenz ist eine Referenz, die erst einen Zeiger aufnimmt, d. h. einen Datenausdruck, dessen Wert die Adresse eines anderen Datenausdrucks ist, und dann die Adresse, die in dem Zeiger enthalten ist, dazu benutzt, die Daten selbst aufzunehmen. In CS 10110 stellen Zeiger UID-Abstandsadressen dar. Der virtuelle Prozessor 612 führt die indirekte Speicherreferenz durch, indem er den Zeiger von MEM 10112 aufnimmt, ihn in die FU 10120-Register plaziert, die durch den Zeiger dargestellte UID 40401 in eine dazugehörige AON 41304 übersetzt, und die resultierende AON-Abstandsadresse benutzt, um auf die Daten an der durch die Adresse spezifizierten Lokation zuzugreifen.
Die meisten solcher Übersetzungen treten jedoch auf, wenn der Zustand des virtuellen Prozessors 612 abgespeichert oder restauriert wird. Wenn z. B. der virtuelle Prozessor 612 eines Prozesses 610 von JP 10114 gelöst wird, und der virtuelle Prozessor 612 eines anderen Prozesses 610 an JP 10114 gebunden wird, wird der Zustand des von JP 10114 gelösten virtuellen Prozessors 612 im Speicher abgespeichert, und der Zustand des virtuellen Prozessors 612, der an JP 10114 gebunden wird, wird in die JP 10114-Register geschoben. Weil nur UID-Abstandsadressen im Speicher gespeichert werden können, müssen sämtliche AON-Abstandsadressen im Zustand des virtuellen Prozessors 612, der von JPM 10114 gelöst wird, in UID-Abstandsadressen übersetzt werden. In ähnlicher Weise müssen alle UID-Abstandsadressen im Zustand des virtuellen Prozessors 612, der an JP 10114 gebunden werden soll, in AON-Abstandsadressen übersetzt werden, bevor sie in die FU 10120-Register geladen werden können.

C. Das Zugangskontrollsystem

Wie bei der Einführung in die Objekte bereits erwähnt, überprüft das KOS-Zugangskontrollsystem jedesmal, wenn ein Prozeß 610 auf Daten oder auf SINs in einem Objekt zugreift, ob das gegenwärtige Subjekt des Prozesses 610 die Rechte besitzt, die Form des Zugangs durchzuführen, die der Prozeß 610 versucht. Wenn das gegenwärtige Subjekt des Prozesses 610 keinen einwandfreien Zugang hat, bricht das Zugangskontrollsystem die Speicheroperation ab, die der Prozeß 610 vor hatte, auszuführen. Die folgende Diskussion stellt Einzelheiten der Implementation des Zugangskontrollsystems dar, beginnend mit Subjekten, fortfahrend mit Subjektschablonen und abschließend mit den Hilfsmitteln, durch deren Nutzung KOS die Zugangsüberprüfung beschleunigt.

a. Subjekte

Das Subjekt ein Prozesses 610 ist Teil des Zustandes des Prozesses 610 und ist zusammen mit anderen Zustandsinformationen, die zum Prozeß 610 gehören, in einem sogenannten Prozeßobjekt enthalten. Prozeßobjekte werden in voller Länge in der detaillierten Diskussion der Prozesse 610 behandelt, die der Diskussion der Objekte folgt. Während ein Subjekt, wie oben erwähnt, vier Komponenten besitzt, die Hauptkomponente, die Prozeßkomponente, die Bereichskomponente und die Kennzeichenkomponente, weist das Zugangskontrollsystem in der gegenwärtigen Verkörperung von CS 10110 nur den ersten drei Komponenten Werte zu und ignoriert bei der Zugangsüberprüfung die Kennzeichenkomponente.
In der gegenwärtigen Verkörperung sind die UIDs 40401, aus denen die Komponenten des Subjekts eines Prozesses 610 bestehen, die UIDs 40401 des Objekts, das die Informationen über die durch die UIDs 40401 dargestellten Einheiten enthält. Die UID 40401 der Hauptkomponente stellt ein Objekt dar, daß das Hauptobjekt genannt wird. Das Hauptobjekt enthält Informationen über den Benutzer, für den der Prozeß 610 kreiert wurde. Zum Beispiel könnten die Informationen die Zugangsrechte betreffen, die der Benutzer auf die Ressourcen von CS 10110 hat, oder sie könnten Aufzeichnungen über seine Benutzung des CS 10110 enthalten. Die UID 40401 der Prozeßkomponente stellt das Prozeßobjekt dar, während die UID 40401 der Bereichskomponente ein Objekt darstellt, das Bereichsobjekt genannt wird. Das Bereichsobjekt enthält Informationen, die allen Prozessen 610 verfügbar sein müssen, deren Subjekt die UID 40401 des Bereichsobjekts als seine eigene Bereichskomponente hat. Andere Verkörperungen von CS 10110 benutzen die Kennzeichenkomponente des Subjekts. In diesen Verkörperungen ist die UID 40401 der Kennzeichenkomponente die UID 40401 eines Kennzeichenobjekts, das wenigstens eine Liste der Subjekte, aus der die Gruppe der Subjekte besteht, die durch die UID der Kennzeichenkomponente dargestellt wird, als Information beinhaltet.

b. Bereiche

Wie oben festgestellt, ist die Bereichskomponente des Subjekts das Ausführungsbereichs- Attribut, das zu dem Prozedurobjekt 608 oder ETM gehört, dessen Code gerade ausgeführt wird, wenn die Zugangsanforderung gemacht wird. Die Bereichskomponente des Subjekts gibt daher dem Prozeß 610, zu dem das Subjekt gehört, potentiellen Zugang auf die Gruppe von Objekten, deren ACLs ACLEs mit Subjektschablonen besitzen, die die Bereichskomponenten enthalten, die zu dem DOE-Attribut passen. Diese Objektgruppe ist der Bereich, der durch das Prozedurobjekt 608 oder ETMs DOE-Attribut definiert wurde. Wenn ein Prozeß 610 eine Prozedur 602 von einem Prozedurobjekt 608 oder ETM mit einem gegebenen DOE-Attribut ausführt, sagt man, daß der Prozeß 610 in dem durch jenes DOE-Attribut definierten Bereich ausführt. Wie aus Obigem geschlossen werden kann, können verschiedene Prozedurobjekte 608 oder ETMs dieselben DOE-Attribute haben, und Objekte können ACLEs besitzen, die sie an verschiedenen Bereichen teilhaben lassen.
Indem man eine Beziehung zwischen einer Gruppe von Prozedurobjekten 608 und einer anderen Gruppe von Objekten aufstellt, wird es einem das CS 10110 benutzenden Programmierer ermöglicht, sicherzustellen, daß ein gegebenes Objekt nur von einem bestimmten Satz Prozeduren 602 gelesen, ausgeführt oder verändert werden kann.
Bereiche können so benutzt werden, um geschützte Untersysteme in CS 10110 aufzubauen. Ein Beispiel eines solchen geschützten Untersystems ist KOS selbst: die Objekte in CS 10110, die KOS-Tabellen enthalten, besitzen sämtlich ACLs, deren Bereichsschablonenkomponenten nur zu dem DOE passen, das den KOS-Bereich darstellt. Die einzigen Prozedurobjekte 608 und ETMs, die dieses DOE haben, sind die, die die KOS- Prozeduren 602 enthalten, und daher können nur KOS-Prozeduren 602 die KOS-Tabellen manipulieren.
Da ein Objekt zu mehr als einem Bereich gehören kann, kann ein Programmierer die Bereiche dazu benutzen, Zugangshierarchien aufzubauen. Wenn z. B. manche der Objekte in einem ersten Bereich sowohl zu dem ersten Bereich als auch zu einem zweiten Bereich gehören, und die Objekte des zweiten Bereichs auch sämtlich zum ersten Bereich gehören, dann können die Prozeduren 602, die in den Prozedurobjekten 608 enthalten sind, deren DOEs den ersten Bereich definieren, Zugang auf jedes beliebige Objekt im ersten Bereich haben, einschließlich jener, die auch zum zweiten Bereich gehören, während jene von den Prozedurobjekten 608, deren DOEs den zweiten Bereich definieren, nur Zugang zu den Objekten im zweiten Bereich haben.

c. Zugangskontroll-Listen

Wie oben erwähnt, vergleicht das Zugangskontrollsystem das Subjekt, das zu einem Prozeß 610 gehört, das einen Zugang zu einem Objekt versucht, und der Art des Zugangs, den der Prozeß 610 zu machen wünscht, mit den ACLs des Objekts, um zu bestimmen, ob der Zugriff legal ist. Die folgende Diskussion der ACLs beschäftigt sich zuerst mit Subjektschablonen, weil sie allen ACLs gemeinsam ist, und danach mit PACLs und EACLs.

1. Subjektschablonen (Fig. 416)

Fig. 416 zeigt Subjektschablonen, PACL-Einträge (PACLEs) und EACL-Einträge (EACLEs). Indem wir uns zuerst den Subjektschablonen zuwenden, besteht eine Subjektschablone 41601 aus vier Komponenten, der Hauptschablone 41606, der Prozeßschablone 41607, der Bereichsschablone 41609 und der Kennzeichenschablone 41611.
Jede Schablone hat zwei Felder, das Geschmacksfeld 41603 und das UID-Feld 41605. Das Geschmacksfeld 41603 zeigt die Art und Weise an, in der die Schablone, zu der es gehört, zur entsprechenden Komponente des Subjekts für den Prozeß 610, der den Zugang versucht, passen muß. Das Geschmacksfeld 41603 kann einen von drei Werten annehmen: passend zu allen, passend zu einem oder passend zur Gruppe. Wenn das Geschmacksfeld 41603 den Wert passend zu allen hat, so paßt jede UID 40401 einer Subjektkomponente zur Schablone, und das Zugangskontrollsystem untersucht das UID-Feld 41605 nicht. Wenn das Geschmacksfeld 41603 den Wert passend zu einem hat, dann muß die entsprechende Subjektkomponente dieselbe UID 40401 besitzen wie die, die im UID-Feld 41605 enthalten ist. Wenn das Geschmacksfeld 41603 schließlich den Wert passend zur Gruppe hat, dann enthält das UID-Feld 41605 eine UID 40401 eines Objekts, das Informationen über die Gruppe von Subjektkomponenten beinhaltet, zu der die gegebene Subjektkomponente passen kann.

2. Primitive Zugangskontroll-Listen (PACLs)

PACLs bestehen aus PACLEs 41613, wie sie in Fig. 416 illustriert sind. Jeder PACLE 41613 hat zwei Teile: eine Subjektschablone 41601 und ein Zugangsartenbitfeld 41615. Die Werte im Zugangsartenbitfeld 41615 definieren elf Arten des Zugriffs. Die elf Arten unterteilen sich in zwei Gruppen: primitiver Datenzugriff und primitiver nicht Datenzugriff. Der primitive Datenzugriff steuert, was das Subjekt mit den Objektinhalten 40406 machen kann; der primitive nicht Datenzugriff steuert, was das Subjekt mit den Objektattributen 40404 machen kann.
Es gibt drei Arten des primitiven Datenzugriffs: lesender Zugriff, schreibender Zugriff und ausführender Zugriff. Wenn ein Subjekt lesenden Zugriff hat, kann es die Daten, die im Objekt enthalten sind, untersuchen; wenn das Subjekt Schreibzugriff hat, kann es die im Objekt enthaltenen Daten ändern; wenn es Ausführungszugriff hat, kann es die im Objekt enthaltenen Daten als eine Prozedur 602 behandeln, und versuchen, sie auszuführen. Ein Subjekt kann keine einzige dieser Zugriffsarten besitzen, oder aber jede beliebige Kombination aus diesen Arten. Bei jeder Referenz auf das Objekt überprüft KOS, ob das Subjekt, daß die Referenz durchführt, den erforderlichen primitiven Datenzugriff besitzt.
Der primitive Nicht-Datenzugriff auf ein Objekt wird nur zum Setzen oder zum Lesen der Attribute 40404 eines Objekts verlangt und wird nur überprüft, wenn diese Operationen durchgeführt werden. Die Arten des Nicht-Datenzugriffs entsprechen den Arten der Attribute 40404:
Attribute Zugriffsart
Objektattribute Objektattribute lesen, Objektattribute setzen
primitive Kontrollattribute primitive Kontrollattribute lesen, primitive Kontrollattribute setzen
erweiterte Kontrollattribute erweiterte Kontrollattribute lesen, erweiterte Kontrollattribute setzen
ETM-Zugriff Benutzung als ETM, ETO erzeugen
Die Zugangsrechte für Objektattribute erlauben einem Subjekt, die oben beschriebenen Objektattribute zu lesen oder zu setzen. Die Zugangsrechte für die primitiven und erweiterten Kontrollattribute erlauben einem Subjekt, die PACL bzw. EACL eines Objekts zu lesen und zu setzen.
Ein Objekt kann jede beliebige Anzahl von PACLEs 41613 in seiner PACL haben. Die ersten fünf PACLEs 41613 in der PACL eines Objekts sind im festen PACLE-Feld 41237 von LAUDE 40906 für dieses Objekt enthalten; der Rest wird in LAUD 40903 an der Lokation gespeichert, die im PACL-Abstandsfeld 41233 von LAUDE 40906 spezifiziert wurde.

3. APAM 10918 und Schutzzwischenspeicher 10234 (Fig. 421)

Primitive Nicht-Datenzugriffsrechte werden nur dann überprüft, wenn Benutzer KOS- Programme aufrufen, die solche Zugangsrechte benötigen, und erweiterte Zugriffsrechte werden nur dann überprüft, wenn Benutzer solche Überprüfungen anfordern. Die primitiven Datenzugriffsrechte andererseits werden jedesmal überprüft, wenn ein virtueller Prozessor 612 eine Speicherreferenz während der Ausführung eines Prozesses 610 durchführt. Daher legt die KOS-Implementation der Überprüfung der primitiven Datenzugangsrechte bevorzugt Wert auf Geschwindigkeit und Effizienz. Es gibt zwei Arten der Implementation: APAM 10918 in MEM 10112 und der Schutzzwischenspeicher 10234 in JP 10114. APAM 10918 ist auf einer Lokation in MEM 10112, die dem KOS-Mikrocode bekannt ist. APAM 10918 enthält primitive Datenzugangsinformationen, die von den PACLEs 41613 kopiert wurden, die zu aktiven Objekten gehören und deren Subjektschablone 41601 zu einem aktiven Subjekt paßt. Der Schutzzwischenspeicher 10234 wiederum enthält Kopien der Informationen in APAM 10918 für das aktive Subjekt des Prozesses 610, dessen virtueller Prozessor 612 augenblicklich an JP 10114 gebunden ist und aktive Objekte, die vom Prozeß 610 referenziert werden. Eine primitive Datenzugangsüberprüfung beginnt in CS 10110 mit dem Schutzzwischenspeicher 10234, und geht weiter zu APAM 10918, falls die Information nicht im Schutzzwischenspeicher 10234 enthalten ist, und wenn sie nicht in APAM 10918 ist, geht sie schließlich zur PACL des Objekts. Die folgende Diskussion beginnt mit APAM 10918.
Fig. 421 zeigt APAM 10918. APAM 10918 ist als zweidimensionaler Vektor organisiert. Die Zeilenindizes des Vektors sind die AONs 41304, und seine Spaltenindizes sind die ASNs. Für jede AON 41304 in CS 10110 gibt es eine Zeile, und für jede ASN gibt es eine Spalte. In Fig. 421 wird nur eine einzige Zeile und eine einzige Spalte gezeigt. Jede primitive Datenzugriffsinformation in APAM 10918 für das durch die AON 41304J repräsentierte Objekt ist in der Zeile 42104 enthalten, während die Spalte 42105 alle primitiven Datenzugriffsinformationen in APAM 10918 für das durch die ASNK repräsentierte Subjekt enthält. Der APAM-Eintrag (APAME) 42106 ist beim Schnittpunkt von Zeile 42104 und Spalte 42105 und enthält die primitiven Datenzugriffsinformationen von dem PACLE 41613, der zu dem durch die AON 41304J dargestellte Objekt gehört, dessen Subjektschablone 41601 zu dem durch die ASNK dargestellte Subjekt paßt.
Eine erweiterte Ansicht von APAME 42106 wird unter der Darstellung von APAM 10918 gezeigt. APAME 42106 enthält vier ein Bit-Felder. Die Bits repräsentieren die Arten des primitiven Datenzugriffs, die das Subjekt, das durch den Spaltenindex von APAME 42106 dargestellt ist, auf das Objekt hat, das durch den Zeilenindex von APAME 42106 dargestellt wird.
- Das Feld 42107 ist das Gültig-Bit. Wenn das Gültig-Bit gesetzt ist, enthält APAME 42106, was immer an primitiver Datenzugriffsinformation für das durch die Spalte dargestellte Subjekt und durch die Zeile dargestellte Objekt verfügbar ist. Die verbleibenden Felder in APAME 42106 sind nur dann von Bedeutung, wenn das Gültig-Bit 42107 gesetzt ist.
- Das Feld 42109 ist das Ausführungsbit. Wenn es gesetzt ist, hat das Subjekt von APAME 42106 Ausführungsrechte auf das Objekt von APAME 42106.
- Das Feld 42111 ist das Lesebit. Wenn es gesetzt ist, hat das Subjekt von APAME 42106 Lesezugriff auf das Objekt von APAME 42106.
- Das Feld 42113 ist das Schreibbit. Wenn es gesetzt ist, hat das Subjekt von APAME 42106 Schreibzugriff auf das Objekt von APAME 42106.
Jede beliebige Kombination von Bits in den Feldern 42109 bis 42113 kann gesetzt werden. Wenn alle diese Felder auf 0 stehen, zeigt APAME 42106 an, daß das von ihm dargestellte Subjekt keinen Zugriff auf das von ihm dargestellte Objekt hat.
KOS setzt APAME 42106 für eine ASN und eine AON 41304, wenn das durch die ASN dargestellte Subjekt zum ersten Mal ein Objekt referenziert, das durch die AON 41304 dargestellt wird. Bis APAME 42106 gesetzt ist, steht das Gültig-Bit 42107 auf 0. Wenn APAME 42106 gesetzt ist, steht das Gültig-Bit 42107 auf 1, und die Felder 42109 bis 42113 sind gemäß den primitiven Datenzugriffsinformationen im PACLE 41613 des Objektes gesetzt, dessen Subjektschablone 41601 zu dem Subjekt paßt. Wenn ein Objekt deaktiviert wird, werden alle Gültig-Bits 42107 in allen APAMEs 42106 in der Zeile, die zu der AON 41304 des Objektes gehört, auf 0 gesetzt; in ähnlicher Weise werden die Gültig-Bits 42107 in allen APAMEs 42106 in der Spalte, die zur ASN des Subjekts gehört, auf 0 gesetzt, wenn dieses Subjekt deaktiviert werden soll.

4. Schutzzwischenspeicher 10432 und Schutzüberprüfung (Fig. 422)

Die letzte Stufe in der Beschleunigung der Schutzinformationen ist der Schutzzwischenspeicher 10234 in JP 10114. Die Einzelheiten der Art und Weise, in der der Schutzzwischenspeicher 10234 funktioniert, werden in der Diskussion der Hardware vorgestellt; hier wir die Art und Weise diskutiert, in der der Schutzzwischenspeicher 10234 Zugangsprüfungen durchführt, die Beziehungen zwischen dem Schutzzwischenspeicher 10234, APAM 10918 und AOT 10712, und die Art und Weise, in der der KOS-Schutzzwischenspeicher-Mikrocode den Schutzzwischenspeicher 10234 verwaltet.
Fig. 422 ist ein Blockdiagramm des Schutzzwischenspeichers 10234, AOT 10712, APAM 10918 und KOS-Mikrocode 42207, der den Schutzzwischenspeicher 10234 verwaltet. Jedesmal, wenn JP 10114 eine Speicherreferenz unter Benutzung eines logischen Beschreibers 27116 macht, präsentiert er gleichzeitig einen logischen Beschreiber 27116 und ein Signal 42208, das dem Schutzzwischenspeicher 10234 und ATU 10228 die Art der Speicheroperation anzeigt. Die Einträge 42215 im Schutzzwischenspeicher 10234 enthalten primitive Datenzugriffs- und Längeninformationen für kürzlich durch das gegenwärtige Subjekt des Prozesses 610 referenzierte Objekte, dessen virtueller Prozessor 612 gegenwärtig an JP 10114 gebunden ist. Bei jeder Speicherreferenz sendet der Schutzzwischenspeicher 10234 ein Gültig/Ungültig-Signal 42205 an MEM 10112. Wenn der Schutzzwischenspeicher 10234 keinen Eintrag 42215 für eine AON 41304 enthält, die im AON- Feld 27111 des logischen Beschreibers 27116 enthalten ist, oder wenn der Eintrag 42215 anzeigt, daß das Subjekt nicht den durch den Prozeß 610 erforderlichen Zugriffstyp besitzt, oder wenn die Summe aus dem OFF-Feld 27113 des logischen Beschreibers 27116 und dem Längenfeld 27115 die gegenwärtige Größe des Objekts übersteigt, sendet der Schutzzwischenspeicher 10234 ein Ungültig-Signal 42205 aus. Dieses Signal veranlaßt MEM 10112, die Speicherreferenz abzubrechen. Anderenfalls sendet der Schutzzwischenspeicher 10234 ein Gültig-Signal 42205 aus, und MEM 10112 führt die Speicherreferenz aus.
Wenn der Schutzzwischenspeicher 10234 ein Ungültig-Signal 42205 aussendet, schiebt er den logischen Beschreiber 27116, der für die Referenzierung benutzt wurde, in die Beschreiberfalle 20256, den Speicherbefehl in die Befehlsfalle 27018 und, falls es eine Schreiboperation war, die Daten in die Datenfalle 20258, und sendet zur gleichen Zeit eins von zwei Ereignissignalen zum KOS-Mikrocode. Das Ereignissignal illegaler Zugriff 42208 tritt auf, wenn der Prozeß 610, der die Referenz ausführt, keine einwandfreien Zugriffsrechte hat, oder die referenzierten Daten sich über die Objektgrenzen hinweg erstrecken. Das Ereignissignal illegaler Zugriff 42208 ruft den KOS-Mikrocode 42215 auf, der einen Mikrocode an Software-Aufruf 42217 (in der Diskussion der Aufrufe beschrieben) zu den KOS-Zugriffskontrollsystemprozeduren durchführt, und übergibt die Inhalte der Beschreiberfalle 20256, der Befehlsfalle 27018, die ASN des Prozesses 610 (in einem Register von MGR 10360 enthalten) und, falls notwendig, der Datenfalle 20258 an diese Prozeduren 602. Diese Prozeduren 602 informieren EOS über die Schutzverletzung, und EOS kann sie behandeln.
Das Zwischenspeicherfehler-Ereignissignal 42206 tritt auf, wenn es im Schutzzwischenspeicher 10234 keinen Eintrag 42215 für die AON 41304 gibt. Das Zwischenspeicherfehler-Ereignissignal 42206 ruft den KOS-Schutzzwischenspeicherfehler-Mikrocode 42207 auf, der den fehlenden Eintrag 42215 im Schutzzwischenspeicher aus Informationen aufbaut, die er von AOT 10712 und APAM 10918 erhält. Wenn APAM 10918 keinen Eintrag für die gegenwärtige ASN des Subjekts und die AON des referenzierten Objekts enthält, so führt der Schutzzwischenspeicherfehler-Mikrocode 42207 einen Mikrocode an Software-Aufruf an KOS-Zugangskontrollsystemprozeduren 602 durch, die zum LAUDE 40906 für dieses Objekt gehen und die benötigten primitiven Datenzugangsinformationen von dem PACLE 41613, der zu dem Objekt gehört, dessen Subjektschablone 41601 zu dem Subjekt paßt, das die Referenz versuchte, in APAM 10918 kopieren. Die KOS- Zugangskontrollsystemprozeduren 602 kehren dann zum Zwischenspeicherfehler-Mikrocode 42207 zurück, der wiederum selbst zurückkehrt. Da der Zwischenspeicherfehler- Mikrocode durch ein Ereignissignal aufgerufen wurde, veranlaßt die Rückkehr JP 10114, die Speicherreferenz, die den Schutzzwischenspeicherfehler verursachte, noch einmal auszuführen. Wenn der Schutzzwischenspeicher 10234 als ein Ergebnis des letzten Schutzzwischenspeicherfehlers geladen wurde, tritt der Fehler nicht wieder auf; wenn der Schutzzwischenspeicher 10234 nicht geladen wurde, weil die benötigte Information nicht in APAM 10918 war, tritt der Fehler wieder auf, aber weil die Informationen in APAM 10918 als Ergebnis des vorherigen Fehlers geschrieben wurden, kann nun der Zwischenspeicherfehler-Mikrocode 42207 einen Eintrag 42215 im Schutzzwischenspeicher 10234 konstruieren. Wenn der Zwischenspeicherfehler-Mikrocode 42207 zurückkehrt, wird die Speicherreferenz erneut versucht, aber diesmal enthält der Schutzzwischenspeicher 10234 die Informationen und der Fehler tritt nicht wieder auf.
Der Zwischenspeicherfehler-Mikrocode 42207 erzeugt einen neuen Schutzzwischenspeichereintrag und lädt ihn in den Schutzzwischenspeicher 10234 wie folgt: indem er die AON 41304 vom logischen Beschreiber 27116, der in die Beschreiberfalle 20256 geschoben wurde, als die Speicherreferenz, die den Fehler verursachte, ausgeführt wurde, und die ASN des gegenwärtigen Subjekts, die in den GRs 10360 enthalten ist, benutzt, lokalisiert der Zwischenspeicherfehler-Mikrocode APAME 42106 für das Subjekt, das durch die ASN dargestellt wurde, und für das Objekt, das durch die AON 41304 dargestellt wurde, und kopiert die Inhalte von APAME 42106 in ein JP 10114-Register, das als Quelle für den JPD-Bus 10142 dienen kann. Er benutzt auch die AON 41304, um AOTE 41306 für das Objekt zu lokalisieren und kopiert die Inhalte des Größenfeldes 41519 in ein anderes JP 10114-Register, das eine Quelle für den JPD-Bus 10142 ist. Darauf benutzt er drei besondere Mikrobefehle, die in aufeinander folgenden Mikrobefehlen ausgeführt werden, um den Schutzzwischenspeichereintrag 42215 zu laden. Der erste Mikrobefehl lädt TS 24010 des Schutzzwischenspeichereintrags 42215 mit der AON 41304 des in die Beschreiberfalle geschobenen logischen Beschreibers 27116; der zweite lädt die Größe des Objekts in das EXTENT-Feld des Schutzzwischenspeichers 10234 und der dritte lädt die Inhalte von APAME 42106 in derselben Weise.
Ein anderer Mikrobefehl macht sämtliche Einträge 42215 im Schutzzwischenspeicher 10234 ungültig. Diese Operation, das sogenannte Löschen, wird durchgeführt, wenn ein Objekt deaktiviert wird, oder wenn das gegenwärtige Subjekt wechselt. Das gegenwärtige Subjekt wechselt immer dann, wenn ein virtueller Prozessor 612 von JP 10114 gelöst wird, und wenn ein Prozeß 610 einen Aufruf oder eine Rückkehr von einer Prozedur 602 durchführt, die in einem anderen Bereich ausführt als in dem, in dem die rufende Prozedur 602 oder die Prozedur 602, zu der zurückgekehrt wird, arbeitet. Im Falle des Aufrufs und des Lösens des virtuellen Prozessors 612 wird das Löschen des Zwischenspeichers durch KOS-Aufruf- und Aufteilungsmikrocode durchgeführt; im Falle einer Objektdeaktivierung wird das Löschen durch eine KOS-Prozedur durchgeführt, die einen besonderen KOS SIN benutzt, der den Zwischenspeicher-Löschmikrocode aufruft.

D. Prozesse

1. Synchronisation von Prozessen 610 mit virtuellen Prozessoren 612

Da Prozesse 610 und die virtuellen Prozessoren 612, an die sie gebunden sind, gleichzeitig in CS 10110 ausführen können, muß KOS Mittel zur Verfügung stellen, um Prozesse zu synchronisieren, die voneinander abhängen. Wenn z. B. Prozeß 610 A nicht fortfahren kann, solange nicht Prozeß 610 B irgendeine Operation durchgeführt hat, so muß es einen Mechanismus zur Unterbrechung der Ausführung von A geben, bis B beendet ist. Ganz allgemein gibt es vier notwendige Synchronisationsarten:
- Ein Prozeß 610 muß imstande sein, anzuhalten und zu warten, bis ein anderer Prozeß 610 eine Aufgabe beendet hat, bevor er weiter macht.
- Ein Prozeß 610 muß in der Lage sein, einem anderen Prozeß 610 eine Nachricht zu schicken, und auf eine Antwort zu warten, bevor er weiter macht.
- Wenn Prozesse 610 eine Datenbasis teilen, muß ein Prozeß 610 in der Lage sein, die anderen Prozesse 610 von dieser Datenbasis fernzuhalten, bis der erste Prozeß 610 die Datenbasis nicht mehr benötigt.
- Ein Prozeß 610 muß in der Lage sein, einen anderen Prozeß 610 zu unterbrechen, d. h. den zweiten Prozeß 610 asynchron dazu zu veranlassen, eine Aktion durchzuführen.
KOS hat für jede Art von Synchronisation interne Mechanismen und stellt darüber hinaus Synchronisationsmechanismen für EOS zur Verfügung. KOS benutzt die internen Mechanismen, um virtuelle Prozessoren 612 und KOS-Prozesse 610 zu synchronisieren, während EOS die von KOS gelieferten Mechanismen dazu benutzt, alle anderen Prozesse 610 zu synchronisieren. Die internen Mechanismen sind folgende:
- Ereigniszähler, Erwartungseinträge und Erwartungstabellen. Wie unten noch genau erklärt wird, ermöglichen Ereigniszähler und Erwartungseinträge einem Prozeß 610, anzuhalten und darauf zu warten, daß ein anderer Prozeß 610 eine Operation abschließt. Ereigniszähler und Erwartungseinträge werden auch dazu benutzt, um Prozeßunterbrechungen zu implementieren. Erwartungseinträge werden in Erwartungstabellen organisiert.
- Nachrichtenwarteschlangen. Nachrichtenwarteschlangen erlauben es einem Prozeß 610, eine Nachricht einem anderen zu senden und auf eine Antwort zu warten. Nachrichtenwarteschlangen werden mit Ereigniszählern und Warteschlangendatenstrukturen implementiert.
- Verriegelungen. Verriegelungen erlauben es einem Prozeß 610, andere Prozesse 610 von einer Datenbasis oder einem Codesegment fernzuhalten. Verriegelungen werden mit Ereigniszählern und Geräten, den sogenannten Ablaufsteuerern, implementiert.
KOS macht Ereigniszähler, Erwartungseinträge und Nachrichtenwarteschlangen für EOS verfügbar. Es stellt keine Verriegelungen bereit, aber dafür Ablaufsteuerer, so daß EOS seine eigenen Verriegelungen konstruieren kann. Die folgende Diskussion definiert und erklärt die logischen Eigenschaften von Ereigniszählern, Erwartungseinträgen, Nachrichtenwarteschlangen, Ablaufsteuerern und Verriegelungen. Ihre Implementation in der gegenwärtigen Verkörperung wird zusammen mit der Implementation von Prozessen 610 und virtuellen Prozessoren 612 beschrieben.

. Ereigniszähler 44801. Erwartungseinträge 44804 und Erwartungstabellen (Fig. 448, 449)

Ereigniszähler, Erwartungseinträge und Erwartungstabellen sind die Hauptkomponenten des KOS-Synchronisationssystems. Fig. 448 verdeutlicht die Ereigniszahler und Erwartungseinträge in der gegenwärtigen Verkörperung. Fig. 449 gibt eine vereinfachte Darstellung der Prozeßereignistabelle 44705, der Erwartungstabellen der gegenwärtigen Verkörperung. Indem wir uns zuerst Fig. 448 zuwenden, ist der Ereigniszähler 44801 eine Speicherfläche, die einen Wert beinhaltet, der nur hochgezählt werden kann. In einer der gegenwärtigen Verkörperungen sind Ereigniszähler 44801 für KOS-Systeme, die keine Fehler übertragen dürfen, immer in MEM 10112 vorhanden; andere Ereigniszähler 44801 werden im Sekundärspeicher 10124 gespeichert, es sei denn, ein Prozeß 610 hat sie referenziert und dadurch das VMM-System dazu veranlaßt, sie in MEM 10112 zu laden. Der Wert, der in einem Ereigniszähler 44801 enthalten wird, wird Ereigniszählerwert 44802 genannt. In der gegenwärtigen Verkörperung enthält der Ereigniszähler 44801 64 Datenbits, von denen 60 den Ereigniszählerwert 44802 bilden. Auf den Ereigniszähler 44801 kann entweder mit einer Variablen oder mit Hilfe eines 128 Bit UID-Zeigers Bezug genommen werden, der die Lokation des Ereigniszählers 44801 enthält. Der UID-Zeiger wird Ereigniszähiername 44803 genannt.
Der Erwartungseintrag 44804 ist eine Komponente der Einträge in Erwartungstabellen. In der gegenwärtigen Verkörperung gibt es zwei Erwartungstabellen: die Prozeßereignistabelle 44705 und die Erwartungstabelle des virtuellen Prozessors (VPAT) 45401. VPAT 45401 ist immer in MEM 10112 vorhanden. Wie bereits erwähnt, verdeutlicht die Fig. 449 PET 44705. Sowohl PET 44705 als auch VPAT 45401 werden später genau beschrieben. Jeder Erwartungseintrag 44804 enthält einen Ereigniszählernamen 44803, einen Ereigniszählerwert 44802 und eine Zurückverbindung 44805, die einen Prozeß 610 oder einen virtuellen Prozessor 612 identifiziert. Ein Erwartungseintrag 44904 stellt so eine Beziehung zwischen einem Ereigniszähler 44801, einem Ereigniszählerwert 44802 und einem Prozeß 610 oder virtuellen Prozessor 612 auf.
Indem wir uns nun der Fig. 449 zuwenden, sind in der gegenwärtigen Verkörperung alle Erwartungseinträge 44804 für Prozesse 610 in PET 44705 enthalten. PET 44705 enthält auch andere Informationen. Fig. 449 stellt nur jene Teile von PET 44705 dar, die die Erwartungseinträge 44804 illustrieren. PET 44705 ist so strukturiert, daß es eine schnelle Auffindung der Erwartungseinträge 44804, die zu einem spezifischen Ereignisfehler 44801 gehören, erlaubt. Die PET-Einträge (PETEs) 44909 enthalten Verbindungen, die in Listen in PET 44705 zusammen gefügt werden können. Es gibt vier Listenarten in PET 44705:
- Ereigniszählerlisten: diese Listen verknüpfen alle PETEs 44909 für Ereigniszähler 44801, deren Ereigniszählernamen 44803 auf einen einzigen Wert verkleinert werden.
- Erwartungslisten: diese Listen verknüpfen alle PETEs 44909 für Ereigniszähler 44801, die ein gegebener Prozeß 610 erwartet.
- Unterbrechungslisten: diese Listen verknüpfen alle PETEs 44909 für Ereigniszähler 44801, die für einen gegebenen Prozeß 610 eine Unterbrechung verursachen werden.
- Die freie Liste: PETEs 44909, die nicht in einer der obigen Listen benutzt werden, befinden sich auf einer freien Liste.
Jeder PETE 44909, der auf einer Erwartungsliste oder einer Unterbrechungsliste steht, steht auch auf einer Ereigniszählerliste.
Indem wir uns zuerst den Ereigniszählerlisten zuwenden, beinhalten sämtliche PETEs 44909 auf einer gegebenen Ereigniszahlerliste Ereigniszählernamen 44803, die auf einen einzigen Wert verkleinert wurden. Der Wert wurde durch eine Hash-Funktion 44901 erzeugt und dann als Index in der PET-Hash-Tabelle (PETHT) 44903 benutzt. Dieser Eintrag in PETHT 44903 enthält den Index in PET 44705 des PETE 44909, der der Kopf der Ereigniszählerliste ist. Die PETE-Liste 44904 stellt eine solche Ereigniszählerliste dar. Daher kann bei einem gegebenem Ereigniszählernamen 44803 KOS sämtliche Erwartungseinträge 44804 schnell finden, die zu dem Ereigniszahler 44801 gehören.
In der gegenwärtigen Verkörperung involviert die Implementation von Ereigniszählern 44801 und Tabellen mit Erwartungseinträgen 44804 sowohl die Prozesse 610 als auch die virtuellen Prozessoren 612, an die Prozesse 610 gebunden sind. Wie später erklärt wird, werden viele Ereigniszähler 44801 und Erwartungseinträge 44804, die zu den Prozessen 610 gehören, auf wenige Ereigniszähler 44801 und Erwartungseinträge 44804, die zu den virtuellen Prozessoren 612 der Prozesse gehören, aufgeteilt. Die Erwartungseinträge 44804 für die Ereigniszähler 44801, die zu den virtuellen Prozessoren 612 gehören, sind in VPAT 45401 enthalten.

b. Die Synchronisation von Ereigniszählern 44801 und Erwartungseinträgen 44804

Die einfachste Form der Prozeß 610-Synchronisation, die von KOS zur Verfügung gestellt wird, benutzt nur Ereigniszähler 44801 und Erwartungseinträge 44804. Die Koordination findet folgendermaßen statt: Ein Prozeß 610 A fordert KOS auf, eine Erwartungsoperation durchzuführen, d. h. einen oder mehrere Erwartungseinträge 44804 aufzubauen und den Prozeß 610 A zu stoppen, bis einer der Erwartungseinträge erfüllt ist. Bei der Anforderung der Erwartungsoperation definiert der Prozeß 610 A, welche Ereigniszähler 44801 er erwartet, und welche Ereigniszählerwerte 44802 diese Ereigniszähler 44801 haben müssen, damit sie ihre Erwartungseinträge 44804 befriedigen. Nachdem KOS die Erwartungseinträge 44804 aufgestellt hat, stoppt es den Prozeß 610 A. Während Prozeß 610 A gestoppt wird, fordern andere Prozesse 610 KOS auf, Vorschuboperationen in den Ereigniszählern 44801 durchzuführen, die durch die Erwartungseinträge 44804 des Prozesses 610 A spezifiziert wurden. Jedesmal, wenn ein Prozeß 610 eine Vorschuboperation auf einem Ereigniszähler 44801 anfordert, inkrementiert KOS den Ereigniszähler 44801 und überprüft die Erwartungseingänge 44804 des Ereigniszählers 44801. Eventuell befriedigt ein Ereigniszähler 44801 einen der Erwartungseingänge 44804 von Prozeß 610 A, d. h. er erreicht einen Wert, der größer oder gleich dem Ereigniszählerwert 44802 ist, der in seinem Erwartungseintrag 44804 für den Prozeß 610 A spezifiziert wurde. An diesem Punkt erlaubt es KOS dem Prozeß 610 A, die Ausführung wieder aufzunehmen.
Sobald Prozeß 610 A seine Ausführung wieder aufnimmt, löscht er alle seine Erwartungseinträge 44804.

E. Virtuelle Prozessoren 612 (Fig. 453)

Wie oben beschrieben, kann ein virtueller Prozessor 612 logisch als ein Mittel definiert sein, durch das ein Prozeß 610 Zugang auf JP 10114 gewinnt. Physikalisch gesehen ist ein virtueller Prozessor eine Speicheffläche von MEM 10112, die Informationen enthält, die der KOS-Mikrocode, der die virtuellen Prozessoren 612 an JP 10114 bindet und sie von JP 10114 löst, benötigt, um die Binde- und Löseoperationen durchzuführen. Fig. 453 zeigt einen virtuellen Prozessor 612. Die Fläche von MEM 10112, die zu einem virtuellen Prozessor 612 gehört, ist der virtuelle Prozessor-Zustandsblock (VPSB) 614 des virtuellen Prozessors 612. Jeder virtuelle Prozessor 612 in einem CS 10110 hat einen VPSB 614. Zusammen bilden die VPSBs 614 den VPSB-Vektor 45301. Innerhalb des virtuellen Prozessor-Managementsystems ist jeder virtuelle Prozessor 612 unter seiner VP-Nummer 45304 bekannt, die der Index des VPSB 614 des virtuellen Prozessors 612 im VPSB- Vektor 45301 ist. Virtuelle Prozessoren 612 werden mit Hilfe von Listen verwaltet, die in Mikro-VP-Listen (MVPL) 45309 enthalten sind. Jeder virtuelle Prozessor 612 hat einen Eintrag (MVPLE) 45321 in MVPL 45309, und wenn der virtuelle Prozessor 612 seinen Zustand ändert, schiebt ihn der virtuelle Prozessormanagement-Mikrocode von einer Liste zu einer anderen in MVPL 45309.
VPSB 614 enthält zwei Informationsarten: Informationen vom Prozeßobjekt 901, das zum Prozeß 610 gehört, der an den virtuellen Prozessor 612 des VPSB 614 gebunden ist, und Informationen, die vom virtuellen Prozessor-Managementsystem benutzt werden, um den virtuellen Prozessor 612 zu verwalten. Folgendes sind die wichtigsten Informationen vom Prozeßobjekt 901:
- Die Haupt- und Prozeß-UIDs 40401 des Prozesses 610.
- Die AONs 41304 für die Stapelspeicherobjekte 44703 des Prozesses 610. (VPSB 614 benutzt AONs 41304, weil KOS garantiert, daß AONs 41304, die zu Stapelspeicherobjekten 44703 gehören, so lange ihren Wert nicht ändern, wie der Prozeß 610 an einen virtuellen Prozessor 612 gebunden ist.)
Bei gegebener AON 41304 des SS-Objekts 10336 des Prozesses 610 kann das virtuelle Prozessor-Managementsystem den Bereich des Zustandes des Prozesses 610 lokalisieren, der in die zu JP 10114 gehörenden Register geschoben wird, wenn der virtuelle Prozessor 612 des Prozesses 610 an JP 10114 gebunden wird. In ähnlicher Weise kann das virtuelle Prozessor-Managementsystem, wenn der virtuelle Prozessor 612 von JP 10114 gelöst wird, die Inhalte der JP 10114-Register in die richtige Lokation im SS-Objekt 10336 schieben.

a. Management des virtuellen Prozessors (Fig. 453)

EOS kann sechs Operationen mit virtuellen Prozessoren 612 durchführen:
- VP anfordern erlaubt es EOS, einen virtuellen Prozessor 612 von KOS an-zufordern.
- VP freigeben erlaubt es EOS, einen virtuellen Prozessor 612 an KOS zurückzugeben.
- Binden bindet einen Prozessor 610 an einen virtuellen Prozessor 612.
- Lösen löst einen Prozeß 610 von einem virtuellen Prozessor 612.
- Laufen erlaubt es KOS, den virtuellen Prozessor 612 des Prozesses 610 an JP 10114 zu binden.
- Stopp verhindert, daß KOS den virtuellen Prozessor 612 des Prozesses 610 an JP 10114 bindet.
Wie aus der obigen Liste der Operationen ersichtlich wird, hat EOS keinen direkten Einfluß auf das aktuelle Binden eines virtuellen Prozessors 612 an JP 10114. Diese Operation wird durch eine Komponente des KOS-Mikrocodes, den sogenannten Aufteiler, durchgeführt. Der Aufteiler-Mikrocode wird immer dann ausgeführt, wenn eines der vier folgenden Dinge auftritt:
- Der Prozeß 610, dessen virtueller Prozessor 612 augenblicklich an JP 10114 gebunden ist, führt eine Erwartungsoperation aus.
- Der Prozeß 610, dessen virtueller Prozessor 612 augenblicklich an JP 10114 gebunden ist, führt eine Vorschuboperation aus, die einen Erwartungseintrag 44801 für einen anderen Prozeß 610 befriedigt.
- Das Intervallzeitmeßgerät 25410 oder die Eieruhr 25412 läuft über, was ein Ereignissignal verursacht, das den Aufteiler-Mikrocode aufruft.
- Der IOJP-Bus 10132 wird aktiviert, was ein Ereignissignal verursacht, das den Aufteiler-Mikrocode aufruft. IOS 10116 aktiviert den IOJP-Bus 10132, wenn es Daten in MEM 10112 für JP 10114 lädt.
Wenn der Aufteiler-Mikrocode von einem dieser Ereignisse aufgerufen wird, untersucht er die Listen in MVPL 45309, um zu bestimmen, welcher virtuelle Prozessor 612 als nächstes laufen soll. Für den Gegenstand der vorliegenden Diskussion sind nur zwei Listen wichtig: die Laufliste und die Möglich-Liste. In der gegenwärtigen Verkörperung beinhaltet die Laufliste, an deren erster Stelle der Lauflistenkopf 45321 steht, nur einen einzigen MVPLE 45321, der den gegenwärtig an JP 10114 gebundenen virtuellen Prozessor 612 darstellt. In Verkörperungen mit mehreren JPs 10114 kann die Laufliste mehr als ein MVPLE 45321 beinhalten. Die Möglich-Liste, an deren erster Stelle der Möglich-Listenkopf 45313 steht, beinhaltet die MVPLEs 45321, die jene virtuellen Prozessoren darstellen, die an JP 10114 gebunden werden können. Die MVPLEs 45321 auf der Möglich-Liste werden durch EOS nach mit Prioritäten belegten Prozessen 610 geordnet. Wann immer der KOS-Aufteilermikrocode aufgerufen wird, vergleicht er die Priorität des Prozesses 610, dessen MVPLE 45321 des virtuellen Prozessors 612 auf der Laufliste steht, mit der Priorität des Prozesses 610, dessen MVPLE 45321 des virtuellen Prozessors 612 am Kopf der Möglich-Liste steht. Wenn der letztere Prozeß 610 eine höhere Priorität hat, plaziert der KOS-Aufteilermikrocode den MVPLE 45321, der zu dem virtuellen Prozessor des früheren Prozesses 610 gehört, auf die Möglich-Liste und den MVPLE 45321, der zu dem virtuellen Prozessor 612 des letzteren Prozesses 610 gehört, auf die Laufliste. Der Aufteilermikrocode tauscht dann die Prozesse 610, indem er den Zustand in JP 10114, der zu dem früheren Prozeß 610 gehört, auf das SS-Objekt 10336 des früheren Prozesses 610 schiebt, und den JP 10114-Zustand, der zu dem letzteren Prozeß 610 gehört, vom SS-Objekt 10336 des letzteren Prozesses 610 in JP 10114 schiebt.

b. Virtuelle Prozessoren 612 und Synchronisation (Fig. 454)

Wenn eine Synchronisationsoperation mit einem Prozeß 610 durchgeführt wird, so ist eine der Folgen der Operation eine Synchronisationsoperation mit einem virtuellen Prozessor 612. Zum Beispiel verursacht eine Vorschuboperation, die einen Erwartungseintrag 44804 für einen Prozeß 610 befriedigt, eine Vorschuboperation, die einen zweiten Erwartungseintrag 44804 für den virtuellen Prozessor 612 des Prozesses 610 befriedigt. In ähnlicher Weise kann eine Synchronisationsoperation, die mit einem virtuellen Prozessor durchgeführt wurde, eine Synchronisationsoperation mit einem Prozeß 610 des virtuellen Prozessors 612 zur Folge haben. Wenn zum Beispiel ein virtueller Prozessor 612 eine Operation durchführt, in der Datei-I/O involviert ist, muß der Prozeß 610 des virtuellen Prozessors 612 die Vollendung der I/O-Operation abwarten.
Fig. 454 verdeutlicht die Hilfsmittel, durch die Synchronisationsoperationen auf Prozeßebene Synchronisationsoperationen auf virtueller Prozessorebene ergeben und umgekehrt. Die Diskussion beschreibt zuerst die Komponenten, die die Synchronisationsoperationen auf Prozeßebene zu den virtuellen Prozessoren 612 übertragen, und die Weise, in der diese Komponenten arbeiten. Danach beschreibt sie die Komponenten, die Synchronisationsoperationen auf virtueller Prozessorebene zu den Prozessen 610 übertragen und die Arbeitsweise dieser Komponenten.
Der erste Komponentensatz besteht aus VPSBA 45301 und VPAT 45401. VPSBA 45301 wird hier mit zwei VPSBs 614 gezeigt: einer, der zu einem virtuellen Prozessor 612 gehört, der an einen Benutzerprozeß 610 gebunden ist, und einen, der zu einem virtuellen Prozessor 612 gehört, der an einen KOS-Prozeßmanagerprozeß 610 gebunden ist. VPAT 45401 ist eine Tabelle von Erwartungseinträgen 44804 auf virtueller Prozessorebene. Jeder Erwartungseintrag 44804 ist in einem VPAT-Eintrag (VPATE) 45403 enthalten. Jeder virtuelle Prozessor 612, der an einen Prozeß 610 gebunden ist, hat ein VPAT-Stück 45402 von vier VPATEs 45403 in VPAT 45401 und kann daher zu einem gegebenen Zeitpunkt bis zu vier Ereigniszähler 44801 erwarten. Die Lokation des VPAT-Stückes 45402 eines virtuellen Prozessors 612 wird im VPSB 614 des virtuellen Prozessors 612 gespeichert. Wenn eine Vorschuboperation irgendeinen der zu einem virtuellen Prozessor 612 gehörenden Erwartungseinträge 44804 befriedigt, werden alle Erwartungseinträge 44804 im VAT- Stück 45402 des virtuellen Prozessors 612 gelöscht. Wie in PET 44705 werden VPATEs 45403, die Erwartungseinträge 44804 enthalten, die einen gegebenen Ereigniszähler 44801 erwarten, in einer Liste miteinander verknüpft.
Die VPATEs 45403 für virtuelle Prozessoren 612, die an Benutzerprozesse 610 gebunden sind, können Erwartungseinträge 44804 für private Ereigniszähler 45405 von Benutzerprozessen 610 enthalten. Der private Ereigniszähler 45405 ist im Prozeßobjekt 901 eines Prozesses 610 enthalten. Er wird jedesmal hochgezählt, wenn ein Erwartungseintrag 44804 in einem PETE 44909 auf einer PET-Liste, die zum Prozeß 610 gehört, befriedigt wird.
Die Komponenten arbeiten wie folgt: Wenn KOS eine Erwartungsoperation mit dem Prozeß 610 durchführt, macht er Erwartungseinträge 44804 sowohl in PET 44705 und in VPAT 45401 und setzt den VP 612 des Prozesses 610 auf die Anhalteliste in MVPL 45309. Wie oben beschrieben, erwartet ein Erwartungseintrag 44804 in PET 44705 einen Ereigniszähler 44801, der in der Erwartungsoperation spezifiziert wurde, die den Erwartungseintrag 44804 erzeugte. Der Erwartungseintrag 44804 in VPAT 45401 erwartet den privaten Ereigniszähler 45405 des Prozesses 610. Jedesmal, wenn ein Erwartungseintrag 44804, der zu einem Prozeß 610 gehört, in PET 44705 befriedigt wird, wird der private Ereigniszähler 45405 des Prozesses 610 hochgezählt. Das Hochzählen des privaten Ereigniszählers 45405 befriedigt den Erwartungseintrag 44804 für den virtuellen Prozessor 612 des Prozesses 610 in VPAT 45401, und daher löscht KOS die VPATEs 45403 des virtuellen Prozessors 612 und schiebt den MVPLE 45321 in MVPL 45309 des virtuellen Prozessors 612 von der Anhalteliste in die Möglich-Liste.
Die Komponenten, die es einem virtuellen Prozessor 612 erlauben, eine Synchronisationsoperation zu einem Prozeß 610 zu übertragen, sind folgende: das Außensignalobjekt (OSO) 45409, der Ereigniszähler für aufgeteilte Außensignale 45407 und PET 44705. OSO 45409 enthält Ereigniszähler 44801, die der KOS FU 10120-Mikrocode hochzählt, wenn er Operationen durchführt, die Benutzerprozesse 610 erwarten. Die Ereigniszähler 44801 in OSO 45409 werden von Erwartungseinträgen 44804 in PET 44705 erwartet. Jedesmal, wenn KOS FU 10120-Mikrocode einen Ereigniszähler 44801 in OSO 45409 hochzählt, zählt er auch den Ereigniszähler für aufgeteilte Außensignale 45407 hoch. Dies wird von einem Erwartungseintrag 44804 in VPAT 45401, der zu einem virtuellen Prozessor 612 gehört, der an einen KOS-Prozeßmanagerprozeß 610 gebunden ist, erwartet. Wenn der virtuelle Prozessor 612, der an den KOS-Prozeßmanagerprozeß 610 gebunden ist, wieder an JP 10114 gebunden wird, untersucht der KOS-Prozeßmanagerprozeß 610 alle PETEs 44909, die zu Ereigniszählern 44801 in OSO 45423 gehören. Wenn ein Vorschub eines Ereigniszähler 44801 in OSO 45423 einen PET 44909 befriedigte, so wird der private Ereigniszähler 45405 des Prozesses 610, wie oben beschrieben, hochgezählt, und der Prozeß 610 kann wieder ausführen.
Eine Benutzer-I/O-Operation verdeutlicht, wie die Komponenten zusammenarbeiten. Jeder Benutzer-I/O-Kanal hat einen Ereigniszähler 44801 in OSO 45409. Wenn ein Prozeß 610 eine Benutzer-I/O-Operation auf einem Kanal durchführt, errichtet das EOS-I/O-Programm einen Erwartungseintrag 44804 in der PET 44705-Liste, die zu dem Prozeß 610 für den Ereigniszähler des Kanals in OSO 45409 gehört. Wenn die I/O-Operation abgeschlossen ist, stellt IOS 10116 eine Nachricht an JP 10114 in eine Fläche von MEM 10112 und aktiviert den IOJP-Bus 10132. Die Aktivierung des IOJP-Busses 10132 bewirkt ein Ereignissignal, welches KOS-Mikrocode aufruft. Der Mikrocode untersucht die Nachricht von IOS 10116, um zu bestimmen, welcher Kanal involviert ist, zählt dann den Ereigniszähler 44801 für diesen Kanal in OSO 45409 und den Ereigniszähler für aufgeteilte Außensignale 45407 hoch. Der letztere Vorschub befriedigt einen Erwartungseintrag 44804 für den virtuellen Prozessor 612 des Prozeßmanagerprozesses 610 in VPAT 45401 und der Prozeßmanagerprozeß 610 fängt mit der Ausführung an. Der Prozeßmanagerprozeß 610 untersucht OSO 45409, um zu bestimmen, welche Ereigniszähler 44801 in OSO 45409 hochgezählt wurden, seitdem der Prozeßmanagerprozeß 610 das letzte Mal ausführte, und wenn es einen solchen Ereigniszähler 44801 findet, so untersucht er die Ereigniszählerkette in PET 44705 für diesen Ereigniszähler 44801. Wenn er herausfindet, daß der Vorschub irgendeinen Erwartungseintrag 44804 in der Ereigniszählerkette befriedigte, so zählt er den privaten Ereigniszähler 45405, der zu dem Prozeß 610 gehört, der im Erwartungseintrag 44804 spezifiziert wurde, hoch, womit er verursacht, daß der Prozeß 610, wie oben beschrieben, seine Ausführung wieder aufnimmt.

F. Stapelspeichermanipulation des Prozesses 610

Dieser Abschnitt der Spezifikation für CS 10110 beschreibt die Art und Weise, in der die MAS 502 und SS 504 eines Prozesses 610 manipuliert werden. Wie oben erwähnt, sind in CS 10110 die MAS 502 und SS 504 eines Prozesses 610 in mehreren Objekten enthalten. IN der gegenwärtigen Verkörperung gibt es fünf Objekte, eines für jeden Bereichsabschnitt des Makrostapelspeichers (MAS) (die MAS-Objekte 10328 bis 10324) und eines für den Sicherheitsstapelspeicher (SS) (SS-Objekt 10336). In anderen Verkörperungen kann der MAS 502 eines Prozesses 610 auch Objekte für Benutzer-definierte Bereiche haben. Obwohl der MAS 502 und SS 504 eines Prozesses 610 in vielen Objekten enthalten sind, funktionieren sie als ein einziger logischer Stapelspeicher. Die Unterteilung in mehrere Objekte ist eine Folge zweier Dinge: die Bereichskomponente des Schutzsystems, die es erforderlich macht, daß ein durch eine Prozedur 602 referenziertes Objekt den Ausführungsbereich der Prozedur 602 hat, und der Bedarf einer für Benutzerprogramme nicht zugänglichen Lokation für Mikromaschinenzustand und Zustand, der nur durch KOS manipuliert werden kann.
Stapelspeichermanipulation findet unter folgenden Umständen statt:
- Wenn eine Prozedur 602 aufgerufen wird oder ein Rückkehr-SIN ausgeführt wird. Aufrufe einer Prozedur 602 werden durch einen SIN-Aufruf durchgeführt. Der Aufruf bewirkt den Transfer der Steuerung zum ersten SIN in der aufgerufenen Prozedur 602, und der Rückkehr-SIN bewirkt einen Transfer der Steuerung zurück zu dem SIN in der aufrufenen Prozedur 602, die dem Aufruf-SIN folgt.
- Wenn ein nicht lokaler Go-To-SIN ausgeführt wird. Das nicht lokale Go To bewirkt einen Transfer der Steuerung zu einer willkürlichen Position in einer Prozedur 602, die früher durch den Prozeß 610 aufgerufen wurde, und deren Aufruf noch nicht beendet ist.
- Wenn eine Bedingung auftaucht, d. h. die Ausführung einer Anweisung in einem Programm versetzt den ausführenden Prozeß 610 in einen Zustand, der die Ausführung einer vorher aufgestellten Bearbeitungsprozedur 602 erforderlich macht.
- Wenn ein Prozeß 610 unterbrochen wird, d. h. wenn ein Unterbrechungseintrag 45718 für den Prozeß 610 befriedigt wird.
Die meisten der bei der Stapelspeichermanipulation involvierten Mechanismen werden beim Aufruf und bei der Rückkehr benötigt; diese Operationen werden daher genau behandelt und die anderen Operationen nur insoweit, als sie sich-von Aufruf und Rückkehr unterscheiden. Die Diskussion führt zuerst Aufruf und Rückkehr ein, erklärt dann die Stapelspeicher genau und analysiert schließlich Aufruf und Rückkehr und die anderen Operationen im Detail.

1. Einführung zu Aufruf und Rückkehr

Wenn ein Prozeß 610 ein Programm ausführt, so führt es Aufruf- und Rückkehr-SINs aus. Ein Aufruf-SIN beginnt eine Invokation einer Prozedur 602 und ein Rückkehr-SIN beendet die Invokation. Im allgemeinen macht ein Aufruf-SIN folgendes:
- Es speichert den Zustand der Ausführung des Prozesses 610 der Prozedur 602, die den Aufruf-SIN enthält. In diesem Zustand enthalten sind die Informationen, die benötigt werden, um die Ausführung der Prozedur 602, nachdem der Aufruf- SIN beendet ist, fortzusetzen. Dieser Bereich des Zustandes ist der sogenannte Makrostatus der rufenden Prozedur 602.
- Er erzeugt den Zustand, den der Prozeß 610 benötigt, um die Ausführung der gerufenen Prozedur 602 zu beginnen.
- Er überträgt die Kontrolle zum ersten SIN im Code der gerufenen Prozedur 602.
Der Rückkehr-SIN macht das Gegenteil: Er gibt den Zustand der gerufenen Prozedur 602 frei, restauriert den gesicherten Zustand der rufenden Prozedur 602 und transferiert die Kontrolle zu dem SIN in der rufenden Prozedur 602, der dem Aufruf-SIN folgt. Eine Invokation einer Prozedur 602 dauert von der Ausführung des Aufruf-SINs, der die Kontrolle zu der Prozedur 602 übergibt, bis zur Ausführung des Rückkehr-SINs, der die Kontrolle zurück zu der Prozedur 602 transferiert, die den Aufruf-SIN beinhaltete. Der Zustand, der zu einer gegebenen Invokation einer Prozedur 602 durch einen Prozeß 610 gehört, wird Invokationszustand der gerufenen Prozedur 602 genannt.
Während Aufruf und Rückkehr in vielen verschiedenen Arten implementiert werden können, ist es vorteilhaft, sie als Stapelspeicher zu implementieren. Wenn ein Aufruf den Invokationszustand für eine Prozedur 602 erzeugt, wird dieser Invokationszustand an den Kopf des Stapelspeichers des Prozesses 610 angefügt. Die Fläche eines Stapelspeichers, die den Invokationszustand einer Prozedur 602 enthält, wird Rahmen genannt. Da eine gerufene Prozedur 602 eine andere Prozedur 602 aufrufen kann, und die wieder eine andere, kann der Stapelspeicher eine Vielzahl von Rahmen besitzen, wobei jeder Rahmen den Invokationszustand enthält, der sich aus der Invokation einer Prozedur 602 durch den Prozeß 610 ergibt, und jeder Rahmen so lange dauert, wie die Invokation, die er darstellt. Wenn eine gerufene Prozedur 602 zu ihrem Aufrufer zurückkehrt, wird der Rahmen, auf dem sie ausführt, frei gegeben, und der Aufrufer nimmt die Ausführung auf seinem eigenen Rahmen wieder auf. Daher läuft die gerade durch einen Prozeß 610 ausgeführte Prozedur 602 immer auf dem oberen Rahmen des MAS 502 des Prozesses 610.
Aufruf und Rückkehr in CS 10110 verhalten sich logisch gesehen wie die in anderen Computersystemen, die Stapelspeicher benutzen, um den Zustand des Prozesses 610 aufzubewahren. Wenn ein Prozeß 610 einen Aufruf-SIN ausführt, speichert der SIN als Makrozustand die gegenwärtigen Werte der ABPs, die Lokation des SIN, an dem die Ausführung der rufenden Prozedur 602 weitermachen muß, und Informationen wie Zeiger auf die Namenstabelle 10350 der rufenden Prozedur 602 und die UID 40401, die zum S- Interpreterobjekt gehört, das den S-Interpreter für die S-Sprache der Prozedur 602 enthält. Der Aufruf-SIN erzeugt dann einen Stapelspeicherrahmen für die gerufene Prozedur 602, erhält die richtigen ABP-Werte, die Lokation der Namenstabelle 10350 der gerufenen Prozedur 602 und die UID 40401, die zu ihrem S-Interpreterobjekt gehört, und beginnt die frisch aufgerufene Prozedur 602 auf dem frisch erzeugten Stapelspeicherrahmen auszuführen. Der Rückkehr-SIN löscht den Stapelspeicherrahmen, bestimmt die ABP- Werte und Namensinterpreter-Informationen aus dem Makrozustand, der während des Aufruf-SINs abgespeichert wurde, und transferiert die Kontrolle zu dem SIN, an dem die Ausführung der rufenden Prozedur 602 fortgesetzt werden muß.
Die Art und Weise jedoch, in der Aufruf und Rückkehr implementiert werden, wird stark durch das Zugangskontrollsystem des CS 10110 beeinflußt. Grob gesehen gibt es zwei Klassen von Aufruf und Rückkehr in CS 10110: die, die durch KOS vermittelt werden, und die, die nicht durch KOS vermittelt werden. In der folgenden Diskussion wird die erste Klasse von Aufruf und Rückkehr vermittelter Aufruf und Rückkehr genannt, und letztere Nachbarschaftsaufruf und -rückkehr. Die meisten Aufrufe und Rückkehren, die durch CS 10110 ausgeführt werden, sind Nachbarschaftsaufrufe und -rückkehren; vermittelte Aufrufe und Rückkehren werden typischerweise ausgeführt, wenn eine Benutzerprozedur 602 EOS-Prozeduren 602 aufruft, und diese wiederum KOS-Prozeduren 602 aufrufen. Der vermittelte Aufruf macht CS 10110 Möglichkeiten für Benutzerprozesse 610 verfügbar, während er diese CS 10110-Möglichkeiten vor Mißbrauch schützt, und daher allgemein dem gleichen Zwecke dient wie Systemaufrufe herkömmlicher Art. Wie in der folgenden Diskussion sichtbar wird, erfordert ein vermittelter Aufruf mehr CS 10110-Aufwand als ein Nachbarschaftsaufruf, aber der Mehraufwand ist geringer als der, der im allgemeinen durch Systemaufrufe herkömmlicher Art erforderlich ist.
Vermittelte Aufrufe und Rückkehren involvieren S-Interpreter, Adreßraum und KOS- Mikrocode. Der S-Interpreter und Adreßraum-Mikrocode interpretieren die im Aufruf involvierten Namen und modifizieren nur die Bereiche des Makrozustandes, die dem S- Interpreter zugänglich sind. Der verbleibende Makrozustand wird durch die KOS-Mikroprogramme verändert, die im Verlauf des Aufruf-SIN aufgerufen werden. Ein vermittelter Aufruf kann zu jeder beliebigen Prozedur 602 gemacht werden, die in einem Objekt enthalten ist, auf das das Subjekt des Prozesses 610 zum Zeitpunkt des Aufrufs Ausführungsrechte besitzt. Vermittelte Aufrufe und Rückkehren müssen in folgenden Situationen gemacht werden:
- Wenn die gerufene Prozedur 602 einen anderen Prozeduren-Umgebungsbeschreiber (PED) 30303 hat als der, der von der rufenden Prozedur 602 benutzt wird. Solche Aufrufe werden PED-übergreifende Aufrufe genannt.
- Wenn die gerufene Prozedur 602 in einem anderen Prozedurobjekt 608 ist als das der rufenden Prozedur 602. Solche Aufrufe werden Prozedurobjekt-übergreifende Aufrufe genannt.
- Wenn das Prozedurobjekt 608 der gerufenen Prozedur 602 ein anderes Ausführungsbereichs (DOE)-Attribut hat als das Prozedurobjekt 608 der rufenden Prozedur 602 und deshalb seinen Invokationszustand auf einem anderen MAS- Objekt plazieren muß als das, das von der rufenden Prozedur 602 benutzt wird. Solche Aufrufe werden bereichsübergreifende Aufrufe genannt.
In allen obigen Aufrufen sind die Informationen, die nötig sind, um den Aufruf zu beenden, für den S-Interpreter nicht verfügbar, und daher wird eine KOS-Vermittlung benötigt, um den Aufruf zu beenden. Nachbarschaftsaufrufe und Rückkehren modifizieren nur zwei Komponenten des Makrozustandes: den Zeiger auf den-gegenwärtigen SIN und den FP ABP. Beide diese Komponenten sind dem S-Interpreter verfügbar, solange die gerufene Prozedur 602 denselben PED 30303 besitzt, d. h. dieselbe Namenstabelle 10350 wie der S-Interpreter oder die rufende Prozedur 602 und Namen mit derselben Silbengröße besitzt wie die Prozedur 602. Die SINs von Aufruf und Rückkehr sind spezifisch für jede S-Sprache, aber sie ähneln sich einander in ihrem allgemeinen Verhalten. Die folgende Diskussion beschäftigt sich ausschließlich mit diesem allgemeinen Verhalten und konzentriert sich auf vermittelte Aufrufe und Rückkehren. Die Diskussion beschreibt zuerst MAS 502 und SS 504, die zu einem Prozeß 610 gehören, und die Teile des Prozedurobjekts 608, die in Aufrufe und Rückkehren involviert sind, und beschreibt dann die Implementation von Aufrufen und Rückkehren.

2. Makrostapelspeicher (MAS) 502 (Fig. 467)

Fig. 467 gibt einen Überblick über ein Objekt, das zu einem MAS 502 eines Prozesses 610 gehört. Der Beschreibung dieser Figur folgen Beschreibungen anderer Figuren, die genaue Darstellungen der Bereiche der MAS-Objekte enthalten.
Ein MAS-Objekt 46703 umfaßt mindestens den KOS MAS-Kopf 10410 und den ungenutzten Speicher 46727, der für die anderen Elemente reserviert ist, aus denen das MAS- Objekt 46703 besteht. Wenn der Prozeß 610 noch nicht von einer Invokation einer Prozedur 602 zurückgekehrt ist, die in einem Prozedurobjekt 608 enthalten ist, dessen DOE das für den Zugang auf das MAS-Objekt 46703 erforderliche ist, umfaßt das MAS- Objekt 46703 weiterhin eine Stapelspeicherbasis 46703 und mindestens einen MAS- Rahmen 46709.
Jeder MAS-Rahmen 46709 stellt eine vermittelte Invokation einer Prozedur 602 dar, die in einem Prozedurobjekt 608 mit dem von MAS 46703 geforderten DOE-Attribut enthalten ist, und kann zusätzlich Nachbarschaftsinvokationen von Prozeduren 602 darstellen, die das Prozedurobjekt jener Prozedur 602 teilen. Der oberste MAS-Rahmen 46709 stellt die jüngste Gruppe von Invokationen von Prozeduren 602 mit dem durch das MAS-Objekt 46703 geforderten DOE-Attribut dar, und der unterste MAS-Rahmen 46709 stellt die jüngste Gruppe von Invokationen dar, von dem der Prozeß 610 noch nicht zurückgekehrt ist. Rahmen für Invokationen von Prozeduren 602 mit anderen Ausführungsbereichen sind in anderen MAS-Objekten 46703 enthalten. Wie später genau erklärt wird, werden MAS- Rahmen 46709 in verschiedenen MAS-Objekten 46703 durch Zeiger miteinander verknüpft.
Die MAS-Bereichsstapelspeicherbasis 46703 hat zwei Teile: den KOS MAS-Kopf 10410, der Informationen enthält, die vom KOS-Mikrocode benutzt werden, der das MAS-Objekt 46703 manipuliert, und bereichsbezogene Informationen 46707, die Informationen über den Bereich von 46703 und statische Informationen beinhalten, d. h. Informationen, die länger leben als eine Invokation und von den Prozeduren 602 mit den MAS-Rahmen 46709 auf dem MAS-Objekt 46703 benutzt werden. Der MAS-Rahmen 46709 hat auch zwei Hauptteile, einen KOS-Rahmenkopf 10414, der Informationen enthält, die von KOS benutzt werden, um den Rahmen 46709 zu manipulieren, und den S-Interpreterbereich 46713, der Informationen enthält, die dem S-Interpreter verfügbar sind, wenn er die Gruppe von Prozeduren 602 ausführt, deren Invokationen durch den Rahmen 46709 dargestellt werden.
Wenn der S-Interpreter und KOS-Mikrocode Aufrufe und Rückkehren machen, benutzen sie eine Gruppe von Zeigern auf Lokationen im MAS-Objekt 46703. Diese Zeiger umfassen folgendes:
- Die MAS-Objekt UID 46715, die UID 40401 des MAS-Objekts 46703.
- Den Abstand des ersten Rahmens (FFO) 46719, der den Anfang des KOS- Rahmenkopfes 10414 lokalisiert, der zu dem ersten MAS-Rahmen 46709 im MAS-Objekt 46703 gehört.
- Den Rahmenkopfzeiger (FHP) 46702, der den Anfang des obersten KOS- Rahmenkopfes 10414 im MAS-Objekt 46703 lokalisiert.
- Der Stapelspeicher-Spitzenabstand (STO) 46704, ein 32 Bit-Abstand von der Stapelspeicher-UID 46715, der das erste Bit im ungenutzten Speicher 46727 markiert.
Wie jetzt ersichtlich wird, sind all diese Zeiger in den Feldern im KOS MAS-Kopf 46705 enthalten.

a.a. MAS-Basis 10410 (Fig. 468)

Fig. 468 ist eine genaue Darstellung der MAS-Bereichsstapelspeicherbasis 10410. Indem wir uns zuerst zu der genauen Darstellung des KOS MAS-Kopfes 46705 zuwenden, die darin enthalten ist, so gibt es folgende Felder:
- Das Formatinformationsfeld 46801, das Informationen über das Format des KOS MAS-Kopfes 46705 enthält.
- Das Kennzeichenfeld 46803. Von diesen Kennzeichen ist in der gegenwärtigen Diskussion nur eines von Interesse: das Bereich-Aktiv-Kennzeichen 46804. Dieses Kennzeichen wird auf wahr gesetzt, wenn der Prozeß 610, zu dem das MAS- Objekt 46703 gehört, die Invokation der Prozedur 602 ausführt, deren Invokationssatz den obersten MAS-Rahmen 46709 bildet, der im MAS-Objekt 46703 enthalten ist, zu dem der KOS MAS-Kopf 46705 gehört.
- Das PFO-Feld 46805: Alle MAS-Köpfe 46705 und Rahmenköpfe 46709 haben Felder, die Abstände enthalten, die die vorherigen und folgenden Köpfe im MAS- Objekt 46703 lokalisieren. In einem Stapelspeicherkopf 46705 gibt es keinen vorangehenden Kopf, und dieses Feld wird auf 0 gesetzt.
- Das FFO-Feld 46805: Das Feld, das den folgenden Kopf lokalisiert. In einem Stapelspeicherkopf 46705 enthält dieses Feld FFO 46719, denn der nächste Kopf ist der erste Rahmenkopf im MAS-Objekt 46703.
- Das STO-Feld 46807: Das Feld enthält den STO-Abstand 46704.
- Das Prozeß-ID-Feld 46809: Die UID 40401, die zum Prozeßobjekt 901 für den Prozeß 610 gehört, zu dem das MAS-Objekt 46703 gehört.
- Das Bereichsumgebungs-Informationszeigerfeld 46811: Der im Feld enthaltene Zeiger lokalisiert eine Fläche, die bereichsspezifische Informationen enthält. In der gegenwärtigen Verkörperung ist diese Fläche Teil der MAS-Stapelspeicherbasis 10410; in anderen Verkörperungen jedoch kann es in einem separaten Objekt enthalten sein.
- Das Signalgeberzeigerfeld 46813: Der im Feld enthaltene Zeiger lokalisiert eine Prozedur 602, die KOS aufruft, wenn die Ausführung eines Prozesses 610 bewirkt, daß eine Bedingung entsteht, während er in dem Bereich ausführt, zu dem das MAS-Objekt 46703 gehört.
- Das AAT-Zeigerfeld 30211: Der Zeiger im Feld 30211 lokalisiert AAT 30201 für das MAS-Objekt 46703. AAT 30201 ist detailliert in Kapitel 3 beschrieben.
- Das Rahmenkennzeichen-Ablaufsteuererfeld 46819: Dieses Feld enthält einen Ablaufsteuerer 45102. Der Ablaufsteuerer 45102 wird benutzt, um Kennzeichen zu erzeugen, die benutzt werden, um MAS-Rahmen 46709 zu lokalisieren, wenn ein nicht lokales Go To ausgeführt wird.
Indem wir uns nun der genauen Darstellung der Bereichsumgebungsinformation 46821 zuwenden, die durch das Bereichsumgebungs-Informationszeigerfeld 46811 lokalisiert wird, so gibt es folgende Felder:
- Das KOS-Formatinformationsfeld 46823.
- Das Kennzeichenfeld 46825, das folgende Kennzeichen enthält:
- Das wartende Unterbrechung-Kennzeichen 46827, das auf wahr gesetzt wird, wenn der Prozeß 610 eine wartende Unterbrechung für den Bereich hat, zu dem das MAS-Objekt 46703 gehört.
- Das Bereich-Tot-Kennzeichen 46829, das auf wahr gesetzt wird, wenn ein Prozeß 610 nicht mehr länger Prozeduren 602 ausführen kann, deren Ausführungsbereiche denen gleich sind, zu dem das MAS-Objekt 46703 gehört.
- Das Beim-Eingang-überprüfen-aufrufen-Kennzeichen 46833 und das Beim-Ausgang-überprüfen-aufrufen-Kennzeichen 46835. Das erste Kennzeichen wird auf wahr gesetzt, wenn KOS eine Prozedur 602 aufrufen soll, die die Datenbasen des Bereichs überprüft, bevor eine Prozedur 602 auf dem MAS-Objekt 46703 des Bereichs ausführen darf; die letztere wird auf wahr gesetzt, wenn KOS eine solche Prozedur 602 beim Ausgang von einer Prozedur 602 mit dem Bereich als seiner DOE aufrufen soll.
- Das Standardbearbeiter-nicht-Null-Kennzeichen 46835 wird auf wahr gesetzt, wenn es einen Standardzerlegungsbearbeiter für den Bereich gibt. Zerlegungsbearbeiter werden später beschrieben.
- Das Unterbrechungsmaskenfeld 46839 bestimmt, welche für den Prozeß 610 gesetzten Unterbrechungen im Bereich des MAS-Objekts 46703 bedient werden.
- Das Bereichs-UID-Feld 46841 enthält die UID 40401 für den Bereich, zu dem das MAS-Objekt 46703 gehört.
- Die Felder 46843 bis 46849 sind Zeiger auf Prozeduren 602 oder Tabellen von Zeigern auf Prozeduren 602. Die so lokalisierten Prozeduren 602 bearbeiten Situationen, die aufkommen, wenn die MASs 502 manipuliert werden. Der Gebrauch dieser Felder wird klar werden, wenn die Operationen erklärt werden, die ihre Nutzung erfordern.

b.b. Bereichsbezogene Datenfläche 46853 (Fig. 468)

Die bereichsbezogene Datenfläche 46853 enthält Daten, die nicht in den MAS-Rahmen 46709 gehalten werden können, die zu Invokationen von Prozeduren gehören, die im Bereich des MAS-Objekts 46703 ausführen, aber die für diese Invokationen verfügbar sein müssen. Die bereichsbezogene Datenfläche 46853 hat zwei Komponenten: die Speicherfläche 46854 und AAT 30201. Die Speicherfläche 46854 enthält statische Daten, die von den Prozeduren 602 mit Invokationen auf dem MAS-Objekt 46703 benutzt werden und Daten, die von den S-Interpretern, die von solchen Prozeduren 602 benutzt werden, benutzt werden. Die zugehörige Adressentabelle (AAT) 30201 wird dazu benutzt, um die Daten in der Speicherfläche 46854 zu lokalisieren. Eine genaue Diskussion von AAT 30201 befindet sich in Kapitel 3.
Zwei Datenarten werden in der Speicheffläche 46854 gespeichert: statische Daten und S- Interpreterdaten.
Statische Daten werden im statischen Datenblock 46863 gespeichert. Der statische Datenblock 46863 umfaßt zwei Teile: die Verkettungszeiger 46865 und den Speicher für statische Daten 46867. Die Verkettungszeiger 46865 sind Zeiger auf statische Daten, die nicht im Speicher für statische Daten 46867 enthalten sind, z. B. Daten, die länger leben als der Prozeß 610, und Zeiger auf externe Prozeduren 602, die die Prozedur 602, zu der der Speicher für die statischen Daten 46867 gehört, aufruft. Der Speicher für statische Daten 46867 enthält Speicher für die statischen Daten, die von der Prozedur 602 benutzt werden, die nicht länger lebt als der Prozeß 610, der die Prozedur 602 ausführt.
Die S-Interpreterdaten sind Daten, die von S-Interpretern benötigt werden, die von Prozeduren 602 benutzt werden, die auf MAS-Objekt 46703 ausführen. Die S-Interpreterdaten werden im S-Interpreter-Umgebungsblock (SEB) 46864 gespeichert, der wie der statische Datenblock 46864 über AAT 30201 lokalisiert wird. Die Inhalte von SEB 46864 hängen vom S-Interpreter ab.

c.c. Einzelheiten des MAS-Rahmens 46709 (Fig. 469)

Fig. 469 stellt einen typischen Rahmen im MAS-Objekt 46703 dar. Jeder MAS-Rahmen 46709 enthält einen vermittelten Rahmen 46947, der von einem vermittelten Aufruf einer Prozedur 602 erzeugt wurde, die in einem Prozedurobjekt 608 enthalten ist, dessen DOE- Attribut das für die Ausführung auf dem MAS-Objekt 46703 erforderliche ist. Ein vermittelter Rahmen 46947 kann von Nachbarschaftsrahmen 46945 gefolgt werden, die von Nachbarschaftsaufrufen von Prozeduren 602 erzeugt werden. Ein vermittelter Rahmen 46947 hat zwei Teile, einen KOS-Rahmenkopf 10414, der vom KOS-Mikrocode manipuliert wird, und einen S-Interpreterbereich, der durch den S-Interpreter und Adreßraum- Mikrocode manipuliert wird. Nachbarschaftsrahmen 46945 haben keine KOS-Rahmenköpfe 10414. Wie bei einer näheren Betrachtung der Fig. 469 klar werden wird, enthalten die vermittelten Rahmen 46947 in der gegenwärtigen Verkörperung keinen Makrozustand. In der gegenwärtigen Verkörperung wird der Makrozustand für diese Rahmen im SS-Objekt 10336 gehalten; in anderen Verkörperungen kann jedoch der Makrozustand in den vermittelten Rahmen 46947 gespeichert werden. Nachbarsschaftsrahmen 46945 enthalten jene Bereiche des Makrozustandes, die durch Nachbarschaftsaufrufe manipuliert werden können; die Lokation dieses Makrozustandes hängt vom SIN des Nachbarschaftsaufrufes ab.
Indem wir uns nun dem KOS-Rahmenkopf 10414 zuwenden, gibt es folgende Felder:
- Das KOS-Formatinformationsfeld 46901, das Informationen über das Format des MAS-Rahmens 46709 enthält.
- Das Kennzeichenfeld 46902. Dieses Feld enthält die folgenden Kennzeichen:
- Das Ergebnis des bereichsübergreifenden Aufrufs-Kennzeichen 46903. Dieses Kennzeichen ist TRUE, falls der MAS-Rahmen 46709, der diesem MAS-Rahmen 46709 vorangeht, in einem anderen MAS-Objekt 46703 ist.
- Das Ist-Signalgeber-Kennzeichen 46905. Dieses Kennzeichen ist TRUE, wenn dieser MAS-Rahmen 46709 durch die Invokation einer Signalgeberprozedur 602 erzeugt wurde.
- Das Kehre nicht zurück-Kennzeichen 46907: Dieses Kennzeichen ist TRUE, wenn der Prozeß 610 nicht zu der Invokation zurückkehren soll, für die dieser MAS-Rahmen 46709 erzeugt wurde.
- Die Kennzeichen 46909 bis 46915 zeigen an, ob verschiedene Listen, die bei der Bedingungsbearbeitung benutzt werden, und nicht lokale Go Tos in dem MAS-Rahmen 46709 vorhanden sind.
- Das Abstandsfeld des vorangegangenen Rahmens 46917, das Abstandsfeld des nächsten Rahmens 46919 und das Abstandsfeld der Rahmenspitze 46921 sind Abstände, die die Lokation ergeben, wo der Kopf 10414 für den vorangegangenen MAS-Rahmen 46709 im MAS-Objekt 46703 beginnt, die Lokation, wo der Kopf für den nächsten MAS-Rahmen 46709 im MAS-Objekt 46703 beginnt, und die Lokation des ersten Bits unterhalb der Spitze des MAS-Rahmens 46709.
- Die Felder 46923 bis 46927 sind Abstände, die Listen im S-Interpreterbereich 46713 des Rahmens 46709 lokalisieren. KOS stellt solche Listen auf, um Bedingungen und nicht lokale Go Tos zu bearbeiten. Ihr Gebrauch wird unter jenen Überschriften genau erklärt.
- Die Felder 46929 und 46933 enthalten Informationen über die Prozedur 602, deren Invokation durch den MAS-Rahmen 46709 dargestellt wird. Das Feld 46929 enthält die Anzahl der von der Prozedur 602 benötigten Argumente, und das Feld 46933 enthält einen auflösbaren Zeiger auf den PED 30303 der Prozedur 602. Beide Felder werden hauptsächlich bei der Fehlersuche benötigt.
- Das dynamische Zurückzeigerfeld 46931 enthält einen auflösbaren Zeiger auf den vorangegangenen MAS-Rahmen 46709, der zu dem MAS 502 des Prozesses 610 gehört, wenn jener MAS-Rahmen 46709 in einem anderen MAS-Objekt 46703 enthalten ist. In diesem Fall wird das Kennzeichenfeld 46903 auf TRUE gesetzt. Wenn der vorangegangene MAS-Rahmen 46709 in demselben MAS- Objekt 46703 enthalten ist, enthält das Feld 46931 einen Zeiger mit einer Null- UID 46401 und das Kennzeichenfeld 46903 wird auf FALSE gesetzt.
- Das Rahmenkennzeichenfeld 46935 ist für ein Rahmenkennzeichen erzeugt, wenn ein nicht lokales Go To aufgestellt wird, das die Kontrolle zu der Invokation transferiert, die durch den MAS-Rahmen 46709 dargestellt wird. Das Kennzeichen wird von dem Rahmenkennzeichen-Ablaufsteuerer 46819 in dem KOS MAS-Kopf 10410 erzeugt.
Der S-Interpreterbereich 46713 des MAS-Rahmens 46709 umfaßt jene Bereiche des MAS- Rahmens 46709, die unter der Kontrolle des S-Interpreters stehen. Der S-Interpreterbereich 46713 wiederum umfaßt zwei Hauptunterteilungen: die Bereiche, die zum vermittelten Rahmen 46947 gehören, und die, die zu Nachbarschaftsrahmen 46945 gehören.
Die exakte Form des S-Interpreterbereichs 46949 des KOS-Rahmens 46947 und der S- Interpreterrahmen 46945 hängt von dem Aufruf-SIN ab, das den fraglichen Rahmen erzeugte. Jedoch haben alle Nachbarschaftsrahmen 46945 und S-Interpreterbereiche 46949 von vermittelten Rahmen 46947 dieselben Anordnungen, um die Verkettungszeiger 10416 und lokalen Daten im Rahmen zu speichern. Die Verkettungszeiger 10416 sind Zeiger auf Lokationen von aktuellen Argumenten, die bei der Invokation benutzt werden, und der lokale Speicher 10420 enthält Daten, die nur während der Invokation existieren. In allen vermittelten Rahmen 46947 und Nachbarschaftsrahmen 46945 kommen die Verkettungszeiger 10416 vor dem lokalen Speicher 10420. Darüber hinaus zeigt FP, wenn ein vermittelter Rahmen 46947 oder ein Nachbarschaftsrahmen 46945 der oberste Rahmen des MAS des Prozesses 610 ist, d. h. wenn der Prozeß 610 auf jenem Rahmen ausführt, immer auf den Anfang des lokalen Speichers 10420, und der Anfang der Verkettungszeiger 10416 befindet sich immer in einem bekannten Abstand von FP. Referenzen auf Verkettungszeiger 10416 können daher als negative Abstände von FP und Referenzen auf den lokalen Speicher 10420 als positive Abstände dargestellt werden.
Darüber hinaus kann der S-Interpreterbereich 46713 Informationslisten enthalten, die von KOS dazu benutzt werden, nicht lokale Go Tos und Bedingungen auszuführen, sowie S- Interpreterrahmen für nicht vermittelte Aufrufe. Die von KOS benutzten Informationslisten befinden sich in der Listenfläche 46943. Die exakte Lokation der Listenfläche 46943 wird vom Compiler bestimmt, der die SINs und Namenstabelle für die Prozedur 602 erzeugt, deren Invokation durch den vermittelten Rahmen 46947 dargestellt wird. Wenn der Quelltext von Prozedur 602 Anweisungen enthält, die Speicherplatz in der Listenfläche 46943 beanspruchen, erzeugt der Compiler SINs, die den geforderten Speicherplatz im lokalen Speicher 10420 plazieren. Die KOS-Programme bauen dann Listen in der Fläche 46943 und plazieren die Abstände der Köpfe der Listen in den Feldern 46923, 46925 oder 46927, je nach Listenart. Die Listen und deren Gebrauch werden später genauer beschrieben.

3. SS 504 (Fig. 470)

Fig. 470 stellt einen Überblick über SS 504, der zu einem Prozeß 610 gehört, dar. SS 504 ist im SS-Objekt 10336 enthalten. Das SS-Objekt 10336 wird nur durch KOS-Mikrocodeprogramme manipuliert. Weder Prozeduren 602, die von einem Prozeß 610 ausgeführt werden, noch S-Interpreter oder Adreßraum-Mikrocode kann auf die im SS-Objekt 10336 enthaltenen Informationen zugreifen.
Das SS-Objekt 10336 umfaßt zwei Hauptkomponenten, die SS-Basis 47001 und die SS- Rahmen 47003. Indem wir uns zuerst der allgemeinen Struktur der SS-Rahmen 47003 zuwenden, so erzeugt der KOS-Mikrocode jedesmal, wenn ein Prozeß 610 einen vermittelten Aufruf ausführt, einen neuen SS-Rahmen 47003 auf dem SS-Objekt 10336, das zum Prozeß 610 gehört, und jedesmal wenn ein Prozeß 610 eine vermittelte Rückkehr ausführt, entfernt der KOS-Mikrocode den gegenwärtigen obersten SS-Rahmen 47003 vom SS- Objekt 10336. Daher gibt es einen SS-Rahmen 47003 auf dem SS-Objekt 10336, das zu einem Prozeß 610 gehört, und zwar für jeden vermittelten Rahmen 46947 auf dem MAS 502 des Prozesses 610.
Die SS-Rahmen 47003 umfassen zwei Rahmenarten: die einfachen Rahmen 10510 und die bereichsübergreifenden Rahmen 47039. Bereichsübergreifende Rahmen 47039 werden jedesmal dann erzeugt, wenn ein Prozeß 610 einen bereichsübergreifenden Aufruf durchführt; für alle anderen vermittelten Aufrufe werden einfache Rahmen 10510 erzeugt. Die bereichsübergreifenden Rahmen 47039 teilen die SS-Rahmen 47003 in Gruppen 47037 von SS-Rahmen 47003, die zu den Invokationsabfolgen in einem einzelnen Bereich gehören. Der erste SS-Rahmen 47003 in einer Gruppe 47037 ist ein bereichsübergreifender Rahmen 47039 für die Invokation, die in den Bereich eintrat, und der Rest der SS- Rahmen 47003 sind einfache Rahmen 10510 für eine Invokationsabfolge in jenem Bereich. Diese Gruppen von SS-Rahmen 47003 entsprechen den Gruppen von vermittelten Rahmen 46947 in einem einzelnen MAS-Objekt 46703.

a.a. SS-Basis 47001 (Fig. 471)

Die SS-Basis 47001 umfaßt vier Hauptteile: den SS-Kopf 10512, den Prozeßmikrozustand 47017, die Speicheffläche 47033 für die JP 10114-Registerinhalte und den Initialisierungsrahmenkopf 47035. Der Sicherheitsstapelspeicherkopf 10512 enthält folgende Informationen:
- Die Felder 47001 und 47009 enthalten Kennzeichen und Formatinformationen; die exakten Inhalte dieser Felder sind für die gegenwärtige Diskussion unwichtig.
- Das Abstandswertfeld des vorangegangenen Rahmens 47011 ist ein Standardfeld in Köpfen im SS-Objekt 10336; hier ist es auf 0 gesetzt, da es keinen vorangegangenen Rahmen gibt.
- Das Abstandsfeld des ersten Rahmens des Sicherheitsstapelspeichers 47013 enthält den Abstand des ersten SS-Rahmens 47039 im SS-Objekt 10336, d. h. den Initialisierungsrahmenkopf 47035.
- Das Prozeß-UID-Feld 47015 enthält die UID 40401 des Prozesses 610, zu dem das SS-Objekt 10336 gehört.
- Das Feld für die Anzahl der bereichsübergreifenden Rahmen 47016 enthält die Anzahl aller bereichsübergreifenden Rahmen 47039 im SS-Objekt 10336.
Der Prozeßmikrozustand 47017 enthält Informationen, die vom KOS-Mikrocode benutzt werden, wenn er einen Prozeß 610 ausführt, zu dem SS-Objekt 10336 gehört. Die Felder 47019, 47021 und 47022 enthalten die Abstände von Lokationen im SS-Objekt 10336. Das Feld 47019 enthält den Wert von SSTO, der Lokation des ersten freien Bits im SS-Objekt 10336; das Feld 47021 enthält den Wert von SSFO, der Lokation des obersten Rahmens im SS-Objekt 10336; das Feld 47022 schließlich enthält den Wert des XDFO, der Lokation des obersten bereichsübergreifenden Rahmens im SS-Objekt 10336. Alle diese Lokationen sind in Fig. 470 aufgeführt.
Andere Felder im Prozeßmikrozustand 47017, die von Interesse sind, umfassen folgendes: Die Abstände im Speichefflächenfeld 47023 enthalten die Abstände von Lokationen in der Speicherfläche 47033 des SS-Objekts 10336; das Bereichsnummernfeld 47025 enthält die Bereichsnummer für den DOE der Prozedur 602, die augenblicklich durch den Prozeß 610 ausgeführt wird. Die Beziehung zwischen Bereichs-UIDs und Bereichsnummern wird bei der Diskussion der Bereiche erklärt. Das VPAT-Abstandsfeld 45027 enthält den Abstand in VPAT 45401 des VPAT-Stückes 45402, das zum virtuellen Prozessor 612 gehört, an den der Prozeß 610 gebunden ist. Das Signalzeigerfeld 47029 enthält einen aufgelösten Zeiger auf den Signalgeber (eine Prozedur 602, die bei der Bedingungsbearbeitung benutzt wird), der zu dem Bereich gehört, der durch das Bereichsnummernfeld 47025 spezifiziert wird, und das Ablaufverfolgungs-Informationsfeld 47031 enthält einen aufgelösten Zeiger auf die Ablaufverfolgungstabelle jenes Bereichs, die später beschrieben wird.
Die Speicherfläche für die JP 10114-Registerinhalte 47033 wird benutzt, wenn ein virtueller Prozessor 612 von JP 10114 gelöst werden muß. Wenn dies auftritt, entweder weil der virtuelle Prozessor 612 von JP 10114 gelöst wird, weil CS 10110 angehalten wird oder weil CS 10110 ein Fehler unterlaufen ist, müssen die Registerinhalte von JP 10114, die die für den virtuellen Prozessor 612 spezifischen Informationen beinhalten, in die Speicherfläche 47033 kopiert werden. Wenn der virtuelle Prozessor 612 an JP 10114 zurückgegeben wird, werden diese Registerinhalte von dort, wo sie herkamen, in die JP 10114-Register zurückgeladen. Der Initialisierungsrahmenkopf 47035 ist schließlich ein Attrappenrahmenkopf, der bei der Erzeugung des SS-Objekts 10336 benutzt wird.

b.b. SS-Rahmen 47003 (Fig. 471)

Indem wir die Diskussion der SS-Rahmen 47039 und 10510 beginnen, verdeutlicht Fig. 471 diese Strukturen im Detail. Der einfache SS-Rahmen 10510 umfaßt drei Haupteinteilungen: den einfachen SS-Rahmenkopf 10514, den Makrozustand 10516 und den Mikrozustand 10520. Der einfache SS-Rahmenkopf 10514 enthält Informationen, die vom KOS-Mikrocode dazu benutzt werden, den einfachen SS-Rahmen 10510, zu dem der Kopf 10514 gehört, zu manipulieren. Der Makrozustand 10516 enthält die Werte der ABPs für die vermittelte Invokation des Rahmens und andere Informationen, die zur Wiederaufnahme der Ausführung der Invokation benötigt werden. Der Mikrozustand 10520 enthält den Mikromaschinenzustand der Register von FU 10120 und EU 10122. Der Umfang des Mikromaschinenzustandes hängt von den Umständen ab; in der gegenwärtigen Verkörperung wird mancher Mikromaschinenzustand auf allen vermittelten Aufrufen abgespeichert; darüber hinaus, wenn ein Prozeß 610 einen Mikrocode nach Software-Aufruf ausführt, wird der Mikromaschinenzustand, der zum Zeitpunkt des Aufrufs existierte, gespeichert; schließlich kann der Mikrozustand 10520, der zu dem obersten SS-Rahmen 47003 gehört, Informationen beinhalten, die von den GRF-Registern 10354 von FU 10120 oder den EU 10122-Registern und den Stapelspeichermechanismen 10216, wenn ihre Kapazität überschritten wurde, transferiert wurden. Wegen weiterer Einzelheiten über diesen Bereich des Mikrozustandes 10520 siehe die Diskussion der FU 10120-Mikromaschine in Kapitel 2. Die Diskussion des SS-Objekts 10336 geht weiter mit Einzelheiten, die den SS-Kopf 10514 und den Makrozustand 10516 betreffen.

a.a.a. Einfache SS-Rahmenköpfe 10514 (Fig. 471)

Folgende Felder im einfachen Sicherheitsstapelspeicher-Rahmenkopf 10514 sind von Interesse:
- Die Formatinformation 47103, die das Format des Kopfes 10514 identifiziert.
- Das Kennzeichenfeld 47105, das ein Kennzeichen enthält, das für diese Diskussion von Interesse ist: das Rahmentypenkennzeichen 47107: in einfachen SS- Rahmen 10510 wird dieses Feld auf FALSE gesetzt.
- Die Abstandsfelder 47109 bis 47113: das Feld 47109 enthält den Abstand des vorherigen SS-Rahmens 47039 oder 10510. Das Feld 47111 enthält den Abstand des folgenden SS-Rahmens 47039 oder 10510, und das Feld 47113 enthält den Abstand des letzten SS-Rahmens 47039 oder 10510, das vor dem nächsten bereichsübergreifenden Rahmen 47039 steht.
- Das Feld 47117 enthält die Nummer des gegenwärtigen Bereiches für den Bereich, in dem die vermittelte Invokation, die durch den SS-Rahmen 47039 oder 10510 dargestellt wird, ausführt.
- Das Feld 47119 enthält den Abstand des vorangehenden bereichsübergreifenden Rahmens 47039.
- Das Feld 47121 enthält die Abstände für wichtige Lokationen im Mikrozustand 10520.

b.b.b. Detaillierte Struktur des Makrozustandes 10516 (Fig. 471)

Diese Felder sind im Makrozustand 10516 von Interesse:
- Das Silbengrößenfeld 47125 enthält den Wert von K, d. h. die Größe von Namen in den SINs, die zur Prozedur 602 gehören, die die Invokation ausführt.
- Das Ende der Namenstabelle-Feld 47127 enthält die Lokation des letzten Namens in der Namenstabelle 10350, die zur Prozedur 602 gehört, die die Invokation ausführt.
- Die Felder 47129 bis 47143 sind aufgelöste Zeiger auf Lokationen im Prozedurobjekt 901, das die durch die Invokation gerade ausgeführte Prozedur 602 und aufgelöste Zeiger auf Lokationen enthält, die Daten enthalten, die von der Prozedur 602 benutzt werden. Das Feld 47129 enthält einen Zeiger auf den PED 30303 der Prozedur 602; wenn Prozedur 602 eine externe Prozedur 602 ist, enthält das Feld 47131 einen Zeiger auf den Eingang der Prozedur 602 in den Verknüpfungsgliedern 10340; das Feld 47135 enthält den UID-Abstandswert von FP für die Invokation; das Feld 47135 enthält einen Zeiger auf SEB 46864, der vom S-Interpreter der Prozedur 602 benutzt wird. Das Feld 47137 enthält den UID-Abstandswert von SDP und das Feld 47139 enthält den von PBP. Das SIP- Feld 47141 enthält einen Zeiger auf das S-Interpreterobjekt der Prozedur 602, und NTP schließlich ist ein Zeiger auf die Namenstabelle 10350 der Prozedur 602.
- Das Feld 47145 enthält den PC für den SIN, der bei der Rückkehr von der vermittelten Invokation, zu der der SS-Rahmen 47003 gehört, ausgeführt werden soll.

c.c.c. Bereichsübergreifende SS- Rahmen 47039 (Fig. 471)

Bereichsübergreifende SS-Rahmen 47039 unterscheiden sich von-einfachen SS-Rahmen 10510 in zweierlei Hinsicht: sie haben eine zusätzliche Komponente, den bereichsübergreifenden Zustand 10513, und die Felder im bereichsübergreifenden Rahmenkopf 47157 haben eine andere Bedeutung als die im einfachen Rahmenkopf 10514.
Der bereichsübergreifende Zustand 10513 enthält Informationen, die der KOS-Aufrufmikrocode benutzt, um zu überprüfen, daß eine Rückkehr zu einer Prozedur 602, deren DOE sich von dem der Prozedur 602 unterscheidet, deren Invokation beendet wurde, in den richtigen Bereich zurückkehrt. Felder von Interesse im bereichsübergreifenden Zustand 10513 beinhalten das Go To-Kennzeichen 47155, das für nicht lokale Go Tos benutzt wird, die Bereichsgrenzen überschreiten, dem Stapelspeicher-Spitzenzeigerwert 47153, der die Lokation des ersten freien Bits im MAS-Objekt 46703 des neuen Bereichs enthält, und den Rahmenkopfzeigerwert 47151, der die Lokation des obersten vermittelten Rahmenkopfes 46709 im neuen MAS-Objekt 46703 enthält.
Es gibt drei Felder im bereichsübergreifenden Rahmenkopf 47157, die sich von denen im einfachen SS-Rahmenkopf 47101 unterscheiden. Diese Felder sind das Kennzeichenfeld 47107, das im bereichsübergreifenden Rahmenkopf 47157 immer den Wert TRUE hat, das Abstandsfeld des vorangehenden bereichsübergreifenden Rahmens 47161, das den Abstand vom vorangehenden bereichsübergreifenden Rahmen 47039 im SS-Objekt 10336 enthält, und das Abstandsfeld des nächsten bereichsübergreifenden Rahmens 47159, das die Lokation des nächsten bereichsübergreifenden Rahmens 47039 enthält. Diese letzten beiden Felder besetzen dieselben Lokationen wie die Felder 47111 bzw. 47109 im einfachen SS-Rahmenkopf 10514.
Wie man durch die obige Beschreibung der SS-Rahmen 47003 feststellen kann, enthält das Sicherheitsstapelspeicherobjekt 10336 in der gegenwärtigen Verkörperung drei Informationsarten: den Makrozustand, den bereichsübergreifenden Zustand und den Mikrozustand. In anderen Verkörperungen können die Informationen im SS-Objekt 10336 in separaten Stapelspeicherstrukturen gespeichert werden, z. B. separate Mikrozustands- und bereichsübergreifende Stapelspeicher, oder die gegenwärtig in MAS-Objekten 46703 gespeicherten Informationen können im SS-Objekt 10336 gespeichert werden und umgekehrt.

4. Für Aufruf und Rückkehr relevante Bereiche des Prozedurobjekts 608 (Fig. 472)

Die Informationen, die ein Prozeß 610 benötigt, um neue Rahmen auf seinen MAS- Objekten 46703 und SS-Objekt 10336 zu konstruieren, und um die Kontrolle der aufgerufenen Prozedur 602 zu transferieren, ist im Prozedurobjekt 608 der aufgerufenen Prozedur 602 enthalten. Fig. 472 ist ein Überblick über das Prozedurobjekt 608, die die Informationen, die bei einem Aufruf benötigt werden, zeigt. Fig. 472 erweitert die Informationen, die in den Fig. 103 und 303 enthalten sind; Felder, die in jenen Figuren auftauchen, haben die Namen und Nummern, die dort benutzt werden.
Mit dem Prozedurobjektkopf 10336 beginnend, so enthält diese Fläche zwei Informationsausdrücke, die bei Aufrufen benutzt werden: einen Abstand im Feld 47201, der die Lokation des Argumenten-Informationsvektors 10352 im Prozedurobjekt 608 wiedergibt, und einen Wert im Feld 47203, der die Anzahl von Verknüpfungsgliedern im Prozedurobjekt 608 spezifiziert. Verknüpfungsglieder erlauben die Invokation von externen Prozeduren 602, d. h. Prozeduren 602, die von Prozeduren 602 aufgerufen werden können, die in anderen Prozedurobjekten 608 enthalten sind. Die Verknüpfungsglieder des Prozedurobjekts 608 sind in der externen Eingangsbeschreiberfläche 10340 enthalten. Es gibt zwei Arten von Verknüpfungsgliedern: die für Prozeduren 602, die in Prozedurobjekt 608 enthalten sind, und die für Prozeduren 602, die in anderen Prozedurobjekten 608 enthalten sind, aber über Prozedurobjekte 608 aufrufbar sind. Verknüpfungsglieder für Prozeduren 602, die in Prozedurobjekt 608 enthalten sind, werden lokale Verknüpfungsglieder 47205 genannt. Lokale Verknüpfungsglieder 47205 enthalten das interne Eingangsabstands (IEO)-Feld 47207, das den Abstand im Prozedurobjekt 608 des Eingangsbeschreibers 47227 für Prozedur 602 beinhaltet. Falls Prozedur 602 nicht im Prozedurobjekt 472 enthalten ist, so ist ihr Verknüpfungsglied ein Bindeverknüpfungsglied 47206. Bindeverknüpfungsglieder 47206 enthalten Verknüpferflächenzeiger (BAP)-Felder 47208. Ein BAP-Feld 47208 enthält die Lokationen einer Fläche in der Verknüpferfläche 30323, die wiederum einen Zeiger auf ein Verknüpfungsglied in einem anderen Prozedurobjekt 608 enthält. Der Zeiger in der Verknüpferfläche 30323 kann entweder aufgelöst oder nicht aufgelöst sein. Wenn die Prozedur 602 in diesem Prozedurobjekt 608 enthalten ist, ist das Verknüpfungsglied ein lokales Verknüpfungsglied 47205; sonst ist es ein neues Bindeverknüpfungsglied 47206.
Prozedurenumgebungsbeschreiber (PEDS) 10348 enthalten PEDS 30303 für Prozeduren 602, die in dem Prozedurobjekt 608 enthalten sind. Ein Großteil der Makrozustandsinformationen für eine Prozedur 602 kann in ihrem PED 30303 gefunden werden. PED 30303 wurde bereits beschrieben, aber ihre Inhalte werden hier des besseren Verständnisses wegen wiederholt.
- Das K-Feld 30305 enthält die Größe der Namen von Prozedur 602.
- Das Feld des längsten Namens (LN) 30307 enthält das i.
Indem wir mit dem Prozedurobjekt 10336 beginnen, so enthält diese Fläche zwei Informationsausdrücke, die bei Aufrufen benötigt werden: einen Abstand im Feld 47201, der die Lokation des Argumenten-Informationsvektors 10352 im Prozedurobjekt 608 angibt, und einen Wert im Feld 47203, der die Anzahl der Verknüpfungsglieder im Prozedurobjekt 608 spezifiziert. Verknüpfungsglieder erlauben die Invokation von externen Prozeduren 602, d. h. Prozeduren 602, die von Prozeduren 602 aufgerufen werden können, die in anderen Prozedurobjekten 608 enthalten sind, zum statischen Datenblock 46863. Daher wird für jene Invokation der Prozedur 602 bei der Invokation der SDP ABP über das SDP-Feld 30313 abgeleitet.
- Das PBP-Feld 30315 ist der Zeiger, aus dem der gegenwärtige PC berechnet wird. Wenn Prozedur 602 aufgerufen wird, wird dieser Wert der PBP ABP.
- Das S-Interpreterumgebungs-Prototypenzeiger (SEPP)-Feld 30316 enthält die Lokation des SEB-Prototypenfeldes 30317. Wenn Prozedur 602 aufgerufen wird, lokalisiert das Feld 30316 SEB 46864 über AAT 30201 in derselben Weise, wie das SDPP-Feld 30313 die statischen Daten der Invokation lokalisiert.
Ein PED 30303 einer Prozedur 602 kann aus ihrem internen Eingangsbeschreiber 47227 lokalisiert werden. Ein PED 30303 kann von mehreren Prozeduren 602 geteilt werden. Natürlich sind die Werte, die in dem geteilten PED 30303 enthalten sind, für alle Prozeduren 602, die ihn teilen, dieselben. Wie später noch genauer erklärt wird, muß ein Aufruf vermittelt werden, wenn eine rufende Prozedur 602 einen PED 30303 mit der gerufenen Prozedur 602 nicht teilt. Eine rufende Prozedur 602 kann einen Nachbarschaftsaufruf nur zu Prozeduren 602 machen, mit denen es einen PED 30303 teilt.
Der nächste Bereich des Prozedurobjekts 608, der von Interesse ist, sind die internen Eingangsbeschreiber 10342. Jede Prozedur 602, die in einem Prozedurobjekt 608 enthalten ist, hat einen Eingangsbeschreiber 47227. Der Eingangsbeschreiber 47227 enthält vier Felder von Interesse:
- Das PBP-Abstandsfeld 47229 enthält den Abstand vom PBP, in dem der erste SIN im Code von Prozedur 602 lokalisiert ist.
- Das Kennzeichenfeld 47230 enthält Kennzeichen, die überprüft werden, wenn Prozedur 602 aufgerufen wird. Vier Kennzeichen sind von Interesse:
- Das Argumenten-Informationsvektor vorhanden-Kennzeichen 47235, das auf TRUE gesetzt wird, wenn die Prozedur 602 Einträge im Argumenten-Informationsvektor 10352 hat.
- Das SEB-Kennzeichen 47237 wird auf TRUE gesetzt, wenn SEPP 47225 nicht 0 ist, d. h. wenn die Prozedur 602 einen SEB 46864 für ihren S-Interpreter besitzt.
- Das Zugang nicht überprüfen-Kennzeichen 47239 wird auf TRUE gesetzt, wenn der KOS-Aufruf-Mikrocode mit den aktuellen Argumenten, die benutzt werden, um Prozedur 602 aufzurufen, keine Schutzüberprüfung durchführen soll.
- Das PED-Abstandsfeld 47231 enthält den Abstand vom PED 30303 der Prozedur 602 vom Anfang des Prozedurobjekts 608.
- Das Rahmengrößenfeld 47233 enthält die anfängliche Größe des lokalen Speicherbereichs 10420 des MAS-Rahmens 46709 für eine Invokation der Prozedur 602.
Andere Flächen, die für Aufrufe von Interesse sind, sind die SEB-Prototypenfläche 47241, der statische Datenflächenprototyp 30317, die Verknüpferfläche 30323 und der Argumenten-Informationsvektor 10352. Die SEB-Prototypenfläche 47241 und der statische Datenflächenprototyp 30315 enthalten Informationen, die bei der Erzeugung eines SEB 46864 bzw. eines statischen Datenblocks 46863 für Prozedur 602 benutzt werden. Diese Flächen werden auf MAS-Objekt 46703-bezogener Basis erzeugt. Wenn ein Prozeß 610 zum ersten mal eine Prozedur 602 in einem Bereich ausführt, so werden die für die Prozedur 602 benötigten SEB 46864 und der statische Datenblock 46863 entweder im MAS-Objekt 46703, das zu dem Bereich gehört, oder in einem anderen Objekt, das vom MAS-Objekt 46703 zugänglich ist, erzeugt. SEB 46864 und der statische Datenblock 46863 verbleiben dann so lange, wie das MAS-Objekt 46703 existiert.
Der statische Datenprototyp 30317 enthält zwei Informationsarten: die statischen Datenverbindungen 30319 und die statische Dateninitialisierungsinformation 30321. Die statischen Datenverbindungen 30319 enthalten Lokationen in der Verknüpferfläche 30323, die wiederum Zeiger enthalten, die aufgelöst werden können, und die Lokationen von Daten oder externen Prozeduren 602 ergeben. Wenn ein statischer Datenblock 46863 für eine Prozedur 602 erzeugt wird, werden die Informationen in der Verknüpferfläche 30323 dazu benutzt, die Verkettungszeiger 46865 zu erzeugen. Die statische Dateninitialisierungsinformation 30321 enthält Informationen, die benötigt werden, um statische Daten im statischen Datenspeicher 46867 zu erzeugen und zu initialisieren.
Wie bei den Diskussionen der Bindeverknüpfungsglieder 47206 und den statischen Datenverbindungen 30319 erwähnt wurde, enthält die Verknüpferfläche 30323 Zeiger, die, wie in Kapitel 3 beschrieben, aufgelöst werden können, um Lokationen von Daten und externen Prozeduren 602 zu ergeben.
Der Argumenten-Informationsvektor (AIA) 10352 enthält vom KOS-Aufruf-Mikrocode benutzte Informationen, um zu überprüfen, ob das Subjekt, das die Prozedur 602 aufruft, Zugang besitzt zu den aktuellen Argumenten, die bei der Invokation benutzt werden, die den Gebrauch erlaubt, der von den Argumenten in Prozedur 602 gemacht wird. Diese sogenannte "Trojanisches Pferd"-Überprüfung ist notwendig, weil ein Aufruf die Bereichskomponente eines Subjekts ändern kann. Daher konnte ein Subjekt, dem eine besondere Zugangsart auf einen Datenausdruck fehlt, diesen Zugang gewinnen, indem er den Datenausdruck als Argument einer Prozedur 602 übergibt, deren DOE ihm die Zugangsrechte gibt, die das rufende Subjekt selbst nicht hat.
Jedes lokale Verknüpfungsglied 47205 im Prozedurobjekt 608 hat ein Element in AIA 10352. Jedes dieser Argumenten-Informationsvektorelemente (AIAEs) 60845 hat Felder, die folgendes anzeigen:
- Die Minimalanzahl der Argumente, die erforderlich sind, um die Prozedur 602 aufzurufen, zu der das lokale Verknüpfungsglied 47205 gehört, in Feld 47247.
- Die Maximalanzahl der Argumente, die benutzt werden können, um die Prozedur 602 aufzurufen, im Feld 47249.
- Die Zugangsrechte, die das aufrufende Subjekt bezüglich der aktuellen Argumente haben muß, um die Prozedur 602 aufzurufen, in Feld 47251.
Das Feld 47251 ist selbst ein Vektor, der die Zugangsarten spezifiziert, die das aufrufende Subjekt bezüglich der Argumente, die es benutzt, um Prozedur 602 aufzurufen, haben muß. Jedes formale Argument für Prozedur 602 hat einen Zugangsarten-Vektoreintrag (AMAE) 47245. Die Reihenfolge der AMAEs 47255 entspricht der Reihenfolge der formalen Argumente der Prozedur 602. Das erste formale Argument hat den ersten AMAE 47255, das zweite den zweiten usw. Ein AMAE 47253 ist vier Bits lang. Es gibt zwei Formen des AMAE 47253: die primitive Zugangsform 47255 und die erweiterte Zugangsform 47257. In der ersten Form wird das am weitesten links stehende Bit auf 0 gesetzt. Die drei verbleibenden Bits spezifizieren lesenden, schreibenden und ausführenden Zugriff. Wenn ein Bit gesetzt ist, muß das Subjekt, das die Invokation durchführt, diese primitive Zugangsart auf das Objekt besitzen, das den Datenausdruck als aktuelles Argument für das formale Argument beinhaltet, das dem AMAE 47253 entspricht. In der erweiterten Zugangsform 47257 ist das am weitesten links stehende Bit auf 1 gesetzt, und die verbleibenden Bits sind definiert, so daß sie den erweiterten Zugriff, der für Prozedur 602 erforderlich ist, darstellen. Die Definition dieser Bits variiert von Prozedur 602 zu Prozedur 602.

5. Ausführung von vermittelten Aufrufen

Nachdem die Bereiche des MAS-Objekts 46703, das SS-Objekt 10336 und das Prozedurobjekt 608, die bei Aufrufen involviert sind, beschrieben worden sind, richtet sich die Diskussion nun zur Beschreibung der Operation des vermittelten Aufrufs. Zuerst wird ein Überblick über den SIN des vermittelten Aufrufs dargestellt, und danach die Implementierung von vermittelten Aufrufen in der gegenwärtigen Verkörperung diskutiert, wobei mit einem einfachen vermittelten Aufruf begonnen wird, mit Prozedurobjekt-übergreifenden Aufrufen bis hin zu bereichsübergreifenden Aufrufen fortgefahren wird. Die Diskussion schließt mit einer Beschreibung der Software-nach-Mikrocode-Aufrufe ab.

a.a. SINs des vermittelten Aufrufs

Während die exakte Form des SINs eines vermittelten Aufrufs S-Sprachen-spezifisch ist, müssen alle SINs eines vermittelten Aufrufs vier Informationsausdrücke beinhalten:
- Den SOP für die Operation.
- Einen Namen, der zu einem Zeiger auf die Prozedur 602 ausgewertet werden kann, die durch den SIN ausgeführt werden soll.
- Ein Literal (Konstante), die die Anzahl der aktuellen Argumente spezifiziert, die bei der Invokation benutzt werden.
- Eine Liste von Namen, die im Zeiger auf die aktuellen Argumente, die beim Aufruf benutzt werden, ausgewertet werden können.
Wenn die Prozedur 602 keine Argumente verlangt, so ist das Literal 0 und die Namensliste, die die aktuellen Argumente darstellt, ist leer.
In der gegenwärtigen Verkörperung werden die SINs des vermittelten Aufrufs und der vermittelten Rückkehr immer dann benutzt, wenn die gerufene Prozedur 602 einen anderen PED 30303 hat als die rufende Prozedur 602. In diesem Fall muß der Aufruf einen anderen Makrozustand als FP und PC speichern und neu berechnen, und eine Vermittlung durch den KOS-Aufruf-Mikrocode ist erforderlich. Die Art und Weise, in der der KOS-Aufruf-Mikrocode den Aufruf vermittelt, hängt davon ab, ob der Aufruf ein einfacher vermittelter Aufruf, ein Prozedurobjekt-übergreifender Aufruf oder ein bereichsübergreifender Aufruf ist.

b.b. Einfache vermittelte Aufrufe (Fig. 270 468, 469, 470, 471, 472)

Wenn der SIN des vermittelten Aufrufs ausgeführt wird, wertet der S-Interpreter-Mikrocode zuerst den Namen aus, der die Lokation der gerufenen Prozedur 602 darstellt. Der Name kann in einen Zeiger auf ein Verknüpfungsglied 47205 oder 4707 in einem anderen Prozedurobjekt 608 oder in einen Zeiger auf einen Eingangsbeschreiber 47227 in dem vorhandenen Prozedurobjekt 608 ausgewertet werden. Wenn der Name ausgewertet worden ist, ruft der S-Interpreter-Aufrufmikrocode den KOS-Aufruf-Mikrocode auf, indem er den ausgewerteten Namen als Argument benutzt. Dieser Mikrocode füllt zuerst die Makrozustandsfelder 10516 im SS-Rahmen 47003 der gegenwärtigen Invokation aus, die bis jetzt leer geblieben waren. Der Mikrocode erhält die Werte für diese Felder von Registern in FU 10120, wo sie verwaltet wurden, während der virtuelle Prozessor 612 des Prozesses 610, der den vermittelten Aufruf ausführt, an JP 10114 gebunden wird.
Der nächste Schritt besteht darin, zu bestimmen, ob der Zeiger, den der KOS-Aufrufmikrocode vom S-Interpreter-Aufrufmikrocode empfangen hat, ein Zeiger auf eine externe Prozedur ist. Um diese Bestimmung durchzuführen, vergleicht der KOS-Aufruf-Mikrocode die AON 41304 des Zeigers mit der des Prozedurobjekts 608 für die Prozedur 602, die den Aufruf macht. Wenn sie verschieden sind, ist der Aufruf ein Prozedurobjekt-übergreifender Aufruf, der unten beschrieben wird. Im Falle eines einfachen vermittelten Aufrufs zeigt das Formatfeld an, daß die Lokation ein Eingangsbeschreiber 47227 ist. Der KOS-Aufruf-Mikrocode fährt fort, indem er die Lokation des Eingangsbeschreibers 47227 abspeichert und einen neuen vermittelten Rahmen 46947 auf dem gegenwärtigen MAS- Objekt 46703, und einen neuen einfachen SS-Rahmen 10510 auf dem SS-Objekt 10336 für die gerufene Prozedur 602 erzeugt. Indem der KOS-Aufruf-Mikrocode dies tut, setzt er die Felder 46917 und 46919 in dem vermittelten Rahmenkopf und die Felder 47109 und 47111 im einfachen Rahmenkopf 10514 auf die Werte, die durch die Addition der Rahmen zum MAS-Objekt 46703 und SS-Objekt 10336 erforderlich sind.
Der neue vermittelte Rahmen 46947 ist nun bereit für die Verkettungszeiger 10416 auf die aktuellen Argumente, die im Aufruf benutzt werden, und so kehrt der KOS-Aufruf- Mikrocode zum S-Interpreter-Aufrufmikrocode zurück, der den SIN analysiert, um das Literal zu erhalten, das die Anzahl der Argumente spezifiziert, und der den Literalwert abspeichert. Der S-Interpreter-Aufrufmikrocode analysiert dann jeden Argumentnamen, wertet ihn aus und plaziert den resultierenden Wert im Verkettungszeigerabschnitt 10416. Wenn der Verkettungszeigerabschnitt 10416 vollständig ist, berechnet der S-Interpreter- Aufrufmikrocode die neue Lokation des FP aus der Lokation der Spitze des Verkettungszeigerabschnitts 10416 und plaziert einen Zeiger auf die Lokation in dem FU 10120- Register, der für FP reserviert ist. Jetzt plaziert der S-Interpreter-Aufrufmikrocode auch die neue Lokation der Spitze des Stapelspeichers im Stapelspeicher-Spitzenabstandsfeld 46807.
Der S-Interpreter-Aufrufmikrocode ruft dann den KOS-Aufrufmikrocode auf, um den Wert des Literales, das die Anzahl der Argumente in das MAS-Rahmenfeld 46929 plaziert, um den neuen Wert des FHP 46702 zu berechnen und ihn in dem FU 10120- Register zu plazieren, das für diesen Wert vorgesehen ist, und um schließlich den notwendigen Zustand zu erhalten, um die gerufene Prozedur 602 vom Eingangsbeschreiber 47227 und vom PED 30303 der gerufenen Prozedur 602 auszuführen. Wie oben festgestellt, speichert der S-Interpreter-Aufrufmikrocode die Lokation des Eingangsbeschreibers 47227 ab. Indem er diese Lokation benutzt, erhält der KOS-Aufruf-Mikrocode die Größe des erforderlichen Speichers für die lokalen Daten von dem Feld 47233 und addiert den Speicherplatzbetrag zu dem neuen MAS-Rahmen 46709. Dann benutzt der KOS-Aufruf- Mikrocode das Feld 47231, um den PED 30303 für die Prozedur 602 zu bestimmen. PED 30303 enthält den Rest der nötigen Informationen über die Prozedur 602, und der KOS- Aufruf-Mikrocode kopiert die Lokation von PED 30303 in das PED-Zeigerfeld 46933 und kopiert dann die Werte des K-Feldes 30305, des letzten Namenfeldes 30307, des NTP- Feldes 30311 und des PBP-Feldes 30315 in die relevanten Register in FU 10120. Als nächstes übersetzt der KOS-Aufruf-Mikrocode die Zeiger im SIP-Feld 30309 in eine Dialektnummer, wie es in Kapitel 3 beschrieben wurde, und plaziert sie im Register RDIAL 24212 von FU 10120 und leitet daraus SDP ab, indem er den Zeiger im SDPP- Feld 30313 und einen Zeiger auf SEB 46864 auflöst, indem er den Zeiger im SEPP-Feld 30316 auflöst. Nachdem er diese Operationen durchgeführt hat, kehrt der KOS-Aufruf- Mikrocode zum S-Interpreter-Aufrufmikrocode zurück, der den Aufruf beendet, indem er einen neuen PC bestimmt, d. h. indem er die Register im I-Stromleser 27001 in FU 10120 zurücksetzt, so daß der nächste SIN, der aufgenommen wird, der erste SIN der gerufenen Prozedur 602 sein wird. Der S-Interpreter-Aufrufmikrocode bestimmt die Informationen, die erforderlich sind, um PC vom Feld 47229 in den Eingangsbeschreiber 47227 zu wechseln, der den Abstand des ersten SIN der gerufenen Prozedur 602 von PBP enthält.
In der gegenwärtigen Verkörperung wird manches des FU 10120-Zustandes, der durch den vermittelten Aufruf-SIN erzeugt wurde, auf SS 504 während der gesamten Lebensdauer der Invokation von Prozedur 602 gespeichert. Der gespeicherte Zustand ermöglicht es dem Prozeß 610, den vermittelten Aufruf erneut zu versuchen, falls der Aufruf fehlschlägt, bevor die gerufene Prozedur 602 anfängt auszuführen. Wenn ein vermittelter Rückkehr-SIN ausgeführt wird, nimmt der die Ausführung auf dem gespeicherten Zustand vom Aufruf-SIN auf. Die vermittelte Rückkehr ist viel einfacher als der Aufruf. Da sämtliche Informationen, die nötig sind, um die Ausführung der Invokation, die den Aufruf ausführte, wieder aufzunehmen, im Makrozustand 10516 im SS-Rahmen 47003 der rufenden Invokation enthalten ist, braucht die Rückkehr nur die Rahmen der gerufenen Invokation vom gegenwärtigen MAS-Objekt 46703 und SS-Objekt 10336 wegzunehmen, den Makrozustand 10516 vom SS-Rahmen 47003 der rufenden Invokation in die richtigen Fu 10120-Register zu kopieren, den SIP-Wert 47147 in eine Dialektnummer übersetzen und mit der Ausführung der rufenden Invokation wieder zu beginnen. Die Wegnahmeoperation involviert nur eine Aktualisierung der Zeiger im MAS-Objekt 46703 und SS-Objekt 10336, die auf Lokationen in dem alten obersten Rahmen zeigten, so daß sie nun auf äquivalente Lokationen in dem neuen obersten Rahmen zeigen.

c.c. Invokationen von Prozeduren 602, die SEBs 46864 benötigen (Fig. 270, 468, 469, 470, 471, 472)

Wenn eine Prozedur 602 einen SEB 46864 benötigt, wird diese Tatsache durch das Kennzeichenfeld 47237 im Eingangsbeschreiber 47227 der Prozedur 602 angezeigt. Der PED 30303 für eine solche Prozedur 602 enthält das SEPP-Feld 47225, dessen Wert ein nicht auflösbarer Zeiger ist. Die Art und Weise, in der ein SEB 46864 für eine Prozedur 602 erzeugt wird, und das SEPP-Feld 47225 in SEP, ein Zeiger, der die Lokation von SEB 46864 enthält und als Teil des Makrozustandes der Invokation im SS 10336 gespeichert wird, übersetzt wird, ist der Art und Weise ähnlich, in der der statische Datenblock 46863 erzeugt wird, und der nicht auflösbare Zeiger, der im SDPP-Feld 47225 enthalten ist, in SDP übersetzt wird. Wenn eine Prozedur 602, die ein SEB 46864 braucht, zum ersten Mal auf einem MAS-Objekt 46703 aufgerufen wird, wird ein SEB 46864 für die Prozedur 602 erzeugt, und ein AATE 46857 wird erzeugt, der den nicht auflösbaren Zeiger im SEPP-Feld 47225 und die Lokation von SEB 46864 miteinander verbindet. Diese Lokation ist der Wert von SEP, wenn die Prozedur im MAS-Objekt 46703 ausführt. Bei nachfolgenden Invokationen der Prozedur 602 dient AATE 46857 dazu, den Wert im SEPP-Feld 47225 in ein SEP zu übersetzen.

d.d. Prozedurobjekt-übergreifende Aufrufe (Fig. 270, 468, 469, 470, 471, 472)

Ein vermittelter Aufruf, der eine externe Prozedur 602 aufruft, wird Prozedurobjektübergreifender Aufruf genannt. Wie oben erwähnt, nimmt der KOS-Aufruf-Mikrocode an, daß jedesmal, wenn der Name, der die gerufene Prozedur 602 darstellt, in einem vermittelten Aufruf-SIN zur Lokation eines Verknüpfungsgliedes aufgelöst wird, daß der Aufruf an eine externe Prozedur 602 gerichtet ist. Solange die frisch aufgerufene externe Prozedur 602 denselben DOE besitzt wie die rufende Prozedur 602, unterscheiden sich die Prozedurobjekt-übergreifenden Aufrufe von den einfachen vermittelten Aufrufen nur in der Art und Weise, in der der Eingangsbeschreiber 47227 der gerufenen Prozedur 602 lokalisiert wird. Sobald der KOS-Aufruf-Mikrocode, wie oben beschrieben, bestimmt hat, daß ein vermittelter Aufruf ein Prozedurobjekt-übergreifender Aufruf ist, muß er als nächstes bestimmen, ob er ein bereichsübergreifender Aufruf ist. Dafür vergleicht der KOS-Aufruf-Mikrocode das DOE-Attribut des Prozedurobjekts 608 der gerufenen Prozedur 602 mit der Bereichskomponente des gegenwärtigen Subjekts. Der KOS-Aufruf- Mikrocode benutzt die AON 41304 des Prozedurobjekts 608, um den DOE des Prozedurobjekts 608 vom Feld 41521 seiner AOTE 41306 zu bestimmen, und er benutzt die ASN für das gegenwärtige Subjekt, die in einem FU 10120-Register gespeichert ist, um die Bereichskomponente des gegenwärtigen Subjekts von AST 10914 zu erhalten. Wenn der DOE und die Bereichskomponente des gegenwärtigen Subjekts sich unterscheiden, ist der Aufruf ein bereichsübergreifender Aufruf, der unten beschrieben wird; sonst lokalisiert der Aufruf das Verknüpfungsglied 47205 oder 47206, das durch den ausgewerteten Namen für die gerufene Prozedur 602 in ihrem Prozedurobjekt 608 spezifiziert ist. Wenn das Verknüpfungsglied ein lokales Verknüpfungsglied 47205 ist, benutzt der Aufruf das Eingangsbeschreiber-Abstandsfeld 47207, um den Eingangsbeschreiber zu lokalisieren, der zur gerufenen Prozedur 602 gehört, und führt dann fort, wie in der Diskussion eines einfachen vermittelten Aufrufs beschrieben.
Wenn das Verknüpfungsglied ein Bindeverknüpfungsglied 47206 ist, erhält der KOS- Aufruf-Mikrocode den entsprechenden Zeiger auf das Bindeverknüpfungsglied 47206 von der Verknüpferfläche 47245 und löst ihn auf, um einen Zeiger auf ein anderes Verknüpfungsglied 47205 oder 47206 zu erhalten, den der KOS-Aufruf-Mikrocode dazu benutzt, den Aufruf der externen Prozedur 602, wie oben beschrieben, zu wiederholen. Die Wiederholungen gehen so lange, bis das frisch lokalisierte Verknüpfungsglied ein lokales Verknüpfungsglied 47205 ist, wobei nun der Aufruf so weitergeht, wie es bei den einfachen vermittelten Aufrufen beschrieben wurde.

e.e. Bereichsübergreifende Aufrufe (Fig. 270, 408, 418, 468, 469, 470, 471, 472)

Wenn das Prozedurobjekt 608 einer gerufenen Prozedur 602 ein DOE-Attribut hat, das sich von dem Prozedurobjekt 608 der rufenden Prozedur 602 unterscheidet, so ist der Aufruf ein bereichsübergreifender Aufruf. Die Hilfsmittel, durch die der KOS-Aufruf- Mikrocode bestimmt, daß ein vermittelter Aufruf ein bereichsübergreifender Aufruf ist, wurden oben bereits beschrieben; wenn der Aufruf ein bereichsübergreifender Aufruf ist, muß der KOS-Aufruf-Mikrocode das MAS-Objekt 46703 für den Bereich inaktivieren, für den der Aufruf gemacht wurde, Überprüfungen hinsichtlich der Trojanischen-Pferd- Argumente durchführen, Subjekte umschalten, einen bereichsübergreifenden Rahmen 47939 auf dem SS-Objekt 10336 plazieren und das MAS-Objekt 46703 für den neuen Bereich lokalisieren und aktivieren, bevor er einen neuen vermittelten Rahmen 46947 auf einem neuen MAS-Objekt 46703 machen kann, und fortfahren, wie es in der Diskussion eines einfachen vermittelten Aufrufs beschrieben wurde.
Der bereichsübergreifende Aufrufmikrocode inaktiviert zuerst das gegenwärtige MAS- Objekt 46703, indem er das Bereich-aktiv-Kennzeichen 46804 auf falsch setzt. Der nächste Schritt sind die Überprüfungen auf "Trojanische Pferd"-Argumente. Um Überprüfungen auf "Trojanische Pferd"-Argumente durchführen zu können, muß der bereichsübergreifende Aufruf Zeiger auf die aktuellen Argumente besitzen, die bei der bereichsübergreifenden Invokation benutzt wurden. Daher fahrt der bereichsübergreifende Aufruf zunächst fort wie ein nicht bereichsübergreifender Aufruf: er erzeugt einen vermittelten Rahmenkopf 10414 auf dem alten MAS-Objekt 46703 und kehrt zum S-Interpreter- Mikrocode zurück, der die Namen der aktuellen Argumente auswertet und die Zeiger in die Verkettungszeiger 10416 über dem vermittelten Rahmenkopf 10414 plaziert. Jedoch wurde der Makrozustand für die den Aufruf durchführende Invokation auf das SS-Objekt 10336 plaziert, bevor der vermittelte Rahmenkopf 10414 und die Verkettungszeiger 10416 auf das alte MAS-Objekt 46703 plaziert wurden. Daher nimmt die rufende Prozedur 602, wenn sie die Ausführung nach einer Rückkehr wieder aufnimmt, die Ausführung auf dem MAS-Rahmen 46709 wieder auf, der dem vorangeht, der durch den bereichsübergreifenden Aufruf-Mikrocode erzeugt wurde.
Sobald die Zeiger auf die aktuellen Argumente verfügbar sind, führt der bereichsübergreifende Aufruf-Mikrocode die Überprüfung auf Trojanische Pferde durch. Wie in der Diskussion des Prozedurobjekts 608 beschrieben und in Fig. 472 verdeutlicht, sind die für die Durchführung der Überprüfung benötigten Informationen in AIA 10352 enthalten. Jedes lokale Verknüpfungsglied 47205 im Prozedurobjekt 608 hat einen AIAE 47245, jedes formale Argument in der Prozedur des lokalen Verknüpfungsgliedes 47205 hat einen Eintrag in AMA 47251 von AIAE 47245, und AMAE 47253 der formalen Argumente zeigt an, welche Zugriffsart auf das aktuelle Argument des formalen Arguments in der gerufenen Prozedur 602 erforderlich ist.
Das Feld AIA OFF 47201 enthält die Lokation von AIA 10352 im Prozedurobjekt 608, und indem er diese Informationen und den Abstand des lokalen Verknüpfungsglieds 47205 im Prozedurobjekt 608 benutzt, lokalisiert der bereichsübergreifende Aufruf-Mikrocode AIAE 47245 für das lokale Verknüpfungsglied 47205. Die ersten beiden Felder im AIAE 47245 enthalten die Minimalanzahl der Argumente in der Invokation und die Maximalanzahl der Argumente. Der bereichsübergreifende Aufruf-Mikrocode überprüft, ob die Anzahl der aktuellen Argumente zwischen diesen beiden Werten ist. Wenn dies der Fall ist, so beginnt der bereichsübergreifende Aufruf-Mikrocode, die einzelnen Argumenten erlaubten Zugriffe zu überprüfen. Der bereichsübergreifende Aufruf-Mikrocode ruft für jeden Argumentenzeiger den LAR-Mikrocode auf, um die gegenwärtige AON 41304 für die UID des Zeigers zu erhalten, und benutzt die AON 41304 und die ASN für das gegenwärtige Subjekt des Prozesses 610 (d. h. das Subjekt des Aufrufers), um einen Eintrag entweder in APAM 10918 oder in ANPAT 10920 zu lokalisieren, je nachdem, ob der AIAE des Arguments einfachen Zugriff (47255) oder erweiterten Zugriff (47257) spezifiziert. Wenn die Informationen aus APAM 10918 oder ANPAT 10920 bestätigen, daß das gegenwärtige Subjekt jenes Prozesses 610 das Recht besitzt, auf das Argument in der in der gerufenen Prozedur 602 geforderten Weise zuzugreifen, geht der Trojanische Pferd-Mikrocode zum nächsten Argument. Wenn das gegenwärtige Subjekt den erforderlichen Zugriff auf alle Argumente besitzt, war die "Trojanische Pferd"-Überprüfung erfolgreich, und der bereichsübergreifende Aufruf geht weiter. Anderenfalls schlägt sie fehl und der bereichsübergreifende Aufruf führt einen Mikrocode zu Software-Aufruf durch, wie er unten erklärt wird.
Als nächstes plaziert der bereichsübergreifende Aufruf-Mikrocode den bereichsübergreifenden Zustand 10513 auf das SS-Objekt 10336. Wie bei der Diskussion des SS- Objekts 10336 erklärt, enthält der bereichsübergreifende Zustand 10513 die benötigten Informationen, um auf den Rahmen des Aufrufers auf dem alten MAS-Objekt 46703 zurückzukehren. Nachdem dies getan wurde, wechselt der bereichsübergreifende Aufruf- Mikrocode die Subjekte. Indem er die ASN des gegenwärtigen Subjekts benutzt, erhält der bereichsübergreifende Aufruf-Mikrocode das gegenwärtige Subjekt von AST 10914, ersetzt die Bereichskomponente des Subjekts durch das DOE-Attribut 41225 für das Prozedurobjekt 608 der gerufenen Prozedur 602 und benutzt AST 10914, um das so erhaltene neue Subjekt in eine neue ASN zu übersetzen. Diese ASN wird dann im geeigneten FU 10120-Register plaziert.
Nachdem das Subjekt gewechselt hat, benutzt der bereichsübergreifende Aufruf-Mikrocode die Bereichstabelle 41801, um den DOE der gerufenen Prozedur 602 in eine Bereichsnummer zu übersetzen. Der bereichsübergreifende Aufruf-Mikrocode benutzt dann die Bereichsnummer als Index in einen Vektor von MAS AONs 46211 in VPSB 614 für den virtuellen Prozessor 612, der zu dem Prozeß 610 gehört, der den bereichsübergreifenden Aufruf macht. Der Eintrag, der der Bereichsnummer entspricht, .enthält die AON 41304 des MAS-Objekts 46703 für diesen Bereich.
Nachdem er das richtige MAS-Objekt 46703 lokalisiert hat, benutzt der bereichsübergreifende Aufruf-Mikrocode das STO-Feld 46807 im MAS-Kopf 10410, der zum MAS- Objekt 46703 des neuen Bereichs gehört, um die Spitze des letzten MAS-Rahmens 46709 zu lokalisieren. Er speichert dann den Wert von FHP 46702, der in der vorherigen Invokation benutzt wurde, in einem FU 10120-Register, fügt einen vermittelten Rahmenkopf 10414 an die Spitze des MAS-Objekts 46703 und berechnet einen neuen FHP 46702, der auf den neuen vermittelten Rahmenkopf 10414 zeigt. Danach plaziert der KOS- bereichsübergreifende Mikrocode den alten Wert von FHP 46702 in das FHP-Wertfeld 47151 des SS-Objekts 10336, und den alten Wert von STO 46704 (der auf die Spitze des letzten vollständigen MAS-Rahmens 46709 auf dem vorherigen MAS-Objekt 46703 zeigt), in das Feld 47153 des bereichsübergreifenden Zustands 10513 und füllt den vermittelten Rahmenkopf 10414 wie folgt: das Feld 46903 des Ergebnisses des bereichsübergreifenden Aufrufs wird auf TRUE gesetzt, das vorherige Rahmenabstandsfeld 46917 wird auf 0 gesetzt, das dynamische Rückwärtszeigerfeld 46931 wird auf den gespeicherten Wert von FHP 46702 gesetzt. Das dynamische Rückwärtszeigerfeld 46931 zeigt so auf den Kopf des obersten vermittelten Rahmens 46947 auf dem vorherigen MAS-Objekt 46703. Die Werte der verbleibenden Felder werden vom vermittelten Rahmenkopf 10414, den der bereichsübergreifende Aufruf erzeugte, auf das vorangegangene MAS-Objekt 46703 kopiert.
Als nächstes kopiert der bereichsübergreifende Aufruf-Mikrocode die Argumentenzeiger für die formalen Argumente von der Spitze des vorherigen MAS-Objekts 46703 zum neuen vermitteiten Rahmen 46947 und berechnet FP. Der bereichsübergreifende Aufruf- Mikrocode beendet sich, indem er zum S-Interpreter-Aufrufmikrocode zurückkehrt, der den Aufruf vervollständigt, wie es für einfache vermittelte Aufrufe beschrieben worden ist.
Abgesehen vom Aufwand des Transfers auf ein neues MAS-Objekt 46703 ist die bereichsübergreifende Rückkehr wie andere Rückkehren von vermittelten Aufrufen. Der alte FHP 46701 vom Feld 47151 des bereichsübergreifenden Zustands 10513 und der alte STO 46704 vom Feld 47153 des bereichsübergreifenden Zustands werden in FU 10120-Register plaziert. Dann werden die zur sich beendenden Invokation gehörenden Rahmen aus dem SS-Objekt 10336 und dem MAS-Objekt 46703, das zu dem Bereich der gerufenen Prozedur 602 gehört, weggenommen, und das MAS-Objekt 46703 wird inaktiviert, indem das Bereich-aktiv-Kennzeichen 46804 auf FALSE gesetzt wird. Dann benutzt der KOS- bereichsübergreifende Rückkehr-Mikrocode den alten FHP 46701 und den alten STO 46704, um das MAS-Objekt 46703, zu dem zurückgekehrt wird, und den obersten vermittelten Rahmen 46947 auf diesem MAS-Objekt 46703 zu lokalisieren. Das MAS- Objekt 46703, zu dem zurückgekehrt wird, wird aktiviert, und schließlich werden die Inhalte des Makrozustands 10516, der zu der Invokation gehört, zu der zurückgekehrt wurde, in die geeigneten Register von FU 10120 plaziert und die Ausführung der Invokation wird wieder aufgenommen.

f.f. Fehlgeschlagene bereichübergreifende Aufrufe (Fig. 270, 468, 469, 470, 471, 472)

Ein bereichsübergreifender Aufruf, wie er oben beschrieben wurde, kann an mehreren Punkten zwischen dem Zeitpunkt, an dem die rufende Invokation den Aufruf beginnt, und dem, an dem die gerufene Prozedur 602 die Ausführung beginnt, fehlschlagen. Bei einem Fehlschlag führt der bereichsübergreifende Aufruf-Mikrocode einen Mikrocode-zu- Software-Aufruf durch. Die durch diesen Aufruf aufgerufenen KOS-Prozeduren 602 können dann die Ursache für das Fehlschlagen des bereichsübergreifenden Aufrufs beheben und den bereichsübergreifenden Aufruf neu versuchen. Dies ist möglich, weil die Implementierung des bereichsübergreifenden Aufrufs in CS 10110 ausreichend FU 10120- Zustand abspeichert, um es dem Prozeß 610, der den bereichsübergreifenden Aufruf ausführt, zu erlauben, zu der Invokation und dem SIN des vermittelten Aufrufs zurückzukehren, von dem der bereichsübergreifende Aufruf begann. Bei einem Fehlschlag kann der MAS-Rahmen 46709 der Invokation aus den Werten des STO-Feldes 47153 und des FHP- Feldes 47151 im bereichsübergreifenden Zustand 10513 lokalisiert werden, und der SIN des vermittelten Aufrufs kann lokalisiert werden, indem die im FU 10120-Zustand abgespeicherte Information verwendet wird.

6. Nachbarschaftsaufrufe (Fig. 468, 469, 472)

Wie oben erwähnt, müssen Prozeduren 602, die über Nachbarschaftsaufrufe aufgerufen werden, denselben PED 30303 besitzen wie die rufende Prozedur 602. Die einzigen Makrozustandswerte, die nicht Teil von PED 30303 sind, sind PC und FP; daher braucht der Nachbarschaftsaufruf nur PC und FP der Invokation, die den Aufruf durchführt, abzuspeichern und diese Werte für die neue Invokation berechnen. Darüber hinaus speichert der Nachbarschaftsaufruf STO 46704, um eine Lokalisierung der Spitze des Nachbarschaftsrahmens 46947 der vorherigen Invokation zu erleichtern. Die Nachbarschaftsrückkehr restauriert einfach die abgespeicherten Werte. Da die Makrozustandswerte, die von PED 30303 kopiert oder über ihn erlangt wurden, sich während der Invokationsabfolge nicht ändern, und daher nicht im SS-Objekt 10336 gespeichert werden brauchen, haben Nachbarschaftsaufrufe keine SS-Rahmen 47003.
Übersetzung: Thomas Reinhardt
Schreibarbeit: Monika Schrader
Zeichnungstext: Agnes Wallisch
Koordinator: Heide Strott

Claims

1. Digitales Datenverarbeitungssystem (CS 10110) mit Prozessormitteln (JP 10114) zur Durchführung von Operationen an Operanden und mit Speichermitteln (MEM 10112) zur Speicherung von Befehlen zur Steuerung der Prozessormittel, wobei die Operanden und Befehle in Objekten (10213) strukturiert sind, gekennzeichnet durch Mittel zur eindeutigen Identifizierung der Objekte, enthaltend Prozessormittel (JP 10114, KOS), die auf erste der Befehle ansprechen zur Strukturierung der Operanden und Befehle in die Objekte (10213), die Prozedurobjekte zur Benutzung bei der Implementierung von Benutzerprogrammprozeduren einschließen, und zur Erzeugung von eindeutigen Identifizierercodes (UID), von denen jeder permanent einem entsprechenden, von den Prozessormitteln (JP 10114, KOS) erzeugten Objekt zugeordnet ist, und Schutzmittel (10230, FU 10120), die einen Benutzer, der gerade das digitale Datenverarbeitungssystem benutzt, um ein Programm auszuführen, das wenigstens ein Prozedurobjekt enthält, am unberechtigten Zugang zu gewissen der Objekte hindern, wobei die Schutzmittel Subjektnummer-Speichermittel (ASN REGISTER 10916) der Prozessormittel (JP 10114, KOS) umfassen, um eine gerade aktive Subjektnummer (ASN) von einer Vielzahl von Subjektnummern zu speichern, von denen jede einem von einer Vielzahl von Subjekten entspricht, von denen jedes zusammengesetzt ist aus einer Kombination aus (1) einem Benutzer (1404) des digitalen Datenverarbeitungssystems, (2) einem Prozeß (1405) des digitalen Datenverarbeitungssystems zur Ausführung einer Prozedur des Benutzers, und (3) dem Typ (R, W, E) der Operation, die vom digitalen Datenverarbeitungssystem infolge eines Befehls einer Prozedur des Programms des Benutzers durchgeführt werden soll, wobei die gerade aktive Subjektnummer den gerade das digitale Datenverarbeitungssystem benutzenden Benutzer, einen Prozeß, der gerade die Prozedur des Programms des Benutzers ausführt, und die Art der gerade infolge eines vorhandenen Befehls einer Prozedur des Programms des Benutzers durchzuführenden Operation des digitalen Datenverarbeitungssystems identifiziert, Schutzspeichermittel (10232) zur Speicherung wenigstens einer Zugriffskontroll-Liste (ACL 1412), von denen jede einem Objekt entspricht und wenigstens einen Zugriffskontrolleintrag (ACLE 1414) aufweist, von denen jeder einem Subjekt mit Zugriffsrechten zum entsprechenden Objekt entspricht und die Zugriffsrechte dieses Subjekts zum entsprechenden Objekt enthält, und Zugriffsrechtmittel (ASNHT 10912, AST 914, PC 10234), die auf eine gerade aktive Subjektnummer und den Betrieb der Prozessormittel (JP 10114, KOS) ansprechen, um die Schutzmittel als Antwort auf eine Prozedur des Programms des Benutzers zu indizieren, wenn ein gerade vorhandener Befehl den Zugriff auf eines der Objekte anfordert, und um die Zugriffsrechte eines entsprechenden aktiven Subjekts mit denen des Objekts zu vergleichen.

2. Digitales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die eindeutigen Identifizierercodes (UID) erste Felder (LAUID) zur eindeutigen Identifizierung des digitalen Datenverarbeitungssystems und zweite Felder (OSN) zur eindeutigen Identifizierung jedes der von den Prozessormitteln (JP 10114, KOS) erzeugten Objekte enthalten, wobei die Mittel zur Erzeugung der eindeutigen Identifizierercodes auf zweite der Befehle zur Kombination eines der ersten Felder und eines der zweiten Felder ansprechen, um einen der eindeutigen Identifizierercodes (UID) an die Prozessormittel (JP 10114, KOS) zu liefern.

3. Digitales Datenverarbeitungssystem nach Anspruch 1 oder 2, gekennzeichnet durch Schutz-Cache-Mittel (PC 1934), die auf den Betrieb der Prozessormittel (JP 10114, KOS) und die gerade aktive Subjektnummer (ASN) zur Speicherung der aus den Schutzspeichermitteln (10232) gelesenen Zugriffsrechte und zum Vergleich der Zugriffsrechte des gerade aktiven Subjekts mit gewissen der Objekte ansprechen.

4. Digitales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die Objekte Daten enthaltende Datenobjekte enthalten.

5. Digitales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die Objekte zumindest die Befehle enthaltenden Prozedurobjekte (z. B. 10312, 10318) enthalten.

6. Digitales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die Prozessormittel (JP 10114, KOS) und Speichermittel (MEM 10112) weiter Stapelspeichermittel (410) zum Speichern von Informationen enthalten, die den derzeitigen Ausführungsstatus der Befehle betreffen, und daß die Objekte Stapelspeicherobjekte enthalten, die die Informationen betreffend den derzeitigen Ausführungsstatus der Befehle enthalten.

7. Digitales Datenverarbeitungssystem nach Anspruch 1, dadurch gekennzeichnet, daß die Speichermittel (MEM 10112) wenigstens die eindeutigen Identifizierercodes (UID) von aktiven, gerade im digitalen Datenverarbeitungssystem benutzten Objekten speichern.

8. Digitales Datenverarbeitungssystem nach Anspruch 2, dadurch gekennzeichnet, daß die ersten Felder (LAUID) der eindeutigen Identifizierercodes aus einem Gruppennummer- Unterfeld (LAUGN 40605) und einem wählbaren Seriennummer-Unterfeld (LAUSN 40607) zusammengesetzt sind, wobei wenigstens eine Gruppennummer eindeutig und permanent dem digitalen Datenverarbeitungssystem zugeordnet ist.

9. Digitales Datenverarbeitungssystem nach Anspruch 8, dadurch gekennzeichnet, daß das Gruppennummer-Unterfeld (LAUGN 40605) und das Seriennummer-Unterfeld (LAUSN 40607) zusammen 32 Informationsbits enthalten.

10. Digitales Datenverarbeitungssystem nach Anspruch 9, dadurch gekennzeichnet, daß die Mittel zur Erzeugung der ersten Felder (LAUID) des eindeutigen Identifizierercodes Speichermittel mit Ausgängen aufweisen, die zu Kombinationsmitteln zur Bildung des Gruppennummer-Unterfelds (LAUGN) und des Seriennummer-Unterfelds (LAUSN) führen.

11. Digitales Datenverarbeitungssystem nach Anspruch 2 oder 8, dadurch gekennzeichnet, daß die zweiten Felder (OSN) der eindeutigen Identifizierercodes aus einem Architekturtaktfeld zusammengesetzt sind, das binäre Informationen enthält, die das ab einer gewählten Anfangszeit verstrichene Zeitintervall repräsentieren.

12. Digitales Datenverarbeitungssystem nach Anspruch 11, dadurch gekennzeichnet, daß die gewählte Anfangszeit allen digitalen Datenverarbeitungssystemen einer Vielzahl von Datenverarbeitungssystemen gemeinsam ist.

13. Digitales Datenverarbeitungssystem nach Anspruch 11 oder 12, dadurch gekennzeichnet, daß die Mittel zur Erzeugung der zweiten Felder (OSN) der eindeutigen Identifizierercodes Taktmittel zur Erzeugung von Architekturtaktsignalen in vorbestimmten Intervallen und Zählermittel mit zu den Prozessormitteln (JP 10114, KOS) führenden Ausgängen zum Zählen der Taktsignale aufweisen.

14. Digitales Datenverarbeitungssystem nach Anspruch 11,12 oder 13, dadurch gekennzeichnet, daß die zweiten Felder (OSN) des eindeutigen Identifizierercodes 48 Informationsbits enthalten.

15. Digitales Datenverarbeitungssystem nach Anspruch 14, dadurch gekennzeichnet, daß das niederwertigste Bit der zweiten Felder (OSN) des Identifizierercodes verstrichene Zeitintervalle von im wesentlichen nicht mehr als 600 Pikosekunden und das höchstwertige Bit der zweiten Felder (OSN) des eindeutigen Identifizierercodes verstrichene Zeitintervalle von im wesentlichen nicht mehr als 127 Jahren repräsentieren.