[go: up one dir, main page]

DE68927415T2 - Kontextumschaltungsverfahren und -anordnung zur Verwendung in einem Vektorverarbeitungssystem - Google Patents

Kontextumschaltungsverfahren und -anordnung zur Verwendung in einem Vektorverarbeitungssystem

Info

Publication number
DE68927415T2
DE68927415T2 DE68927415T DE68927415T DE68927415T2 DE 68927415 T2 DE68927415 T2 DE 68927415T2 DE 68927415 T DE68927415 T DE 68927415T DE 68927415 T DE68927415 T DE 68927415T DE 68927415 T2 DE68927415 T2 DE 68927415T2
Authority
DE
Germany
Prior art keywords
vector
scalar
instruction
data processing
processing system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE68927415T
Other languages
English (en)
Other versions
DE68927415D1 (de
Inventor
Dileep P Bhandarkar
Wayne Cardoza
Dave Cutler
Dave Orbits
Rich Witek
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Digital Equipment Corp
Original Assignee
Digital Equipment Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Digital Equipment Corp filed Critical Digital Equipment Corp
Application granted granted Critical
Publication of DE68927415D1 publication Critical patent/DE68927415D1/de
Publication of DE68927415T2 publication Critical patent/DE68927415T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/461Saving or restoring of program or task context
    • G06F9/462Saving or restoring of program or task context with multiple register sets

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Complex Calculations (AREA)

Description

    HINTERGRUND DER ERFINDUNG
  • Diese Anmeldung ist verwandt mit der Patentanmeldung EP-A-0 335 514 mit dem Titel "Exception Reporting Mechanism for a Vector Processor" von D. Bhandarkar u. a.; mit der Patentanmeldung EP-A-0 335 515 mit dem Titel "Method and Apparatus for Executing Instructions for a Vector Processing System" von D. Bhandarkar u. a.; und mit der Anmeldung EP-0 333 365 mit dem Titel "Method and Apparatus for Handling Asynchronous Memory Management Exceptions by a Vector Processor" von F. Mckeen u. a.
  • Die Erfindung bezieht sich allgemein auf Datenverarbeitungssysteme mit Vektorverarbeitung und insbesondere auf solche Datenverarbeitungssysteme, die mehrere Prozesse ausführen können, wovon nicht alle eine Vektorverarbeitung erfordern.
  • Bestimmte Hochleistungs-Datenverarbeitungssysteme enthalten zusätzlich zu einem Haupt- oder Skalarprozessor einen separaten Vektorprozessor, um Vektoranweisungen schnell und effizient zu verarbeiten. Vektoranweisungen weisen einen Prozessor an, daß er Speicher-, Arithmetik- oder Logikoperationen an durch Vektoren repräsentierten Daten ausführt. Der Haupt- oder "Skalar"-Prozessor verarbeitet andere Anweisungen, die oftmals "skalare" Anweisungen genannt werden. Skalare Anweisungen weisen beispielsweise einen Prozessor an, daß er Speicher-, Arithmetik- oder Logikoperationen an logischen oder skalaren Daten ausführt.
  • Datenverarbeitungssysteme, die ein Multitasking ausführen (d. h. mehrere verschiedene Tasks oder Prozesse ausführen), erfordern ein spezielles Handling von Vektorregistern. Beispielsweise bietet das IBM 3090 ein Multitasking, wobei die CPU ihre Aufmerksamkeit auf mehrere Prozesse verteilt. Jeder Prozeß wird für eine kurze Zeitperiode ausgeführt, bevor er vom Hauptspeicher ausgeblendet wird und ein weiterer Prozeß eingeblendet wird. Der Ausblendprozeß wird "Kontextumschaltung" genannt. Jedesmal, wenn ein Prozeß "ausgeblendet" wird, wird der momentane Zustand oder Kontext der Maschine gesichert, außerdem werden die Zustandsinformationen des nächsten Prozesses, der eingeblendet werden soll, wiederhergestellt.
  • Zustandsinformationen können Elemente wie etwa Merker (z. B. Ausnahme-Freigabemerker usw.), Statuswörter (z. B. Prozessorstatuswörter, Programmzähler usw.), Skalarregister und Vektorregister enthalten. Alle diese Informationen müssen in der Weise gespeichert sein, daß ein Prozeß, der "ausgeblendet" worden ist, dann, wenn er später "eingeblendet" wird, die Verarbeitung genau dort wiederaufnehmen kann, wo er sich befand, als er "ausgeblendet" wurde. Der mit der Kontextumschaltung verbundene Aufwand ist erheblich, insbesondere zum Speichern der Vektorregister. Typische Vektorprozessoren enthalten 8 bis 16 Vektorregister mit 32 bis 128 Elementen pro Register. Das Speichern solcher Register erfordert dann die Speicherung und Wiederherstellung der Inhalte von 256 bis 2048 Registerelementen.
  • Das IBM 3090 verwendet Schreibmerker, um ein Ausblenden jedes Vektorregisters bei jedem Auftreten einer Kontextumschaltung zu vermeiden. Immer dann, wenn während der Ausführung eines Prozesses in ein Vektorregister geschrieben wird, wird ein entsprechender Schreibmerker gesetzt. Wenn der laufende Prozeß ausgeblendet wird, werden nur die Inhalte jener Vektorregister, in die während der Ausführung des Prozesses geschrieben wurde, gesichert. Dadurch ist es möglich, daß das Betriebssystem nur die Inhalte der Register sichert, die seit der letzten Sicherung geändert worden sind, jedoch bei einem erheblichen Hardware- und Software-Aufwand. Ein solches System ist in der EP-0 211 152 beschrieben, in der "Vektoränderungs"- Bits verwendet werden, um anzugeben, ob sich ein Vektorregister seit der letzten Sicherung geändert hat.
  • Obwohl diese Prozedur die Anzahl der Vektorregister reduziert, die bei jeder Kontextumschaltung gesichert werden müssen, müssen für sämtliche Vektorregister neue Registerwerte wiederhergestellt werden, bevor der nächste Prozeß ausgeführt wird. Da kein Versuch unternommen wird festzustellen, ob die Ausführung des nächsten Prozesses die Inhalte irgendeines der Vektorregister erfordern wird, kann die Anstrengung umsonst gewesen sein.
  • Daher erzeugt die Sicherung eines alten Zustands und die Wiederherstellung eines neuen Zustands bei jeder Kontextumschaltung selbst dann, wenn sie wie in dem IBM 3090 nur teilweise erfolgt, einen erheblichen Aufwand, vor allem dann, wenn eine große Anzahl von Prozessen den Prozessor gemeinsam nutzen, jedoch nur wenige Prozesse Vektoranweisungen verwenden.
  • In der EP-0 239 078 ist ein Master-Slave-Multiprozessorsystem beschrieben, in dem Register nur dann gesichert und wiederhergestellt werden, wenn die am wenigsten weit zurückliegende Task, d. h. die letzte Task, die von der CPU ausgeführt worden ist, und die momentan ausgeführte Task verschieden sind.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist daher eine Aufgabe der Erfindung, wie sie beansprucht wird, in einem mehrere Prozesse ausführenden Datenverarbeitungssystem die Speicherung und Wiedergewinnung von Vektorregistern und Merkern in effizienter Weise zu verwalten.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, wie sie beansprucht wird, die Speicherung und Wiedergewinnung von Zustandsinformationen für einen Vektorprozessor minimal zu machen.
  • Weitere Aufgaben und Vorteile der Erfindung werden zum Teil in der folgenden Beschreibung angegeben und gehen zum Teil aus der Beschreibung hervor oder können durch die Praxis der Erfindung gelernt werden. Die Aufgaben und Vorteile der Erfindung werden mittels der Elemente und Kombinationen, die insbesondere in den beigefügten Ansprüchen angegeben sind, verwirklicht und erzielt.
  • Für die Lösung der Aufgaben und in Übereinstimmung mit dem Zweck der Erfindung, wie sie hier ausgeführt und im weiteren Sinn beschrieben ist, enthält das Datenverarbeitungssystem dieser Erfindung, das mehrere Prozesse sequentiell ausführt, einen Speicher, eine Vektorverarbeitungseinrichtung, eine Vektoranweisungs-Identifizierungseinrichtung, eine Letzter-Benutzer-Anzeigeeinrichtung und eine Sicherungseinrichtung. Der Speicher besitzt mehrere Abschnitte, wovon jeder einem anderen der vom Datenverarbeitungssystem auszuführenden Prozesse entspricht. Die Vektorverarbeitungs einrichtung führt Vektoranweisungen in den Prozessen aus und enthält eine Vektorzustandseinrichtung, um Zustandsinformationen, die einen Ausführungszustand der Vektorverarbeitungseinrichtung beschreiben, zu speichern. Die Vektoranweisungs-Identifizierungsvorrichtung erkennt, wenn der laufende Prozeß (d. h. der momentan ausgeführte Prozeß) eine Vektoranweisung ausführt, während die Letzter-Benutzer-Anzeigeeinrichtung den Prozeß, für den der Vektorprozessor zuletzt eine Vektoranweisung ausgeführt hat, als letzten Vektorbenutzer-Prozeß identifiziert. Die Sicherungseinrichtung veranlaßt als Antwort auf die Vektoranweisungs-Identifizierungseinrichtung und die Letzter-Benutzer-Anzeigeeinrichtung das Datenverarbeitungssystem, die Vektorzustandsinformationen im Speicher an einer Stelle zu speichern, die dem letzten Vektorbenutzer-Prozeß entspricht, wenn die Vektoranweisungs-Identifizierungseinrichtung erkennt, daß der laufende Prozeß eine Vektoranweisung ausführt und der letzte Vektorbenutzer-Prozeß vom laufenden Prozeß verschieden ist.
  • Die beigefügten Zeichnungen, die in dieser Beschreibung enthalten sind und einen Teil von ihr bilden, veranschaulichen eine Ausführungsform der Erfindung und dienen zusammen mit der Beschreibung der Erläuterung der Prinzipien der Erfindung.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • Fig. 1 ist eine Zeichnung einer bevorzugten Ausführungsform eines Datenverarbeitungssystems gemäß der vorliegenden Erfindung;
  • Fig. 2 ist ein Blockschaltbild bestimmter Abschnitte der bevorzugten Ausführungsform der in Fig. 1 gezeigten Vektorverarbeitungseinheit;
  • Fig. 3 ist ein Blockschaltbild bestimmter Abschnitte der bevorzugten Ausführungsform der in Fig. 2 gezeigten Vektorsteuerlogik;
  • Fig. 4 zeigt verschiedene Formate für Vektoranweisungswörter, die in einem in Fig. 1 gezeigten Datenverarbeitungssystem verwendet werden können;
  • Fig. 5 zeigt ein Vektorsteuerwort, das den in Fig. 4 gezeigten Vektoranweisungswörtern zugeordnet ist;
  • Fig. 6 zeigt die MERKER-Felder des in Fig. 4 gezeigten Vektorsteuerworts;
  • Fig. 7 zeigt ein Format eines Skalaranweisungsworts, das in einem Datenverarbeitungssystem gemäß der vorliegenden Erfindung verwendet werden kann;
  • Fig. 8 zeigt die Inhalte der verschiedenen Register und Vektorsteuerwort-Felder während der Verarbeitung einer Vektoranweisung;
  • Fig. 9 zeigt eine bevorzugte Ausführungsform eines Anweisungsdecodierers;
  • Fig. 10 zeigt ein Flußdiagramm der Operationen, die bei der Decodierung einer Vektoranweisung ausgeführt werden;
  • Fig. 11 ist ein Diagramm eines Vektorprozessorstatus-Registers für die in den Fig. 1 und 2 gezeigte Vektorverarbeitungseinheit;
  • Fig. 12 ist ein Diagramm eines Vektorarithmetikausnahme- Registers für die in den Fig. 1 und 2 gezeigte Vektorverarbeitungseinheit;
  • Fig. 13 ist ein Diagramm eines Vektorzustand-Adressenregisters für die in den Fig. 1 und 2 gezeigte Vektorverarbeitungseinheit;
  • Fig. 14 ist ein Diagramm eines Speichermanagementfehler- Stapelrahmens, der von der in den Fig. 1 und 2 gezeigten Vektorverarbeitungseinheit erzeugt wird;
  • Fig. 15 ist ein Flußdiagramm, das eine bevorzugte Prozedur darstellt, die von dem in Fig. 1 gezeigten Datenverarbeitungssystem auszuführen ist, wenn die Vektorverarbeitungseinheit dieses Systems eine Speichermanagementausnahme festgestellt hat;
  • Fig. 16 ist ein Flußdiagramm, das eine bevorzugte Prozedur darstellt, die von dem in Fig. 1 gezeigten Datenverarbeitungssystem während der Kontextumschaltung auszuführen ist;
  • Fig. 17 ist ein Flußdiagramm, das eine bevorzugte Prozedur darstellt, die von dem Anweisungsdecodierer von Fig. 9 für die Anweisungsdecodierung auszuführen ist; und
  • Fig. 18 ist ein Flußdiagramm, das eine bevorzugte Prozedur darstellt, die von dem Datenverarbeitungssystem in Fig. 1 in der Verarbeitung eines in der in Fig. 17 gezeigten Prozedur gesetzten Vektorprozessordeaktivierungs- Fehlers auszuführen ist.
  • BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
  • Nun wird auf eine derzeit bevorzugte Ausführungsform der Erfindung im einzelnen Bezug genommen, wovon ein Beispiel in den beigefügten Zeichnungen dargestellt ist. Wann immer möglich, werden in sämtlichen Zeichnungen die gleichen Bezugszeichen verwendet, um die gleichen oder ähnliche Teile zu bezeichnen.
  • A. Allgemeine Systembeschreibung
  • Gemäß der vorliegenden Erfindung wird ein Datenverarbeitungssystem wie etwa das System 10 geschaffen, das Vektoranweisungen und Skalaranweisungen ausführen kann. Fig. 1 zeigt ein Datenverarbeitungssystem 10, das verschiedene Elemente wie etwa eine Skalarverarbeitungseinheit (SPU) 15, eine Speicherverarbeitungseinheit 20, eine Anweisungsverarbeitungseinheit (IPU) 25 und eine Vektorverarbeitungseinheit (VPU) 30 enthält.
  • Das Datenverarbeitungssytem dieser Erfindung enthält eine Skalarverarbeitungseinheit zum Ausführen von Skalaranweisungen. In der bevorzugten Ausführungsform der Erfindung empfängt die SPU 15 sämtliche Anweisungen von der IPU 25, führt die Skalaranweisungen aus und sendet die Vektoranweisungen und die von der IPU 25 empfangenen Vektordaten zur VPU 30.
  • Gemäß der vorliegenden Erfindung enthält das Datenverarbeitungssystem außerdem eine Vektorverarbeitungseinrichtung zum Ausführen von Vektoranweisungen gleichzeitig mit der Ausführung von Skalaranweisungen durch die Skalarverarbeitungseinrichtung. In der in den Figuren gezeigten Ausführungsformen führt die VPU 30 Vektoranweisungen gleichzeitig mit der Ausführung der Skalaranweisung durch die SPU 15 aus. Die VPU 30 enthält mehrere Vektorregister, wie im folgenden im einzelnen erläutert wird.
  • Das Datenverarbeitungssystem dieser Erfindung enthält außerdem eine Anweisungsdecodierungseinrichtung zum Leiten von Vektoranweisungen an die Vektorverarbeitungseinrichtung und von Skalaranweisungen an die Skalarverarbeitungseinrichtung. Wie in Fig. 1 gezeigt, enthält die IPU 25 einen Anweisungsanalysator 50, der von der Speicherverarbeitungseinheit 20 empfangene Anweisungen in der im folgenden beschriebenen Weise vorverarbeitet. Der Analysator 50 sendet Skalaranweisungen und Daten zur SPU 15 und sendet Vektoranweisungen und Skalardaten über die SPU 15 zur VPU 30. Die SPU 15 enthält eine Steuerlogikeinheit 40, die einen Mikrocode enthält, um die Vektoranweisungen und Daten zur VPU 30 weiterzuleiten. Selbstverständlich könnte der Analysator 50 so beschaffen sein, daß er die Vektoranweisungen direkt zur VPU 30 sendet. Die VPU 30 empfängt von der Speicherverarbeitungseinheit 20 Vektordaten und sendet Adressen und Vektordaten zur Speicherverarbeitungseinheit 20, ohne die Verwendung der IPU 25 oder der SPU 15 zu erfordern.
  • Die Speicherverarbeitungseinheit 20 empfängt Steuer-, Adressen- und Datensignale von der IPU 25, der SPU 15 und der VPU 30 und entscheidet dann über diese Signale, verarbeitet sie und antwortet auf sie. Das Datenverarbeitungssystem 10 kann außerdem andere Elemente enthalten, um verschiedene Funktionen auszuführen, ein Verständnis solcher Elemente ist jedoch für das Verständnis der vorliegenden Erfindung nicht notwendig.
  • Fig. 2 ist ein Diagramm, das eine bevorzugte Ausführungsform der VPU 30 zeigt. Wie in Fig. 2 gezeigt, enthält die VPU 30 eine Steuerlogik 60 als Hauptschnittstelle mit den anderen Teilen des Datenverarbeitungssystems 10 und eine Vektorregisterdatei 35 für die Unterstützung von Vektordatenzugriffsanforderungen. Solche Anforderungen können entweder Schreibanforderungen sein, die aus Schreibsteuersignalen und Schreibadressen aufgebaut sind, oder Leseanforderungen, die aus Lesesteuersignalen und Leseadressen aufgebaut sind. Die Vektorregisterdatei 35 enthält mehrere Schreib-Ports, die bei Schreib-Port 0 bis Schreib-Port 2 gezeigt und mit den Bezugszeichen 41 bis 43 bezeichnet sind, sowie mehrere Lese-Ports, die bei Lese-Port 0 bis Lese-Port 4 gezeigt und mit den Bezugszeichen 51 bis 55 bezeichnet sind. Die Schreib-Ports empfangen Lese/Schreib-Steuersignale 45 und Schreibdaten von der Vektorsteuerlogik 60, von einem Vektormultiplizierer 70 oder von einem Vektoraddierer 80.
  • Die Lese-Ports arbeiten ähnlich wie die Schreib-Ports. Beispielsweise empfängt der Lese-Port 53, der dem Lese- Port 0 entspricht, ein Lesefreigabesignal, ein Vektorregister-Wählsignal und Vektorelementadressen-Signale von der Steuerlogik 60 über die Lese/Schreib-Steuersignal- Leitung 45. Die Lesedaten für den Lese-Port 53 werden für eine Maskierungseinheit 90 bereitgestellt.
  • Die anderen Lese-Ports empfangen von der Steuerlogik 60 ebenfalls ihre Steuer- und Adressensignale. Die Ausgänge von den Lese-Ports 55 und 54, d. h. Lese-Port 1 bzw. Lese-Port 2, sind an den Vektormultiplizierer 70 angeschlossen, während die Ausgänge der Lese-Ports 52 und 51, Lese-Port 3 bzw. Lese-Port 4, an den Vektoraddierer 80 angeschlossen sind.
  • Die Vektorregisterdatei 35 enthält mehrere Vektorregister, vorzugsweise 16, die Vektoren speichern, die von der VPU 30 verarbeitet werden. Jedes Vektorregister besitzt vorzugsweise 64 Elemente. Die Größe der Datei 35 ist jedoch für die vorliegende Erfindung nicht kritisch.
  • Die Anzahl der Einträge des verarbeiteten Vektors, d. h. die Länge dieses Vektors, ist in einem Vektorlängenregister (VLR) 182 in der Steuerlogik 60 gespeichert. In der bevorzugten Ausführungsform kann ein Vektor bis zu 64 Einträge besitzen, weshalb das Vektorlängenregister 182 eine Länge von 7 Bits besitzt, um Vektorlängen mit 0 bis 64 Einträgen zu repräsentieren.
  • Der Vektoraddierer 80 führt Ganzzahl- und Gleitkomma-Additions- und Subtraktionsoperationen für zwei Vektoren aus, die von der Vektorregisterdatei 35 über Lese-Port 3 und Lese-Port 4 geliefert werden. Vorzugsweise führt der Addierer 80 außerdem bestimmte Logik- und Verschiebungsoperationen aus. Der Ausgang des Vektoraddierers 80, der mit "Ergebnis" bezeichnet ist, schafft für den Schreib- Port 1 einen Dateneingang. Der Vektoraddierer 80 enthält außerdem eine Ausnahmelogik 82, die an die Maskierungseinheit 90 angeschlossen ist und dem Addierer 80 ermöglicht, bedingte Operationen auszuführen und der Maskierungseinheit 90 über Arithmetikausnahmebedingungen Mitteilung zu machen.
  • Der Vektormultiplizierer 70 führt Ganzzahl- und Gleitkomma-Multiplikations- und Divisionsoperationen an zwei Vektoren aus, die von Lese-Port 1 und Lese-Port 2 der Vektorregisterdatei 35 empfangen werden. Das Produkt oder der Quotient dieser Eingänge ist ein mit "Ergebnis" bezeichneter Vektor, der als Eingangsdaten für Schreib- Port 2 bereitgestellt wird. Die Ausnahmelogik 72, die an die Maskierungseinheit 90 angeschlossen ist, zeigt der Maskierungseinheit 90 an, wenn eine Arithmetikausnahmebedingung vorliegt, die sich aus der Multiplikation oder der Division durch den Multiplizierer 70 ergibt.
  • Die Maskierungseinheit 90 empfängt Daten von der Vektorregisterdatei 35 über den Lese-Port 0 und stellt Vektordaten von der VPU 30 für die SPU 15 über die in Fig. 2 gezeigte Vektordaten-Leitung bereit. Die Maskierungseinheit 90 kann außerdem die Daten von Lese-Port 0 lesen und sie in eine Adresse für die Speicherverarbeitungseinheit 20 umwandeln. Weiterhin ist die Maskierungseinheit 90 an die Ausnahmelogik 72 und 82 angeschlossen und führt eine Zwischenspeicherung der Ausnahmebedingungen aus.
  • In der Maskierungseinheit 90 ist ein 64-Bit-Vektormaskierungsregister 92 enthalten. Jedes Bit im Register 92 entspricht einem anderen der 64 Vektorelemente in einem gegebenen Vektorregister und zeigt an, ob das entsprechende Vektorelement aktiviert ist und verarbeitet werden soll. Das Maskierungsregister 92 kann mit Daten von der SPU 15 über die Steuerlogik 60 geladen werden. Vorzugsweise stellt das Vektormaskierungsregister 92 sicher, daß nur die Ergebnisse von den aktivierten Elementen in einem Vektorregister gespeichert werden.
  • Die Vektorsteuerlogik 60 enthält vorzugsweise einen Anweisungsanalysator 65 und eine Vektorsicherungs- und Vektordecodierungslogik 66, um bestimmte Steuerfunktionen zu implementieren. Die Vektorsicherungs- und Vektordecodierungslogik 66 in der Steuerlogik 60 überblickt den Zeitplan sämtlicher Aktivitäten in der VPU 30 und führt bestimmte Datenübertragungsaktivitäten aus.
  • Der Anweisungsanalysator 65, wovon Teile in Fig. 3 genauer gezeigt sind, empfängt Informationen (d. h. Anweisungen über die Vektordaten-Leitung) von der SPU 15 und leitet ankommende Daten und Adressen an die geeigneten Lese- und Schreib-Ports und dann an den Vektormultiplizierer 70, den Vektoraddierer 80 oder die Maskierungseinheit 90. Vorzugsweise schickt der Anweisungsanalysator 65 Daten, die er von der SPU 15 empfangen hat, auf eine Skalardaten-Leitung, um sie vorzugsweise in (nicht gezeigten) Skalarregistern in der Vektorregisterdatei 35 zu speichern, damit sie während der Vektorverarbeitungsoperationen verwendet werden.
  • Fig. 3 zeigt die interne Logik des Anweisungsanalysators 65 in der VPU 30. Der Analysator 65 empfängt von der SPU 15 als Eingangssignale 100 teilweise decodierte Vektoranweisungsinformationen und Skalardaten. Diese Eingangssignale werden in einem Anweisungspuffer 115 gespeichert, der die Anweisungen und die Daten in der geeigneten Reihenfolge hält, bis die Vektoranweisungen von der VPU 30 ausgeführt werden können.
  • Ein Multiplexierer 116, der an die Ausgänge BUF0-BUF3 des Puffers 115 angeschlossen ist, gibt dann die Anweisungsinformationen für die nächste zu decodierende Anweisung korrekt aus. Diese Informationen werden durch ein Anweisungswählsignal bestimmt, das ein umlaufendes 2-Bit-Zählsignal ist, das den Puffer 115 so erscheinen läßt, als ob er als Umlaufpuffer arbeitet.
  • Von einem Multiplexer 102, der außerdem so angeschlossen ist, daß er vom Puffer 115 die Ausgänge BUF0-BUF3 empfängt, werden gemäß dem Befehlswählsignal + 1, dessen Wert um 1 größer als das Befehlswählsignal ist, Skalardaten ausgewählt. Die Skalardaten werden zur Vektorregisterdatei 35 geschickt, wo sie in einem Skalarregister, das entweder dem Vektoraddierer 80, dem Vektormultiplizierer 70 oder der Maskierungseinheit 90 entspricht, gespeichert werden.
  • Falls die momentan decodierte Vektoranweisung nur Vektoroperanden erfordert, werden die Informationen durch den Puffer 116 geschickt, wobei die Operanden entsprechend dem Steuerwort-Decodierungselement 103 in einer im folgenden beschriebenen Weise bestimmt werden. Falls jedoch ein Befehl Skalardaten erfordert, werden diese Daten nach der Anweisung von der SPU 15 geschickt und im richtigen Zeitpunkt vom Multiplexierer 102 ausgegeben.
  • Wenn vom Multiplexierer 116 die Anweisung gewählt worden ist, werden bestimmte Felder verteilt, um Logikelemente 103, 104, 105 und 106 zu decodieren. Die Anweisungsinformationen in der teilweise decodierten Anweisung enthalten einen Operationscode-Abschnitt, der den Anweisungstyp angibt, einen Steuerworttyp-Abschnitt, der den Typ des Steuerworts angibt (wie weiter unten genauer beschrieben wird), einen Versendeabschnitt, der angibt, welche der Hauptvektoreinheiten wie etwa der Addierer 80 oder der Multiplizierer 70 von der Anweisung verwendet werden soll, sowie einen Steuerwortabschnitt, der die Operanden und Merker für die Vektoranweisung spezifiziert.
  • Das Steuerwortdecodierungselement 103 entnimmt die Operanden aus dem Steuerwortabschnitt, um die Adressen für die Register in der Vektorregisterdatei 35 sowohl für die Vektorregister, die die Datenquelle für die spezifizierten Vektoroperationen schaffen, d. h. das Quellregister 1 und das Quellregister 2, als auch für die Vektorregister, die das Ergebnis der Vektoroperation speichern, d. h. das Zielregister, zu bilden. Weiterhin entnimmt das Decodiererelement 103 auch die Ausnahmen/Maskierungs-Merker.
  • Die Werte für Quellregister 1, Quellregister 2 und Zielregister werden in Adressengeneratoren 108, 109 bzw. 110 eingegeben, die Adressen für den Vektoraddierer 80, den Vektormultiplizierer 70 bzw. die Maskierungseinheit 90 entsprechend dem Typ der Anweisungen erzeugen. Vorzugsweise sind die Adressengeneratoren 108, 109 und 110 Zähler, die die besondere momentan ausgeführte Unteroperation bestimmen und die als Zähler 44 in der Vektorsteuerlogik 60 gezeigt sind (Fig. 2).
  • Die anderen Anweisungstyp-Abschnitte werden zur Versendelogik 104, zur Steuerwortlogik 105 oder zur Operationscode-Decodierungslogik 106 für die weitere Decodierung geschickt. Auf der Grundlage einer solchen Decodierung bestimmt eine Ausgabeentscheidungslogik 107 dann, ob die Anweisung ausgegeben werden kann. Falls beispielsweise ein Vektoraddierer 80 beschäftigt ist, muß die nächste Anweisung verzögert werden, falls sie den Addierer 80 erfordert, bis der Addierer 80 frei ist. Falls die Ausgabeentscheidungslogik 107 bestimmt, daß die nächste Anweisung ausgeführt werden kann, gibt sie ein Neuausgabe-Signal aus, das die Adressengeneratoren 108, 109 und 110 dazu veranlaßt, ihren richtigen Wert zu laden.
  • B. Vektoranweisungsformat
  • Fig. 4 zeigt die Formate der verschiedenen Vektoranweisungswörter, die Operandenspezifizierer in verschiedener Anzahl besitzen. Fig. 5 zeigt verschiedene Formate eines Vektorsteuerworts, auf das ein Vektorsteuerwort-Spezifizierer 140 eines Vektoranweisungsworts mit dem in den Zeilen (a)-(d) von Fig. 4 gezeigten Format zeigt.
  • Wie in Fig. 4 der vorliegenden Ausführungsform gezeigt, enthalten Vektoranweisungen ein Operationscode-Feld 150, das einen den Anweisungstyp identifizierenden Operationscode hält, und einen Operandenzeigerabschnitt 152. Der Operandenzeigerabschnitt 152 kann irgendeine Anzahl von Operandenspezifizierern 154-158 und einen Vektorsteuerwort-Spezifizierer 140 enthalten. Vorzugsweise besitzen sämtliche Operandenspezifizierer im Operandenzeigerabschnitt 152 das gleiche Format wie die Operandenspezifizierer in einer Skalaranweisung, wobei die Operandenspezifizierer in den Vektoranweisungswörtern wie die Spezifizierer in der Skalaranweisung den Ort eines Skalaroperanden identifizieren. Da die Vektoroperanden-Spezifizierer und die Skalaroperanden-Spezifizierer (siehe Fig. 7) übereinstimmende Formate besitzen, können die Operanden geholt werden, bevor bekannt ist, ob eine gegebene Anweisung eine Vektoranweisung oder eine Skalaranweisung ist.
  • Fig. 7 zeigt ein Skalaranweisungswort mit drei Operandenspezifizierern 154', 155' und 1561. Der Vektorsteuerwort- Spezifizierer 140 in den Zeilen (a)-(d) von Fig. 4 und die Vektoroperandenspezifizierer 154', 155' und 156' von Fig. 7 verwenden übereinstimmende Adressenschemata, so daß der Anweisungsanalysator 50 nicht damit belastet ist, Operanden für Vektoranweisungen und Skalaranweisungen in unterschiedlicher Weise zu holen. Die Verwendung übereinstimmender Adressenschemata ermöglicht eine für die IPU 25 durchsichtige Organisation der VPU 30. Das bevorzugte Adressierungsschema, mit dem die Operandenspezifizierer 154-158 Operanden identifizieren, ist in dem US-Patent Nr. 4,241,399, erteilt an Strecker u. a., erläutert.
  • Im Gegensatz zu den Operandenspezifizierern 154-158 zeigt der Vektorsteuerwort-Spezifizierer 140 auf ein 16-Bit- Vektorsteuerwort 160, wovon in Fig. 5 drei Beispiele gezeigt sind. Das Vektorsteuerwort 160 enthält, wie in Fig. 5 gezeigt ist, 16 Bits, es könnte jedoch irgendeine Länge wie etwa 8, 32 oder 64 Bits besitzen. In Fig. 5(a) ist das Vektorsteuerwort 160 in vier 4-Bit-Felder 162-165 unterteilt. Vorzugsweise ist das Feld 162 ein Merkerfeld, während entweder eines, zwei oder drei der Felder 163-165 Vektorregisterspezifizierer-Felder sind, die Zeiger auf oder Spezifizierer für Vektorregisteroperanden enthalten, auf die während der Ausführung von Vektoranweisungen zugegriffen werden soll. Jeder Vektorregisterspezifizierer identifiziert vorzugsweise ein eindeutiges Vektorregister. Die 4 Bits jedes Vektorregisterspezifizierer-Feldes können eines der 16 Vektorregister eindeutig identifizieren, die in der vorliegenden Ausführungsform der Erfindung enthalten sind.
  • Fig. 5(b) zeigt ein alternatives Format für ein Vektorsteuerwort 160'. Zusätzlich zum Merkerfeld 162 und den Vektorspezifizierer-Feldern 163 und 164 enthält das Steuerwort 160' ein 4-Bit-Operandeninformationsfeld 168 anstatt des 4-Bit-Vektorregisterspezifizierer-Feldes 165 von Fig. 5(a). Das Operandeninformationsfeld 168 enthält Informationen, die für die verschiedenen Vektoroperationen erforderlich sind. Falls beispielsweise der Operationscode im Operationscode-Feld 150 angibt, daß eine Vergleichsoperation ausgeführt werden soll, kann das Operandeninforrnationsfeld 168 Daten enthalten, die spezifizieren, ob ein " größer als"- oder " kleiner als"-Vergleich ausgeführt werden soll. Das Operandeninformationsfeld 168 kann auch anstelle des Vektorregisterspezifizierers 163, des Vektorregisterspezifizierers 164 oder des Vektorregisterspezifizierers 165 in Abhängigkeit vom Wert des Operationscode-Feldes 150 auftreten.
  • Fig. 5(c) zeigt ein nochmals weiteres Format für ein Vektorsteuerwort 160". Das Steuerwort 160" enthält ein Umwandlungsfeld 166 anstelle des Vektorspezifiziererfeldes 163. Das Umwandlungsfeld 166 identifiziert eine auszuführende Umwandlungsfunktion, so daß Werte in dem durch das Feld 164 spezifizierten Vektorregister vor der Speicherung in dem im Feld 165 spezifizierten Vektorregister geeignet umgewandelt werden. Eine solche Umwandlung kann beispielsweise eine Gleitkomma-zu-Ganzzahl- oder eine Langwort-Umwandlung enthalten.
  • Fig. 6 zeigt eine Erweiterung des Merkerfeldes 162 des Vektorsteuerworts 160 von Fig. 5(a). Ein Bit enthält einen Maskierungsoperation-Freigabemerker (MOE-Merker) 170. Ein zweites Bit enthält einen Merker 172 für wahre/falsche Gleichheit (MTF-Merker). Der MTF-Merker 172 bestimmt, ob ein Boolscher Wert von 0 oder 1 in einem Vektormaskierungsregister 92 ein aktiviertes Bit repräsentiert. Ein drittes Bit enthält den Ausnahmefreigabemerker (EXC-Merker) 174, der ein Ausnahmehandling freigibt, wenn Vektorverarbeitungsausnahmen auftreten. Ein viertes Merkerbit 176 ist momentan unbenutzt. Die Verwendung dieser Bits hängt von der momentan verarbeiteten Anweisung ab.
  • Wie oben kurz erläutert worden ist, werden in der durch den MOE-Merker 170 aktivierten Maskierungsfunktion nur jene Ergebnisse einer Vektoroperation, die einem aktivierten Bit in einem Vektormaskierungsregister 192 entsprechen, nach einer Operation gespeichert. Fig. 8 zeigt ein Beispiel, wie das Vektormaskierungsregister 92, das Vektorlängenregister 182 und die MOE- und MTF-Merker 170 bzw. 172 des Merkerfeldes des Vektorsteuerworts 160 die Speicherung eines Ergebnisses einer Vektoroperation beeinflussen. In Fig. 8(a) enthält der MOE-Merker 170 des Vektorsteuerworts einen Wert von "1", der angibt, daß die Maskierung aktiviert ist. Der MTF-Merker 172 enthält den Wert "0", der angibt, daß nur jene Ergebnisse, die den Werten "0" im Vektormaskierungsregister 92 entsprechen, gespeichert werden sollen.
  • Fig. 8(b) zeigt die Inhalte eines Zielregisters 192 der Vektorregisterdatei 35, bevor eine Vektoroperation aufgetreten ist, d. h. bevor Ergebnisdaten von einer Vektoroperation im Zielregister 192 gespeichert worden sind. Fig. 8(c) zeigt das Vektormaskierungsregister 92, in dem auf "0" gesetzte Bits wegen des MTF-Feldes 172 in Fig. 8(a) aktivierte Bits sind.
  • Fig. 8(d) zeigt ein Ergebnis 190 einer Vektoroperation vor der Maskierung und bevor das Vektorergebnis 190 im Zielregister 192 gespeichert worden ist (die Werte im Ergebnis 190 sind für das Beispiel beliebig gewählt worden). Es wird darauf hingewiesen, daß in Fig. 8(b) die beiden am weitesten links befindlichen Elemente des Zielregisters 192 die Werte "9" bzw. "7" enthalten. Nach der Vektoroperation enthalten die zwei ganz links befindlichen Elemente des Vektorergebnisses 190 die Werte "4" bzw. "5", wie in Fig. 8(d) gezeigt ist. Das am weitesten links befindliche Element des Vektorergebnisses 190 entspricht einem Bit im Vektormaskierungsregister 92 mit dem Wert "0". Das links an zweiter Stelle befindliche Bit im Vektorergebnis 190 entspricht einem Bit im Vektormaskierungsregister 92 mit dem Wert "1".
  • Fig. 8(e) zeigt das Zielregister 192 nach der Maskierung, wenn bestimmte Elemente des Vektorergebnisses 190 von Fig. 8(d) im Zielregister 192 gespeichert worden sind. Das am weitesten links befindliche Element des Zielregisters 192 enthält den Wert "4". Dieser Wert wurde in das Zielregister 192 gespeichert, weil ein entsprechendes Bit im Vektormaskierungsregister 92 den Wert "0" enthielt. Das links an zweiter Stelle befindliche Element des Zielregisters 192 hält jedoch noch immer seinen ursprünglichen Wert "7" in Fig. 8(e). Der Ergebniswert von "5" im Vektorergebnis 190 in Fig. 8(d) wurde im Zielregister 192 in Fig. 8(e) nicht gespeichert, weil ein entsprechendes Bit im Vektormaskierungsregister 92 eine "1" enthielt. Annlich sind alle anderen Elemente des Vektorergebnisses 190, die aktivierten Bits des Vektorrnaskierungsregisters 92 entsprechen, im Zielregister 192 gespeichert, hingegen ist im Zielregister 192 kein Element des Vektorregisters 190 gespeichert, das einem nicht aktivierten Vektormaskierungsregister-Bit entspricht.
  • C. Anweisungsvorverarbeitung
  • Bevor die SPU 15 Anweisungen entweder an die VPU 30 oder an eine andere Schaltungsanordnung in der SPU 15 leitet, um sie auszuführen, führt die IPU 25 bestimmte Vorverarbeitungen an den Anweisungen aus. Wie oben kurz erläutert worden ist, ermöglicht die eindeutige Art der Anweisungsformate, die oben diskutiert worden sind, der IPU 25 die Verwendung derselben Schaltungsanordnung, wovon eine Ausführungsform in Fig. 9 gezeigt ist, die einen Puffer 187 und eine Operandensteuerlogik 185 enthält, um sowohl Vektoranweisungen als auch Skalaranweisungen in übereinstimmender Weise vorzuverarbeiten.
  • Fig. 10 ist ein Flußdiagramm einer bevorzugten Prozedur für die Vorverarbeitung von Anweisungen in der IPU 25. Wenn eine Speicherverarbeitungseinheit 20 eine Anweisung an die IPU 25 überträgt, wird diese Anweisung in den Puffer 187 eingegeben (Schritt 194 in Fig. 10). Der Operationscode-Abschnitt dieser Anweisung (d. h. das in den Fig. 4(a)-(d) gezeigte Operationscode-Feld 150) wird dann entnommen (Schritt 196) und an die SPU 15 übertragen. Der Operandenzeiger-Abschnitt dieser Anweisung (d. h. der Operandenzeiger-Abschnitt 152 in den Fig. 4(a)-(d)) wird ein Eingang einer Operandensteuerlogik 185, die ebenfalls Zugriff auf den Operationscode-Abschnitt hat, um gegebenenfalls dessen Funktionen auszuführen.
  • Die Operandensteuerlogik 185 decodiert die Operandenspezifiziererabschnitte, erforderlichenfalls unter Verwendung der Operationscodes, und führt irgendwelche Zugriffe auf die Speicherverarbeitungseinheit 20 aus, die notwendig sind, um die Operanden zu bestimmen, auf die jeder der Operandenspezifiziererabschnitte zeigt (Schritt 198). Die Einzelheiten der Prozedur für die Bestimmung von Operanden ist in dem oben zitierten Patent von Strecker u. a. erläutert. Schließlich sendet die IPU 25 die Operanden und die Operationscode-Abschnitte an die SPU 15, damit sie entweder von der SPU 15 ausgeführt werden oder, bei Vektoranweisungen und -operanden, an die VPU 30 übertragen werden.
  • Da die Vektor- und Skalarverarbeitungsanweisungen das gleiche Format besitzen, führt die Operandensteuerlogik 185 sowohl für Vektor- als auch für Skalaranweisungen die gleiche Funktion aus. Tatsächlich erlaubt die Verwendung der obenbeschriebenen Anweisungsformate für irgendeinen Typ einer Datenverarbeitungseinrichtung, die einen separat arbeitenden Prozessor wie etwa einen FFT-Prozessor oder einen Gleitkommaprozessor besitzt, einem einzelnen Anweisungsprozessor wie etwa der IPU 25, sämtliche Anweisungen in der gleichen Weise vorzuverarbeiten.
  • D. Vektorverarbeitungsausnahmen 1. Vektorprozessorregister
  • Gemäß der vorliegenden Erfindung enthält die Vektorverarbeitungseinrichtung eine Zustandseinrichtung zum Halten von Vektorzustandsinformationen, die einen Ausführungszustand der Vektorverarbeitungseinrichtung repräsentieren. In der bevorzugten Ausführungsform dieser Erfindung ist in der VPU 30 ein Vektorprozessorstatus-Register (VPSR) 200, das in Fig. 11 gezeigt ist, vorgesehen, um Informationen zu halten, die den Ausführungszustand der VPU 30 repräsentieren. Das VPSR 200 hält 32 Bits von Statusinformationen über die VPU 30 und befindet sich vorzugsweise in der Steuereinheit 60, obwohl sie sich anderswo befinden könnte. In der Maskierungseinheit 90 befindet sich außerdem ein Vektorarithmetikausnahmeregister (VAER) 300, das in Fig. 12 gezeigt ist, und ein Vektorzustandadressenregister (VSAR) 400, das in Fig. 13 gezeigt ist. Die Inhalte der Register 200, 300 und 400 sowie der anderen weiter unten diskutierten Daten bilden einen Teil der Zustandsinformationen der VPU 30.
  • Das Bit 0 des VPSR 200 ist ein Vektorprozessorfreigabe- Bit (VEN-Bit) 210, das angibt, ob die VPU 30 deaktiviert ist. Die VPU 30 wird aktiviert, indem für dieses Bit eine 1 geschrieben wird und deaktiviert, indem für dieses Bit eine 0 geschrieben wird. Wenn die VPU 30 deaktiviert ist, hat jeder Versuch der SPU 15, Vektoranweisungen zur VPU 30 zu senden, einen Vektorprozessordeaktivierungs-Fehler zur Folge.
  • Das Bit 1 des VPSR 200 ist ein Vektorprozessorzustandrücksetz-Bit (RST-Bit) 220. Das Schreiben einer 1 für dieses Bit löscht das VPSR 200 mit Ausnahme des VEN-Bits 210.
  • Das Bit 2 des VPSR 200 ist ein Vektorzustandspeicher-Bit (STS-Bit) 230, das, falls es auf 1 gesetzt ist, die Speicherung der Implementierung spezifischer Vektorzustandsinformationen in die Speicherverarbeitungseinheit 20 unter Verwendung einer virtuellen Speicheradresse 420 im VSAR 400 für ein asynchrones Handling der Speichermanagementausnahmen einleitet. Falls ein synchrones Handling von Ausnahmen implementiert ist, wird das STS-Bit 230 ignoriert. Die bevorzugte Ausführungsform der Erfindung läßt die Auswahl einer von zwei Weisen der Ausführung der Vektorverarbeitungs-Speicherzugriffsanweisungen zu. Die beiden Weisen haben unterschiedliche Mechanismen des Handlings von Speichermanagementausnahmen zur Folge, wie im nächsten Abschnitt erläutert wird. Einer ist die synchrone Speichermanagementausführung, während der andere die asynchrone Speichermanagementausführung ist. Während der synchronen Ausführung verarbeiten die VPU 30 und die SPU 15 keinen neuen Anweisungen, bis der Abschluß der momentan ausgeführten Vektorspeicherzugriffanweisung sichergestellt ist.
  • Für die asynchrone Ausführung kann die VPU 30 eine Vektorspeicherzugriffanweisung gleichzeitig entweder mit der Ausführung der SPU-Anweisung oder mit einer VPU-Ausführung anderer Vektorspeicheranweisungen ausführen. Das asynchrone Speichermanagement erlaubt die verkettete Ausführung einer Befehlsfolge wie etwa Laden/Addieren/Multiplizieren/Speichern.
  • Das Bit 3 des VPSR 200 ist ein Vektorzustandneulade-Bit (RLD-Bit) 240, das, falls es auf 1 gesetzt ist, das erneute Laden von implementierungsspezifischen Vektorzustandsinformationen vom Speicher unter Verwendung einer virtuellen Speicheradresse 420 im VSAR 400 für das asynchrone Handling von Speichermanagementausnahmen einleitet. Falls ein synchrones Handling von Ausnahmen implementiert ist, wird das RLD-Bit 240 in gleicher Weise wie das STS-Bit 230 ignoriert.
  • Das Bit 5 des VPSR 200 ist ein Speicherfehler-Bit (MF- Bit) 250, das von der VPU 30 auf 1 gesetzt wird, um das Vorhandensein einer neu auszuführenden Speicherbezugnahme wegen einer asynchronen Speichermanagementausnahme anzeigt. Dies wird weiter unten genauer erläutert. Falls ein synchrones Handling der Speichermanagementausnahmen implementiert ist, ist dieses Bit auf 0 gesetzt.
  • Das Bit 6 des VPSR 200 ist ein Bit 260 für anhängigen Speicherfehler (PMF-Bit). Die VPU 30 setzt das PMF-Bit 260 auf Eins, um anzuzeigen, daß eine asynchrone Speichermanagementausnahme anhängig ist. Falls ein synchrones Handling von Speichermanagementausnahmen implementiert ist, ist dieses Bit stets Null.
  • Das Bit 7 des VPSR 200 ist ein Arithmetikausnahme-Bit (AEX-Bit) 270, das normalerweise 0 ist, um anzuzeigen, daß die VPU 30 durch bestimmte Arithmetikausnahmen wie etwa einen Gleitkomma-Unterlauf oder einen Ganzzahl-Überlauf nicht deaktiviert ist. Die VPU 30 setzt dieses Bit stets, wenn eine Arithmetikausnahme auftritt. Informationen hinsichtlich der besonderen Art der Ausnahme befinden sich im VAER 300.
  • Das Bit 24 des VPSR 200 ist ein Bit 280 für einen implementierungsspezifischen Hardwarefehler (IMP-Bit). Das IMP-Bit 280 wird auf 1 gesetzt, wenn die VPU 30 aufgrund eines Hardwarefehlers deaktiviert ist.
  • Das Bit 31 des VPSR 200 ist ein Vektorprozessor-Beschäftigt-Bit (BSY-Bit) 290, das die VPU 30 auf 1 setzt, wenn sie Vektoranweisungen ausführt. Wenn dieses Bit auf 0 gelöscht ist, ist die VPU 30 im Leerlauf oder hat die Ausführung einer Anweisung aufgrund einer asynchronen Speichermanagementausnahme beendet.
  • Vorzugsweise ist das VAER 300 ein Register, das für die Aufzeichnung von Informationen hinsichtlich Vektorarithmetikausnahmen verwendet wird. Das VAER 300 befindet sich in der Maskierungseinheit 90 und wird durch die Ausnahmeeinheiten 82 und 72 beschrieben. Die Steuerlogikeinheit 40 der SPU 15 kann die Inhalte des VAER 300 lesen, jedoch nicht in das VAER 300 schreiben. Das VAER 300 enthält in der bevorzugten Ausführungsform zwei Felder: ein Vektorzielregistermaskierungs-Feld 310 und ein Ausnahmebedingungsverzeichnis-Feld 320. Das Vektorzielregistermaskierungs-Feld 310 des VAER 300 zeichnet auf, welche Vektorregister aufgrund von Arithmetikausnahmen einen Voreinstellungswert empfangen haben. Falls das n-te der 16 Vektorregister einen Voreinstellungswert als Ergebnis einer Arithmetikausnahme empfängt, wird für das Bit n des Maskierungsfeldes 310 (Bit (16 + n) des VAER 300) eine 1 geschrieben.
  • Das Ausnahmebedingungsverzeichnis-Feld 320 gibt den Typ der Ausnahme an, die aufgetreten ist. Vorzugsweise umfassen diese Bedingungen die Ausnahmebedingungen eines Gleitkomma-Unterlaufs, einer Gleitkommadivision durch 0, eines für eine Gleitkommaoperation reservierten Operanden, eines Gleitkommaüberlaufs oder eines Ganzzahlüberlaufs.
  • Wie oben erläutert worden ist, schickt der Anweisungsanalysator 50 in der IPU 25 Vektor- und Skalaranweisungen zur SPU 15. Die SPU 15 identifiziert dann Vektoranweisungen und schickt sie zur VPU 30. Selbstverständlich könnten die Vektoranweisungen ebensogut direkt von der IPU 25 zur VPU 30 geschickt werden. Die VPU 30 führt dann gemäß ihrem Normalbetrieb die Vektoranweisungen aus. Während der Ausführung der Vektoranweisungen können jedoch zwei Typen von Vektorprozessorausnahmen auftreten: Vektorspeichermanagementausnahmen und Vektorarithmetikausnahmen.
  • 2. Speichermanagementausnahmen
  • Die zwei Typen der Vektorprozessorausnahmen werden etwas unterschiedlich gehandhabt. Im Gegensatz zu Vektorarithmetikausnahmen deaktivieren Vektorspeichermanagementausnahmen die VPU 30 nicht. Speichermanagementausnahmen, die während einer Speicherzugriffanweisung auftreten, verhindem eine weitere Verarbeitung dieser Anweisung, was bei Arithmetikausnahmen nicht der Fall ist. Speichermanagementausnahmen halten auch die Ausführung aller anderen Anweisungen, die von den Daten abhängen, an.
  • Die Vektorverarbeitungseinrichtung dieser Erfindung enthält eine Ausnahmeerfassungseinrichtung zum Anzeigen des Vorhandenseins einer Speicherrnanagementausnahme. In der bevorzugten Ausführungsform der VPU 30 wird der Steuerlogik 66 von der Speicherverarbeitungseinheit 20 gemeldet, wenn eine Speichermanagementausnahme auftritt. Die Einzelheiten dieser Prozedur werden weiter unten erläutert.
  • Vektorspeichermanagement-Ausnahmen enthalten Zugriffssteuerungsverletzungen, Ausnahmen einer ungültigen Übersetzung, Modifizierungsausnahmen und Vektorausrichtungsausnahmen. Vorzugsweise erzeugt die Speicherverarbeitungseinheit 20 Signale, die den Typ der Speichermanagementausnahme identifizieren, obwohl solche Signale ebensogut in der SPU 15 oder in der VPU 30 erzeugt werden könnten. Diese Ausnahmeidentifizierungssignale bilden einen Teil der Zustandsinformationen der VPU 30.
  • Zugriffssteuerungsverletzungen umfassen Versuche der VPU 30, auf geschützte Abschnitte des Speichers oder auf Abschnitte des Speichers außerhalb des dem laufenden Vektorprozeß zugeordneten Speicherraums zuzugreifen. Der laufende Vektorprozeß bezieht sich auf den Prozeß, der die Vektoranweisung enthält, deren Ausführung die Speichermanagementausnahme verursachte. Eine Ausnahme für nicht gültige Übersetzung tritt auf, wenn ein Seitenfehler oder irgendein anderer Versuch, auf einen momentan nicht in der Speicherverarbeitungseinheit 20 befindlichen Abschnitt des Speichers zuzugreifen, vorhanden sind. Eine Modifizierungsausnahme tritt auf, wenn der Zugriff auf eine Seite im Speicher eine Modifikation einer Seite zur Folge hat, die vom laufenden Vektorprozeß zum erstenmal erstellt wird. Vektorausrichtungsausnahmen treten auf, wenn Langwörter (die 4 Bytes belegen) oder Doppellangwörter (die 8 Bytes belegen) nicht in Langwort- bzw. Doppellangwort-Grenzen in der Speicherverarbeitungseinheit 20 fall'n. Eine Vektorausrichtungsausnahme wird auch als Zugriffssteuerungsverletzung angesehen, weil eine ähnliche Software beide Bedingungen handhabt.
  • Falls während der Verarbeitung einer einzelnen Vektoranweisung mehr als eine Art von Speichermanagementausnahmen auftreten, muß eine bestimmte Hierarchie der Handhabung der Ausnahmen befolgt werden. Die höchste Priorität geht an Zugriffssteuerungsausnahmen (und daher an Vektorausrichtungsausnahmen, die ähnlich behandelt werden), weil sie die ernsthaftesten sind. Solche Ausnahmen veranlassen das Datenverarbeitungssystem 10, den laufenden Vektorprozeß aus der Verarbeitung zu entnehmen. Die Ausnahme für nicht gültige Übersetzung besitzt die nächsthöchste Priorität.
  • Die Vektorverarbeitungseinrichtung der vorliegenden Erfindung enthält außerdem eine Vektoranhalteinrichtung zum Anhalten der Ausführung der fehlerhaften Vektorverarbeitungs anweisung durch die Vektorverarbeitungs einrichtung, wenn eine Speichermanagementausnahme auftritt, und zum Ermöglichen daß die Skalarverarbeitungseinrichtung Skalaranweisungen fortgesetzt ausführt. Wenn eine Speichermanagementausnahme auftritt, veranlaßt eine Vektorzustands- und Vektordecodierungslogik 66 die VPU 30, die Ausführung von Vektoranweisungen zu unterbrechen. Dies erfolgt durch Anhalten der Übertragung gültiger Daten an die VPU 30.
  • Gemäß der vorliegenden Erfindung enthält das Datenverarbeitungssystem eine Ausnahmeaufzeichnungseinrichtung zum Aufzeichnen eines Hinweises bezüglich des Auftretens einer Speichermanagementausnahme sowie ausreichender Informationen über den Zustand der Vektorverarbeitungseinrichtung, so daß die Vektorverarbeitungseinrichtung später die Ausführung der Unteroperation der Vektorverarbeitungsanweisung, während der die Speichermanagementausnahme auftrat, wiederaufnehmen kann. In der bevorzugten Ausführungsform dieser Erfindung veranlaßt das Auftreten der Speichermanagementausnahme die SPU 15 und insbesondere die Steuerlogikeinheit 40 in der SPU 15, einen Speichermanagementfehler-Stapelrahmen zu erzeugen, den sie an einer vorgegebenen Stelle in der Speicherverarbeitungseinheit 20 speichert. Die Software für die Handhabung der Speichermanagementausnahme ist so beschaffen, daß sie die den Speichermanagement fehler-Stapelrahmen enthaltende vorgegebene Stelle erkennt, so daß eine geeignete Verarbeitung, die wohlbekannte Routinen enthalten kann, die für die spezifische Ausnahme geeignet sind, schnell fortgesetzt werden kann.
  • Fig. 14 veranschaulicht ein Beispiel eines Speichermanagementfehler-Stapelrahmens 500. Der Stapelrahmen 500 enthält einen Speichermanagement-Fehlercode 510, ein Adressenwort 520, einen Programmzähler PC 530 und ein Programmstatuswort PSL 540.
  • Der Fehlercode 510 enthält vorzugsweise ein Längenbit 511, ein Seitentabellenreferenzbit 512, ein Modifizierungsbit 513, ein Vektorausrichtungsbit 514, ein Vektor- E/A-Bit 515 und ein Bit 516 für eine asynchrone Vektorspeichermanagementausnahme. Das Längenbit 511 wird gesetzt, wenn eine Zugriffssteuerungsverletzung vorliegt, die durch einen Zugriff auf eine Stelle in der Speicherverarbeitungseinheit 20 außerhalb des Speicherraums verursacht wird, der dem die VPU 30 verwendenden Vektorprozeß zugeordnet ist. Das Seitentabellenreferenzbit 512 wird gesetzt, falls während des Zugriffs auf eine Seitentabelle eine Speichermanagementausnahme auftritt. Das Modifizierungsbit 513 wird gesetzt, falls die die Ausnahme verursachende Anweisung ein Schreiben in die Speicherverarbeitungseinheit 20 ist. Das Vektorausrichtungsbit (VAL- Bit) 514 wird gesetzt, wenn die Ausnahme durch die Fehlausrichtung eines Vektorelements bedingt ist. Das Vektor-E/A-Bit (Vb-Bit) 515 wird gesetzt, wenn während der Bezugnahme einer Vektoranweisung auf eine Adresse im E/A-Raum eine Zugriffssteuerungsverletzung auftritt. Das Bit 516 für eine asynchrone Vektorspeichermanagementausnahme (VAS-Bit) wird gesetzt, wenn eine Vektorprozessor- Speichermanagementausnahme bei Implementierung eines asynchronen Speichermanagements auftritt.
  • Während des synchronen Speichermanagements werden Ausnahmen sofort gehandhabt, woraufhin die Ausführung der fehlerhaften Anweisung erneut begonnen wird. Die Anweisung wird erneut begonnen, indem die Vektorspeicherzugriffanweisung bis zum Beginn gesichert wird. An diesem Punkt beginnt ein Speichermanagementfehler, wobei der Wert im PC 530 die fehlerhafte Vektorspeicherzugriffsanweisung identifiziert. Das VSAR 400 wird während der synchronen Speichermanagementausnahmen ignoriert, weil Speichermanagementausnahmen gleich bei ihrem Auftreten gehandhabt werden, so daß kein Bedarf an einer Speicherung von Zustandsinformationen der VPU 30 besteht.
  • Die Adresse 520 im Stapelrahmen 500 repräsentiert eine virtuelle Adresse in derjenigen Seite in der Speicherverarbeitungseinheit 20, in der die Ausnahme auftrat. Der PC 530 ist der Programmzähler in der Anweisung, die die Ausnahme auslöste. Es wird darauf hingewiesen, daß die die Ausnahme auslösende Ausnahme von der den Vektorspeicherzugriff ausführenden Anweisung im Fall des asynchronen Speichermanagements verschieden ist. Das PSL 540 ist ein Programmstatuswort für die SPU 15.
  • Wie oben erläutert worden ist, kann während des asynchronen Speichermanagements nicht nur die SPU 15 skalare Anweisungen gleichzeitig mit der VPU 30 ausführen, sondern die VPU 30 kann Vektorarithmetikanweisungen zusammen mit einer Vektorspeicherzugriffanweisung ausführen. Falls in Implementierungen, die ein asynchrones Speichermanagement verwenden, eine Speichermanagementausnahme auftritt, ergreift die VPU 30 Schritte, um ihren Zustand einzufrieren, so daß der Zustand gespeichert und später wieder aufgerufen werden kann, um die Verarbeitung an dem Punkt, an dem die Ausnahme auftrat, wieder aufzunehmen.
  • Genauer führt die Decodierungs- und Steuerlogik 66 dann, wenn die VPU 30 eine Vektorspeicherzugriffsanweisung ausführt, mehrere Unteroperationen aus, die für die Implementierung einer solchen Anweisung notwendig sind. Beispielsweise führt die Decodierungs- und Steuerlogik 66 für eine Vektorladeoperation für jedes Vektorelement vom 0-ten Element bis zum n-ten Element (n = Inhalte des VLR 82 - 1) die folgenden Unteroperationen aus:
  • 1. Implementieren irgendwelcher Maskierungs funktionen;
  • 2. Prüfen der Vektorausrichtung; und
  • 3. Laden des entsprechenden Vektorelements mit den Inhalten an der nächsten Stelle der Speicherverarbeitungseinheit 20 beginnend bei einer Adresse, die von einem Operanden der Vektorspeicherzugriffsanweisung erzeugt wird.
  • Zu jedem Vektorregister, das an der Ausführung einer Vektoranweisung beteiligt ist, gehört einer von mehreren Zählern 44 in der Vektorregistersteuerlogik 60, der von n bis 0 herabzählt, wenn die Unteroperationen ausgeführt werden, und der für die zugeordneten Vektorelemente im zugeordneten Vektorregister eine Adresse erzeugt. Falls eine Vektoranweisung aufgrund einer Speichermanagementausnahme angehalten wird, gibt der Wert eines der Zähler 44, der der fehlerhaften Anweisung zugehört, die Unteroperation an, bei der die Ausnahme auftrat. Dieser Wert sowie der Zähler, der zu irgendeiner anderen nicht beendeten Anweisung gehört, werden als Teil der Zustandsinformationen der VPU 30 gespeichert. Wenn die VPU 30 mit den gespeicherten Zustandsinformationen erneut geladen wird und wenn der Speichermanagementfehler aufgerufen wird, werden die Zähler 44 mit den Unteroperationswerten erneut geladen, so daß die Ausführung der fehlerhaften Anweisung und sämtlicher nicht beendeter Anweisungen dort beginnen kann, wo die Ausnahme auftrat. Diese Hardware ist in der US-Anmeldung mit der lfd. Nr. 093,499 genauer gezeigt.
  • Falls während der Verarbeitung einer Vektorspeicherzugriffanweisung die Speicherverarbeitungseinheit 20 der Vektordecodierungs- und Vektorsteuerlogik 66 eine Speichermanagementausnahme meldet, setzt die Logik 66 das PMF-Bit 260 und das MF-Bit 250 des VPSR 200. Die VPU 30 informiert jedoch die SPU 15 nicht über die Ausnahmebedingung, so daß sie der SPU 15 erlaubt, weiterhin ihre skalaren Anweisungen zu verarbeiten.
  • Weiterhin erlaubt die Logik 66 der VPU 30, die Ausführung irgendwelcher Vektoranweisungen, die bei Auftreten der Ausnahme begonnen hatten, zu beenden, solange diese Vektoranweisungen keine Quelldaten verwenden, deren Gültigkeit durch die Ausnahmebedingung beeinflußt sein könnte. Dies geschieht durch Untersuchen der Qüell- und Zielregister. Wie oben mit Bezug auf Fig. 3 erläutert worden ist, identifizieren die Adressengeneratoren 108, 109, 110 die Vektorregister in der Vektorregisterdatei 35, die die Daten für die Vektoranweisung enthalten. Diese Adressengeneratoren identifizieren auch das Vektorregister, das die Ergebnisse der Vektoranweisungen empfängt. Falls die Logik 66 bestimmt, daß die Zielregisterwerte für eine fehlerhafte Anweisung gleich den Quellregisterwerten für eineweitere Anweisung sind, wird diese andere Anweisung ebenfalls angehalten.
  • Die Speichermanagementanweisung wird nicht weiter behandelt, bis die SPU 15 zum nächstenmal versucht, eine Vektoranweisung zur VPU 30 zu senden. Zu diesem Zeitpunkt beginnt die SPU 15 mit der Ausführung einer Prozedur, um die Vektoranweisung zur VPU 30 zu senden, wofür das bevorzugte Verfahren durch das Flußdiagramm in Fig. 15 gezeigt ist.
  • Vor dem Senden einer Vektoranweisung zur VPU 30 prüft die SPU 15 zunächst das VEN-Bit 210, um festzustellen, ob die VPU 30 deaktiviert ist (Schritt 700). Die SPU 15 arbeitet daher als Anweisungsblockierungseinrichtung gemäß der vorliegenden Erfindung, um die Weiterleitung von Vektoranweisungen zur VPU 30 zu verhindern, wenn das VEN-Bit 210 anzeigt, daß die VPU 30 deaktiviert ist. Wenn dies der Fall ist, schließt die SPU 15 darauf, daß etwas anderes als eine Speichermanagementausnahme aufgetreten ist (wenigstens in der bevorzugten Ausführungsform), und erzeugt für einen Vektorprozessordeaktivierungs-Fehler eine Falle (710). Die Routine für die Handhabung dieses Fehlers wird in der folgenden Beschreibung der Arithmetikhandling-Ausnahmen diskutiert. Eine Einrichtung zum Erfassen, ob die VPU 30 deaktiviert ist, und zum Stellen der Falle sind in verschiedenen Schaltungsanordnungen oder Abschnitten eines Mikrocodes in der Steuerlogikeinheit 40 der SPU 15 enthalten.
  • Falls die VPU 30 nicht deaktiviert ist, prüft die SPU 15 anschließend das PMF-Bit 260 (Schritt 720). Falls das PMF-Bit 260 gesetzt ist, ist eine Speichermanagementausnahme aufgetreten, über die nicht berichtet worden ist. Die SPU 15 setzt dieses Bit zurück (Schritt 730) und tritt in eine Speichermanagementfehler-Handhabung ein, um die Vektorprozessorspeichermanagement-Ausnahme zu verarbeiten (Schritt 735). Diese Fehlerhandhabung ist eine Standard-Speichermanagement-Fehlerhandhabung, die den Fachleuten wohlbekannt ist.
  • Falls das PMF 260 nicht gesetzt ist (Schritt 720), prüft die SPU 15 anschließend das MF-Bit 250 (Schritt 740). Falls das MF-Bit 250 gesetzt ist, was anzeigt, daß die Ursache für die Speicherausnahme korrigiert worden ist, daß jedoch die die Ausnahme verursachende Unteroperation noch nicht ausgeführt worden ist, löscht die SPU 15 das MF-Bit (Schritt 743) und startet die VPU 30 erneut, um die fehlerhafte Speicherbezugnahme erneut zu versuchen (Schritt 746).
  • Nachdem die VPU 30 erneut gestartet worden ist oder falls das MF-Bit 250 nicht gesetzt war, wird eine (nicht gezeigte) Anweisungswarteschlange für die VPU 30 geprüft, um festzustellen, ob sie voll ist (Schritt 750). Wenn dies der Fall ist, wird erneut in die Prozedur von Fig. 15 eingetreten. Falls die Warteschlange der VPU 30 nicht voll ist, gibt die SPU 15 die nächste Anweisung aus (Schritt 760), die die anhängige Vektoranweisung ist, die ursprünglich die Speichermanagementausnahme auslöste.
  • 3. Arithmetikausnahmen
  • Im Gegensatz zur Situation von Vektorspeichermanagementausnahmen werden Vektoranweisungen, die auf Vektorarithmetikausnahmen treffen, stets bis zum Ende ausgeführt. Falls eine Arithmetikausnahme auftritt, wird in das entsprechende Vektorregisterelement entweder eine Voreinstellung oder ein abgeschnittenes Ergebnis geschrieben. Der Typ der Arithmetikausnahmebedingung und die Nummer des Zielregisters werden in dem Ausnahmebedingungsverzeichnis-Feld 320 des VAER 300 aufgezeichnet. Die Maskierungseinheit 90 in der VPU 30 liest dann das EXC- Bit 174 der Vektoranweisung, um zu bestimmen, ob Ausnahmen möglich sind. Wie oben erläutert worden ist, ermöglicht dieses Bit Ausnahmen eines Gleitkommaunterlaufs und eines Ganzzahlüberlaufs.
  • Falls das EXC-Bit 174 für eine Anweisung gesetzt ist, die einen Gleitkommaunterlauf oder einen Ganzzahlüberlauf bewirkt, sendet die VPU 30 einen einer Voreinstellung vorbehaltenen Operandenwert für den Gleitkommaunterlauf oder die niedrigerwertigen Bits für einen Ganzzahlüberlauf zum geeigneten Zielregisterelement, löscht das VEN-Bit 210 des VPSR 200 und speichert die geeigneten Arithmetikausnahmeinformationen im VAER 300. Die VPU 30 fährt mit der Verarbeitung fort. Die VPU 30 folgt derselben Prozedur für Arithmetikausnahmen eines Gleitkommaüberlaufs, einer Gleitkommadivision durch 0 und eines der Gleitkommaoperation vorbehaltenen Operanden, die nicht deaktiviert werden können.
  • Die 16 Bits des Vektorzielregistermaskierungs-Feldes 310 des VAER 300 geben an, welche der 16 Vektorregister aufgrund des Auftretens von Arithmetikausnahmen einen Voreinstellungswert empfangen haben. Die Typen der Arithmetikausnahmen enthalten einen Gleitkommaunterlauf, eine Gleitkommadivision durch 0, einen der Gleitkommaoperation vorbehaltenen Operanden, einen Gleitkommaüberlauf und einen Ganzzahlüberlauf. Wenn eine Vektorarithmetikausnahme auftritt, deaktiviert sich die VPU 30 selbst. Die VPU 30 beendet die Ausführung der die Ausnahme verursachenden Vektoranweisung sowie irgendwelcher anderer bereits in der VPU 30 befindlicher Anweisungen, sie weigert sich dann jedoch, nachfolgende Vektoranweisungen von der SPU 15 anzunehmen, bis sie wieder aktiviert worden ist. Die VPU 30 wird durch Schreiben einer 0 für das VEN-Bit 210 in das VPSR 200 deaktiviert.
  • Falls die SPU 15 später versucht, eine Vektoranweisung zur VPU 30 zu senden, wenn diese deaktiviert ist, tritt ein Vektorprozessordeaktivierungs-Fehler auf.
  • 4. Kontextumschaltung und Anweisungsdecodierung
  • Speichermanagementausnahmen und Arithmetikausnahmen sind am schwersten zu handhaben, falls die VPU 30 und die SPU 15 Anweisungen von abwechselnd ausgeführten Prozessen oder Programmen ausführen. Diese Bedingung tritt immer dann auf, wenn eine Kontextumschaltung stattgefunden hat. Im allgemeinen ist während der Kontextumschaltung ein großer System-"Aufwand" erforderlich, wobei selbst kleine Einsparungen ein Datenverarbeitungssystem effizienter machen.
  • Fig. 16 zeigt ein Flußdiagramm eines bevorzugten Algorithmus, der während einer Kontextumschaltung ausgeführt wird, wenn die Ausführung eines Prozesses der "letzter Prozeß" genannt wird, angehalten wird und die Ausführung eines neuen Prozesses, der "laufender Prozeß" genannt wird, begonnen wird. Sobald eine Kontextumschaltung auftritt (Schritt 800), wartet die SPU 15, bis die VPU 30 nicht mehr beschäftigt ist (Schritt 810). Ein nicht beschäftigter Zustand wird durch das BSY-Bit 290 des VPSR 200 angezeigt, wenn es den Wert 0 besitzt. Sobald die VPU 30 nicht beschäftigt ist, sichert die SPU 15 nur die Skalarzustandsinformationen des letzten Prozesses (Schritt 802). Diese Zustandsinformationen werden durch Speichern an Stellen in der Speicherverarbeitungseinheit 20 gesichert, die dem letzten Prozeß entsprechen. Die SPU 15 enthält ihr eigenes Prozeßstatusregister (siehe PSL 540 in Fig. 14), deren Inhalte als Teil des Schrittes der Sicherung des letzten Zustands der SPU 15 gesichert wurden. Während dieses Schrittes werden auch die Inhalte sämtlicher Register der SPU 15 gesichert.
  • Die Zustandsinformationen der VPU 30 werden zu diesem Zeitpunkt nicht gespeichert. Dies verzögert oder beseitigt den Aufwand, der hervorgerufen wird, wenn die Zustandsinformationen der VPU 30 gespeichert werden. Die Speicherung der Zustandsinformationen der VPU 30 würden nicht nur die Speicherung des VPSR 200 des VAER 300, des VSAR 400 und der anderen Systemregister erfordern, sondem es würde die Speicherung der 16 Vektorregister mit jeweils 64 Elementen erfordern, die einen großen Teil der Systembetriebsmittel beanspruchen würden, was erheblicher ist.
  • Dann deaktiviert die SPU 15 die VPU 30, indem sie das VEN-Bit 210 im VPSR 200 löscht (Schritt 804). Das Löschen des VEN-Bits 210 verhindert, daß der laufende Prozeß eine Vektoranweisung ausführt, ohne daß dies einen Vektorprozessordeaktivierungs-Fehler zur Folge hätte. Tatsächlich braucht der Zustand der VPU 30 für den letzten Prozeß, wie weiter unten genauer erläutert werden wird, während der Ausführung des laufenden Prozesses nicht gespeichert werden, falls der laufende Prozeß keine Vektoranweisung ausführt.
  • Anschließend werden von Stellen in der Speicherverarbeitungseinheit 20, die dem laufenden Prozeß entsprechen, Skalarzustandsinformationen des laufenden Prozesses geladen (Schritt 806), woraufhin der laufende Prozeß mit der Ausführung beginnt (Schritt 808). Da der Vektorzustand des laufenden Prozesses während einer Kontextumschaltung nicht geladen wird, enthält die VPU 30 die Zustandsinformationen des letzten Prozesses, um eine Vektoranweisung auszuführen. Dieser Zustand ist jedoch für den laufenden Prozeß nicht zugänglich, weil die VPU 30 deaktiviert ist.
  • Fig. 17 zeigt ein Flußdiagramm eines bevorzugten Algorithmus, der jedesmal ausgeführt werden muß, wenn ein Prozeß mit der Ausführung einer neuen Anweisung beginnt. Vorzugsweise werden die in Fig. 17 gezeigten Schritte in der SPU 15 ausgeführt. Falls die Anweisung eine privilegierte Anweisung ist (Schritt 900) und die SPU 15 sich nicht im privilegierten Modus befindet (Schritt 902), tritt eine Falle für illegale Anweisung auf (Schritt 904), woraufhin der in Fig. 17 gezeigte Algorithmus beendet ist. Die Prozedur für die Handhabung der Falle für illegale Anweisung ist in nahezu jedem Datenverarbeitungssystem, das privilegierte Anweisungen enthält, üblich und liegt im Bereich des Wissens des Fachmanns.
  • Falls die Anweisung eine privilegierte Anweisung ist (Schritt 900) und die SPU 15 sich im privilegierten Modus befindet (Schritt 902), wird die Anweisung ausgeführt (Schritt 905).
  • Falls die Anweisung keine privilegierte Anweisung ist (Schritt 900) und keine Vektoranweisung ist (Schritt 908), führt die SPU 15 die Anweisung aus (Schritt 910). Falls jedoch die Anweisung eine Vektoranweisung ist (Schritt 908), prüft der Mikrocode in der Steuerlogikeinheit 40 das VEN-Bit 210 des VPSR 200 (Schritt 912). Falls das VEN-Bit 210 gesetzt ist, was anzeigt, daß die VPU 30 aktiv ist, führt die VPU 30 die Anweisung aus (Schritt 914).
  • Falls das VEN-Bit 210 nicht gesetzt ist (Schritt 912), tritt ein Vektorprozessordeaktivierungs-Fehler auf (Schritt 916). Wie oben erläutert worden ist, wird das VEN-Bit 210 nicht gesetzt, wenn der laufende Prozeß eine Vektoranweisung noch nicht ausgeführt hat oder falls eine Arithmetikausnahmebedingung auftritt. Falls der laufende Prozeß versucht, eine Vektoranweisung auszuführen, wenn das VEN-Bit 210 nicht gesetzt ist, muß das System sicherstellen, daß der Vektorzustand des laufenden Prozesses in den Speicher eingeblendet worden ist und daß irgendwelche Ausnahmebedingungen verarbeitet werden, bevor die Vektoranweisung des laufenden Prozesses ausgeführt wird.
  • Fig. 18 zeigt ein Flußdiagramm eines bevorzugten Algorithmus für die Verarbeitung eines Vektorprozessordeaktivierungs-Fehlers, wie er im Schritt 916 von Fig. 17 gezeigt ist. Der Zweck dieses Algorithmus ist dreifach: (1) um irgendwelche Vektorausnahmebedingungen zu verarbeiten; (2) um sämtliche Zustandsinformationen der VPU 30 aus dem Prozeß, der zuletzt eine Vektoranweisung ausführte, zu speichern; und (3) um die Zustandsinformationen der VPU 30 für den laufenden Prozeß wiederzugewinnen. Die Positionen (2) und (3) sind nicht notwendig, falls der laufende Prozeß gleich dem Prozeß ist, der die VPU 30 zuletzt benutzt hatte. Die Position (1) ist nur notwendig, wenn eine Ausnahmebedingung anhängig ist. Es ist jedoch möglich, daß die Positionen (1), (2) und (3) alle beendet sein müssen, bevor der momentan ausgeführte Prozeß eine Vektoranweisung ausführt.
  • Der erste Schritt in der Operation für Vektorprozessordeaktivierungs-Fehler besteht darin festzustellen, ob der laufende Prozeß auch der letzte Prozeß ist, der die VPU 30 verwendet hat, um eine Vektoranweisung auszuführen (Schritt 1000), indem die Prozeßidentifizierungsnummern verglichen werden, die an den Speicherstellen gespeichert sind, die durch Identifizierer des laufenden Prozesses und des letzten Prozesses bezeichnet sind. Alternativ kann diese Operation auch durch spezielle Hardwareregister, die in der SPU 15 vorgesehen sind, ausgeführt werden. Falls die Bestimmung im Schritt 1000 "JA" lautet, ist es nicht notwendig, die Zustandsinformationen für die VPU 30 zu aktualisieren. Falls die Bestimmung im Schritt 1000 "JA" lautet, wird festgestellt, ob irgendwelche Arithmetik- oder Speichermanagement-Ausnahmebedingungen anhängig sind (Schritt 1002). Wie oben erläutert worden ist, verarbeitet das Datenverarbeitungssystem 10 im Gegensatz zu Systemen des Standes der Technik die Ausnahmen nicht, wenn sie auftreten, sondern verarbeitet sie, wenn die VPU 30 wieder verwendet wird. Dies kann der gleiche Zeitpunkt sein, zu dem die VPU 30 ihre Vektorzustandsinformationen sichert und die Vektorzustandsinformationen für den laufenden Prozeß wiedergewinnt. Das Vorhandensein von Ausnahmebedingungen wird durch die Untersuchung des PMF-Bits 260 (Speichermanagementausnahmen) und des AEX- Bits 270 (Arithmetikausnahmen) des VPSR 200 durch die SPU 15 bestimmt.
  • Wenn eine Arithmetikausnahme anhängig ist, wird das AEX- Bit 270 gelöscht (Schritt 1003), ferner wird die Ausnahme in einer Weise verarbeitet (Schritt 1004), die für die Ausnahme geeignet ist und mit einer Prozedur übereinstimmt, die den Fachleuten im Gebiet der Datenverarbeitung bekannt ist. Falls keine Arithmetikausnahmebedingung anhängig ist (Schritt 1002), kann es notwendig sein festzustellen, ob eine Kontextumschaltung seit dem letzten Vektorprozessordeaktivierungs-Fehler aufgetreten ist. Selbst wenn der laufende Prozeß gleich dem Prozeß ist, der zuletzt die VPU 30 verwendete (Schritt 1000), so daß kein Bedarf an einer Sicherung oder Wiederherstellung von Vektorzustandsinformationen der VPU 30 besteht, kann es notwendig sein, Register in der VPU 30 zu aktualisieren, die durch die normale Skalarverarbeitung beeinflußt werden. Falls die VPU 30 beispielsweise Kopien von in der SPU 15 befindlichen Speichermanagementregistern enthält, würden die Register in der VPU 30 nach jeder Kontextumschaltung aktualisiert werden müssen, um sicherzustellen, daß ihre Inhalte mit den Inhalten der Register der SPU 15 übereinstimmen.
  • Dann wird die VPU 30 aktiviert, indem das VEN-Bit 210 gesetzt wird (Schritt 1010). Die Steuerung kehrt dann zum Schritt B des Anweisungsdecodierungsalgorithmus von Fig. 17 zurück (Schritt 1012), ferner beginnt der laufende Prozeß mit der Ausführung einer neuen Anweisung.
  • Falls 4er laufende Prozeß nicht gleich dem Prozeß ist, der zuletzt die VPU 30 benutzte (Schritt 1000), treten mehrere Schritte auf. Die SPU 15 wartet zunächst, bis die VPU 30 keine Vektoranweisung ausführt (Schritt 1014). Dieser Nicht-Beschäftigt-Zustand wird durch einen Wert des BSY-Bits 290 des VPSR 200 angezeigt. Zweitens wird festgestellt, ob irgendwelche Arithmetikausnahmen anhängig sind (Schritt 1016). Falls das AEX-Bit 270 des VPSR 200 gesetzt ist, was anzeigt, daß eine Arithmetikausnahme anhängig ist, wird der Arithmetikausnahmezustand, der im VAER 300 enthalten ist, gesichert, ferner wird das Vorhandensein einer Arithmetikausnahme für den letzten Prozeß, der die VPU 30 verwendet, für eine spätere Verarbeitung vorgemerkt (Schritt 1018). Die Vormerkung einer solchen Ausnahme wird vorzugsweise über einen Software-Merker erzielt, der dem letzten die VPU 30 verwendenden Prozeß zugeordnet ist.
  • Der nächste Schritt besteht darin festzustellen, ob eine asynchrone Speichermanagementausnahme anhängig ist (Schritt 1020). Falls eine solche Ausnahme anhängig ist, was durch den Wert 1 im MF-Bit 250 des VPSR 200 angezeigt wird, wird vorzugsweise ein Software-Merker, der dem letzten die VPU 30 verwendenden Prozeß zugeordnet ist, gesetzt, ferner werden die implementierungsspezifischen Vektorinformationen für diesen Prozeß gesichert (Schritt 1022).
  • Dann wird die VPU 30 aktiviert, indem das VEN-Bit 210 des VPSR 200 gesetzt wird, außerdem wird die VPU 30 durch Setzen des RST-Bits 200 des VPSR 300 zurückgesetzt (Schritt 1024). Da der momentane Prozeß nicht gleich dem Prozeß ist, der die VPU 30 zuletzt benutzte (Schritt 1000), müssen die Zustandsinformationen für die VPU 30 aktualisiert werden. Dies erfolgt in zwei Schritten. Zunächst werden die Zustandsinformationen der VPU 30 in einem Bereich der Speicherverarbeitungseinheit 20 gespeichert, der dem Prozeß entspricht, der zuletzt die VPU 30 benutzte (Schritt 1026). Es können auch Speichermanagementregister in der SPU 15 und entsprechende Speichermanagementregister in der VPU 30 vorgesehen sein, um Funktionen einer virtuellen Adressierung und eines Speicherschutzes auszuführen. In diesem Fall kann es notwendig sein, daß die Speichermanagementregister in der VPU 30 aktualisiert werden müssen, um sicherzustellen, daß sie mit den entsprechenden Speichermanagementregistern in der SPU 15 übereinstimmen. Dann werden die Zustandsinformationen für die VPU 30 für den laufenden Prozeß aus dem Bereich der Speicherverarbeitungseinheit 20, der dem laufenden Prozeß entspricht, wiedergewonnen und in den Vektorregistern der VPU 30 gespeichert (Schritt 1027), ferner wird die Identifizierungsnummer des laufenden Prozesses an der Speicherstelle oder in dem speziellen Hardwareregister gespeichert, das für die Identifizierung des letzten Vektorprozesses vorgesehen ist.
  • Anschließend wird ein Software-Merker, der dem laufenden Prozeß zugeordnet ist, geprüft, um festzustellen, ob eine asynchrone Speichermanagementausnahme für den laufenden Prozeß anhängig ist (Schritt 1028). Falls eine solche Ausnahme anhängig ist, wird der Software-Merker für den laufenden Prozeß gelöscht, ferner wird der Vektorzustand zu diesem Zeitpunkt der asynchronen Speichermanagementausnahme ausgelesen (Schritt 1030). Dies wird durch Schreiben der Adresse der gesicherten Vektorzustandsinformationen in das VSAR 400 und durch Setzen des RLD-Bits 240 und des VEN-Bits 210 des VPSR 300 erzielt, wie oben in dem die Register der VPU 30 beschreibenden Abschnitt diskutiert worden ist.
  • Anschließend wird ein Software-Merker, der dem laufenden Prozeß zugeordnet ist, geprüft, um festzustellen, ob eine Arithmetikausnahme für den laufenden Prozeß anhängig ist (Schritt 1032). Falls eine solche Ausnahme anhängig ist, wird das VEN-Bit 210 des VPSR 300 gelöscht, wodurch die VPU 30 deaktiviert wird, außerdem wird die Arithmetikausnahme ähnlich wie im Schritt 1004 in einer Weise verarbeitet, die mit einer Prozedur übereinstimmt, die den Fachleuten im Gebiet der Datenverarbeitung wohlbekannt ist (Schritt 1034).
  • Wenn der Algorithmus für die Handhabung des Vektorprozessordeaktivierungs-Fehlers von Fig. 18 abgeschlossen ist (Schritt 1036), kehrt die Steuerung zum Schritt B des Anweisungsdecodierungsalgorithmus von Fig. 17 zurück, woraufhin der laufende Prozeß mit der Ausführung einer neuen Anweisung beginnt.
  • Die Kontextumschaltung, die für Vektorprozessoren eine aufwendige Operation sein kann, wird daher erheblich vereinfacht. Der ein solches Umschalten begleitende Aufwand wird solange verzögert, bis er nicht mehr länger notwendig ist.

Claims (13)

1. Multitasking-Datenverarbeitungssystem (10) für die abwechselnde Ausführung von Abschnitten mehrerer Prozesse, die aus Anweisungsfolgen bestehen, die Vektoranweisungen, welche Datenverarbeitungsoperationen für Vektorgrößen verwenden, und Skalaranweisungen, die Datenverarbeitungsoperationen für Nicht-Vektorgrößen verwenden, enthalten können, wobei einer der mehreren Prozesse, der momentan vom Datenverarbeitungssystem ausgeführt wird, laufender Prozeß genannt wird und wobei das Datenverarbeitungs system enthält:
einen Speicher (20) mit mehreren Abschnitten, wovon jeder einem anderen Prozeß entspricht;
eine Skalarverarbeitungsvorrichtung (15) zum Ausführen von Skalaranweisungen;
eine Vektorverarbeitungsvorrichtung (13) zum Ausführen von Vektoranweisungen in den Prozessen, wobei die Vektorverarbeitungsvorrichtung eine Vektorzustandsvorrichtung (35) enthält, um Zustandsinformationen zu speichern, die einen Ausführungszustand der Vektorverarbeitungsvorrichtung beschreibt;
eine Anweisungsdecodierungsvorrichtung (50), die mit der Skalarverarbeitungsvorrichtung und der Vektorverarbeitungsvorrichtung gekoppelt ist, um die Skalaranweisungen und Vektoranweisungen in den Prozessen zu identifizieren und der Skalarverarbeitungsvorrichtung bzw. der Vektorverarbeitungsvorrichtung zuzuführen;
eine Vektoranweisungs- Identifizierungsvorrichtung (15), die mit der Anweisungsdecodierungsvorrichtung (50) gekoppelt ist, um zu erkennen, wenn der laufende Prozeß eine Vektoranweisung ausführt;
und gekennzeichnet durch:
eine Letzter-Benutzer-Anzeigevorrichtung (15, 30) zum Identifizieren eines letzten Vektorbenutzer-Prozesses der Prozesse, für den die Vektorverarbeitungsvorrichtung zuletzt eine Vektor-Anweisung ausgeführt hat; und
eine Sicherungsvorrichtung (15), die mit der Vektoranweisungs-Identifizierungsvorrichtung und der Letzter-Benutzer-Anzeigevorrichtung gekoppelt ist, um das Datenverarbeitungssystem zu veranlassen, die Vektorzustandsinformationen im Speicher (20) an einer Stelle zu speichern, die dem letzten Vektor-Benutzer-Prozeß zugeordnet ist, wenn die Vektoranweisungs-Identifizierungsvorrichtung erkennt, daß der laufende Prozeß eine Vektoranweisung ausführt und der letzte Vektorbenutzer-Prozeß vom laufenden Prozeß verschieden ist.
2. Datenverarbeitungssystem nach Anspruch 1, das ferner enthält:
eine Wiederherstellungsvorrichtung (15), die mit der Sicherungsvorrichtung gekoppelt ist, um das Datenverarbeitungssystem zu veranlassen, die Inhalte eines Abschnitts des Speichers, die dem laufenden Prozeß zugeordnet sind, in die Vektorzustandsvorrichtung zu speichern.
3. Datenverarbeitungssystem nach Anspruch 1, das ferner enthält:
eine Kontext-Umschaltvorrichtung (15) zum Erkennen, wenn das Datenverarbeitungssystem beginnt, einen neuen Prozeß der mehreren Prozesse auszuführen.
4. Datenverarbeitungsvorrichtung nach Anspruch 1, in der die Datenverarbeitungsvorrichtung eine Vektorsperrvorrichtung (210) enthält, um die Vektorverarbeitungsvorrichtung zu sperren, ohne die Skalarverarbeitungsvorrichtung nachteilig zu beeinflussen, bevor die Datenverarbeitungsvorrichtung beginnt, einen neuen Prozeß der mehreren Prozesse auszuführen, und
in der die Vektoranweisungs Identifizierungsvorrichtung (15) eine Vorrichtung zum Überprüfen der Vektorverarbeitungsvorrichtung (30) enthält, um zu prüfen, ob diese gesperrt ist.
5. Datenverarbeitungssystem nach Anspruch 3, das ferner enthält:
eine Skalarzustandsvorrichtung in der Skalarverarbeitungsvorrichtung (15), um Skalarzustandsinformationen zu speichern, die einen Ausführungszustand der Skalarverarbeitungsvorrichtung beschreiben; und
eine Skalarsicherungsvorrichtung, um das Datenverarbeitungssystem zu veranlassen, die Skalarzustandsinformationen im Speicher (20) in einem der Abschnitte zu speichern, der dem laufenden Prozeß zugeordnet ist, wenn das Datenverarbeitungssystem die Ausführung des laufenden Prozesses beendet.
6. Datenverarbeitungssystem nach Anspruch 5, das ferner enthält:
eine Skalarwiederherstellungsvorrichtung, die mit der Skalarsicherungsvorrichtung gekoppelt ist, um das Datenverarbeitungssystem zu veranlassen, in die Skalarzustandsvorrichtung neue Skalar-Zustandsinformationen zu speichern, die in einem Abschnitt des Speichers gespeichert sind, der dem neuen auszuführenden Prozeß zugeordnet ist.
7. Verfahren zum Verwalten eines Multitasking- Datenverarbeitungssystems (10), das abwechselnd Abschnitte mehrerer Prozesse ausführt, die Vektoranweisungen, welche eine Datenverarbeitung von Vektorgrößen verwenden, und Skalaranweisungen, welche eine Datenverarbeitung von Nicht-Vektor-Prozessen verwenden, enthält, wobei der momentan ausgeführte Prozeß der mehreren Prozesse laufender Prozeß genannt wird, wobei das Datenverarbeitungssystem einen Skalarprozessor und einen Vektorprozessor enthält, und wobei das Verfahren die folgenden vom Datenverarbeitungssystem ausgeführten Schritte umfaßt:
a) Ausführen der Vektoranweisungen im Vektorprozessor (30);
b) Ausführen der Skalaranweisungen im Skalarprozessor (15) unabhängig von der Ausführung der Vektoranweisungen im Vektorprozessor;
c) Speichern der Vektorprozessor-Vektorzustandsinformationen, die einen Ausführungszustand des Vektorprozessors für einen letzten Vektorprozeß beschreiben, der ein Prozeß mit den zuletzt ausgeführten Vektoranweisungen ist;
und gekennzeichnet durch die weiteren Schritte
d) Fortsetzen (808) der Ausführung der Skalaranweisungen im Skalarprozessor, nachdem der Vektorprozessor die Ausführung (801) einer letzten Vektoranweisung des letzten Vektorprozesses abgeschlossen hat, bis eine nächste Vektoranweisung im laufenden Vektorprozeß auszuführen ist; und
e) Speichern (1026) von Vektorzustandsinformationen für den letzten Vektorprozeß in einem Speicher (20) und Zurückspeichern der Vektorzustandsinformationen für den laufenden Prozeß aus dem Speicher in den Vektorprozessor, wenn der laufende Prozeß nicht derselbe Prozeß ist wie der letzte Vektorprozeß (1000), wenn die nächste Vektoranweisung ausgeführt werden soll.
8. Verfahren nach Anspruch 7, das ferner die Schritte enthält:
Sperren (804) des Vektorprozessors, wenn der letzte Vektorprozeß zurückgestellt wird;
Verarbeiten (916) eines Vektorprozessor-Sperrfehlers, wenn die nächste Vektoranweisung ausgeführt werden soll und der Vektorprozessor gesperrt ist;
Sichern (1026) des Vektorzustands des letzten Vektorprozesses und Wiederherstellen (1027) des Vektorzustands des laufenden Prozesses, wenn der laufende Prozeß nicht derselbe Prozeß wie der letzte Vektorprozeß ist; und
Freigeben (1010) des Vektorprozessors und erneutes Versuchen (1012), die nächste Vektoranweisung auszuführen, die den Vektorprozessor-Sperrfehler verursacht hat.
9. Verfahren nach Anspruch 7, das die Schritte enthält:
Sichern (802) der Skalarzustandsinformationen, die einen Ausführungszustand des Skalarprozessors (15) beschreiben, im Speicher (20), wenn ein neuer Prozeß der mehreren Prozesse gestartet wird, und
Zurückspeichern (806) der gesicherten Skalarzustandsinformationen, die einen Ausführungszustand des neuen Prozesses beschreiben, aus dem Speicher in den Skalarprozessor.
10. Multitasking-Datenverarbeitungssystem nach Anspruch 1, in dem die Anweisungsdecodierungsvorrichtung einen Anweisungsanalysierer (50) enthält, der seinerseits enthält:
eine Vorrichtung (15) zum Weiterleiten der Vektoranweisungen zur Vektorverarbeitungsvorrichtung (30) über die Skalarverarbeitungsvorrichtung.
11. Multitasking-Datenverarbeitungssystem nach Anspruch 10, in dem die Vektoranweisungs- Identifizierungsvorrichtung in der Skalarverarbeitungsvorrichtung (15) enthalten ist.
12. Multitasking-Datenverarbeitungssystem nach Anspruch 1, in dem die Letzter-Benutzer-Anzeigevorrichtung in der Vektorzustandsvorrichtung (30) enthalten ist.
13. Multitasking-Datenverarbeitungssystem nach Anspruch 4, in dem die Vektor-Sperrvorrichtung (210) in der Vektorzustandsvorrichtung (30) enthalten ist.
DE68927415T 1988-03-18 1989-03-06 Kontextumschaltungsverfahren und -anordnung zur Verwendung in einem Vektorverarbeitungssystem Expired - Fee Related DE68927415T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US07/170,399 US5008812A (en) 1988-03-18 1988-03-18 Context switching method and apparatus for use in a vector processing system

Publications (2)

Publication Number Publication Date
DE68927415D1 DE68927415D1 (de) 1996-12-12
DE68927415T2 true DE68927415T2 (de) 1997-05-28

Family

ID=22619714

Family Applications (1)

Application Number Title Priority Date Filing Date
DE68927415T Expired - Fee Related DE68927415T2 (de) 1988-03-18 1989-03-06 Kontextumschaltungsverfahren und -anordnung zur Verwendung in einem Vektorverarbeitungssystem

Country Status (5)

Country Link
US (1) US5008812A (de)
EP (1) EP0333366B1 (de)
JP (1) JPH0242569A (de)
CA (1) CA1317027C (de)
DE (1) DE68927415T2 (de)

Families Citing this family (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5167028A (en) * 1989-11-13 1992-11-24 Lucid Corporation System for controlling task operation of slave processor by switching access to shared memory banks by master processor
JP2504235B2 (ja) * 1989-11-16 1996-06-05 三菱電機株式会社 デ―タ処理装置
US5623650A (en) * 1989-12-29 1997-04-22 Cray Research, Inc. Method of processing a sequence of conditional vector IF statements
US5197130A (en) * 1989-12-29 1993-03-23 Supercomputer Systems Limited Partnership Cluster architecture for a highly parallel scalar/vector multiprocessor system
US5544337A (en) * 1989-12-29 1996-08-06 Cray Research, Inc. Vector processor having registers for control by vector resisters
US5598547A (en) * 1990-06-11 1997-01-28 Cray Research, Inc. Vector processor having functional unit paths of differing pipeline lengths
US5390329A (en) * 1990-06-11 1995-02-14 Cray Research, Inc. Responding to service requests using minimal system-side context in a multiprocessor environment
WO1992003783A1 (en) * 1990-08-23 1992-03-05 Supercomputer Systems Limited Partnership Method of implementing kernel functions
US5742839A (en) * 1992-01-30 1998-04-21 Fujitsu Limited Coprocessor for performing an arithmetic operation by automatically reading data from an external memory
US5423051A (en) * 1992-09-24 1995-06-06 International Business Machines Corporation Execution unit with an integrated vector operation capability
US5428779A (en) * 1992-11-09 1995-06-27 Seiko Epson Corporation System and method for supporting context switching within a multiprocessor system having functional blocks that generate state programs with coded register load instructions
JP2561801B2 (ja) * 1993-02-24 1996-12-11 インターナショナル・ビジネス・マシーンズ・コーポレイション プロセス・スケジューリングの管理方法およびシステム
US5623698A (en) * 1993-04-30 1997-04-22 Cray Research, Inc. Memory interconnect network having separate routing networks for inputs and outputs using switches with FIFO queues and message steering bits
US5619709A (en) * 1993-09-20 1997-04-08 Hnc, Inc. System and method of context vector generation and retrieval
US5490272A (en) * 1994-01-28 1996-02-06 International Business Machines Corporation Method and apparatus for creating multithreaded time slices in a multitasking operating system
US5666523A (en) * 1994-06-30 1997-09-09 Microsoft Corporation Method and system for distributing asynchronous input from a system input queue to reduce context switches
US5481719A (en) * 1994-09-09 1996-01-02 International Business Machines Corporation Exception handling method and apparatus for a microkernel data processing system
EP1265132A3 (de) * 1994-12-02 2005-02-09 Intel Corporation Mikroprozessor mit Packfunktion für zusammengesetzte Operanden
US5835748A (en) * 1995-12-19 1998-11-10 Intel Corporation Method for executing different sets of instructions that cause a processor to perform different data type operations on different physical registers files that logically appear to software as a single aliased register file
US5852726A (en) * 1995-12-19 1998-12-22 Intel Corporation Method and apparatus for executing two types of instructions that specify registers of a shared logical register file in a stack and a non-stack referenced manner
US5940859A (en) 1995-12-19 1999-08-17 Intel Corporation Emptying packed data state during execution of packed data instructions
US5701508A (en) * 1995-12-19 1997-12-23 Intel Corporation Executing different instructions that cause different data type operations to be performed on single logical register file
US5857096A (en) * 1995-12-19 1999-01-05 Intel Corporation Microarchitecture for implementing an instruction to clear the tags of a stack reference register file
US6792523B1 (en) 1995-12-19 2004-09-14 Intel Corporation Processor with instructions that operate on different data types stored in the same single logical register file
US5812823A (en) * 1996-01-02 1998-09-22 International Business Machines Corporation Method and system for performing an emulation context save and restore that is transparent to the operating system
US5809286A (en) * 1996-05-01 1998-09-15 Mci Communications Corporation Method and apparatus for emulating a dynamically configured digital cross-connect switch network
US5850536A (en) * 1996-05-01 1998-12-15 Mci Communications Corporation Method and system for simulated multi-tasking
US5867689A (en) * 1996-05-01 1999-02-02 Mci Communications Corporation Method and apparatus for emulating a digital cross-connect switch network using a flexible topology to test MCS network management
US5812826A (en) * 1996-06-27 1998-09-22 Mci Communications Corporation Method and apparatus for emulating a network of state monitoring devices
US6061711A (en) * 1996-08-19 2000-05-09 Samsung Electronics, Inc. Efficient context saving and restoring in a multi-tasking computing system environment
US5954829A (en) * 1996-12-30 1999-09-21 Mci Communications Corporation System, method, and computer program product for digital cross connect testing
US5854930A (en) * 1996-12-30 1998-12-29 Mci Communications Corporations System, method, and computer program product for script processing
US6128641A (en) * 1997-09-12 2000-10-03 Siemens Aktiengesellschaft Data processing unit with hardware assisted context switching capability
US6223208B1 (en) 1997-10-03 2001-04-24 International Business Machines Corporation Moving data in and out of processor units using idle register/storage functional units
US5893159A (en) * 1997-10-22 1999-04-06 International Business Machines Corporation Methods and apparatus for managing scratchpad memory in a multiprocessor data processing system
US6230259B1 (en) * 1997-10-31 2001-05-08 Advanced Micro Devices, Inc. Transparent extended state save
US5974532A (en) * 1997-12-09 1999-10-26 Mci Communications Corporation System and method for generating responses for inputs using a hybrid state engine table
US6256659B1 (en) 1997-12-09 2001-07-03 Mci Communications Corporation System and method for performing hybrid preemptive and cooperative multi-tasking in a computer system
US7013467B1 (en) 1997-12-09 2006-03-14 Mci Communications Corporation System and method for managing computer system resources using command control vectors
US6205468B1 (en) * 1998-03-10 2001-03-20 Lucent Technologies, Inc. System for multitasking management employing context controller having event vector selection by priority encoding of contex events
EP1785863A3 (de) * 2000-02-29 2007-07-18 Fujitsu Limited Ein Dividierer mit Übertragsicherstellungsaddierer und Volladdierer
US7162615B1 (en) 2000-06-12 2007-01-09 Mips Technologies, Inc. Data transfer bus communication using single request to perform command and return data to destination indicated in context to allow thread context switch
US8271994B2 (en) * 2006-02-11 2012-09-18 International Business Machines Corporation Reduced data transfer during processor context switching
JP2017037370A (ja) * 2015-08-06 2017-02-16 富士通株式会社 計算機、プロセス制御方法およびプロセス制御プログラム
US10599428B2 (en) * 2016-03-23 2020-03-24 Arm Limited Relaxed execution of overlapping mixed-scalar-vector instructions
GB2548601B (en) 2016-03-23 2019-02-13 Advanced Risc Mach Ltd Processing vector instructions

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4128880A (en) * 1976-06-30 1978-12-05 Cray Research, Inc. Computer vector register processing
US4541046A (en) * 1981-03-25 1985-09-10 Hitachi, Ltd. Data processing system including scalar data processor and vector data processor
JPS57209570A (en) * 1981-06-19 1982-12-22 Fujitsu Ltd Vector processing device
JPS58114274A (ja) * 1981-12-28 1983-07-07 Hitachi Ltd デ−タ処理装置
JPS592143A (ja) * 1982-06-29 1984-01-07 Hitachi Ltd 情報処理装置
US4661900A (en) * 1983-04-25 1987-04-28 Cray Research, Inc. Flexible chaining in vector processor with selective use of vector registers as operand and result registers
US4636942A (en) * 1983-04-25 1987-01-13 Cray Research, Inc. Computer vector multiprocessing control
JPS6015771A (ja) * 1983-07-08 1985-01-26 Hitachi Ltd ベクトルプロセッサ
JPS6069746A (ja) * 1983-09-26 1985-04-20 Fujitsu Ltd ベクトル・デ−タ処理装置の制御方式
US4740893A (en) * 1985-08-07 1988-04-26 International Business Machines Corp. Method for reducing the time for switching between programs
JP2610821B2 (ja) * 1986-01-08 1997-05-14 株式会社日立製作所 マルチプロセツサシステム
JPS62221732A (ja) * 1986-03-24 1987-09-29 Nec Corp 情報処理装置

Also Published As

Publication number Publication date
JPH0242569A (ja) 1990-02-13
EP0333366A3 (de) 1991-05-02
EP0333366A2 (de) 1989-09-20
DE68927415D1 (de) 1996-12-12
CA1317027C (en) 1993-04-27
EP0333366B1 (de) 1996-11-06
US5008812A (en) 1991-04-16

Similar Documents

Publication Publication Date Title
DE68927415T2 (de) Kontextumschaltungsverfahren und -anordnung zur Verwendung in einem Vektorverarbeitungssystem
DE68924546T2 (de) Verfahren und Vorrichtung zur Ausführung von Befehlen für ein Vektorverarbeitungssystem.
DE68928677T2 (de) Verfahren und digitaler Computer zur Vorverarbeitung mehrerer Befehle
DE69131637T2 (de) Registerhaltige Datenbearbeitung in einem Prozessor mit reduziertem Befehlssatz
DE3851488T2 (de) Registerverwaltungssystem mit Ausführung von Befehlen in Unordnung in einem Computerprozessor.
DE69233493T2 (de) RISC-Prozessor mit erweiterbarer Architektur
DE69308548T2 (de) Vorrichtung und verfahren zum befehlsabschluss in einem superskalaren prozessor.
DE69325086T2 (de) Verfahren und System für spekulative Befehlsausführung
DE3751474T2 (de) Verzweigungsstrom-Koprozessor.
DE69622663T2 (de) Zweistufige vorausholungspufferstruktur und verfahren mit bypass
DE69024068T2 (de) Verfahren und Datenverarbeitungseinheit zur Pipeline- Verarbeitung von Register- und Registeränderungs- Spezifizierern in dem gleichen Befehl
DE69329778T2 (de) System und verfahren zur handhabung von laden und/oder speichern in einem superskalar mikroprozessor
DE69115344T2 (de) Vorverarbeitungsprozessor zur Verbindung von Befehlen für einen Cache-Speicher
DE69904189T2 (de) Konfigurierter prozessor zur abbildung von logischen registernummern auf physikalische registernummern unter verwendung von virtuellen registernummern
DE69130379T2 (de) Datenvorausladebefehl in einem Prozessor mit reduziertem Befehlssatz
DE68928513T2 (de) Verfahren zur Vorverarbeitung mehrerer Befehle
DE3685913T2 (de) Vektorenverarbeitung.
DE68927855T2 (de) Verfahren und Datenverarbeitungseinheit zur Vorverarbeitung von implizierten Spezifizierern in einem Pipeline-Prozessor
DE68929215T2 (de) Datenprozessor
DE4206062C2 (de) Pipelineverarbeitung von Instruktionen
DE69233313T2 (de) Hochleistungsarchitektur für RISC-Mikroprozessor
DE68927371T2 (de) Verfahren und Vorrichtung zur Verarbeitung von mehreren Zustandscodes wie für einen Parallel-Pipeline-Rechner
DE69227465T2 (de) Cpu mit pipeline-einheit und effektiv-adressenrechnungseinheit mit möglichkeit zur beibehaltung von virtuellen operandenadressen.
DE69506623T2 (de) Datenprozessor mit einer Ausführungseinheit zur Durchführung von Ladebefehlen und Verfahren zu seinem Betrieb
DE69331448T2 (de) Dataprozessor mit einem Cachespeicher

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee