DE3853529T2

DE3853529T2 - Dynamische Mehrbefehle-Mehrdaten-Mehrpipeline-Gleitpunkteinheit.

Info

Publication number: DE3853529T2
Application number: DE3853529T
Authority: DE
Inventors: Eric Mark Schwarz; Stamatis Vassiliadis
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-09-30
Filing date: 1988-06-21
Publication date: 1995-09-28
Anticipated expiration: 2008-06-22
Also published as: EP0328721A3; DE3853529D1; BR8804969A; EP0328721B1; US4916652A; JPH01102644A; CA1313273C; EP0328721A2

Description

Der beanspruchte Inhalt der vorliegenden Erfindung betrifft eine Verarbeitungsvorrichtung mit Pipeline, wie sie in der Präambel von Anspruch 1 definiert ist. Eine solche Vorrichtung ist beispielsweise aus der EP-A-0 106 670 bekannt.
Die meisten Prozessoren von Computern verwenden eine Art Pipelineverarbeitung. Innerhalb eines Prozessors mit Pipeline werden mehrere Befehle aus einer Befehlsfolge gleichzeitig ausgeführt. Jedoch wird jeder der auszuführenden Befehle in unterschiedlichen Stufen der Pipeline angeordnet. Die Leistungsfähigkeit eines Prozessors mit Pipeline ist notwendigerweise besser als die eines Prozessors ohne Pipeline. Es gibt verschiedene Arten der Pipelineverarbeitung. Ein Typ wird als "Einzelbefehls-Abfolge- Einzeldaten" (SISD) Pipelineverarbeitung bezeichnet. Beim SISD- Typ der Pipelineverarbeitung werden einzelne Befehle mit meist Einzeldaten-Operationen mit Pipelines verarbeitet. Jedoch treten bei Verwendung des SISD-Ansatzes der Pipelineverarbeitung vielerlei "Hasards" auf. Die "Hasards" können in zwei Kategorien unterteilt werden, nämlich in strukturelle Hasards und in datenabhängige Hasards. Ein struktureller Hasard tritt auf, wenn zwei Datenteile versuchen, dieselbe Hardware zu benutzen und folglich Kollisionen stattfinden. Datenabhängige Hasards können auftreten, wenn die Befehle, die durch die Pipeline laufen, in einer Stufe der Pipeline bestimmen, ob bestimmte Daten durch eine andere Stufe der Pipeline weitergegeben werden sollen oder nicht. zum Beispiel, wenn jede Stufe einer Pipeline, die zwei Stufen besitzt, einen einzelnen (denselben) Speicher anfordert, muß wenn eine Stufe den Speicher verwendet, die andere Stufe im Ruhezustand verharren, bis die erste Stufe den Speicher nicht mehr verwendet. Ein anderer Typ der Pipelineverarbeitung wird als "Mehrbefehls-Abfolge-Mehrdaten-" (MIMD) Pipelineverarbeitung bezeichnet. Wenn der MIMD-Typ der Pipelineverarbeitung verwendet wird, werden nicht nur einzelne Befehle in der Pipeline verarbeitet, wie dies bei den Befehls-"Folgen" des SISD-Ansatzes erfolgt. Beim MIMD-Ansatz der Pipelineverarbeitung treten Hasardprobleme nicht in Erscheinung. Obwohl beim MIMD-Ansatz in der Pipeline Befehlsfolgen blockweise verarbeitet werden, muß die Ausführung einer ersten Befehlsfolge erst beendet sein, bevor die Ausführung einer zweiten Befehlsfolge beginnen kann. Somit wurde die Leistungsfähigkeit der MIMD-Pipeline, obwohl sie besser war als die Leistungsfähigkeit der SISD-Pipeline, durch die Ausführungsphilosophie "eine Befehlsfolge zu jedem Zeitpunkt" begrenzt.
Dementsprechend ist es eine Hauptaufgabe der vorliegenden Erfindung, einen neuen Pipelinetyp für Computerfunktionseinheiten einzuführen, der im folgenden als "dynamische MIMD-Pipeline" bezeichnet wird.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, eine dynamische MIMD-Pipeline einzuführen, deren Leistungsfähigkeit nicht durch die Ausführungsphilosophie "eine Befehlsfolge zu jedem Zeitpunkt" eingeschränkt wird.
Es ist eine weitere Aufgabe der vorliegenden Erfindung, eine dynamische MIMD-Pipeline einzuführen, die in der Lage ist, eine Vielzahl von Befehlsfolgen in einer Vielzahl von Pipelines zu verarbeiten und damit die Leistungsfähigkeit der Funktionseinheit, welche die dynamische MIMD-Pipeline enthält wesentlich zu erhöhen.
Gemäß dieser und anderer Aufgaben der wie beansprucht vorliegenden Erfindung, sind eine Vielzahl von Pipes in der Lage eine weitere Vielzahl von Befehlen zur dortigen Ausführung aufzunehmen. Jede Pipe ist in der Lage, gleichzeitig eine Vielzahl von Befehlen zur Ausführung zu speichern. Somit ist die Vielzahl der Pipes in der Lage gleichzeitig die weitere Vielzahl von Befehlen zur Ausführung zu speichern. Die weitere Vielzahl von Befehlen wird aus einer Vielzahl von Befehlsfolgen ausgewählt, die gleichzeitig in der Vielzahl Pipes ausgeführt werden. Weil sich die Ausführung der Befehle innerhalb einer speziellen Pipe in unterschiedlichen Beendigungsstadien befinden kann, speichert eine dynamische Ablaufprotokoll-FIFO-Tabelle Informationen, zu jedem der Befehle, die sich in der Vielzahl der Pipes befinden, wobei die sich auf jeden Befehl beziehende Information die Pipe- Nummer, in welcher der Befehl zeitweilig gespeichert ist und den Status der Beendigung der Befehlsausführung des speziellen Befehls enthält. Eine Handshake- und globale Hasard-Schaltung bestimmt den Auslastungsstatus der Funktionseinheit, in welcher sich die dynamische MIMD-Pipeline befindet und kommuniziert mit den anderen Funktionseinheiten des Computersystems, beispielsweise mit der zentralen Verarbeitungseinheit (CPU). Sie bestimmt ebenfalls ob Hasards aufgetreten sind. Wenn die Funktionseinheit nicht besetzt ist und keine Hasards aufgetreten sind, wird der nächste Befehl aus einer der Vielzahl der Befehlsfolgen in die nächste verfügbare Pipe eingegeben. Ein MIMD/SISD-Umschaltvorrichtung bestimmt, ob ein eingehender Befehl von der Länge her größer als "X" Bits ist (z.B. 64) und wenn dies so ist, schaltet der Schalter die dynamische MIMD-Pipeline der vorliegenden Erfindung in den Standard-SISD-Modus und verarbeitet den eingegangenen Befehl entsprechend der Ausführungsphilosophie "eine Befehlsfolge zu jedem Zeitpunkt". Der SISD-Modus wird ebenfalls für schwierige Befehle eingestellt, als solche werden Divisionen und Quadratwurzeln betrachtet.
Weitere Anwendungsbereiche der vorliegenden Erfindung werden aus der nachfolgenden detaillierten Beschreibung ersichtlich werden.
Ein volles Verständnis der vorliegenden Erfindung erhält man aus nachstehender detaillierter Beschreibung der bevorzugten Ausführungsform sowie den begleitenden Zeichnungen, welche nur Illustrationszwecken dienen und mit denen nicht beabsichtigt ist, die vorliegende Erfindung einzugrenzen und worin:
Fig. 1 ein Beispiel einer dem Stand der Technik entsprechenden standardmäßigen MIMD-Pipeline darstellt;
Fig. 2 die dynamische MIMD-Pipeline der vorliegenden Erfindung darstellt;
Fig. 3 den Befehlsstapelspeicher von Fig. 2 darstellt;
Fig. 4 die dynamische Ablaufprotokolltabelle von Fig. 2 darstellt;
Fig. 5 Pipe 1 von Fig. 2 darstellt;
Fig. 6 Pipe 2 von Fig. 2 darstellt;
Fig. 7 Pipe 3 von Fig. 2 darstellt;
Fig. 8 Pipe 4 von Fig. 2 darstellt;
Fig. 9 den Datenstapelspeicher und die Datenstapelspeicher- Steuerungen von Fig. 2 darstellt;
Fig. 10 einen Aufbau der Handshake- und globalen Hasard-Schaltung von Fig. 2 darstellt;
Fig. 11 einen Aufbau der Initialisierungsschaltung von Fig. 2 darstellt; und
Fig. 12 ein Beispiel einer Befehlsfolge darstellt.
Zur Darstellung von Hintergrundinformationen ist die dynamische MIMD-Pipeline der vorliegenden Erfindung in einer Funktionseinheit eines Computersystems installiert. Eine solche Funktionseinheit könnte eine Gleitpunkteinheit (FPU) sein. Zusätzlich zur FPU enthält das Computersystem ebenfalls einen schnellen Pufferspeicher, eine zentrale Verarbeitungseinheit (CPU) und einen Vektorprozessor (VP). Gleitpunkteinheit (FPU) empfängt Daten direkt aus dem schnellen Pufferspeicher, von der zentralen Verarbeitungseinheit (CPU) oder dem Vektorprozessor (VP) sowie Befehle von der CPU. Die CPU steuert nicht die aus dem schnellen Pufferspeicher kommenden Daten. Die CPU fordert Daten aus dem schnellen Pufferspeicher an, während sie an die FPU Befehle sendet. Während durch die CPU auf Daten aus dem schnellen Pufferspeicher zugegriffen wird, sendet die CPU weitere Befehle an die FPU, ohne daß eine Synchronisation der Zyklen, in denen auf die Daten aus dem schnellen Pufferspeicher zugegriffen wird und der Zyklen, in denen die entsprechenden Befehle an die FPU gesendet werden, erfolgt. Deshalb können die Daten, die im Zyklus N an der FPU ankommen, zu den Daten eines Befehls gehören, der im Zyklus M an die Gleitpunkteinheit geliefert wurde, mit M ≤ N. Die CPU sendet ihre Anforderungen zur Ausführung der verschiedenen Operationen durch die FPU und andere Einheiten, wie beispielsweise den schnellen Pufferspeicher, über einen sogenannten CBUS. Der CBUS ist das einzige Mittel, über das Befehle zwischen der CPU und der FPU übertragen werden. Der CBUS leitet Handshake-Steuersignale und Befehlscodes. Wenn die CPU derartige Anforderungen sendet, werden die Funktionseinheiten, an welche diese Anforderungen gesendet werden, Prozessor-Buseinheiten (PBU) genannt. Die FPU enthält eine der PBUs. Wenn die CPU auf einen Befehl trifft, welchen sie nicht ausführen kann und eine PBU den Befehl ausführen soll, überträgt die CPU ein Prozessorbusoperations-Signal (PBO) an die geeignete PBU. Zum Beispiel dann, wenn die CPU einen Befehl decodiert hat, der eine Multiplikation im langen Gleitpunktformat beinhaltet. Weil es für die FPU viel einfacher ist, diese Operation auszuführen, sendet die CPU ein PBO-Signal an die FPU, womit die FPU aufgefordert wird, die lange Gleitpunktmultiplikation auszuführen.
Die FPU enthält zwei Hauptteile: einen ersten Abschnitt, in welchen die aktuellen Daten fließen und einen zweite Abschnitt, in welchen die Befehle eingegeben und nachfolgend in Steuersignale gewandelt werden. Die vorliegende Spezifikation beschreibt den zweiten Abschnitt.
Wir beziehen uns auf Fig. 1, worin ein dem Stand der Technik entsprechendes MIMD-Pipelinesystem dargestellt wird.
In dem System von Fig. 1 speichert ein Speicher 10 eine Vielzahl Befehlsfolgen und im besonderen den Status jeder dieser Befehlsfolgen. Eine Initialisierungssteuerung 12 ist mit dem Ausgang des Speichers 10 verbunden, die Pipeline-Schaltung 14 besitzt keine Hasard-Erkennungsschaltung. Der Ausgang der Pipeline 14 ist mit dem Speicher 10 verbunden.
Im Betrieb wird eine Befehlsfolge, die im Speicher 10 von Fig. 1 gespeichert ist, zur Initialisierungssteuerung 12 übertragen. Die Initialisierungssteuerung 12 überträgt in Reaktion darauf jeden Befehl der Befehlsfolge, immer einen Befehl zu jedem Zeitpunkt, an die Pipeline-Schaltung 14. Die Befehle werden durch die Pipeline-Schaltung 14 durchgeschoben und einzeln ausgeführt. In Abhängigkeit davon werden aktualisierte Befehle von der Pipeline-Schaltung 14 zum Speichern in den Speicher 10 übertragen. Wenn der letzte Befehl der Befehlsfolge von der Initialisierungssteuerung zur Pipeline-Schaltung 14 übertragen, dort eingegeben und ausgeführt wird, wird der letzte aktualisierte Befehl der ursprünglichen Befehlsfolge zum Speicher 10 übertragen. An diesem Punkt wird eine weitere Befehlsfolge vom Speicher 10 zur Initialisierungssteuerung 12 zur Ausführung in der Pipeline- Schaltung 14 übertragen. Es ist klar, daß bei der Anordnung von Fig. 1, die ursprüngliche Befehlsfolge vollständig die Pipeline durchlaufen haben und in der Pipeline-Schaltung 14 ausgeführt worden sein muß, bevor die nächste Befehlsfolge aus dem Speicher 10 zur Initialisierungssteuerung 12 zur Eingabe in die Pipeline und zur Ausführung in der Pipeline-Schaltung 14 übertragen werden darf. Dies charakterisiert die Leistungsgrenze und den Nachteil, die mit dem standardmäßigen MIMD-Pipelineansatz verbunden sind.
Wir beziehen uns auf Fig. 2. Es ist darin eine dynamische MIMD- Pipeline gemäß der vorliegenden Erfindung dargestellt.
In Fig. 2 ist der CBUS mit einem Befehlsstapelspeicher 20.1 verbunden. Ein Ausgang des Befehlsstapelspeichers 20.1 ist mit einer Decodierschaltung 20.2 verbunden. Der Ausgang der Decodierschaltung 20.2 ist mit einer Handshake- und globalen Hasard- Schaltung 20.3, einem MIMD/SISD-Schalter 20.4 und einer Initialisierungsschaltung 20.5 verbunden. Die Ausgänge der Handshake- und globalen Hasard-Schaltung 20.3 und des MIMD/SISD-Schalters 20.4 sind mit den Eingängen der Initialisierungsschaltung 20.5 verbunden. Der Ausgang der Initialisierungsschaltung 20.5 ist mit einer dynamischen Ablaufprotokolltabelle 20.7, Pipeline- Schaltungen 20.6 und mit Gleitpunkt-Registern (FPR) verbunden. Der Ausgang der Handshake- und globalen Hasard-Schaltung 20.3 ist ebenfalls mit der Schaltung zur Behandlung von Ausnahmebedingungen 20.11 verbunden, deren Ausgang in Folge mit der dynamischen Ablaufprotokolltabelle 20.7 verbunden ist. Die Pipeline- Schaltungen 20.6 sind ebenfalls mit der dynamischen Ablaufprotokolltabelle 20.7 und der Schaltung zur Behandlung von Ausnahmebedingungen 20.11 verbunden und erzeugen ein Ausgangssignal, welches auf einem Bus, dem sogenannten DBUS weitergeleitet wird, welcher mit dem Daten-Cache verbunden ist und die Signale auch zu den FPR 20.8 weiterleitet, welche eine lokal definierte Speicherarchitektur darstellen. Das Ausgangssignal der dynamischen Ablaufprotokolltabelle 20.7 wird verwendet, um die Weiterleitung der Ausgangssignale zum DBUS und zu den FPR 20.8 zu steuern. Der CBUS liefert neben den Eingangssignalen für den Befehlsstapelspeicher 20.1 auch die Eingangssignale für die DBUS-Stapelspeicher-Steuerungen 20.10. Der Ausgang der DBUS-Stapelspeicher- Steuerungen 20.10 ist mit einem DBUS-Stapelspeicher 20.9 verbunden, dessen Eingang an den DBUS angeschlossen ist. Der Ausgang des DBUS-Stapelspeichers 20.9 und der Ausgang der FPR 20.8 erzeugen die Daten, die den Datenfluß starten.
Die dynamische MIMD-Pipeline der vorliegenden Erfindung, die in Fig. 2 dargestellt ist, kann in zwei Signalpfade unterteilt werden: einer für Befehle und Steuersignale (CBUS-Pfad) und der andere für den Datenfluß (DBUS-Pfad). Die Befehle werden über den CBUS empfangen, in den Befehlsstapelspeicher 20.1 eingegeben und anschließend durch die Decodierschaltung 20.2 decodiert. Die Daten werden in die dynamische MIMD-Pipeline von Fig. 2 über den DBUS eingegeben.
Die Handshake- und Hasard-Schaltung 20.3 von Fig. 2 sendet "Handshake"-Signale an die CPU und detektiert globale Hasards. Der eigentliche Aufbau der Handshake- und globalen Hasard-Schaltung 20.3 ist in Fig. 10 der Zeichnungen zu finden. Eine detailliertere Beschreibung der Handshake- und globalen Hasard-Schaltung 20.3 von Fig. 10 erfolgt weiter unten in einem der folgenden Abschnitte dieser Spezifikation. Der CBUS umfaßt einen Satz Handshake-Signale, die von der CPU zu jeder PBU, einschließlich der FPU, übertragen werden müssen. Wenn die FPU eine Anforderung über den CBUS empfängt, muß die Handshake- und globale Hasard- Schaltung 20.3 der FPU ein Quittungssignal an die CPU zurücksenden und zwar ein Bereitschaftssignal, ein Besetztsignal oder ein Unterbrechungssignal, wenn die CBUS-Anforderung von der CPU gesendet wurde und die FPU die einzige PBU ist, die über die Anforderung angesprochen wurde. Das Bereitschafts-Handshake-Signal wird von der FPU an die CPU gesendet, wenn eine CBUS-Anforderung an die FPU gesendet worden ist und die FPU nicht BESETZT ist. Das Unterbrechungssignal wird von der FPU an die CPU gesendet, wenn eine Ausnahmebedingung in den Daten aufgetreten ist und kritische Informationen im Statuswort gespeichert sind. Das Besetzt-Handshake-Signal wird von der FPU an die CPU gesendet, wenn die FPU keine weiteren Befehle zur Ausführung annehmen kann. Die Handshake-Signale, Bereitschaft, Besetzt und Unterbrechung, werden von der Handshake- und globalen Hasard-Schaltung 20.3 der FPU an die CPU gesendet. Globale Hasards werden in der Handshake- und globalen Hasard-Schaltung 20.3 der FPU erkannt und es wird ein Signal für die Übertragung zur Initialisierungsschaltung 20.5 erzeugt, das für das Auftreten solcher Hasards kennzeichnend ist. Die Handshake-Logik 20.3 stellt (in Verbindung mit der Initialisierungsschaltung) die entsprechende Reaktion der FPU für die anderen Prozessorbuseinheiten (PBU) bereit. Sie trägt ebenfalls mit zur Erkennung des Anfangs und des Endes einer Befehlsfolge bei. Die Hasard-Schaltung detektiert das Auftreten von Hasards auf Grund von Datenabhängigkeiten einzelner Befehle zu anderen auszuführenden Befehlen (Datensperre).
In Abhängigkeit von den eingehenden Befehlen, die von der Decodierschaltung 20.2 decodiert werden, schaltet der MIMD/SISD- Schalter entweder in den SISD-Modus oder in den MIMD-Modus. Wenn ein eingehender Befehl Operanden enthält, die eine Länge von mehr als 64 Bits aufweisen oder wenn ein Befehl erkannt wird, der schwierig auszuführen ist, wählt der MIMD/SISD-Schalter 20.4 den SISD-Modus, ansonsten wird der MIMD-Modus verwendet.
Die speziellen Befehle, die bezüglich der Ausführung als schwierig betrachtet werden und die die Umschaltung in den SISD-Modus bewirken sind:
Divisionen, sowohl Gleitpunkt als auch Festpunkt, Quadratwurzeln,
Operationen, die erweiterte Operanden einbeziehen.
Während der Ausführung im SISD-Modus werden neben der Ausführung des schwierigen Befehls alle Zusatzfunktionen abgeschaltet. Dies wird dadurch erreicht, daß das Besetztsignal, das durch die Handshake-Schaltung 20.3 der FPU erzeugt und an die CPU gesendet wird, im aktiven Zustand verbleibt. Dies verhindert, daß die CPU über den CBUS weitere Anforderungen an die FPU sendet. Die folgenden Befehle oder beliebigen Kombinationen dieser Befehle bewirken, daß der MIMD/SISD-Schalter 20.4 den Pipeline-Modus in den MIMD-Modus umschaltet:

Gleitpunkt-Operationen

Additionen
Vergleiche
Halbieren
Laden
Multiplikationen
Speichern
Subtraktionen

Festpunkt-Operationen - Mikrocode

Multiplikation

Andere Operationen - Mikrocode

Laden
Speichern
Statuswort
Indirekter Modus
Wiederholung
Die folgenden Befehle bewirken, daß der MIMD/SISD-Schalter 20.4 den Pipeline-Modus in den SISD-Modus umschaltet:

Gleitpunkt-Operationen - Mikrocode

Addition erweitert
Multiplikation erweitert
Divisionen
Division erweitert
Quadratwurzel
Laden gerundet, erweitert

Festpunkt-Operationen - Mikrocode

Division
Die Initialisierungsschaltung 20.5 von Fig. 2 startet die Pipe und aktualisiert die Dynamische Ablaufprotokolltabelle 20.7. Der eigentliche Aufbau der Initialisierungsschaltung 20.5 ist in Fig. 11 der Zeichnungen zu finden. Eine detailliertere Beschreibung der Initialisierungsschaltung 20.5 von Fig. 11 erfolgt weiter unten in einem der folgenden Abschnitte dieser Spezifikation. In Verbindung mit der Handshake/Hasard-Logik 20.3 bestimmt die Initialisierungsschaltung 20.5 den Anfang und das Ende einer Befehlsfolge und bestimmt ob irgendwelche datenabhängige Hasards existieren. Nach dem Decodierungsschritt wird der Typ des Befehls, der durch das Ausgangssignal des Decodierers 20.2 angezeigt wird, in der Initialisierungsschaltung 20.5 und der Hasard-Schaltung 20.3 mit dem Beendigungs-Status der ersten Arbeitsstufe der geeignet zu verwendenden Pipe verglichen wird, der durch die internen Pipe-Steuerungen 20.6a bis d angezeigt wird. Wenn keine globalen Hasards existieren, was durch die dynamische Ablaufprotokolltabelle 20.7 angezeigt wird und keine unmittelbaren inneren Hasards aufgetreten sind, was durch das Ausgangssignal der Handshake- und globalen Hasard-Schaltung 20.3 angezeigt wird, wird der Befehl initialisiert. Wenn das BESETZT- Handshake-Signal durch die Handshake- und globale Hasard-Schaltung 20.3 aktiviert ist, findet in der Initialisierungsschaltung 20.5 keine Initialisierung statt. Die Initialisierung beinhaltet das Starten der Status-Steuerungen der geeigneten Pipe und das Eintragen einer neuen Zeile in der Dynamischen Ablaufprotokolltabelle. Die Meldung der Initialisierung wird durch die Handshake-Steuerung 20.3 ausgeführt, die ein Bereitschaftssignal an die CPU sendet, was anzeigt, daß der Befehl gestartet worden ist oder indem ein Besetztsignal an die CPU gesendet wird, was anzeigt, daß die FPU den Befehl übernommen hat, die Folge der eingehenden Befehle aber besser gestoppt werden sollte, weil die FPU nicht viel mehr Befehle verarbeiten kann. Die Initialisierungslogik 20.5 und die Hasard-Logik 20.3 bestimmen den Beginn und das Ende einer Befehlsfolge. Die Antworten "Bereitschaft" und "nicht besetzt" auf einen Befehl, der nicht schon innerhalb einer Befehlsfolge liegt, zeigt den Beginn einer Befehlsfolge an und "besetzt" zeigt das Ende einer Befehlsfolge an. Die Hasard- Schaltung 20.3 wird verwendet, um Hasards auf Grund von Datenabhängigkeiten zu erkennen. Die Initialisierungslogik 20.5 fügt neue Zeilen in die dynamische Ablaufprotokolltabelle 20.7 ein. Deshalb besteht die Initialisierung aus dem Quittungsaustausch, der Aktualisierung der Ablaufprotokolldatei und einer möglichen Behandlung von Daten-Hasards.
Die dynamische MIMD-Pipeline von Fig. 2 enthält vier Pipeline- Schaltungen 20.6: Pipe 1 20.6a, Pipe 2 20.6b, Pipe 3 20.6c und Pipe 4 20.6d. Somit gibt es vier Kategorien von Befehlen, eine Kategorie für jede Pipe 20.6a bis 20.6d.
Die Daten auf dem DBUS werden entweder durch die FPR 20.8 verarbeitet oder in den DBUS-Stapelspeicher 20.9 übernommen, welcher durch die DBUS-Stapelspeicher-Steuerungen 20.10 gesteuert wird.
Die Schaltung zur Behandlung von Ausnahmebedingungen 20.11 bestimmt, ob eine Ausnahmebedingung eingetreten ist. Die verschiedenen Typen von datenabhängigen Ausnahmebedingungen, die bei der Ausführung von Befehlen auftreten können, sind:
Positiver Exponenten-Überlauf
Negativer Exponenten-Überlauf
Ausnahmebedingung bei Gleitpunkt-Division
Ausnahmebedingung bei Festpunkt-Division
Signifikanz-Ausnahmebedingung
Ausnahmebedingung bei Quadratwurzel
Wenn ein Befehl erkannt wird, der eine dieser Ausnahmebedingungen hervorruft, müssen alle hinter diesem Befehl empfangenen Befehle ungültig gemacht werden, als ob sie niemals empfangen worden wären, selbst dann, wenn sie sich bereits in Ausführung befinden. Dies ist ein Merkmal einer SISD-Architektur, welches durch die dynamische MIMD-Architektur übernommen werden muß. Dies wird dadurch erreicht, daß alle Gültigkeits-Bits in der Dynamischen Ablaufprotokolltabelle auf Null gesetzt werden, nachdem der Befehl, der die Ausnahmebedingung bewirkt hat, beendet wurde. Zusätzlich werden die CPU und alle anderen Einheiten über die Unterbrechung unterrichtet und diese müssen ihre Befehle ungültig machen, bis die CPU ein Unterbrechungs-Behandlungsprogramm startet.
Die dynamische MIMD-Pipeline 20, die sich in der FPU des Computersystems befindet, empfängt Befehle über den CBUS und die FPU antwortet, wie es auch die anderen Prozessorbuseinheiten tun, durch Senden verschiedener "Handshake"-Signale, die ein BEREITSCHAFTS-Handshake-Signal, ein BESETZT-Handshake-Signal und ein UNTERBRECHUNGS-Handshake-Signal umfassen. Weil die CPU in einem Pipelineverarbeitungs-Modus arbeitet und in jedem Zyklus, unabhängig davon, ob das letzte PBO mit einem Bereitschaftssignal quittiert wurde, PBO-Kommandos sendet, müssen die PBU bestimmen, ob das letzte PBO positiv quittiert wurde, bevor mit der Verarbeitung des nächsten PBO fortgesetzt wird. Die PBUs enthalten eine intelligente Schnittstelle. Deshalb muß eine PBU unter Benutzung der intelligenten Schnittstelle die Handshake-Signale der anderen PBUs mit der CPU verfolgen. Eine PBU muß in dem auf den Empfang eines PBO folgenden Zyklus eines der drei Handshake- Signale (erzeugt durch die Handshake-Schaltung 20.3 von Fig. 2) an die CPU senden. Wenn eine PBU, wie beispielsweise die FPU, Hasards behandelt wird durch die PBU ein BESETZT-Handshake-Signal an die CPU gesendet. Wenn das Besetztsignal an die CPU gesendet wird, speichert die PBU den empfangenen Befehl und den folgenden Befehl in einem Befehls-FIFO-Stapelspeicher (wie beispielsweise in dem Befehlsstapelspeicher 20.1 von Fig. 2 bei einer FPU), so daß die Abfolge der Befehle, die von der CPU empfangen werden, erhalten bleibt. Somit werden ein CBUS-Register 20.1.2 und ein CBUS-Stapelspeicher 20.1.1, welcher den empfangenen Befehl und den folgenden Befehl speichert, als Teil des Befehlsstapelspeichers 20.1 in der FPU implementiert. Ohne daß Hasards behandelt werden, welche die Erzeugung des BESETZT-Handshake-Signals bewirken, werden Befehle nicht gestapelt. Die FPU akzeptiert so viele Befehle, wie sie bearbeiten kann. Die FPU hat jedoch nicht so viele Informationen, wie sie die CPU besitzt. Die CPU kann, wenn sie in ihrem Befehlspuffer sieht, daß Probleme auftreten können, diesen Befehl zurückhalten noch bevor der Befehl an die Buseinheiten gesendet wird. Wenn durch die CPU PBO-Kommandos gesendet werden, die die Ausführung durch die FPU und eine andere Buseinheit, wie beispielsweise den Daten-Cache, erfordern, hat die FPU keine Möglichkeit, den Daten-Cache daran zu hindern, mit der Ausführung des Befehls zu beginnen. Somit ist es für die FPU am effektivsten, so weit wie möglich weiterzuarbeiten, bis ein Hasard auftritt.
Wir beziehen uns auf die Fig. 3a bis 3c. Es wird der Aufbau des Befehlsstapelspeichers 20.1 von Fig. 2 dargestellt. Fig. 3a zeigt den Aufbau des Befehlsstapelspeichers 20.1, Fig. 3b zeigt die Bedeutung der Bits des CBUS während festverdrahteter Befehlsverarbeitung und Fig. 3c zeigt die Bedeutung der Bits des CBUS während einer Mikrocode-Operation.
Der Befehlsstapelspeicher 20.1 von Fig. 3a umfaßt das CBUS-Stapelspeicher-Register 20.1.1 und ein CBUS-Register 20.1.2., das mit dem Ausgang des CBUS-Stapelspeicher-Registers 20.1.1 verbunden ist. Der Befehlsstapelspeicher umfaßt so wie der CBUS 25 Informationsbits für höchstens zwei Befehle. Diese 25 Informationsbit umfassen:
Bit 0 - das PBO-Bit, welches anzeigt, ob die FPU im festverdrahteten Modus oder im Mikrocode-Modus arbeitet; wenn sie im festverdrahteten Modus (0) arbeitet, werden Ausnahmebedingungen an die CPU gemeldet, wenn sie im Mikrocode-Modus arbeitet, werden Ausnahmebedingungen im Statuswort gespeichert (siehe Fig. 8, Element-Nummer 20.6d.3) aber nicht gemeldet;
Bit 1 - das FPU-Anforderungsbit, welches der FPU anzeigt, daß dieser Befehl durch die FPU ausgeführt werden muß;
Bit 2 - das IPU/Cache-Anforderungsbit, welches dem Cache anzeigt, daß er den Befehl decodieren muß;
Bit 3 - das VP-Anforderungsbit;
Bits 17 bis 19 - im Mikrocode-Modus sind diese Bits die Identifikationsbits für die Quelle (SRC - source);
Bits 20 bis 22 - im Mikrocode-Modus sind diese Bits die Identifikationsbits für das Ziel (DST - destination);
Bits 4 bis 10 - die Operationscodebits des Befehls;
Bits 17 bis 19 - im festverdrahteten Modus sind diese Bits das Unterbrechung-Markierungsfeld, welches im Statuswort einer Ausnahmebedingung gespeichert wird; und
Bit 24 - das Paritätsbit, das zur Überprüfung der Gültigkeit des Befehls verwendet wird.
Somit wird über die oben definierten CBUS-Bits der Befehl auf dem CBUS in den Befehlsstapelspeicher 20.1 eingegeben.
Wir beziehen uns auf Fig. 4. Darin wird der Aufbau der dynamischen Ablaufprotokolltabelle von Fig. 2 dargestellt.
Die dynamische Ablaufprotokolltabelle 20.7 von Fig. 4 umfaßt 17 Informationsbits, die für höchstens 8 Befehle gleichzeitig fortlaufend gespeichert werden. Die Dynamische Ablaufprotokolltabelle 20.7 umfaßt Daten, die benötigt werden, wenn ein eingehender Befehl in eine der Pipes 20.6a bis 20.6d eingegeben werden soll und um Befehle aus diesen Pipes zu beenden. Weil die Befehle gestapelt werden, stellt die Tabelle 20.7 Mittel bereit, die Abfolge der Beendigung der Ausführung von Befehlen einer oder mehrerer Befehlsfolgen zu steuern. Die Leistungsgrenze des CBUS, einen Befehl zu jedem Zeitpunkt senden zu können, bestimmt die Startzeit des Befehls. Weil die Ausführung der Befehle einer oder mehrerer Befehlsfolgen eine Vielzahl Zyklen bis zu ihrer jeweiligen Beendigung beanspruchen kann, und weil mehr als eine Pipe existiert, ist es möglich, daß mehrere Befehle gleichzeitig ausgeführt werden. Auf Grund der Beschränkungen der Architektur muß die Reihenfolge der Beendigung der Befehle aufrechterhalten werden, weil mögliche unvorhergesehene Ergebnisse eintreten können, wenn eine Unterbrechung ausgelöst wird und die Befehlsverarbeitung nicht in der richtigen Reihenfolge stattgefunden hat. Deshalb ist es notwendig, Abfolge-Informationen und Beendigungs- Informationen in der Tabelle 20.7 zu speichern und zu halten. Die dynamisch Ablaufprotokolltabelle 20.7 speichert die folgenden Informationen:
1. die Pipe-Nummer (PIPE NR),
2. die Schreibadresse (WR ADR),
3. welchen Schreibtyp (WT) der Befehl hat,
4. eine Markierung (INT TAG), welche eindeutig einen Befehl im Stapelspeicher der CPU identifiziert,
5. ob der Befehl ein SISD-Befehl (M/S) ist, wobei "M" den MIMD-Befehlstyp kennzeichnet und "S" den SISD-Befehlstyp,
6. die Ergebnislänge (LEN),
7. ob es ein festverdrahtetes oder ein Mikrocode-PBO ist (H),
8. Wiederholungsinformation (PSW, PTR) und
9. ein Gültigkeitsbit (V - valid).
Die Pipe-Nummer (PIPE NR) ist kritisch, weil sie für die Vielzahl Pipes der Pipeline-Schaltungen 6a bis 6d von Fig. 2 eine Abfolge festlegt. Die Ablaufsteuerung hat in einem Ein-Pipe-System keinerlei Bedeutung, bei mehreren Pipes muß jedoch die Ablauf-Information erhalten werden. Die Schreibadresse (WR ADR), der Schreibtyp (WT) und die Ergebnislänge unterstützen die Beendigung des Befehls. Die Markierungs-Information (INT TAG) wird weggespeichert, wenn eine Ausnahmebedingung eintritt und unterstützt die Identifikation des genauen Befehls, welcher die Ausnahmebedingung hervorgerufen hat. Wenn dies ein SISD-Befehl ist, wird die Beendigung nicht dadurch erfaßt, daß nachgesehen wird, ob am Ende der Pipe gültige Daten erscheinen. Stattdessen wird dies durch einen Zähler bestimmt, der die Zyklen zählt. Das wichtigste Bit ist das Gültigkeitsbit (V), welches anzeigt, ob der Befehl, der zu diesem Eintrag des Stapelspeichers gehört, gültig ist. Das Gültigkeitsbit (V) wird gelöscht, wenn eine Ausnahmebedingung auftritt. Nach Beendigung der Ausführung eines Befehls wird der Gültigkeitsbit- (V) Eintrag gelöscht und der Stapelspeicher verschoben. Damit ist ein schnelles Verfahren verfügbar, um alle anhängigen Befehle in der FPU ungültig zu machen, und zwar indem die Gültigkeitsbits (V) der dynamischen Ablaufprotokolltabelle 20.7 gelöscht werden.
Wir beziehen uns auf die Fig. 5 bis 8. Darin wird der Aufbau der Pipeline 20.6 von Fig. 2 dargestellt. Im besonderen zeigt Fig. 5 den Aufbau der Pipe 1 20.6a, welche für Befehle vom Additionstyp verwendet wird, beispielsweise für Additionen, Subtraktionen, Divisionen, Vergleiche und Quadratwurzeln. Die Pipe von Fig. 5 arbeitet in drei Zyklen. Fig. 6 stellt den Aufbau von Pipe 2 20.6b dar, der Multiplikations-Pipe, welche in fünf Zyklen arbeitet und für Multiplikationsbefehle verwendet wird. Fig. 7 zeigt den Aufbau von Pipe 3 20.6c, welche für Befehle vom Typ Lade RX verwendet wird und in zwei Zyklen arbeitet. Fig. 8 stellt den Aufbau von Pipe 4 20.6d dar, welche für alle anderen Zusatzfunktionen verwendet wird, was normalerweise ein Schreiben oder Lesen von Hilfs- oder Statusregistern ist.
Die Pipeline 20.6a von Fig. 2 enthält einen Steuerungsteil und einen Pipe-1-Teil. Genauso enthält jede der Pipes 20.6b bis 20.6d einen Steuerungsteil. Die Pipeline-Steuerungen der Pipes 20.6a bis 20.6d steuern die internen Teile jeder Pipe, indem die Operationen so weit wie möglich durch die Pipes geschoben werden, indem erfaßt wird, wann die FPR 20.8 verriegelt sind und indem bestimmt wird, wo gute Daten zu finden sind. Zum besseren Verständnis dieser Steuerungen ist es am besten zuerst die Struktur jeder Pipe zu verstehen. In Fig. 2 und in den Fig. 5 bis 8 umfaßt die Pipeline 20.6 vier Pipes: 20.6a bis 20.6d. Im MIMD-Modus haben diese Pipes unterschiedliche Längen, was folglich Schwierigkeiten für die globale Steuerung dieser Pipes hervorruft. Im Innern der Pipes befinden sich Register und diesen Registern sind Statusfelder zugeordnet.
Wir beziehen uns auf Fig. 5b. Wie unten vollständiger dargestellt wird, bestehen die Statusfelder der Register der Additions-Pipe von Fig. 5 aus der FPR-Adresse der Operanden (ADR), der Anzeige ob der SISD- oder MIMD-Modus (M/S) eingenommen wird, einer Umgehungs- (bypass) Information (2BY), ob die Stufe der Pipe einem gültigen Befehl entspricht (VI), ob die Daten in dem Register gültig sind (VD) und ob der Befehl vom Typ RX oder RR (RX) ist.
Wir beziehen uns auf Fig. 6b. Die Statusfelder, die den Registern der Multiplikations-Pipe von Fig. 6 zugeordnet sind, speichern diese Informationen sowie weitere Informationen, einschließlich der Länge der Operanden (LI), ob es sich um Gleitpunkt- oder Festpunkt-Operanden handelt (FLP) und ob die Daten auch dann noch gültig sind, wenn diese Stufe der Pipe keinen gültigen Befehl enthält. Die anderen Pipes benötigen keine Statusinformationen, weil sie sehr kurz sind.
Wir beziehen uns wieder auf Fig. 2. Die Statusinformation jeder einzelnen Stufe der Pipe zeigt der folgenden Stufe ihre Gültigkeit an, und anschließend während des folgenden Zyklus, wird die nächste Stufe gültig, wenn keine Konflikte auftreten. Somit unterstützen die Markierungen die Erkennung von Konflikten und schieben die Befehlsdaten so weit sie können durch die Pipe. Nachdem die entsprechende Pipe die Daten auf dem DBUS lokalisiert hat und die Ausführung in der Pipe stattfindet, wartet die entsprechende Pipe darauf, daß der älteste Eintrag der Dynamischen Ablaufprotokolltabelle mit der Pipe-Nummer (PIPE NR) der entsprechenden Pipe übereinstimmt. Zu diesem Zeitpunkt wird die Pipe freigegeben, um den Befehl zu beenden und auf diese Weise erfolgt die Synchronisation der Beendigung der Befehle.
Wir beziehen uns auf Fig. 5. Darin werden die internen Steuerungsregister der Pipe 1 (Addition) dargestellt.
Die Pipe 1 20.6a von Fig. 5a umfaßt ein Ausrichtungs-Register 20.6a.4, ein FA-Register 20.6a.1, ein FB-Register 20.6a.2, ein A-Register 20.6a.5, ein B-Register 20.6a.6, einen Addierer 20.6a.7, ein FS-Register 20.6a.3, ein S-Register 20.6a.8 und ein nachträgliches Normierungs-Register 20.6a.9. In Fig. 5b ist ein Statusfeld dargestellt, wie es dem FA-Register 20.6a.1, dem FB- Register 20.6a.2 und dem FS-Register 20.6a.3 zugeordnet ist.
Fig. 5 stellt die Additions-Pipe 20.6a und die ihr zugeordneten internen Pipe-Steuerungsregister dar. Die Additions-Pipe von Fig. 5 arbeitet in drei Zyklen. Während des ersten Zyklus werden die Daten entweder aus den FPR 20.8 und/oder vom DBUS wiederhergestellt. Durch die Ausrichtungs-Hardware 20.6a.4 erfolgt die Ausrichtung. Die Operanden werden im A-Register 20.6a.5 und im B-Register 20.6a.6 zwischengespeichert. Im Zyklus zwei wird die eigentliche Addition durch den Addierer 20.6a.7 durchgeführt, und das Ergebnis wird im S-Register 20.6a.8 gespeichert. Im dritten und letzten Zyklus schiebt, wenn erforderlich, der nachträgliche Normierer 20.6a.9. führende Nullen aus dem Ergebnis heraus und sendet die Daten zurück in die FPR 20.8. Die im vorhergehenden beschriebenen Funktionen spiegeln die Art und Weise wider, in welcher die Pipe Additionsbefehle bearbeitet. Bei anderen Befehlen, die zu derselben Kategorie gehören, werden mindestens einige der Register oder einige der internen Umgehungs- Steuerungen in der Pipe verwendet. Somit wird die Drei-Zyklen- Pipe für viele unterschiedliche Befehle verwendet. Um diese Pipe zu überwachen und zu steuern werden drei Haupt-Steuerungsregister benötigt: ein FA-Register 20.6a.1, ein FB-Register 20.6a.2 und ein FS-Register 20.6a.3.
Wir beziehen uns auf Fig. 5b. Es wird das Statusfeld des FA-Registers 20.6a.1, des FB-Registers 20.6a.2 und des FS-Registers 20.6a.3 dargestellt.
Das Statusfeld von Fig. 5b umfaßt die folgenden Bits:
1. FPR-Adreßbits (ADR) der Operanden, die verwendet werden, um Operanden zu lokalisieren, welche gesperrt sein können.
2. Ein gültiger-Befehl-Bit (VI), welches verwendet wird, um anzuzeigen, daß diese Stufe der Pipeline als Befehl gültig ist.
3. Ein gültige-Daten-Bit (VD), welches anzeigt, daß das zugeordnete Datenregister gültig ist.
4. Eine MIMD/SISD-Anzeige für die Pipe (M/S), welche das Befehlsende anzeigt. Im MIMD-Modus ist die letzte Stufe gültig und es gibt keine Konflikte bei der Beendigung. Im SISD-Modus sind die Verhältnisse etwas komplexer, da der Befehl mehrmals durch die Pipe geschleift werden kann.
5. Ein Bit, um anzuzeigen, daß der Befehl vom RX-Typ ist (RX), welches beispielsweise beim FB-Register anzeigt, daß die Adreßbits ungültig sind und daß der Datenbus bezüglich eingehender Daten überwacht werden sollte, wenn diese noch nicht gültig sindu
6. Ein Bit, das den ersten Zyklus einer Zwei-Zyklen-Umgehung (2BY) anzeigt. Manchmal werden zwei Zyklen benötigt, um gesperrte Daten, wenn sie lokalisiert sind, wiederherzustellen.
Wir beziehen uns auf Fig. 6a. Darin werden Pipe 2 20.6b, die Multiplikations-Pipe, und die internen Steuerungsregister der Pipe dargestellt.
Die Pipe 2 20.6b von Fig. 6a umfaßt ein FXA-Register 20.6b.1, ein FYS-Register 20.6b.2, ein FXB-Register 20.6b.3, FY-Register 20.6b.4, ein FP-Register 20.6b.5, ein XA-Register 20.6b.6, eine 3X-Hardware 20.6b.7, XB- und 3X-Register 20.6b.8, ein Y-Register 20.6b.9, eine M1-Hardware 20.6b.10, eine M2-Hardware 20.6b.11 und ein P-Register 20.6b.12. Die Multiplikations-Pipe umfaßt 5 Zyklen, wenn keine Hasards auftreten.
Zyklus 1 - Operand 1 wird aus den FPR 20.8 in das XA-Register 20.6b.6 geladen und wenn Operand 2 ebenfalls aus den FPR kommt, wird er gelesen und in einem temporären Register gespeichert, weil die Busstruktur nur das Laden eines Operanden in einem Zyklus erlaubt.
Zyklus 2 - Operand wird entweder aus dem temporären Register oder vom DBUS in das Y-Register 20.6b.9 geladen; gleichzeitig wird das 3-Fache des Operanden 1 durch die 3X- Hardware 20.6b.7 berechnet und in dem 3X-Register 20.6b.8 gespeichert. Das XA-Register 20.6b.6 lädt direkt das XB- Register 20.6b.8.
Zyklen 3 und 4 - Dies sind die zwei Zyklen der eigentlichen Arbeit des Multiplizierers. Diese Zyklen werden als M1- und M2-Zyklus bezeichnet. Es wird die M1-Hardware 20.6b.10 und die M2-Hardware 20.6b.11 verwendet. Die beiden Ausführungszyklen werden durch keine Registeroperationen unterschieden. Somit müssen das XB- und das 3X-Register 20.6b.8 und das Y-Register 20.6b.9 während dieser Zyklen ihren Inhalt halten, bis die Daten im P-Register 20.6b.12 zwischengespeichert werden.
Zyklus 5 - Dieser Zyklus beinhaltet das Schreiben vom P- Register 20.6b.12 in die FPR 20.8. Wenn das Ergebnis erweitert ist, gibt es einen sechsten Zyklus, welcher ein zweiter Schreibzyklus ist, weil die Busstruktur zwischen den Chips auf einen 8-Byte-Datenbus beschränkt ist.
Die Steuerungsregister, die diese Pipe steuern sind: das FXA- Register 20.6b.1, welches den Status des XA-Registers 20.6b.6 speichert; das FYS-Register 20.6b.2, welche den Status eines temporären Registers speichert, das zu Beginn den Operand 2 eines RR-Befehls erhält; das FXB-Register 20.6b.3; das FY-Register 20.6b.4; und das FP-Register 20.6b.5, welche den Status der ihnen zugeordneten Register speichern. Diese Statusregister speichern, wie in Fig. 6b beschrieben, 12 Informationsbits.
Wir beziehen uns auf Fig. 6b. Es wird eine Beschreibung jedes Feldes der Steuerungsregister (des FXA-Registers 20.6b.1, des FYs-Registers 20.6b.2, des FXB-Registers 20.6b.3, des FY-Registers 20.6b.4 und des FP-Registers 20.6b.5) gegeben.
Es folgt die Beschreibung jedes Feldes von Fig. 6b:
1. FPR-Adreßbits (ADR) des Operanden, die verwendet werden, um Operanden zu lokalisieren, welche gesperrt sein können.
2. Ein gültiger-Befehl-Bit (VI), welches verwendet wird, um anzuzeigen, daß diese Stufe der Pipeline als Befehl gültig ist.
3. Ein gültige-Daten-Bit (VD), welches anzeigt, daß das zugeordnete Datenregister gültig ist.
4. Ein gültiges-Ergebnis-Bit (VR), welches verwendet wird, um einen lokalen Arbeitsspeicher auf einem anderen Chip zu schaffen. Bei einem RR-Befehl bleibt Operand 2 (nach der Multiplikationsoperation) im Y-Register 20.6b.9 gültig bis ein anderer Befehl dieses FPR modifiziert. Das gültiges- Ergebnis-Bit würde anzeigen, daß die Daten im Y-Register für die definierte Adresse gültig sind. Bei einem RR- und einem RX-Befehl ist ebenfalls das Produktregister 20.6b.12, welches das Ergebnis der Multiplikation enthält, mit dem durch den Operanden 1 adressierten FPR gleichwertig, bis eine andere Multiplikation durch die Pipe durchläuft oder ein anderer Befehl diese Adresse modifiziert. Dies ist für die Verbesserung der Leistungsfähigkeit von großer Bedeutung. Denn, wenn irgendein Ladevorgang eliminiert werden kann, ergibt sich normalerweise eine Verbesserung der Leistungsfähigkeit,
5. Ein Bit, um anzuzeigen, daß der Befehl vom RX-Typ ist (RX) und daß die Adreßbits ungültig sind; der Datenbus sollte bezüglich eingehender Daten überwacht werden, wenn diese noch nicht gültig sind.
6. Ein Bit, das den ersten Zyklus einer Zwei-Zyklen-Umgehung (2BY) anzeigt. Manchmal werden zwei Zyklen benötigt, um gesperrte Daten, wenn sie lokalisiert sind, wiederherzustellen.
7. Ein Bit, um anzuzeigen, daß ein erweitertes Ergebnis (EXT) in die FPR zurückgespeichert werden muß.
8. Ein Bit, um anzuzeigen, daß sich in den Registern lange Operanden (LI) befinden.
9. Ein Bit, um anzuzeigen, daß der Befehl auf dieser Stufe der Pipe ein Gleitpunktbefehl ist (FLP).
10. Ein Bit, um anzuzeigen, daß der Operand im Y-Register gesperrt ist (INTL).
Das FXA-Register 20.6b.1 und das FYS-Register 20.6b.2 werden im Zyklus eins durch die Initialisierungs-Hardware 20.5 gesetzt. Wenn keine "Konflikte" mit den XB-, 3X-Registern 20.6b.8 auftreten, wird das FXB-Register 20.6b.3 vom FXA-Register 20.6b.1 aus gesetzt. Wen keine "Konflikte" mit dem Y-Register 20.6b.9 auftreten, wird das FY-Register 20.6b.4 durch die Initialisierungs-Hardware 20.5 gesetzt, oder aber ein FYS-Register 20.6b.2 "Konflikt" kann die folgende Form annehmen:
M1 ist gültig oder
M2 ist gültig und ein P-Register-Konflikt oder
XA ist seit der vorhergehenden Multiplikation schon gültig und
ein XB-Konflikt
Das FP-Register 20.6b.5 wird durch das FXB-Register 20.6b.3 gesetzt, wenn M2 gültig ist und kein Konflikt mit dem P-Register 20.6b.12 auftritt. Das gültiges-Ergebnis-Bit des FP-Registers 20.6b.5 wird separat gespeichert, weil es von anderen Schreiboperationen in die FPR abhängig ist. Somit wird die Multiplikations-Pipe durch die internen Pipe-Steuerungen überwacht, welche die Daten so weit wie möglich durch die Pipe schieben, bis interne Hasards auftreten, welche eine Beendigung der Befehle in dieser Pipe verhindern.
Wir beziehen uns auf Fig. 7. Darin wird die Pipe 3 20.6c dargestellt, welche für Ladebefehle vom RX-Typ verwendet wird.
Die Pipe 3 20.6c von Fig. 7 umfaßt zwei Zyklen, während derer keine Verarbeitung der Daten erfolgt. Die Daten fließen nur durch die Pipe. Der Befehl wird von dem Decodierer 20.2 decodiert und die FPU wartet auf das passende DBUS-Gültig-Signal von der DBUS-Stapelspeicher-Steuerungen 20.10. Die Daten, die empfangen und in das DREG 20.9.1 des DBUS-Stapelspeichers 20.9 weitergeleitet werden, werden während Zyklus 1 empfangen. Dann werden die Daten im Zyklus 2 zu den FPR 20.8 gesendet. Die Steuerungen, die dies überwachen, sind das DREG-Gültigkeits-Register 20.10.1 der DBUS-Stapelspeicher-Steuerungen 20.10 und der Rest der DBUS-Stapelspeicher-Steuerungen 20.10.
Wir beziehen uns auf Fig. 8. Darin wird Pipe 4 20.6d dargestellt, welche Zusatzfunktionen ausführt.
Die in Fig. 8 dargestellte Pipe 4 20.6d umfaßt indirekte Adreßregister (IND ADR REG) 20.6d.1 die mit einem Ausgang des DREG 20.9.1 verbunden sind, welches einen Teil des DBUS-Stapelspeichers 20.9 von Fig. 2 bildet, ein Statuswort-Register 20.6d.2, das mit dem mit dem Ausgang des DREG 20.9.1 verbunden ist, Wiederholungs-Statusregister 20.6d.3, die mit einem CBUS-Register verbunden sind und ein Register für den indirekten Adreßmodus 20.6d.4, das init dein CBUS-Register verbunden ist. Das Statuswort-Register 20.6d.2 und das Wiederholungs-Statusregister 20.6d.3 sind über ihre Ausgänge mit dem DREG 20.9.1 und den FPR 20.8 verbunden. Die Daten werden vom DBUS in die indirekten Adreßregister (IND ADR REG) 20.6d.1 und die Statuswort-Register (STATUS WORT) 20.6d.2 geladen. Die indirekten Adreßregister 20.6d.1 werden im Mikrocode-Modus verwendet und enthalten Adressen der FPRs 20.8. Die Statuswort-Register 20.6d.2 speichern den Status der FPU. Ein solcher Status besteht aus der Statusinformation bezüglich der Ausnahmebedingungen und dem Status der Prüfeinrichtungen.
In Fig. 8 gibt es fünf grundlegende Gruppen Befehle, welche die Zusatzfunktionen in Pipe 4 20.6d ausführen:
1. Die Gruppe RR-Laden - Dies sind grundsätzlich Ein-Zyklus- Operationen, wobei ein Lesen (möglicherweise eine einfache Bitmanipulation) ausgeführt wird, der ein Schreiben in die FPR 20.8 folgt.
2. Die Befehlsgruppe RX-Laden arbeitet mit anderen Registern als den FPR 20.8, beispielsweise mit den indirekten Adreßregistern und den Statuswort-Registern.
3. Die Befehle in dieser dritten Gruppe umfassen zwei Zyklen: Zyklus Eins beinhaltet das Warten darauf, daß das DREG-Gültig-Register 20.10.1 gültig wird, während das DREG 20.9.1 geladen wird und Zyklus Zwei beinhaltet das Laden des DREG- Gültig-Registers 20.10.1 aus dem DREG 20.9.1. Befehle, welche auf der Basis von CBUS-Informationen Register setzen, sind ebenfalls in dieser Kategorie enthalten. Solche Register können das Wiederholungs-Statusregister 20.6d.3, welches die Wiederholungs-Information speichert und das Register für den indirekten Adreßmodus 20.6d.4 sein, welches das Modusbit zu Adressierungszwecken speichert.
4. Die Gruppe RX-Speichern beinhaltet das Lesen der FPRs 20.8 und das Speichern im DREG im Zyklus 1. Im Zyklus 2 werden die Daten des Datenbusses getrieben und es wird die Gültigkeit des DBUS signalisiert.
5. Die letzte Befehlsgruppe sind Abspeicher-Befehle, welche den Inhalt eines Registers, nicht den der FPRs 20.8, innerhalb von zwei Zyklen auf den Datenbus legen. Die zwei Registertypen, die auf diese Weise gelesen werden können, sind die Statuswort-Register 20.6d.2 und die Wiederholungs-Statusregister 20.6d.3.
Es gibt keine Steuerungsregister, die der Arbeit der Pipe 4 zugeordnet sind, außer in den Fällen, in denen die DBUS-Stapelspeicher-Steuerungsregister 20.10 anwendbar sind.
Wir beziehen uns auf Fig. 9. Darin werden der DBUS-FIFO-Stapelspeicher 20.9 und die DBUS-Stapelspeicher-Steuerungen 20.10 dargestellt.
Die DBUS-Stapelspeicher-Steuerungen 20.10 von Fig. 9a umfassen das DREG-Gültig-Register 20.10.1, das DCBUS-Register 20.10.2, den Decodierer 20.10.3, das DS5-Register 20.10.4, das DS4-Register 20.10.5, das DS3-Register 20.10.6, das DS2-Register 20.10.7, das DS1-Register 20.10.8, das S2-Gültig-Register 20.10.9, das S1-Gültig-Register 20.10.10 und die Multiplexer- Auswahl-Logik 20.10.11. Der DBUS-Stapelspeicher 20.9 umfaßt das S2-Register 20.9.3, das mit dem DBUS verbunden ist, das S1-Register 20.9.2, das mit dem Ausgang des S2-Registers und mit dem DBUS verbunden ist und das DREG-Register 20.9.1, das mit dem Ausgang des S1-Registers und mit dem DBUS verbunden ist.
Die Bits innerhalb der Register DS1 bis DS5 (20.10.8 bis 20.10.4 von Fig. 4) haben folgende Bedeutung:
Die Bits 0 bis 2, welche die Befehlsadresse anzeigen; die drei Bits, zeigen, wenn sie nicht Null sind, an, daß Datenteile geladen werden sollen, die über Wortgrenzen reichen, so daß zwei DBUS-Gültig-Signale erforderlich sind, eines für jeden Datenteil.
Die Bits 3 und 4, welche die Pipe-Nummer darstellen, identifizieren eindeutig die Pipe, zu der die Daten übertragen werden sollen.
Bit 5 ist ein Gültiger-Befehl-Bit.
Bit 6 zeigt an, daß sich die Daten für diesen Befehl im DREG 20.9.1 des DBUS-Stapelspeichers befinden, wie in den Fig. 2 und 9a dargestellt.
Bit 7 zeigt an, daß sich die Daten für diesen Befehl im S1- Register 20.9.2 des DBUS-Stapelspeichers befinden, wie in den Fig. 2 und 9a dargestellt.
Bit 8 zeigt an, daß sich die Daten für diesen Befehl im S2- Register 20.9.3 des DBUS-Stapelspeichers befinden, wie in den Fig. 2 und 9a dargestellt.
Fig. 9 zeigt an, daß der Befehl gerade ausgeführt wird und daß die geeignete Pipe initialisiert worden ist.
Wenn Daten empfangen werden, muß deren Weg zum passenden Befehl gefunden werden, welcher dann wie oben beschrieben durch die Pipes geschoben wird. Dies erzeugt einen chaotische Zustand. Dieser chaotische Zustand, in dem die Daten ihren Weg zum richtigen Befehl finden müssen, wird tiefgründiger im folgenden Abschnitt beschrieben.
Die Daten für eine Operation, die normale RR-Operationen beinhaltet, kommen aus den FPR 20.8, wenn nicht eine Sperre vorhanden ist. In jenem Fall finden die lokalen Pipe-Steuerungen die passenden Daten durch Vergleichen der Adreßfelder der Statusregister aller Pipes. Bei RX-Operationen ist dies ein klein wenig schwieriger. Operand Eins wird auf dieselbe Weise gefunden, Operand Zwei kommt jedoch vom Datenbus. Wenn der Daten-Cache oder eine andere Buseinheit aufgefordert wird, die Daten gleichzeitig mit dem Empfang des Befehls durch die FPU zu liefern, die andere Buseinheit, die aufgefordert ist, die Daten zu liefern aber BESETZT sein kann, kann der Empfang der Daten durch die FPU zu dem Empfang des Befehls durch die FPU asynchron erfolgen. Als ein Ergebnis dessen, kann ein positiver oder negativer Überlauf der Daten auftreten. Die DBUS-Stapelspeicher-Steuerungen 20.10 informieren die lokalen Pipe-Steuerungen 20.6, wenn das DREG 20.9.1 für ihre Pipe gültig ist. Das ist für die Trennung der Daten von entscheidender Bedeutung, speziell wenn mehrere Pipes auf Daten vom Datenbus warten und der Datenbus gültig wird. Deshalb verknüpft der DBUS-Stapelspeicher die Daten mit den Befehlen. Nachdem dies erreicht ist, schieben die Pipe-Steuerungen 20.6 die Daten durch die Pipe und erwarten die Freigabe durch die globale Dynamische Ablaufprotokolltabelle 20.7, die die Beendigung der Befehlsausführung freigibt (wie weiter unten diskutiert werden wird, besteht die Beendigung der Befehlsausführung darin, daß die Pipe-Nummer des ältesten Befehls in der dynamischen Ablaufprotokolltabellendatei 20.7, d.h. der unterste Eintrag in der Tabelle, mit der Pipe-Nummer der entsprechenden Pipe übereinstimmen muß). Somit wird der Datenfluß vom Beginn bis zum Ende gesteuert. Die DBUS-Stapelspeicher-Steuerungen 20.10 werden außerdem deshalb benötigt, weil der Speicher die Daten liefert, wenn er kann, unabhängig davon, wann die Daten angefordert wurden. Somit sind ein positiver und negativer Datenüberlauf möglich. Ein negativer Überlauf tritt auf, wenn der Speicher beim Bereitstellen der Daten langsam ist und verschiedene Pipes initialisiert worden sind, mit er Ausnahme, wenn ein aus dem Speicher stammender Operand (RX-Typ) fehlt. Weil verschiedene Pipes auf Daten warten können, werden Steuerungen benötigt, die die Daten nach den Pipes sortieren, zu welchen die Daten übertragen werden sollen, wenn diese schließlich eintreffen. Ein positiver Überlauf tritt auf, wenn eine Pipe oder mehrere Pipes voll sind und verschiedene Befehle, welche Daten aus dem Speicher benutzen, von der CPU gleichzeitig zur Gleitpunkteinheit (FPU) und zum Speicher übertragen werden. Dies bewirkt, daß der Speicher Daten an die Gleitpunkteinheit sendet. Diese kann die Daten nicht sofort in eine geeignete Pipe schieben. Deshalb müssen die Daten gestapelt und mit der entsprechenden Pipe-Nummer identifiziert werden, zu der die Daten nachfolgend übertragen werden müssen.
Wir beziehen uns auf Fig. 10. Darin wird die Handshake- und globale Hasard-Schaltung 20.3 dargestellt.
Die Handshake- und globale Hasard-Schaltung 20.3 umfaßt eine Konflikt-Erkennungsschaltung für neuen Befehl in Pipe 1 20.3.1, eine Konflikt-Erkennungsschaltung für neuen Befehl in Pipe 2 20.3.2, eine Konflikt-Erkennungsschaltung für neuen Befehl in Pipe 3 20.3.3 und eine Konflikt-Erkennungsschaltung für neuen Befehl in Pipe 4 20.3.4. Alle diese Schaltungen sind mit den internen Pipe-Steuerungen 20.6 und der Decodierschaltung 20.2 von Fig. 2 verbunden. Eine globale Konflikt-Erkennungsschaltung 20.3.5 ist mit der dynamischen Ablaufprotokolltabelle 20.7 verbunden und ist bezüglich des Quittungsaustausches mit den anderen Einheiten verantwortlich für das Senden eines "FPU BESETZTSIGNALS" an die CPU des Computersystems und für Senden eines "EINHEIT BESETZTSIGNALS" an die Initialisierungsschaltung 20.5. Eine kombinatorische Handshake-Logikschaltung 20.3.6 ist mit der globalen Konflikt-Erkennungsschaltung 20.3.5 verbunden und ist bezüglich des Quittungsaustausches mit den anderen Einheiten verantwortlich für das Senden eines "FPU BEREIT"-Signals an die CPU des Computersystems und für Senden eines "BEFEHL GÜLTIG"-Signals an die Initialisierungsschaltung 20.5. Schließlich ist eine koinbinatorische Handshake-Logikschaltung 20.3.7 mit der kombinatorischen Handshake-Logikschaltung 20.3.6 und mit der Schaltung zur Behandlung von Ausnahmebedingungen 20.11 verbunden, um ein "FPU UNTERBRECHUNG"-Signal an die CPU des Computersystems zu übertragen.
Die Eingangssignale der Handshake- und globalen Hasard-Schaltung 20.3 von Fig. 10 umfassen die Handshake-Signale von den anderen PBUs sowie Signale von den internen Pipe-Steuerungen 20.6, von der dynamischen Ablaufprotokolltabelle 20.7 und von der Decodierschaltung 20.2. Die Decodierschaltung-Signale informieren die Handshake-Schaltung 20.3 darüber, ob ein neuer Befehl auf dem CBUS anliegt und in welcher Pipe der neue Befehl ausgeführt werden muß. Die Signale von den internen Pipe-Steuerungen zeigen für jede Pipe an, ob es irgendwelche Hasards in der ersten Stufe der Pipe gibt. Die Handshake-Signale von den anderen Einheiten werden von der Handshake-Schaltung 20.3 daraufhin überwacht, ob außerhalb der FPU Hasards aufgetreten sind. Die Signale von der dynamischen Ablaufprotokolltabelle zeigen an, ob es irgendwelche globalen internen Hasards gibt. Wenn keine Hasards aufgetreten sind und es in der Pipe, in welcher der neue Befehl ausgeführt werden inuß, keine Konflikte gibt, wie dies in Fig. 10 dargestellt wird, wird von der kombinatorischen Handshake-Logik ein "FPU BEREIT" an die CPU und die anderen Buseinheiten gesendet (außer in dem Fall, wenn der Befehl für mehr als eine Buseinheit bestimmt ist und dann das Bereitschaftssignal unterdrückt wird).
Wenn ein neuer Befehl vorhanden ist, aber Hasards oder Konflikte aufgetreten sind, wird ein "EINHEIT BESETZT" an die Initialisierungsschaltung und ein "FPU BESETZT" an die CPU und die anderen PBU gesendet. Zusätzlich wird der neue Befehl im CBUS-Register 20.1.2 des Befehls-Stapelspeichers 20.1 von Fig. 3 zwischengespeichert und im nächsten Zyklus wiederum als ein neuer Befehl betrachtet und dies immer so weiter, bis ein Zyklus erreicht wird, während dessen dieser Befehl angenommen werden kann (die FPU bereit ist). "BEFEHL GÜLTIG" wird an die Initialisierungsschaltung gesendet und dies ist ein frühzeitiges Signal dafür, welches anzeigt, daß der Befehl im CBUS-Register die entsprechenden CPU-Meldungen aufweist, die anzeigen, daß es ein Befehl ist, den die FPU ausführen soll. Dies erfolgt unabhängig von Hasards oder Konflikten. Das letzte Signal, das von dieser Einheit gesendet wird, ist das "FPU UNTERBRECHUNG", welches an die CPU gesendet wird, um eine Ausnahmebedingung anzuzeigen. Dieses Signal muß von der Schaltung zur Behandlung von Ausnahmebedingungen 20.11 weitergeleitet werden, welche die Ausnahmebedingung bestimmt, weil diese von den Reaktionen der anderen PBU auf vorhergehende Befehle abhängig ist. In einem Computer mit Pipeline werden mehrere Befehle parallel ausgegeben und ausgeführt. Als ein Ergebnis dessen können verschiedene Ausnahmebedingung in ein und demselben Zyklus auftreten. Wenn der Befehlssatz zum SISD- Modus gehört, müssen Ausnahmebedingung so behandelt werden, als ob die Befehle nacheinander ausgeführt würden. Dies erfolgt durch verknüpfen des FPU UNTERBRECHUNG-Signals mit Bedingungen, die aus den Handshake-Steuersignalen abgeleitet werden. Somit wird die Handshake- und globale Hasard-Erkennung durch die Handshake- und globale Hasard-Schaltung 20.3 von Fig. 10 und Fig. 2 durchgeführt.
Wir beziehen uns auf Fig. 11. Darin wird die Initialisierungsschaltung 20.5 dargestellt.
Die Initialisierungsschaltung 20.5 von Fig. 11 reagiert auf Ausgangssignale von der Handshake- und globalen Hasard-Schaltung 20.3, von der Decodierschaltung 20.2 und vom MIMD/SISD-Schalter 20.4. Die Ausgangssignale von der Handshake- und globalen Hasard-Schaltung 20.3 sind das BEFEHL GÜLTIG-Signal und das BEREIT-Signal. Das Ausgangssignal der Decodierschaltung 20.2 enthält die folgenden Informationen: eine Längeninformation (LÄNGE), die sich auf die Länge der Daten des Befehls bezieht (bei Daten kurzer Länge mit Nullen gefüllt); eine Schreibtyp-Information (SCHREIBTYP), die Adreßinformationen bereitstellt, wenn ein Schreiben in die Gleitpunktregister (FPR) 20.8 ausgeführt wird; FPR-Adreßinformationen (FPR ADRESSE), die sich auf die Adreßinformation beziehen, wenn Daten aus den FPR 20.8 wiederherstellt werden sollen; RX-Befehlsinformationen (RX), die anzeigen, ob der in die Initialisierungsschaltung eingegebene Befehl ein Befehl vom RX-Typ ist (Bei einem Befehl vom RX-Typ kommt der zweite Teil der Befehlsdaten über den DBUS aus dem Hauptspeicher und nicht aus den FPR 20.8); "ETC"-Informationen, die beliebige andere von den Pipe-Steuerungen für die Pipes 20.6a bis 20.6d benötigte Informationen bereitstellen können; und die Pipe-Nummer (PIPE NR), welche die Pipe-Nummer angibt, der Kennzeichner für eine der Pipes 20.6a bis 20.6d. Die Decodierschaltung 20.2 stellt die Pipe-Nummer bereit, weil jede der Pipes 20.6a bis 20.6d auf Funktionen spezialisiert ist, die den speziell zugeordneten Befehlen entsprechen und die Decodierschaltung 20.2 auf Grund ihrer Decodierfunktion weiß, welcher Befehlstyp in die Initialisierungsschaltung 20.5 eingegeben wird und damit in welche Pipe der spezielle eingehende Befehl zur Ausführung geschoben werden soll. Das Ausgangssignal des MIMD/SISD-Schalters 20.4 liefert Informationen, die sich auf die "Position" des MIMD/SISD-Schalters 20.4 beziehen. Die Initialisierungsschaltung 20.5 umfaßt einen ersten Multiplexer 20.5.1, einen zweiten Multiplexer 20.5.2, einen dritten Multiplexer 20.5.3, einen vierten Multiplexer 20.5.4 und einen fünften Multiplexer 20.5.5, wobei jeder Multiplexer dasselbe Auswahlsignal und dasselbe Informationssignal empfängt. Das Auswahlsignal wählt in Abhängigkeit von der binären Bitdarstellung des Auswahlsignals den spezifischen Multiplexer aus. Das Informationssignal wird durch den ausgewählten Multiplexer durchgeschaltet, der gemäß dem Auswahlsignal ausgewählt wird. Das Auswahlsignal umfaßt (1) die BEFEHL GÜLTIG/BEREIT - Ausgangssignale von der Handshake- und globalen Hasard-Logik 20.3 und (2) das Pipe-Nummer- "PIPE NR" Ausgangssignal von der Decodierlogik 20.2. Das Informationssignal umfaßt (1) die Länge, (2) den Schreibtyp, (3) die FPR-Adresse, (4) RX, (5) MIMD/SISD und (6) die anderen Informationen "ETC". Im Betrieb, wenn ein spezieller Multiplexer (einer der 20.5.1 bis 20.5.5) über das Auswahlsignal, das das PIPE NR-Signal und die BEFEHL GÜLTIG/BEREIT-Signale enthält, ausgewählt wird, wird das Informationssignal, das die Längeninformation, die Schreibtyp- Information, die FPR-Adressen-Information, Die RX-Befehl-Information, die MIMD/SISD-Schalter-Information und die anderen Informationen enthält, zu einer der Pipe 20.6a bis 20.6d und/oder zur dynamischen Ablaufprotokolltabelle 20.7 durchgeschaltet.
Eine Beschreibung der Arbeitsweise der dynamischen MIMD-Pipeline 20 der vorliegenden Erfindung wird mit Bezug auf die Fig. 2 bis 8 der Zeichnungen im folgenden Abschnitt gegeben.
Wir beziehen uns auf Fig. 2 und nehmen an, daß eine Vielzahl von Befehlsfolgen, von denen jede eine Vielzahl von Befehlen enthält, auf die Ausführung durch die Prozessoren warten, die innerhalb der Pipeline-Schaltungen 6 von Fig. 2 angeordnet sind. Eine Auswahlschaltung, die in den Zeichnungen nicht dargestellt ist, wählt aus der Vielzahl der Befehlsfolgen Befehle aus, welche in die dynamische MIMD-Pipeline 20 von Fig. 2 eingegeben werden sollen. Diese Befehl werden einer nach dem anderen über den CBUS in die dynamische MIMD-Pipeline 20 eingegeben. Wenn ein Befehl zu der dynamischen MIMD-Pipeline, die in der FPU von Fig. 2 angeordnet ist, über den CBUS übertragen wird, wird er im Decodierer 20.2 decodiert und es wird festgestellt, ob dieser Befehl zu denen gehört, die in der FPU ausgeführt werden können. Der Empfang eines solchen Befehls wird durch die Handshake- und globale Hasard-Schaltung 20.3 quittiert (ein Bereitschafts-Handshake-Signal wird von der Handshake-Schaltung 20.3 an die CPU zurückgesendet) und der Befehl wird sobald als möglich ausgeführt. Die CPU wird kontinuierlich Befehle an die in Fig. 2 dargestellte FPU senden, ohne anzuhalten, wenn angenommen wird, daß eine kontinuierliche FPU-Verarbeitung möglich ist. Wir nehmen an, daß die Daten und die Befehle einer Befehlsfolge, einer Vielzahl von Befehlsfolgen oder eines einzelnen Befehls anliegen und bereit sind, über den CBUS in die FPU eingegeben zu werden. Dann wird die FPU: die Befehle durch den Decodierer 20.2 decodieren, einen zu jedem Zeitpunkt, entscheiden, ob die Pipeline im SISD- oder im MIMD-Modus arbeiten soll und dies über den MIMD/SISD-Schalter 20.4 vorgeben, mittels der globalen Hasard- Logik 20.3 bestimmen, ob irgendwelche Hasards aufgetreten sind, mittels der Decodierlogik 20.2 und der Initialisierungslogik 20.5 bestimmen, welche Pipe 20.6a bis 20.6d den Befehl ausführen wird, mittels der dynamischen Ablaufprotokolltabelle 20.7 festlegen, wann die entsprechende Pipe 20.6a bis 20.6d die Ausführung beendet, so daß ein eingehender Befehl zur Ausführung wieder eingegeben werden kann, und wenn alle oben beschriebenen Dinge erledigt sind, wird die FPU versuchen den (die) Befehl (e) auszuführen, indem die Befehle mit maximaler Geschwindigkeit, einer zu jedem Zeitpunkt, in die Pipeline-Struktur 20.6 eingegeben werden. Die Initialisierungslogik 20.5 wird zusammen mit der globalen Hasard-Schaltung 20.3 entscheiden, ob eine Befehlsfolge gestartet oder beendet wird und wird die CPU über den normalen oder abnormalen Abschluß sowohl einer Befehlsfolge als auch einzelner Befehle informieren. Auf Grund des möglichen Auftretens von Hasards wird die Initialisierungslogik 20.5 zusammen mit der globalen Hasard-Steuerungslogik 20.3 entscheiden, wann eine der Pipelines 20.6a bis 20.6d verwendet werden soll und wann Befehle benötigt werden. Es sei daran erinnert, daß die Pipes 20.6a bis 20.6d darauf spezialisiert sind, bestimmte Kategorien von Befehlen zu verarbeiten. Wenn ein eingehender neuer Befehl mittels Decodierer 20.2 decodiert wird, wird der Befehlstyp bestimmt und somit die spezielle Pipe identifiziert, die verwendet werden soll. Die Initialisierungslogik 20.5 empfängt die Pipe-Nummer von der Decodierlogik 20.2 und überträgt den neuen Befehl in Übereinstimmung mit der empfangenen Pipe-Nummer über die Multiplexer 20.5.1 bis 20.5.5 zu der entsprechenden Pipeline-Schaltung, eine der Schaltungen 20.6a bis 20.6d. Wenn der Befehl in einer der Pipes 20.6a bis 20.6d eingegeben wird, wird die dynamische Ablaufprotokolltabelle 20.7 aktualisiert, so daß die Identität der Pipe, in welche der Befehl zur Ausführung eingegeben wurde, aufgezeichnet wird. Weil die Pipes 20.6a bis 20.6d mit der dynamischen Ablaufprotokolltabelle 20.7 in einer Art Rückkopplungsschaltung verschaltet sind, wird der Status der Ausführung des speziellen Befehls in der Pipe kontinuierlich in der dynamischen Ablaufprotokolltabelle aufgezeichnet. Deshalb wird, wenn ein weiterer neuer Befehl mittels des Decodierers 20.2 und der Initialisierungsschaltung 20.5 als zu einer speziellen Pipe zugehörig identifiziert wurde und fertig ist, in die spezielle Pipe eingegeben zu werden, die in den Pipe-Steuerungen gespeicherte Information gelesen, die der ersten Stufe der speziellen Pipe zugeordnet ist, um festzustellen, ob innerhalb der speziellen Pipe interne Hasards aufgetreten sind, wie beispielsweise gesperrte Daten oder ob die Pipe voll ist. Der weitere neue Befehl kann, wenn die Pipe mit Befehlen gefüllt ist oder interne Hasards aufgetreten sind, nicht in die Pipe eingegeben werden. In Tabelle 20.7 wird dann nachgeschlagen, um festzustellen, ob die Pipe-Nummer der speziellen Pipe in der Pipe- Nummern-Spalte des untersten Eintrags der Tabelle 20.7 steht. Wenn zum Beispiel die spezielle Pipe durch die Nummer X identifiziert wird und drei Pipeline-Stufen besitzt und wenn die Tabelle 20.7 drei Einträge enthält, die die Pipe-Nummer X in der Pipe-Nummern-Spalte anzeigen, dann ist die Pipe X mit Befehlen gefüllt und der älteste Befehl in der Pipe X muß beendet werden, bevor der weitere neue Befehl in die Pipe eingegeben werden kannu Wenn der älteste (unterste) Eintrag in der Tabelle 20.7 die Pipe-Nummer X in der Pipe-Nummern-Spalte anzeigt, darf der ältesten Befehl in der Pipe X beendet werden, was Raum schafft für die Eingabe des weiteren neuen Befehls und zu dessen Ausführung. Zusammenfassend ist zu sagen, daß die Tabelle 20.7 gemeinsam mit den internen Pipe-Steuerungen 20.6a bis 20.6d kontinuierlich abgefragt wird, um die richtige Verwendung der einzelnen Pipelines sicherzustellen und um zu gewährleisten, daß die Befehle vom Beginn bis zur Beendigung richtig verarbeitet werden. Jede einzelne der Pipelines 20.6a bis 20.6d führt eine Kategorie von Befehlen aus, und wird von außen durch die in der dynamischen Ablaufprotokolltabelle 20.7 gespeicherten Informationen und durch die Initialisierungslogik 20.5 gesteuert. Die interne Steuerung erfolgt durch die internen Pipe-Steuerungen. Wenn möglich führt jede der Pipelines 20.6a bis 20.6d mehrere Befehle aus, die zu einer Vielzahl von Befehlsfolgen gehören und jede der Pipelines 20.6a bis 20.6d wird durch die ihr entsprechenden Pipeline-Steuerungen (siehe 20.6a bis 20.6d) so gesteuert, daß eine maximale Nutzung der Pipeline gewährleistet ist.
Eine Beschreibung der Arbeitsweise der dynamischen Ablaufprotokolltabelle 20.7 wird mit Bezug auf die Fig. 2 und 4 der Zeichnungen im folgenden Abschnitt gegeben.
Wir beziehen uns auf Fig. 4. Wenn das Bereitschaftssignal von der Handshake-Schaltung 20.3 gesendet wird oder wenn das Besetztsignal durch die Handshake-Schaltung zurückgenommen wird, wird der eingehende Befehl in eine Zeile der dynamischen Ablaufprotokolltabelle 20.7 eingetragen. Die Tabelle 20.7 enthält einige Parameter, welche benötigt werden, um festzulegen, wie der eingehende Befehl beendet werden soll. Der Schlüsselparameter ist die Pipe-Nummer (PIPE NR), welche anzeigt, in welcher der Pipes sich der jeweilige Befehl befindet. Somit wird, weil eine Ausführung der Befehle in der richtigen Reihenfolge gewährleistet werden muß, um den Beschränkungen der Rechnerarchitektur zu entsprechen, die Ablaufprotokolltabelle 20.7 in jedem Zyklus gelesen, um anzuzeigen, welche Pipe 20.6a bis 20.6d der Pipeline-Schaltung 20.6, die nächste Pipe ist, in der die Ausführung eines eingegebenen Befehls beendet wird. Die während jedes Zyklus aus der Tabelle 20.7 gelesenen Information wird dann mit dem internen Status der ausgewählten Pipe verglichen (über deren Statusregister), um festzustellen, ob die Pipe darauf wartet, die Ausführung eines Befehls zu beenden. Wenn dies so ist, wird die Ausführung des Befehls beendet, und der entsprechende Eintrag in der dynamischen Ablaufprotokolltabelle 20.7 wird aus der Ablaufprotokolltabellendatei 20.7 gestrichen. Anders ausgedrückt, wenn eine Pipe mit der Nummer X Befehle in sich hat, die darin ausgeführt werden und die Pipe-Nummer X ist in dem ältesten (untersten) Eintrag der Pipe-Nummern-Spalte der dynamischen Ablaufprotokolltabellendatei 20.7 aufgezeichnet, dann besteht die Beendigung eines solchen Befehls in der Pipe X darin, daß die in der Tabelle 20.7 gespeicherten Parameter, die dem ältesten (untersten) Befehl in der dynamischen Ablaufprotokolltabellendatei 20.7 entsprechen, mit dem Status der Pipe X verglichen werden, wie er durch deren Statusregister anzeigt wird. Wenn die Statusregister der Pipe X anzeigen, daß die innere Ausführung des ältesten Befehls beendet ist, führt die weitere Verarbeitung dazu, daß der älteste Befehl aus der Pipe X herausgeschoben und zu seinem Ziel übertragen werden. Der Inhalt der Pipe X wird um eine Stufe verschoben, was Raum schafft für die Eingabe und Ausführung eines weiteren neuen Befehls in der Pipe X.
Eine Beschreibung der Arbeitsweise des DBUS-Stapelspeicher 20.9 und der DBUS-Stapelspeicher-Steuerungen 20.10 wird mit Bezug auf Fig. 9 der Zeichnungen im folgenden Abschnitt gegeben.
In Fig. 9a sind zwei FIFO-Stapelspeicher dargestellt: ein Stapelspeicher für Befehle, d.h. die Register DS1 bis DS5 20.10.8 bis 20.10.4 der DBUS-Stapelspeicher-Steuerungen 20.10 und ein Stapelspeicher für Daten, d.h. DREG 20.9.1, das S1-Register 20.9.2 und das S2-Register 20.9.3 des DBUS-Stapelspeichers 20.9. Der Befehlsstapel wird durch Decodieren der CBUS-Signale erhalten. Um dies zu erreichen wird ein weiteres Register benötigt, das DCBUS-Register 20.10.2, welches unabhängig von den Besetztsignalen das CBUS-Signal während jedes Zyklus zwischenspeichert. Die Decodier-Hardware 20.10.3 zeigt im Zusammenhang mit der Kenntnis der vorhergehenden Besetztsignale an, wann ein neuer DBUS-Ladebefehl für die FPU anliegt. Somit wird die Information, die sich auf jeden Befehl vom Typ DBUS-Laden bezieht, so lange erhalten, bis die Daten eingegangen sind und der Befehl beginnt. Andere bedeutende Statusregister sind die Register DREG Gültig 20.10.1, S1 Gültig 20.10.10 und S2 Gültig 20.10.9, von denen jedes zwei Bits umfaßt und die anzeigen, ob die Daten teilweise oder vollständig gültig sind. Ein positiver Datenüberlauf tritt ein, wenn sich in den DS-Registern 20.10.4 bis 20.10.8 Befehle befinden aber nicht ausgeführt werden und Daten in dem Daten-Stapelspeicher 20.9.1 bis 20.9.3 stehen. Ein negativer Datenüberlauf tritt auf, wenn verschiedene Befehl in den DS-Registern 20.10.4 bis 20.10.8 stehen, sich aber nicht genügend Daten in dem Daten-Stapelspeicher 20.9.1 bis 20.9.3 befinden. Eingehende Daten werden in den S2-, S1- und DREG-Registern 20.9.1 bis 20.9.3 des DBUS-Stapelspeichers 20.9 gestapelt und eingehende Befehle werden in den DS5- bis DS1-Registern 20.10.4 bis 20.10.8 der DBUS-Stapelspeicher-Steuerungen gestapelt, wobei eine Eins-zu-Eins-Beziehung zwischen den gestapelten Befehlen, die DBUS-Daten benötigen und den gestapelten Daten besteht. Weil die eingehenden Daten im DBUS-Stapelspeicher 20.9 gestapelt werden und die eingehenden Befehle in den DBUS-Stapelspeicher-Steuerungen 20.10 gestapelt werden, muß, wenn ein Satz Daten auf dem DBUS eintrifft und zur Eingabe in eine der Pipes 20.6a bis 20.6d bereit ist, festgestellt werden, welche der Pipes 20.6a bis 20.6d den Datensatz erhält. Weil eine Eins-zu-Eins-Beziehung zwischen den Daten, die in den S2-, S1- und DREG-Registern des DBUS-Stapelspeichers 20.9 gestapelt sind und den Befehlen, die in den DS3-, DS2- und DS1-Registern der DBUS-Stapelspeicher- Steuerungen 20.10. gestapelt sind, besteht, werden die eingehenden Daten zu der Pipe (eine der Pipes 20.6a bis 20.6d) weitergeleitet, deren Nummer in den Bitpositionen 3 und 4 des untersten der Daten-Stapelspeicher-Steuerungsregister DS5 bis DS1, des DS1-Registers 20.10.8, steht (man erinnere sich, daß innerhalb der Register DS1 bis DS5 die Bits 3 und 4 die Pipe-Nummer repräsentieren, um die Pipe, zu welcher die Daten übertragen werden sollen, eindeutig zu identifizieren).
Wir beziehen uns auf Fig. 12. Um die Arbeitsweise der dynamischen MIMD-Pipeline der vorliegenden Erfindung weitergehend zu beschreiben, wir diese anhand einer einfachen Befehlsfolge dargestellt. Mit Bezug auf die Fig. 2 bis 11 wird die Art und Weise, in der eine Befehlsfolge durch die in Fig. 2 dargestellte Hardware hindurchgeht, in den folgenden Abschnitten erläutert.
Wir betrachten die folgenden drei Befehle, welche eine Befehlsfolge bilde: (1) ein Lade RX in FPR1, (2) eine Multiplikation RR lang von FPR1 und FPR2, wobei das lange Ergebnis in FPR1 gespeichert wird und (3) eine Addition RR lang von FPR3 und FPR4, wobei das lange Ergebnis in FPR3 gespeichert wird. Die folgenden Beobachtungen werden bei Betrachtung dieser Befehlsfolge gemacht: (a) jeder Befehl benötigt für seine Ausführung eine andere Pipe; (b) der Lade-Befehl schreibt in ein Register, das durch den Multiplikationsbefehl benutzt wird - dieser Konflikt könnte ein Sperren der Daten bewirken, wenn der Multiplikationsbefehl vor dem Schreiben (Laden) stattfindet; und (c) der Additionsbefehl erfordert keine Verwendung von FPRs 20.8, die durch einen der anderen vorhergehenden Befehle in der Befehlsfolge benutzt wurden. Im folgenden wird eine zyklusweise Beschreibung dazu gegeben, wie die Befehlsfolge durch die Hardware von Fig. 2 verarbeitet würde.
Zyklus 0 - Die CPU sendet einen Lade-RX-Befehl auf dem CBUS an die FPU und das CBUS-Signal wird in dem CBUS-Register 20.1.2 von Fig. 3 und dem DCBUS-Register 20.10.2 von Fig. 9 zwischengespeichert.
Zyklus 1 - Lade-RX wird durch die Decodierschaltung 20.2 von Fig. 2 und die Decodierschaltung 20.10.3 der DBUS-Stapelspeicher-Steuerungen 20.10 von Fig. 9 decodiert. Die Handshake- und globale Hasard-Schaltung 20.3 von Fig. 2 und Fig. 10 stellt durch überprüfen der internen Pipe-Steuerung von Pipe 3 20.6c fest, daß dem Beginn eines Ladebefehls keine Probleme entgegenstehen und daß keine globalen Hasards aufgetreten sind, wie aus der Überprüfung der dynamischen Ablaufprotokolltabelle 20.7 hervorgeht. Somit wird von der Handshake- und globalen Hasard-Schaltung 20.3 ein Bereitschaftssignal (FPU BEREIT) an die Initialisierungsschaltung 20.5 gesendet, welche Pipe 3 20.6c initialisiert (FPU BEREIT wird nicht an die anderen Buseinheiten gesendet, weil der Daten-Cache im Fall einer Multi-Buseinheit PBO für beide Einheiten antwortet. Die Initialisierungs- Hardware 20.5 stellt auch Informationen bereit, um den Ladebefehl in die dynamische Ablaufprotokolltabelle 20.7 einzutragen. Die DBUS-Stapelspeicher-Steuerungen 20.10 schreiben Informationen über den Ladebefehl in das DS1-Register 20.10.8 von Fig. 9, weil die Decodierschaltung 20.10.3 festgestellt hat, daß es sich um einen RX-Befehl handelt. Ebenfalls wurde ein Daten-gültig-Signal auf dem DBUS empfangen, das Signal wird in dem DREG 20.9.1 des DBUS-Stapelspeichers zwischengespeichert, und als ein Ergebnis dessen wird der DREG-Gültig-Zwischenspeicher 20.10.1 der DBUS-Stapelspeicher-Steuerungen 20.10 aktiv. Während dieses Zyklus sendet die CPU einen Multiplikations-RR-Befehl auf dem CBUS an die FPU und dieser Befehl vom CBUS wird in dem CBUS-Register 20.1.2 des Befehls-Stapelspeichers 20.1 und in dem DCBUS-Register 20.10.2 der DBUS-Stapelspeicher-Steuerungen 20.10 zwischengespeichert.
Zyklus 2 - Der RR-Multiplikationsbefehl wird durch die Decodierschaltung 20.2 von Fig. 2 und die Decodierschaltung 20.10.3 der DBUS-Stapelspeicher-Steuerungen 20.10 von Fig. 9 decodiert. Die Handshake- und globale Hasard-Schaltung 20.3 von Fig. 2 und Fig. 10 stellt durch Überprüfen der internen Pipe-Steuerung von Pipe 2 20.6b fest, daß dem Beginn einer Multiplikation keine Probleme entgegenstehen und daß keine globalen Hasards aufgetreten sind, wie aus der Überprüfung der dynamischen Ablaufprotokolltabelle 20.7 hervorgeht. Somit wird ein Bereitschaftssignal (FPU BEREIT) an die CPU und die anderen PBU gesendet. Die Initialisierungsschaltung 20.5 initialisiert Pipe 2 20.6b und liest auch das Register FPR2 der FPRs 20.8 über den FLPBUS von Fig. 6, um den Wert im Y-Register 20.6b.9 zwischenzuspeichern. Die Initialisierungs-Hardware 20.5 stellt auch Informationen bereit, um den Multiplikationsbefehl in die dynamische Ablaufprotokolltabelle 20.7 einzutragen. Die Initialisierungs-Hardware 20.5 bekommt auch von der globalen Hasard-Logik 20.3, welche die Einträge der dynamischen Ablaufprotokolltabelle 20.7 decodiert, die Nachricht, daß FPR1 durch den Ladebefehl gesperrt ist und somit Operand 1 der Multiplikation gesperrt ist. Die Initialisierungs-Hardware 20.5 initialisiert mit der Information von der Decodierschaltung 20.2 die Steuerungsregister, das FXA-Register 20.6b.1 und das FY-Register 20.6b.6. Die Decodierschaltung 20.10.3 von Fig. 9 der DBUS-Stapelspeicher-Steuerungen stellt fest, daß der RR-Multiplikationsbefehl den DBUS nicht benutzt, aber durch DREG 20.9.1 gesperrt ist und somit wird DREG 20.9.1 in das XA-Register 20.6b.6 von Fig. 6 geladen. Während dieses Zyklus ist das DREG 20.9.1 gültig und die FPR 20.8 werden geladen (hinein geschrieben), um den Ladebefehl zu beenden (die Beendigung des Ladebefehls ist auf Grund des DREG-Gültig-Registers 20.10.1 von Fig. 9 und des Eintrags in der dynamischen Ablaufprotokolltabelle 20.7, welcher anzeigt, daß die nächste zu beendende Pipe Pipe 3 ist, gestattet). Die CPU sendet einen Addition-RR- Befehl auf dem CBUS an die FPU und dieser Befehl vom CBUS wird in dem CBUS-Register 20.1.2 des Befehls-Stapelspeichers 20.1 und in dem DCBUS-Register 20.10.2 der DBUS-Stapelspeicher-Steuerungen 20.10 zwischengespeichert.
Zyklus 3 - Der RR-Additionsbefehl wird durch die Decodierschaltung 20.2 von Fig. 2 und die Decodierschaltung 20.10.3 der DBUS-Stapelspeicher-Steuerungen 20.10 von Fig. 9 decodiert. Die Handshake- und globale Hasard-Schaltung 20.3 von Fig. 2 und Fig. 10 stellt durch überprüfen der internen Pipe-Steuerung von Pipe 1 20.6a fest, daß dem Beginn einer Addition keine Probleme entgegenstehen und daß keine globalen Hasards aufgetreten sind, wie aus der Überprüfung der dynamischen Ablaufprotokolltabelle 20.7 hervorgeht. Somit wird von der Handshake-Schaltung 20.3 ein Bereitschaftssignal (FPU BEREIT) an die CPU und die anderen PBU gesendet. Die Initialisierungsschaltung 20.5 initialisiert Pipe 1 20.6a und liest auch die Register FPR3 und FPR4 der FPRs 20.8 und speichert die Werte in das A-Register 20.6a.5 und das B-Register 20.6a.6 von Fig. 5. Die Initialisierungs- Hardware 20.5 stellt auch Informationen bereit, um den Additionsbefehl in die dynamische Ablaufprotokolltabelle 20.7 einzutragen und bekommt von der globalen Hasard-Logik 20.3, welche die Einträge der dynamischen Ablaufprotokolltabelle 20.7 decodiert, die Nachricht, daß keine Sperren existieren. Mit der von den Decodierschaltungen bereitgestellten Information initialisiert die Initialisierungs-Hardware 20.5 die Steuerungsregister, das FA-Register 20.6a.1 und das FY-Register 20.6a.2 von Fig. 5. Die Multiplikations- Hardware von Figu 6 hält den Wert im Y-Register 20.6b.9 fest, weil durch die Multiplexer-Auswahl-Logik 20.6b.13 Konflikte festgestellt worden sind, führt mittels der 3X- Hardware 20.6b.7 eine 3X-Berechnung durch und speichert die XB- und 3X-Register 20.6b.8. Die Steuerungsinformation für den Multiplikationsbefehl wird im FY-Register 20.6b.4 von Fig. 6 gehalten und wird vom FXA-Register 20.6b.1 in das FXB-Register 20.6b.3 übertragen. Die Ausrichtung 20.6a.4 des Additionsbefehls erfolgt ebenfalls während dieses Zyklus.
Zyklus 4 - Entsprechend der Darstellung von Fig. 6 sind beide Operanden verfügbar und stehen bereit, um aus den XB & 3X-Registern 20.6b.8 und dem Y-Register 20.6b.9 heraus miteinander multipliziert zu werden. Somit beginnt der M1- Zyklus und die M1-Hardware 20.6b.10 wird verwendet, um die Multiplikation auszuführen. Die Addition tritt entsprechend der Darstellung von Fig. 5 in Zyklus 2 ein, verläuft über den Addierer 20.6a.7 und das Ergebnis wird im S-Register 20.6a.8 zwischengespeichert. Die Daten des FA-Steuerungsregisters 20.6a.1 werden in das FS-Register 20.6a.3 übertragen.
Zyklus 5 - Entsprechend der Darstellung von Fig. 6 beginnt bei der Multiplikation der M2-Zyklus, es wird die M2-Hardware 20.6b.11 verwendet, und das Ergebnis im P-Register 20.6b.12 zwischengespeichert. Das FXB-Steuerungsregister setzt das FP-Register 20.6b.5. Entsprechend der Darstellung von Fig. 5 muß die Addition warten, das Ergebnis verbleibt im S-Register 20.6a.8, weil die dynamische Ablaufprotokolltabelle 20.7 anzeigt, daß der Multiplikationsbefehl von Pipe 2 20.6b von Fig. 6 als nächster Befehl beendet werden muß.
Zyklus 6 - Entsprechend der Darstellung von Fig. 6 wird der Multiplikationsbefehl beendet, weil das P-Register 20.6b.12 gültig ist, wie dies durch das FP-Register 20.6b.5 angezeigt wird und weil die dynamische Ablaufprotokolltabelle 20.7 anzeigt, daß diese Pipe als nächstes beendet wird. Die dynamische Ablaufsprotokolltabelle 20.7 stellt die Schreibadresse und die Länge für die FPR 20.8 bereit, um die Multiplikation zu beenden. Entsprechend der Darstellung von Fig. 5 muß die Addition warten, das Ergebnis verbleibt im S-Register 20.6a.8, weil die dynamische Ablaufprotokolltabelle 20.7 anzeigt, daß der Befehl von Pipe 2 von Fig. 6 als nächster Befehl beendet werden muß.
Zyklus 7 - Entsprechend der Darstellung von Fig. 5 wird die Addition beendet, weil das FS-Register 20.6a.3 anzeigt, daß das S-Register 20.6a.8 gültig ist und weil die dynamische Ablaufprotokolltabelle 20.7 auf die Additions-Pipe als die Pipe zeigt, deren Befehl als nächster beendet werden muß.
Somit ist die Ausführung der Befehlsfolge beendet worden.

Claims

1. Pipelineverarbeitungsvorrichtung mit Pipeline mit Empfangsmittel (20.1) für eingehende Befehle, eine Decodierschaltung (20.2), eine Vielzahl Prozessoren mit Pipeline (20.6a bis d), die mit den Befehle empfangenden Mitteln (20.1) und der Decodierschaltung (20.2) verbunden sind, Schaltmittel (20.4, 20.5) zur Verteilung der Befehle auf die Prozessoren mit Pipeline (20.6a bis d) gemäß ihrem Typ, und einen Speicher (20.1) zum Speichern der Befehle in Reihenfolge des Programms, gekennzeichnet durch

einen MIMD/SISD-Schalter (20.4) innerhalb der Schaltmittel (20.4, 20.5), der die Arbeitsweise der Prozessoren mit Pipeline (20.6a bis d) so einstellt, wie durch die Decodierschaltung (20.2) festgelegt wird und zwar auf einen Einzelbefehls-Abfolge-Einzeldaten-Modus (SISD - single instruction stream single data) für eine erste Kategorie von Befehlen und auf einen Mehrbefehls-Abfolge-Mehrdaten-Modus (MIMD - multiple instruction stream multiple data) für eine zweite Kategorie von Befehlen;

FIFO-Tabellenmittel (20.7), die mit den Empfangsmitteln (20.1) und der Vielzahl der Prozessoren mit Pipeline (20.6a bis d) verbunden sind, um zeitweilig Sätze von eingehenden Sätzen zusammen mit den eindeutigen Nummern der entsprechend ausgewählten Prozessoren mit Pipeline und einer MIMD/SISD-Modusanzeige (M/S) zu speichern, welche die Befehlsverarbeitung durch die Prozessoren mit Pipeline (20.6a bis d) in einer vorgegebenen Folge halten;

Pipeline-Steuerungen, die jedem der Prozessoren mit Pipeline (20.6a bis d) zugeordnet sind; und

Mittel (20.3, 20.5) zur Abfrage der Tabellenmittel (20.7) und der Pipeline-Steuerungen, um zu bestimmen, ob ein ausgewählter Prozessor mit Pipeline (20.6a bis d) zum Empfang eines Befehls und der entsprechenden Daten bereit ist.

2. Vorrichtung nach Anspruch 1, dadurch gekennzeichnet, daß die erste Kategorie von Befehlen, welche im SISD-Modus verarbeitet werden, Befehle enthält, die eine Länge haben, welche außerhalb eines vorgegebenen Bitbereiches liegt oder Befehle, welche schwieriger auszuführen sind, wie beispielsweise Divisionen und Quadratwurzeln.

3. Vorrichtung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der jeweils ausgewählte der Prozessoren mit Pipeline (20.6a bis d) zur Benutzung verfügbar ist, wenn er nicht mit Befehlen gefüllt ist, oder wenn er mit Befehlen gefüllt ist und deren Anzahl mit der Anzahl übereinstimmt, die in den Tabellenmitteln (20.7) für die längste Zeitspanne aufgezeichnet ist und der älteste Befehl in dem ausgewählten Prozessor mit Pipeline (20.6a bis d) ausgeführt worden ist.

4. Vorrichtung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß eine Gefahrenschaltung (20.3) zwischen die Empfangsmittel, die Tabellenmittel (20.7) und die Vielzahl der Prozessoren mit Pipeline (20.6a bis d) geschaltet ist, um datenabhängige Störungen zu erkennen und um Steuersignale zu erzeugen, um die Ausführung eines Befehls durch einen der Prozessoren mit Pipeline (20.6a bis d) entweder zu gestatten oder zu verhindern.

5. Vorrichtung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß eine Handshake-Schaltung (20.3), die auf das decodierte Ausgangssignal der Decodierschaltung (20.2) reagiert, ein gültiger-Befehl-Signal und ein Bestätigungssignal erzeugt, wenn der älteste der gestapelten, eingehenden Befehle gültig ist.

6. Vorrichtung nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß eine Initialisierungsschaltung (20.5), die auf das Ausgangssignal der Decodierschaltung (20.2), das Bestätigungssignal und das gültiger-Befehl-Signal reagiert und einen der Prozessoren mit Pipeline (20.6a bis d) identifiziert und auswählt, entsprechend dieser drei Signale die Charakteristika des ältesten der gestapelten, eingehenden Befehle an den ausgewählten Prozessor mit Pipeline (20.6a bis d) weitergibt.

7. Vorrichtung nach einem der vorhergehenden Ansprüche, gekennzeichnet durch

einen FIFO-Datenstapelspeicher (20.9.1 bis 3) zum Stapeln der von einem Datenbus empfangenen Daten;

FIFO-Stapelspeicher-Steuerungen (20.10.4 bis 8) zum Stapeln von Befehlsinformationen, zum Identifizieren der Pipe-Nummer des ausgewählten Prozessors mit Pipeline (20.6a bis d) und zum Speichern der Daten in einer Eins-zu-Eins-Abbildung der Daten in dem FIFO-Stapelspeicher (20.9.1 bis 3).

8. Verfahren zum Anpassen der Daten an die Befehle innerhalb einer Vorrichtung nach Anspruch 7, umfassend die Schritte:

Abfrage der Tabellenmittel (20.7) und der Steuerelemente, die dem ausgewählten Prozessor mit Pipeline (20.6a bis d) zugeordnet sind, ob dieser zur Ausführung des Befehls bereit ist; und

Übertragen der Daten aus dem FIFO-Stapelspeicher (20.9.1 bis 3) zu dem ausgewählten Prozessor mit Pipeline (20.6a bis d), der gemäß der Pipe-Nummer identifiziert wurde.