DE3853529T2 - Dynamische Mehrbefehle-Mehrdaten-Mehrpipeline-Gleitpunkteinheit. - Google Patents
Dynamische Mehrbefehle-Mehrdaten-Mehrpipeline-Gleitpunkteinheit.Info
- Publication number
- DE3853529T2 DE3853529T2 DE3853529T DE3853529T DE3853529T2 DE 3853529 T2 DE3853529 T2 DE 3853529T2 DE 3853529 T DE3853529 T DE 3853529T DE 3853529 T DE3853529 T DE 3853529T DE 3853529 T2 DE3853529 T2 DE 3853529T2
- Authority
- DE
- Germany
- Prior art keywords
- instruction
- data
- pipe
- instructions
- register
- 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
Links
- 238000012545 processing Methods 0.000 claims description 21
- 230000001419 dependent effect Effects 0.000 claims description 6
- 238000000034 method Methods 0.000 claims description 6
- 238000013507 mapping Methods 0.000 claims 1
- 238000007792 addition Methods 0.000 description 16
- 102100021145 fMet-Leu-Phe receptor Human genes 0.000 description 11
- 239000000872 buffer Substances 0.000 description 9
- 238000001514 detection method Methods 0.000 description 9
- 101710108492 fMet-Leu-Phe receptor Proteins 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000013459 approach Methods 0.000 description 5
- 101000818522 Homo sapiens fMet-Leu-Phe receptor Proteins 0.000 description 4
- 101001059802 Homo sapiens N-formyl peptide receptor 3 Proteins 0.000 description 3
- 102100028130 N-formyl peptide receptor 3 Human genes 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 101150094459 FPR4 gene Proteins 0.000 description 2
- 101000818546 Homo sapiens N-formyl peptide receptor 2 Proteins 0.000 description 2
- 102100021126 N-formyl peptide receptor 2 Human genes 0.000 description 2
- 101100334862 Rhizopus delemar (strain RA 99-880 / ATCC MYA-4621 / FGSC 9543 / NRRL 43880) FKBP4 gene Proteins 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000000739 chaotic effect Effects 0.000 description 2
- 238000012163 sequencing technique Methods 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
- G06F15/8053—Vector processors
- G06F15/8092—Array of vector units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
- G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements 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/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3885—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
- G06F9/3889—Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled by multiple instructions, e.g. MIMD, decoupled access or execute
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Multimedia (AREA)
- Advance Control (AREA)
- Multi Processors (AREA)
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:
- Additionen
- Vergleiche
- Halbieren
- Laden
- Multiplikationen
- Speichern
- Subtraktionen
- Multiplikation
- 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:
- Addition erweitert
- Multiplikation erweitert
- Divisionen
- Division erweitert
- Quadratwurzel
- Laden gerundet, erweitert
- 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 (8)
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.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/102,985 US4916652A (en) | 1987-09-30 | 1987-09-30 | Dynamic multiple instruction stream multiple data multiple pipeline apparatus for floating-point single instruction stream single data architectures |
Publications (2)
Publication Number | Publication Date |
---|---|
DE3853529D1 DE3853529D1 (de) | 1995-05-11 |
DE3853529T2 true DE3853529T2 (de) | 1995-09-28 |
Family
ID=22292751
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE3853529T Expired - Fee Related DE3853529T2 (de) | 1987-09-30 | 1988-06-21 | Dynamische Mehrbefehle-Mehrdaten-Mehrpipeline-Gleitpunkteinheit. |
Country Status (6)
Country | Link |
---|---|
US (1) | US4916652A (de) |
EP (1) | EP0328721B1 (de) |
JP (1) | JPH01102644A (de) |
BR (1) | BR8804969A (de) |
CA (1) | CA1313273C (de) |
DE (1) | DE3853529T2 (de) |
Families Citing this family (164)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5241635A (en) * | 1988-11-18 | 1993-08-31 | Massachusetts Institute Of Technology | Tagged token data processing system with operand matching in activation frames |
US5333287A (en) * | 1988-12-21 | 1994-07-26 | International Business Machines Corporation | System for executing microinstruction routines by using hardware to calculate initialization parameters required therefore based upon processor status and control parameters |
US5067069A (en) * | 1989-02-03 | 1991-11-19 | Digital Equipment Corporation | Control of multiple functional units with parallel operation in a microcoded execution unit |
WO1990010267A1 (en) * | 1989-02-24 | 1990-09-07 | Nexgen Microsystems | Distributed pipeline control for a computer |
US5226126A (en) * | 1989-02-24 | 1993-07-06 | Nexgen Microsystems | Processor having plurality of functional units for orderly retiring outstanding operations based upon its associated tags |
US5781753A (en) * | 1989-02-24 | 1998-07-14 | Advanced Micro Devices, Inc. | Semi-autonomous RISC pipelines for overlapped execution of RISC-like instructions within the multiple superscalar execution units of a processor having distributed pipeline control for speculative and out-of-order execution of complex instructions |
US5768575A (en) * | 1989-02-24 | 1998-06-16 | Advanced Micro Devices, Inc. | Semi-Autonomous RISC pipelines for overlapped execution of RISC-like instructions within the multiple superscalar execution units of a processor having distributed pipeline control for sepculative and out-of-order execution of complex instructions |
JPH0719222B2 (ja) * | 1989-03-30 | 1995-03-06 | 日本電気株式会社 | ストアバッフア |
JPH0640316B2 (ja) * | 1989-04-20 | 1994-05-25 | 工業技術院長 | 演算レジスタ上でのデータ待ち合せ実現方法 |
CA2016068C (en) * | 1989-05-24 | 2000-04-04 | Robert W. Horst | Multiple instruction issue computer architecture |
US5317734A (en) * | 1989-08-29 | 1994-05-31 | North American Philips Corporation | Method of synchronizing parallel processors employing channels and compiling method minimizing cross-processor data dependencies |
EP0820007B1 (de) * | 1989-09-25 | 1999-08-04 | Matsushita Electric Industrial Co., Ltd. | Rechner mit Pipeline-Struktur |
US5185871A (en) * | 1989-12-26 | 1993-02-09 | International Business Machines Corporation | Coordination of out-of-sequence fetching between multiple processors using re-execution of instructions |
JP2818249B2 (ja) * | 1990-03-30 | 1998-10-30 | 株式会社東芝 | 電子計算機 |
JP2771683B2 (ja) * | 1990-07-17 | 1998-07-02 | 三菱電機株式会社 | 並列処理方式 |
US5163139A (en) * | 1990-08-29 | 1992-11-10 | Hitachi America, Ltd. | Instruction preprocessor for conditionally combining short memory instructions into virtual long instructions |
US5588152A (en) * | 1990-11-13 | 1996-12-24 | International Business Machines Corporation | Advanced parallel processor including advanced support hardware |
DE69131272T2 (de) * | 1990-11-13 | 1999-12-09 | International Business Machines Corp., Armonk | Paralleles Assoziativprozessor-System |
US5734921A (en) * | 1990-11-13 | 1998-03-31 | International Business Machines Corporation | Advanced parallel array processor computer package |
US5794059A (en) * | 1990-11-13 | 1998-08-11 | International Business Machines Corporation | N-dimensional modified hypercube |
US5590345A (en) * | 1990-11-13 | 1996-12-31 | International Business Machines Corporation | Advanced parallel array processor(APAP) |
US5765011A (en) * | 1990-11-13 | 1998-06-09 | International Business Machines Corporation | Parallel processing system having a synchronous SIMD processing with processing elements emulating SIMD operation using individual instruction streams |
US5809292A (en) * | 1990-11-13 | 1998-09-15 | International Business Machines Corporation | Floating point for simid array machine |
US5828894A (en) * | 1990-11-13 | 1998-10-27 | International Business Machines Corporation | Array processor having grouping of SIMD pickets |
US5713037A (en) * | 1990-11-13 | 1998-01-27 | International Business Machines Corporation | Slide bus communication functions for SIMD/MIMD array processor |
US5765012A (en) * | 1990-11-13 | 1998-06-09 | International Business Machines Corporation | Controller for a SIMD/MIMD array having an instruction sequencer utilizing a canned routine library |
US5963745A (en) * | 1990-11-13 | 1999-10-05 | International Business Machines Corporation | APAP I/O programmable router |
US5815723A (en) * | 1990-11-13 | 1998-09-29 | International Business Machines Corporation | Picket autonomy on a SIMD machine |
US5765015A (en) * | 1990-11-13 | 1998-06-09 | International Business Machines Corporation | Slide network for an array processor |
US5630162A (en) * | 1990-11-13 | 1997-05-13 | International Business Machines Corporation | Array processor dotted communication network based on H-DOTs |
US5963746A (en) * | 1990-11-13 | 1999-10-05 | International Business Machines Corporation | Fully distributed processing memory element |
US5966528A (en) * | 1990-11-13 | 1999-10-12 | International Business Machines Corporation | SIMD/MIMD array processor with vector processing |
US5625836A (en) * | 1990-11-13 | 1997-04-29 | International Business Machines Corporation | SIMD/MIMD processing memory element (PME) |
US5261063A (en) * | 1990-12-07 | 1993-11-09 | Ibm Corp. | Pipeline apparatus having pipeline mode eecuting instructions from plural programs and parallel mode executing instructions from one of the plural programs |
JP2842958B2 (ja) * | 1991-04-01 | 1999-01-06 | 松下電器産業株式会社 | パイプライン計算機の同期方法及びそれを実現したパイプライン計算機 |
JP2925818B2 (ja) * | 1991-04-05 | 1999-07-28 | 株式会社東芝 | 並列処理制御装置 |
JP2642529B2 (ja) * | 1991-04-30 | 1997-08-20 | 株式会社東芝 | 並列プロセッサーの命令分配処理装置 |
US5594918A (en) * | 1991-05-13 | 1997-01-14 | International Business Machines Corporation | Parallel computer system providing multi-ported intelligent memory |
JP2908598B2 (ja) * | 1991-06-06 | 1999-06-21 | 松下電器産業株式会社 | 情報処理装置 |
JPH04367936A (ja) | 1991-06-17 | 1992-12-21 | Mitsubishi Electric Corp | スーパースカラープロセッサ |
US5363495A (en) * | 1991-08-26 | 1994-11-08 | International Business Machines Corporation | Data processing system with multiple execution units capable of executing instructions out of sequence |
US5283874A (en) * | 1991-10-21 | 1994-02-01 | Intel Corporation | Cross coupling mechanisms for simultaneously completing consecutive pipeline instructions even if they begin to process at the same microprocessor of the issue fee |
CA2073516A1 (en) * | 1991-11-27 | 1993-05-28 | Peter Michael Kogge | Dynamic multi-mode parallel processor array architecture computer system |
JP2642039B2 (ja) * | 1992-05-22 | 1997-08-20 | インターナショナル・ビジネス・マシーンズ・コーポレイション | アレイ・プロセッサ |
WO1994008287A1 (en) | 1992-09-29 | 1994-04-14 | Seiko Epson Corporation | System and method for handling load and/or store operations in a superscalar microprocessor |
US6735685B1 (en) * | 1992-09-29 | 2004-05-11 | Seiko Epson Corporation | System and method for handling load and/or store operations in a superscalar microprocessor |
JP3338488B2 (ja) * | 1992-11-18 | 2002-10-28 | 富士通株式会社 | データ処理装置の検証方法及び装置 |
US5761473A (en) * | 1993-01-08 | 1998-06-02 | International Business Machines Corporation | Method and system for increased instruction synchronization efficiency in a superscalar processsor system utilizing partial data dependency interlocking |
JPH06242948A (ja) * | 1993-02-16 | 1994-09-02 | Fujitsu Ltd | パイプライン処理計算機 |
US5717947A (en) * | 1993-03-31 | 1998-02-10 | Motorola, Inc. | Data processing system and method thereof |
US5434987A (en) * | 1993-09-21 | 1995-07-18 | Intel Corporation | Method and apparatus for preventing incorrect fetching of an instruction of a self-modifying code sequence with dependency on a bufered store |
US5721854A (en) * | 1993-11-02 | 1998-02-24 | International Business Machines Corporation | Method and apparatus for dynamic conversion of computer instructions |
JP3199205B2 (ja) * | 1993-11-19 | 2001-08-13 | 株式会社日立製作所 | 並列演算装置 |
KR100186916B1 (ko) * | 1994-02-14 | 1999-05-01 | 모리시다 요이치 | 신호처리장치 |
US5751986A (en) * | 1994-03-01 | 1998-05-12 | Intel Corporation | Computer system with self-consistent ordering mechanism |
JP3212213B2 (ja) * | 1994-03-16 | 2001-09-25 | 株式会社日立製作所 | データ処理装置 |
US5465336A (en) * | 1994-06-30 | 1995-11-07 | International Business Machines Corporation | Fetch and store buffer that enables out-of-order execution of memory instructions in a data processing system |
US5542109A (en) * | 1994-08-31 | 1996-07-30 | Exponential Technology, Inc. | Address tracking and branch resolution in a processor with multiple execution pipelines and instruction stream discontinuities |
US6128720A (en) * | 1994-12-29 | 2000-10-03 | International Business Machines Corporation | Distributed processing array with component processors performing customized interpretation of instructions |
JP3597540B2 (ja) * | 1995-06-01 | 2004-12-08 | 富士通株式会社 | 並列データプロセッサにおけるアクティブ命令を回転させる方法および装置 |
US5751983A (en) * | 1995-10-03 | 1998-05-12 | Abramson; Jeffrey M. | Out-of-order processor with a memory subsystem which handles speculatively dispatched load operations |
US6317803B1 (en) * | 1996-03-29 | 2001-11-13 | Intel Corporation | High-throughput interconnect having pipelined and non-pipelined bus transaction modes |
US5848256A (en) * | 1996-09-30 | 1998-12-08 | Institute For The Development Of Emerging Architectures, L.L.C. | Method and apparatus for address disambiguation using address component identifiers |
US5970241A (en) * | 1997-11-19 | 1999-10-19 | Texas Instruments Incorporated | Maintaining synchronism between a processor pipeline and subsystem pipelines during debugging of a data processing system |
KR100453254B1 (ko) * | 1998-02-19 | 2004-10-15 | 인피니언 테크놀로지스 아게 | 대규모 통합 시스템에서 프로그램 가능 모듈의 계층적 및 분산 제어를 위한 장치 |
US6311262B1 (en) | 1999-01-18 | 2001-10-30 | Infineon Technologies Ag | Apparatus for the hierarchical and distributed control of programmable modules in large-scale integrated systems |
US7526630B2 (en) | 1999-04-09 | 2009-04-28 | Clearspeed Technology, Plc | Parallel data processing apparatus |
US7802079B2 (en) | 1999-04-09 | 2010-09-21 | Clearspeed Technology Limited | Parallel data processing apparatus |
GB2391093B (en) * | 1999-04-09 | 2004-04-07 | Clearspeed Technology Ltd | Parallel data processing systems |
US7627736B2 (en) | 1999-04-09 | 2009-12-01 | Clearspeed Technology Plc | Thread manager to control an array of processing elements |
US7506136B2 (en) | 1999-04-09 | 2009-03-17 | Clearspeed Technology Plc | Parallel data processing apparatus |
US6425072B1 (en) * | 1999-08-31 | 2002-07-23 | Advanced Micro Devices, Inc. | System for implementing a register free-list by using swap bit to select first or second register tag in retire queue |
US6766437B1 (en) | 2000-02-28 | 2004-07-20 | International Business Machines Corporation | Composite uniprocessor |
US6643763B1 (en) | 2000-02-28 | 2003-11-04 | International Business Machines Corporation | Register pipe for multi-processing engine environment |
US7139898B1 (en) * | 2000-11-03 | 2006-11-21 | Mips Technologies, Inc. | Fetch and dispatch disassociation apparatus for multistreaming processors |
US7035998B1 (en) | 2000-11-03 | 2006-04-25 | Mips Technologies, Inc. | Clustering stream and/or instruction queues for multi-streaming processors |
US20020144101A1 (en) * | 2001-03-30 | 2002-10-03 | Hong Wang | Caching DAG traces |
US6907534B2 (en) * | 2001-06-29 | 2005-06-14 | Hewlett-Packard Development Company, L.P. | Minimizing power consumption in pipelined circuit by shutting down pipelined circuit in response to predetermined period of time having expired |
US6789048B2 (en) * | 2002-04-04 | 2004-09-07 | International Business Machines Corporation | Method, apparatus, and computer program product for deconfiguring a processor |
US7451326B2 (en) * | 2002-08-26 | 2008-11-11 | Mosaid Technologies, Inc. | Method and apparatus for processing arbitrary key bit length encryption operations with similar efficiencies |
US7082517B2 (en) * | 2003-05-12 | 2006-07-25 | International Business Machines Corporation | Superscalar microprocessor having multi-pipe dispatch and execution unit |
US7085917B2 (en) * | 2003-05-12 | 2006-08-01 | International Business Machines Corporation | Multi-pipe dispatch and execution of complex instructions in a superscalar processor |
US7043626B1 (en) | 2003-10-01 | 2006-05-09 | Advanced Micro Devices, Inc. | Retaining flag value associated with dead result data in freed rename physical register with an indicator to select set-aside register instead for renaming |
US7543119B2 (en) * | 2005-02-10 | 2009-06-02 | Richard Edward Hessel | Vector processor |
US20060229638A1 (en) * | 2005-03-29 | 2006-10-12 | Abrams Robert M | Articulating retrieval device |
US8751755B2 (en) | 2007-12-27 | 2014-06-10 | Sandisk Enterprise Ip Llc | Mass storage controller volatile memory containing metadata related to flash memory storage |
US8365041B2 (en) * | 2010-03-17 | 2013-01-29 | Sandisk Enterprise Ip Llc | MLC self-raid flash data protection scheme |
US8909982B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | System and method for detecting copyback programming problems |
US8910020B2 (en) | 2011-06-19 | 2014-12-09 | Sandisk Enterprise Ip Llc | Intelligent bit recovery for flash memory |
US9058289B2 (en) | 2011-11-07 | 2015-06-16 | Sandisk Enterprise Ip Llc | Soft information generation for memory systems |
US8924815B2 (en) | 2011-11-18 | 2014-12-30 | Sandisk Enterprise Ip Llc | Systems, methods and devices for decoding codewords having multiple parity segments |
US8954822B2 (en) | 2011-11-18 | 2015-02-10 | Sandisk Enterprise Ip Llc | Data encoder and decoder using memory-specific parity-check matrix |
US9048876B2 (en) | 2011-11-18 | 2015-06-02 | Sandisk Enterprise Ip Llc | Systems, methods and devices for multi-tiered error correction |
US8892958B2 (en) | 2012-06-15 | 2014-11-18 | International Business Machines Corporation | Dynamic hardware trace supporting multiphase operations |
US9699263B1 (en) | 2012-08-17 | 2017-07-04 | Sandisk Technologies Llc. | Automatic read and write acceleration of data accessed by virtual machines |
US9501398B2 (en) | 2012-12-26 | 2016-11-22 | Sandisk Technologies Llc | Persistent storage device with NVRAM for staging writes |
US9239751B1 (en) | 2012-12-27 | 2016-01-19 | Sandisk Enterprise Ip Llc | Compressing data from multiple reads for error control management in memory systems |
US9612948B2 (en) | 2012-12-27 | 2017-04-04 | Sandisk Technologies Llc | Reads and writes between a contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device |
US9454420B1 (en) | 2012-12-31 | 2016-09-27 | Sandisk Technologies Llc | Method and system of reading threshold voltage equalization |
US9003264B1 (en) | 2012-12-31 | 2015-04-07 | Sandisk Enterprise Ip Llc | Systems, methods, and devices for multi-dimensional flash RAID data protection |
US9329928B2 (en) | 2013-02-20 | 2016-05-03 | Sandisk Enterprise IP LLC. | Bandwidth optimization in a non-volatile memory system |
US9214965B2 (en) | 2013-02-20 | 2015-12-15 | Sandisk Enterprise Ip Llc | Method and system for improving data integrity in non-volatile storage |
US9870830B1 (en) | 2013-03-14 | 2018-01-16 | Sandisk Technologies Llc | Optimal multilevel sensing for reading data from a storage medium |
US9092350B1 (en) | 2013-03-15 | 2015-07-28 | Sandisk Enterprise Ip Llc | Detection and handling of unbalanced errors in interleaved codewords |
US9009576B1 (en) | 2013-03-15 | 2015-04-14 | Sandisk Enterprise Ip Llc | Adaptive LLR based on syndrome weight |
US9244763B1 (en) | 2013-03-15 | 2016-01-26 | Sandisk Enterprise Ip Llc | System and method for updating a reading threshold voltage based on symbol transition information |
US9136877B1 (en) | 2013-03-15 | 2015-09-15 | Sandisk Enterprise Ip Llc | Syndrome layered decoding for LDPC codes |
US9367246B2 (en) | 2013-03-15 | 2016-06-14 | Sandisk Technologies Inc. | Performance optimization of data transfer for soft information generation |
US9236886B1 (en) | 2013-03-15 | 2016-01-12 | Sandisk Enterprise Ip Llc | Universal and reconfigurable QC-LDPC encoder |
US9170941B2 (en) | 2013-04-05 | 2015-10-27 | Sandisk Enterprises IP LLC | Data hardening in a storage system |
US10049037B2 (en) | 2013-04-05 | 2018-08-14 | Sandisk Enterprise Ip Llc | Data management in a storage system |
US9159437B2 (en) | 2013-06-11 | 2015-10-13 | Sandisk Enterprise IP LLC. | Device and method for resolving an LM flag issue |
US9384126B1 (en) | 2013-07-25 | 2016-07-05 | Sandisk Technologies Inc. | Methods and systems to avoid false negative results in bloom filters implemented in non-volatile data storage systems |
US9043517B1 (en) | 2013-07-25 | 2015-05-26 | Sandisk Enterprise Ip Llc | Multipass programming in buffers implemented in non-volatile data storage systems |
US9524235B1 (en) | 2013-07-25 | 2016-12-20 | Sandisk Technologies Llc | Local hash value generation in non-volatile data storage systems |
US9235509B1 (en) | 2013-08-26 | 2016-01-12 | Sandisk Enterprise Ip Llc | Write amplification reduction by delaying read access to data written during garbage collection |
US9639463B1 (en) | 2013-08-26 | 2017-05-02 | Sandisk Technologies Llc | Heuristic aware garbage collection scheme in storage systems |
US9519577B2 (en) | 2013-09-03 | 2016-12-13 | Sandisk Technologies Llc | Method and system for migrating data between flash memory devices |
US9442670B2 (en) | 2013-09-03 | 2016-09-13 | Sandisk Technologies Llc | Method and system for rebalancing data stored in flash memory devices |
EP3014429B1 (de) * | 2013-09-06 | 2020-03-04 | Huawei Technologies Co., Ltd. | Verfahren und vorrichtung zur asynchronen prozessorentfernung von metastabilität |
US9158349B2 (en) * | 2013-10-04 | 2015-10-13 | Sandisk Enterprise Ip Llc | System and method for heat dissipation |
US9323637B2 (en) | 2013-10-07 | 2016-04-26 | Sandisk Enterprise Ip Llc | Power sequencing and data hardening architecture |
US9442662B2 (en) | 2013-10-18 | 2016-09-13 | Sandisk Technologies Llc | Device and method for managing die groups |
US9298608B2 (en) | 2013-10-18 | 2016-03-29 | Sandisk Enterprise Ip Llc | Biasing for wear leveling in storage systems |
US9436831B2 (en) | 2013-10-30 | 2016-09-06 | Sandisk Technologies Llc | Secure erase in a memory device |
US9263156B2 (en) | 2013-11-07 | 2016-02-16 | Sandisk Enterprise Ip Llc | System and method for adjusting trip points within a storage device |
US9244785B2 (en) | 2013-11-13 | 2016-01-26 | Sandisk Enterprise Ip Llc | Simulated power failure and data hardening |
US9152555B2 (en) | 2013-11-15 | 2015-10-06 | Sandisk Enterprise IP LLC. | Data management with modular erase in a data storage system |
US9703816B2 (en) | 2013-11-19 | 2017-07-11 | Sandisk Technologies Llc | Method and system for forward reference logging in a persistent datastore |
US9520197B2 (en) | 2013-11-22 | 2016-12-13 | Sandisk Technologies Llc | Adaptive erase of a storage device |
US9280429B2 (en) | 2013-11-27 | 2016-03-08 | Sandisk Enterprise Ip Llc | Power fail latching based on monitoring multiple power supply voltages in a storage device |
US9520162B2 (en) | 2013-11-27 | 2016-12-13 | Sandisk Technologies Llc | DIMM device controller supervisor |
US9122636B2 (en) | 2013-11-27 | 2015-09-01 | Sandisk Enterprise Ip Llc | Hard power fail architecture |
US9250676B2 (en) | 2013-11-29 | 2016-02-02 | Sandisk Enterprise Ip Llc | Power failure architecture and verification |
US9582058B2 (en) | 2013-11-29 | 2017-02-28 | Sandisk Technologies Llc | Power inrush management of storage devices |
US9092370B2 (en) | 2013-12-03 | 2015-07-28 | Sandisk Enterprise Ip Llc | Power failure tolerant cryptographic erase |
US9235245B2 (en) | 2013-12-04 | 2016-01-12 | Sandisk Enterprise Ip Llc | Startup performance and power isolation |
US9129665B2 (en) | 2013-12-17 | 2015-09-08 | Sandisk Enterprise Ip Llc | Dynamic brownout adjustment in a storage device |
US9549457B2 (en) | 2014-02-12 | 2017-01-17 | Sandisk Technologies Llc | System and method for redirecting airflow across an electronic assembly |
US9497889B2 (en) | 2014-02-27 | 2016-11-15 | Sandisk Technologies Llc | Heat dissipation for substrate assemblies |
US9703636B2 (en) | 2014-03-01 | 2017-07-11 | Sandisk Technologies Llc | Firmware reversion trigger and control |
US9485851B2 (en) | 2014-03-14 | 2016-11-01 | Sandisk Technologies Llc | Thermal tube assembly structures |
US9519319B2 (en) | 2014-03-14 | 2016-12-13 | Sandisk Technologies Llc | Self-supporting thermal tube structure for electronic assemblies |
US9348377B2 (en) | 2014-03-14 | 2016-05-24 | Sandisk Enterprise Ip Llc | Thermal isolation techniques |
US9390814B2 (en) | 2014-03-19 | 2016-07-12 | Sandisk Technologies Llc | Fault detection and prediction for data storage elements |
US9454448B2 (en) | 2014-03-19 | 2016-09-27 | Sandisk Technologies Llc | Fault testing in storage devices |
US9448876B2 (en) | 2014-03-19 | 2016-09-20 | Sandisk Technologies Llc | Fault detection and prediction in storage devices |
US9390021B2 (en) | 2014-03-31 | 2016-07-12 | Sandisk Technologies Llc | Efficient cache utilization in a tiered data structure |
US9626399B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Conditional updates for reducing frequency of data modification operations |
US9626400B2 (en) | 2014-03-31 | 2017-04-18 | Sandisk Technologies Llc | Compaction of information in tiered data structure |
US9697267B2 (en) | 2014-04-03 | 2017-07-04 | Sandisk Technologies Llc | Methods and systems for performing efficient snapshots in tiered data structures |
US9070481B1 (en) | 2014-05-30 | 2015-06-30 | Sandisk Technologies Inc. | Internal current measurement for age measurements |
US10656840B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Real-time I/O pattern recognition to enhance performance and endurance of a storage device |
US8891303B1 (en) | 2014-05-30 | 2014-11-18 | Sandisk Technologies Inc. | Method and system for dynamic word line based configuration of a three-dimensional memory device |
US10372613B2 (en) | 2014-05-30 | 2019-08-06 | Sandisk Technologies Llc | Using sub-region I/O history to cache repeatedly accessed sub-regions in a non-volatile storage device |
US10114557B2 (en) | 2014-05-30 | 2018-10-30 | Sandisk Technologies Llc | Identification of hot regions to enhance performance and endurance of a non-volatile storage device |
US9703491B2 (en) | 2014-05-30 | 2017-07-11 | Sandisk Technologies Llc | Using history of unaligned writes to cache data and avoid read-modify-writes in a non-volatile storage device |
US9645749B2 (en) | 2014-05-30 | 2017-05-09 | Sandisk Technologies Llc | Method and system for recharacterizing the storage density of a memory device or a portion thereof |
US9093160B1 (en) | 2014-05-30 | 2015-07-28 | Sandisk Technologies Inc. | Methods and systems for staggered memory operations |
US10656842B2 (en) | 2014-05-30 | 2020-05-19 | Sandisk Technologies Llc | Using history of I/O sizes and I/O sequences to trigger coalesced writes in a non-volatile storage device |
US10162748B2 (en) | 2014-05-30 | 2018-12-25 | Sandisk Technologies Llc | Prioritizing garbage collection and block allocation based on I/O history for logical address regions |
US10146448B2 (en) | 2014-05-30 | 2018-12-04 | Sandisk Technologies Llc | Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device |
US9652381B2 (en) | 2014-06-19 | 2017-05-16 | Sandisk Technologies Llc | Sub-block garbage collection |
US9443601B2 (en) | 2014-09-08 | 2016-09-13 | Sandisk Technologies Llc | Holdup capacitor energy harvesting |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3840861A (en) * | 1972-10-30 | 1974-10-08 | Amdahl Corp | Data processing system having an instruction pipeline for concurrently processing a plurality of instructions |
US4390946A (en) * | 1980-10-20 | 1983-06-28 | Control Data Corporation | Lookahead addressing in a pipeline computer control store with separate memory segments for single and multiple microcode instruction sequences |
JPS5852751A (ja) * | 1981-09-24 | 1983-03-29 | Fujitsu Ltd | 実行命令順序制御方式 |
JPS5899867A (ja) * | 1981-12-08 | 1983-06-14 | Nec Corp | 並列処理方式 |
JPS58146952A (ja) * | 1982-02-26 | 1983-09-01 | Toshiba Corp | 並列計算機方式 |
US4594660A (en) * | 1982-10-13 | 1986-06-10 | Honeywell Information Systems Inc. | Collector |
AU569258B2 (en) * | 1982-10-13 | 1988-01-28 | Honeywell Information Systems Incorp. | Distributor for pipeline unit |
US4594655A (en) * | 1983-03-14 | 1986-06-10 | International Business Machines Corporation | (k)-Instructions-at-a-time pipelined processor for parallel execution of inherently sequential instructions |
JPS60120472A (ja) * | 1983-12-02 | 1985-06-27 | Fujitsu Ltd | 多重ル−プのベクトル処理方式 |
-
1987
- 1987-09-30 US US07/102,985 patent/US4916652A/en not_active Expired - Lifetime
-
1988
- 1988-06-21 DE DE3853529T patent/DE3853529T2/de not_active Expired - Fee Related
- 1988-06-21 EP EP88109842A patent/EP0328721B1/de not_active Expired - Lifetime
- 1988-07-21 CA CA000572709A patent/CA1313273C/en not_active Expired - Fee Related
- 1988-09-20 JP JP63233855A patent/JPH01102644A/ja active Pending
- 1988-09-27 BR BR8804969A patent/BR8804969A/pt not_active Application Discontinuation
Also Published As
Publication number | Publication date |
---|---|
EP0328721A3 (en) | 1990-07-18 |
DE3853529D1 (de) | 1995-05-11 |
BR8804969A (pt) | 1989-05-02 |
EP0328721B1 (de) | 1995-04-05 |
US4916652A (en) | 1990-04-10 |
JPH01102644A (ja) | 1989-04-20 |
CA1313273C (en) | 1993-01-26 |
EP0328721A2 (de) | 1989-08-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE3853529T2 (de) | Dynamische Mehrbefehle-Mehrdaten-Mehrpipeline-Gleitpunkteinheit. | |
DE3889578T2 (de) | Vorrichtung zur Sicherung und Rückspeicherung einer Registerinformation. | |
DE3689394T2 (de) | Informationsverarbeitungsanlage mit einem Allzweckprozessor und einem Sonderzweckprozessor. | |
DE69017178T2 (de) | Datenverarbeitungssystem mit Vorrichtung zur Befehlskennzeichnung. | |
DE69130858T2 (de) | Überlappende Serienverarbeitung | |
DE68927492T2 (de) | Verfahren und Vorrichtung zur gleichzeitigen Verteilung von Befehlen an mehrere funktionelle Einheiten | |
DE3685913T2 (de) | Vektorenverarbeitung. | |
DE3851488T2 (de) | Registerverwaltungssystem mit Ausführung von Befehlen in Unordnung in einem Computerprozessor. | |
DE69227664T2 (de) | Hardwarekonfiguriertes Betriebssystemkern für einen Multitaskprozessor | |
DE3686991T2 (de) | Mechanismus fuer parallele speicherdatenabholung und befehlsausfuehrung in einem prozessor mit reduziertem befehlssatz. | |
DE68927029T2 (de) | Pipelineprozessor | |
DE69308548T2 (de) | Vorrichtung und verfahren zum befehlsabschluss in einem superskalaren prozessor. | |
DE69232045T2 (de) | Vorrichtung und verfahren zur ausführung von instruktionen in nicht sequentieller reihenfolge | |
DE3210816C2 (de) | ||
DE3852928T2 (de) | Datenprozessor mit A/D-Umsetzer, um mehrere analoge Eingabekanäle in Digitaldaten umzusetzen. | |
DE2234867C2 (de) | Anordnung in einer Datenverarbeitungsanlage zum Steuern der Verarbeitung zweier voneinander unabhängiger Befehlsfolgen | |
DE69429226T2 (de) | Absendung von Befehlen an mehrere Verarbeitungseinheiten | |
DE2714805C2 (de) | ||
DE2855106C2 (de) | Einrichtung zur Durchführung von bedingten Verzweigungen | |
DE3587167T2 (de) | Geraet zur vektorverarbeitung. | |
DE3685876T2 (de) | Meister-sklave-mikroprozessorsystem mit einem virtuellen speicher. | |
DE3851746T2 (de) | Sprungvorhersage. | |
DE69622776T2 (de) | Von Multitasking gebrauch machendes Sortieren | |
DE68924546T2 (de) | Verfahren und Vorrichtung zur Ausführung von Befehlen für ein Vektorverarbeitungssystem. | |
DE69623146T2 (de) | Verfahren und Vorrichtung zum Koordinieren der Benutzung von physikalischen Registern in einem Mikroprozessor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8364 | No opposition during term of opposition | ||
8339 | Ceased/non-payment of the annual fee |