-
Für jegliche
Einzelanweisungs-Mehrfachdatenstrom-(SIMD)-Maschine mit einer vorgegebenen Zahl von
parallelen Verarbeitungselementen wird es Algorithmen geben, die
keinen effizienten Gebrauch von den verfügbaren parallelen Verarbeitungselementen,
oder, mit anderen Worten, von den verfügbaren Computerressourcen,
machen können.
Maschinen von der Mehrfachanweisungs-Mehrfachdatenstrom-(MIMD)-Klasse führen einige
dieser Algorithmen mit mehr Effizienz aus, erfordern aber zusätzliche
Hardware, um einen separaten Anweisungsstrom auf jedem Prozessor
zu unterstützen
und verlieren ein Leistungsvermögen
aufgrund einer Kommunikationsverzögerung mit eng gekoppelten
Programmimplementationen. Die vorliegende Erfindung ist auf eine
bessere Maschinenorganisation zur Ausführung dieser Algorithmen gerichtet,
die Hardwarekosten und komplexität
reduziert, während
die besten Merkmale von sowohl den SIMD- als auch den MIMD-Maschinen
aufrecht erhalten werden und eine Kommunikationsverzögerung minimiert
wird. Eine erfindungsgemäße Ausführungsform
stellt für
SIMD-Verarbeitungselemente
für indirekte
sehr lange Anweisungswörter
(iVLIW, indirect Very Long Instruction Word) einen Grad an MIMD-Verarbeitungs-Auotonomie
bereit, während
der einzelne Steuerungs-Thread, der in der SIMD-Maschinenorganisatione
verwendet wird, aufrecht erhalten wird. Daher wird der Ausdruck
Synchron-MIMD (SMIMD) verwendet, um die erfindungsgemäßen Ausführungsformen
zu beschreiben.
-
Hintergrund der Erfindung
-
Es
gibt zwei hauptsächliche
parallele Programmiermodelle, das SIMD- und das MIMD-Modell. Im SIMD-Modell
gibt es einen einzelnen Programm-Thread, der mehrere Verarbeitungselemente
(PEs) in einem synchronen Sperr-Schritt-Modus steuert. Jedes PE
führt dieselbe
Anweisung aus, allerdings an verschiedenen Daten. Dies steht im
Gegensatz zum MIMD-Modell, wo mehrere Steuerungs-Programm-Threads
vorliegen und jegliche Inter-Prozessor-Operationen
mit der Verzögerung
zu kämpfen
haben, die auftritt, wenn sie zwischen den mehreren Prozessoren
kommunizieren, weil es Anforderungen gibt, die unabhängigen Programm-Threads
vor der Kommunikation zu synchronisieren. Das Problem bei SIMD ist,
dass nicht alle Algorithmen einen effizienten Gebrauch von dem Grad
an Parallelität,
der im Prozessor vorliegt, machen können. Das Ausmaß an Parallelität, das in
verschiedenen Algorithmen inhärent
vorliegt, variiert, was zu Schwierigkeiten führt, eine breite Vielfalt von
Algorithmen auf SIMD-Maschinen effizient zu implementieren. Das
Problem bei MIMD-Maschinen ist, dass die Verzögerung von Kommunikationen
zwischen mehreren Prozessoren zu Schwierigkeiten führt, Prozessoren
zum Zusammenarbeiten bei der Verarbeitung eines Algorithmus' effizient zu synchronisieren.
Typischerweise ziehen MIMD-Maschinen im Vergleich zu SIMD-Maschinen
auch größere Implementationskosten
nach sich, weil jedes MIMD-PE seinen eigenen Anweisungs-Abfolge-Mechanismus haben
muss, was zu einem bedeutsamen Aufwand an Hardware führen kann.
MIMD-Maschinen weisen auch eine inhärent größere Komplexität an Programmsteuerung
auf, die erforderlich ist, um die unabhängigen parallelen Verarbeitungselemente
zu verwalten. Daher treten Grade von Programmierkomplexität und Kommunikationsverzögerung in
einer Vielzahl von Kontexten auf, wenn parallele Verarbeitungselemente
verwendet werden. Es wird von großem Vorteil sein, solche Probleme
effizient anzugehen, wie unten ausführlicher erläutert wird.
-
Von
Pechanek, G. G. et. al: "MFAST:
A Single Chip Highly Parallel Image Processing Architecture", Proceedings of
the International Conference on Image Processing (ICIP), Washington,
October 23-26 1995, Los Alamitos, IEEE Comp. Soc. Press, US. Vol.
3, 23 October 1995, pages 69-72, XP010196926 ISBN: 0-7803-3122-2
ist es für
einen Prozessor bekannt, einen Anweisungssatz zu verwenden, der
gekapselte sehr lange Anweisungswörter (eVLIW, encapsulated Very
Long Instruction Words) in jedem Verarbeitungselement in einem skalierbaren
Array verwendet, wobei jedes Verarbeitungselement ein eVLIW in einem
VLIW-Speicher speichert, der aus mehreren 32-Bit-Anweisungsslots gebildet ist, die mit
Ausführungseinheiten
und Speicherzugriffsfunktionen verbunden sind.
-
Minigawa
et. al: "Pre-Decoding
Mechanism for Superscalar Architecture", IEEE, May 1991, pages 21-24, XP002917704,
offenbart einen Predekodierungsmechanismus zum Predekodieren von
Anweisungen während
eines Ausführungspfades,
in welchem ein Predekoder entscheidet, welche funktionelle Einheit
Anweisungen ausführen
sollte. Ein Predekodier-Tag, das durch Dekodieren der Anweisungen
erzeugt wurde, wird in einem Anweisungs-Cache-Speicher gesichert.
-
US-A-5,649,135
offenbart ein paralleles Verarbeitungssystem, das ein sehr langes
Anweisungswort (VLIW, Very Long Instruction Word) für eine parallele
Steuerung einer Mehrzahl von primitiven Ausführungselementen verwendet.
-
Erfindungsgemäße Aspekte
sind in den begleitenden Ansprüchen
dargelegt.
-
Ein
ManArray-Prozessor, der dazu geeignet ist, in Übereinstimmung mit den Ausführungsformen
in Zusammenhang mit indirekten sehr langen ManArray-Anweisungswörtern (iVLIW)
verwendet zu werden, kann als ein Arrayprozessor implementiert sein,
der einen Ablaufprozessor (SP, Sequence Processor) aufweist, der als
eine Arraysteuerung für
ein skalierbares Array von Verarbeitungselementen (PEs) arbeitet,
um eine Architektur bereitzustellen, die auf indirekte sehr lange
Anweisungswörter
bezogen ist. Indirekte sehr lange Anweisungswörter (iVLIWs) in Übereinstimmung
mit den Ausführungsformen
können
durch den SIMD-Arraysteuerungs-Ablaufprozessor oder SP in einem
iVLIW-Anweisungsspeicher (VIM) zusammengesetzt werden. Vorzugsweise
existiert ein VIM in jedem Verarbeitungselement oder PE und enthält eine
Mehrzahl von iVLIWs. Nachdem ein iVLIW im VIM zusammengesetzt ist,
führt eine
andere SP-Anweisung,
in der bevorzugten Ausführungsform
als XV für "führe iVLIW aus" ("execute iVLIW") bezeichnet, das
iVLIW an einer identischen VIM-Adresse in allen PEs gleichzeitig
aus. Wenn alle PE-VIMs dieselbe Anweisung enthalten, tritt eine SIMD-Operation
auf. Es gibt eine Eins-zu-Eins-Zuordnung zwischen der XV-Anweisung
und dem einzelnen identischen iVLIW, das in jedem PE vorliegt.
-
Um
die Effizienz bestimmter Algorithmen, die auf dem ManArray laufen,
zu verbessern, ist es möglich, mit
der indirekten Ausführung,
die durch eine Ausführungs-VLIW-(XV)-Anweisung
initiiert wurde, und mit verschiedenen VLIW-Anweisungen, die in
den mehreren PEs an derselben VLIW-Speicheradresse gespeichert sind,
indirekt auf VLIW-Anweisungen, die in einem VLIW-Speicher gespeichert sind, zu arbeiten.
Wenn die SP-Anweisung bewirkt, dass dieser Satz von iVLIWS gleichzeitig über alle
PEs ausgeführt
wird, tritt eine synchrone MIMD- oder SMIMD-Operation auf. Zwischen der XV-Anweisung
und den mehreren verschiedenen iVLIWS, die in jedem PE existieren,
gibt es eine Eins-zu-Viele-Zuordnung. Es ist kein spezialisierter
Synchronisierungsmechanismus erforderlich, weil die mehreren verschiedenen
iVLIW-Ausführungsoperationen
mit dem Aussenden der XV-Anweisung durch den einzelnen Steuerungspunkt
SP syn chron initiiert sind. Durch die Verwendung eines Empfangs-Modells, um die Kommunikation
zwischen PEs und einem ManArray-Netz zu verwalten, ist das Merkmal
der Kommunikationsverzögerung,
das den MIMD-Operationen gemeinsam ist, vermieden, wie weiter unten
erläutert
wird. Da es nur einen synchronen Ausführungsort gibt, ist außerdem eine
zusätzliche
MIMD-Hardware für einen
separaten Programmablauf in jedem PE nicht erforderlich. Auf diese
Weise ist die Maschine dazu organisiert, SMIMD-Operationen bei reduzierten
Hardwarekosten zu unterstützen, während eine
Kommunikationsverzögerung
minimiert wird.
-
Ein
indirektes ManArray-VLIW oder -iVLIW wird vorzugsweise unter einer
Programmsteuerung geladen, obwohl die Alternativen eines Ladens
der iVLIWs über
direkten Speicherzugriff (DMA) und Implementierens eines Abschnitts
von VIM-Adressraum mittels eines ROM, das festgelegte iVLIWs enthält, nicht
ausgeschlossen sind. Um einen gewissen Grad an dynamischer Programmflexibilität aufrecht
zu erhalten, wird ein Bereich des VIM, wenn nicht der gesamte VIM,
typischerweise vom Random-Access-Speichertyp
sein. Um den VIM-Random-Access-Typ zu laden, spezifiziert eine Trennsymbol-Anweisung,
LV für
Lade-iVLIW, dass eine
bestimmte Zahl von Anweisungen, die auf das Trennsymbol folgen,
in den VIM zu laden sind, anstatt ausgeführt zu werden. Für eine SIMD-Operation
erhält
jedes PE dieselben Anweisungen für
jede VIM-Adresse. Um eine SMIMD-Operation
einzurichten ist es notwendig, verschiedene Anweisungen an derselben VIM-Adresse
in jedem PE zu laden.
-
In
der gegenwärtig
bevorzugten Ausführungsform
wird dies durch einen Maskierungsmechanismus erreicht, der so funktioniert,
dass das Laden des VIM nur auf PEs auftritt, die auf ON maskiert
sind. PEs, die auf OFF maskiert sind, führen die Trennsymbol-Anweisung
nicht aus und laden daher den spezifizierten Satz von Anweisungen,
der dem Trennsymbol folgt, nicht in den VIM. Alternativ könnten verschiedene
Anweisungen parallel vom lokalen PE-Speicher geladen werden oder
der VIM könnte
das Ziel einer DMA-Übertragung
sein. Eine andere Alternative zum Laden verschiedener Anweisungen
in dieselbe VIM-Adresse ist durch die Verwendung einer zweiten LV-Anweisung, LV2, gegeben,
welche ein zweites 32-Bit-Steuerungswort
aufweist, das der LV-Anweisung folgt. Die ersten und zweiten Steuerungswörter ordnen
die Bits zwischen sich neu an, so dass ein PE-Label hinzugefügt werden
kann. Dieses zweite LV2-Herangehen erfordert nicht, dass die PEs maskiert
werden und kann einige Vorteile in verschiedenen Systemimplementationen
bereitstellen. Indem verschiedene Anweisungen wahlweise in dieselbe
VIM-Adresse auf verschiedenen PEs geladen werden, ist der ManArray
für eine
SMIMD-Operation eingerichtet.
-
Ein
Problem, das beim Implementieren einer SMIMD-Operation angetroffen
wird, ist der Umgang mit der Kommunikation zwischen den Verarbeitungselementen.
Im SIMD-Modus führen
alle PEs im Array dieselbe Anweisung aus. Typischerweise denkt man,
dass diese SIMD-PE-zu-PE-Kommunikationen unter Verwendung eines
Sende-Modells stattfinden. Das heißt, dass die SIMD-Sende-Modell-Anweisungen
anzeigen, in welche Richtung oder zu welchem Ziel-PE jedes PE seine
Daten senden sollte. Wenn eine Kommunikationsanweisung, wie zum
Beispiel SEND-WEST angetroffen wird, sendet jedes PE Daten an das
PE, das topologisch als sein westlicher Nachbar definiert wurde.
Das Sende-Modell spezifiziert sowohl die Sender- als auch Empfänger-PEs.
Im SEND-WEST-Beispiel sendet jedes PE seine Daten an sein West-PE und empfängt Daten
von seinem Ost-PE. Im SIMD-Modus ist dies kein Problem.
-
Im
SMIMD-Operations-Modus ist es, unter Verwendung eines Sende-Modells,
mehreren Verarbeitungselementen möglich, ganz zu versuchen, Daten
zum selben Nachbarn zu senden. Dieser Versuch stellt eine riskante
Situation dar, weil Verarbeitungselemente wie die im ManArray so
definiert sein können,
dass sie nur einen Empfangsanschluss haben, der nur in der Lage
ist, von einem anderen Verarbeitungselement zur Zeit zu empfangen.
Wenn jedes Verarbeitungselement so definiert ist, dass es einen
Empfangsanschluss hat, kann solch eine versuchte Operation nicht
erfolgreich abgeschlossen werden und führt zu einem Kommunikationsrisiko.
-
Um
das oben beschriebene Kommunikationsrisiko zu vermeiden, wird ein
Empfangs-Modell für
die Kommunikation zwischen PEs verwendet. Unter Verwendung des Empfangs-Modells
steuert jedes Verarbeitungselement einen Schalter, der auswählt, von
welchem Verarbeitungselement er empfängt. Es ist unmöglich, dass
Kommunikationsrisiken auftreten, weil für beliebige zwei Verarbeitungselemente
unmöglich
ist, denselben Empfangsanschluss zu beanspruchen. Per Definition
steuert jede PE seinen eigenen Empfangsanschluss und macht Daten
ohne Ziel-PE-Spezifikation
verfügbar.
Für jegliche
bedeutsame Kommunikation, die zwischen Verarbeitungselementen unter
Verwendung des Empfangs-Modells stattfinden soll, müssen die
PEs programmiert sein, um beim Empfang der Daten, die verfügbar gemacht
wurden, zusammenzuarbeiten. Unter Verwendung von synchroner MIMD
(SMIMD) ist garantiert, dass dies geschieht, wenn die zusammenarbeitenden
Anweisungen alle am selben iVLIW-Ort existieren. Ohne SMIMD wäre ein komplexer
Mechanismus nötig, um
Kommunikationen zu synchronisieren und das Empfangs-Modell zu verwenden.
-
Ein
vollständigeres
Verständnis
der vorliegenden Erfindung sowie weitere erfindungsgemäße Leistungsmerkmale
und Vorteile werden von der folgenden ausführlichen Beschreibung und den
begleitenden Figuren offensichtlich.
-
Kurze Beschreibung der
Figuren
-
1 zeigt
verschiedene Aspekte eines ManArray-Speichers für indirekte VLIW-Anweisungen
in Übereinstimmung
mit einer Ausführungsform;
-
2 zeigt
einen grundlegenden iVLIW-Datenpfad;
-
3 zeigt
einen iVLIW mit fünf
Slots mit einer erweiterten Ansicht des ALU-Slots;
-
4A zeigt
eine LV-Laden/Modifizieren-VLIW-Anweisung;
-
4B zeigt
eine XV-Ausführungs-VLIW-Anweisung;
-
4C zeigt
Anweisungs-Feld-Definitionen;
-
4D zeigt
weitere Anweisungs-Feld-Definitionen;
-
4E zeigt
eine ADD (Hinzufügen)-Anweisung;
-
4F zeigt eine Slot-Speicherung für drei synchrone
MIMD-iVLIWs in einer 2 × 2
ManArray-Konfiguration;
-
5 zeigt
eine iVLIW-Laden-und-Holen-Pipeline in Übereinstimmung mit einer Ausführungsform;
-
6 zeigt
Aspekte von SIMD-iVLIW-Array-Verarbeitung;
-
7 zeigt
eine iVLIW-Übersetzungserweiterung;
-
8A zeigt
eine iVLIW-Übersetzungserweiterungs-Laden-und-Holen-Pipeline;
-
8B zeigt
ein alternatives Format für
eine VIM-iVLIW-Speicherung;
-
9 zeigt
eine Sende-Modell-Cluster-Schalter-Steuerung und ein beispielhaftes
Risiko für SMIMD-Kommunikationen,
die das Sende-Modell verwenden;
-
10 zeigt
ein Sende-Modell mit einer zentralisierten Cluster-Schalter-Steuerung;
und
-
11 zeigt
eine Empfangs-Modell-Cluster-Schalter-Steuerung, die verwendet wird, um Kommunikationsrisiken
im SMIMD-Operations-Modus zu vermeiden.
-
Ausführliche Beschreibung
-
Ein
Satz von gegenwärtig
bevorzugten Steuerungsanweisungen in Bezug auf indirekte sehr lange
Anweisungswörter
(iVLIW) (indirect Very Long Instruction Word (iVLIW) control instructions)
zur Verwendung in Verbindung mit einer Ausführungsform ist unten ausführlich beschrieben. 1 zeigt
ein System zur Ausführung
der iVLIWS an der Adresse "i", wo das iVLIW durch
den vertikalen Satz von Kästchen
SLAMD 105 in jedem VIM angezeigt ist, welche einen S=Speichern-,
L=Laden-, A=Arithmetisch-Logische-Einheit- (ALU)-, M=Multiplizieren-Akkumulieren-Einheit-
(MAU)-, und D=Daten-Auswahl-Einheit(DSU)-Satz von Anweisungen in
einem 2 × 2-ManArray 100 von
PEs 104, PE0-PE3, darstellen. In 1 beinhaltet
das 2 × 2-ManArray 100 ferner
eine Ablaufprozessor-(SP)-Steuerung 102, die 32-Bit-Anweisungen
an die Array-PEs über
einen einzelnen 32-Bit-Bus weitersendet. Ein Typ von 32-Bit-Instruktionen
ist eine Ausführungs-iVLIW-(XV)-Anweisung, die
einen VIM-Adressenoffset-Wert
enthält,
der in Verbindung mit einer VIM-Basis-Adresse
verwendet wird, um einen Pointer zu dem iVLIW zu erzeugen, von dem
gewünscht
wird, dass es ausgeführt
wird. Die PEs 104 sind durch einen Cluster-Schalter miteinander
verbunden.
-
Der
SP 102 und jedes PE 104 in der ManArray-Architektur,
die zur Verwendung in Übereinstimmung mit
der Ausführungsform
ausgebildet sind, enthalten einen Bereich vom iVLIW-Speicher (VIM) 106,
wie in 1 gezeigt ist. Jeder VIM 106 enthält Speicherplatz,
um mehrere VLIW-Anweisungsadressen 103 zu halten und jede
Adresse ist in der Lage, bis zu acht Simplex-Anweisungen zu speichern. Gegenwärtig bevorzugte Implementationen
gestatten es jeder iVLIW-Anweisung, bis zu fünf Simplex-Anweisungen zu enthalten:
eine, die mit jedem von der Speichereinheit 108, Ladeinheit 110,
Arithmetisch-Logischen-Einheit 112 (ALU),
Multiplizieren-Akkumulieren-Einheit 114 (MAU) und Daten-Auswahl-Einheit 116 (DSU) 116 verbunden
ist. Beispielsweise enthält
eine iVLIW-Anweisung an der VIM-Adresse "i" 105 die fünf Anweisungen SLAMD.
-
2 zeigt
eine grundlegende iVLIW-Datenpfad-Anordnung 200, durch
welche eine geholte Anweisung in einem Anweisungsregister 20 gespeichert
wird, das mit der VIM-Laden-und-Speichern-Steuerungsfunktion 22 verbunden
ist. Die VIM-Laden-und-Speichern-Steuerungsfunktion
stellt die Schnittstellensignale zum VIM 24 bereit. Der
VIM 24 entspricht dem VIM 106, wobei jeder VIM 106 von 1 zugeordnete
Register und Steuerungen aufweist, wie die, die in 2 gezeigt
sind. Der Ausgang des VIM 24 wird dem iVLIW-Register 26 über eine
Pipeline zugeführt. 3 zeigt
einen Fünf-Slot-iVLIW-VIM 300 mit
N Einträgen
0, 1, ... N – 1.
Jeder durch den VIM 300 adressierte Ort beinhaltet Speicherplatz
für Speichern-,
Laden-, ALU-, MAU- und DSU-Anweisungen 301-305.
Eine erweiterte ALU-Slot-Ansicht 303' zeigt einen
32-Bit Speicherraum, bei dem das Bit-31 mit "d" markiert
wurde. Die Verwendung der Anweisungsbits im VIM-Speicher wird unten
ausführlicher
erläutert.
-
iVLIW-Anweisungen
können
gemeinsam in ein Array von PE-VIMs geladen werden, oder jeder PE-VIM
kann unter Verwendung spezieller Anweisungen zum Maskieren eines
PE oder PEs individuell geladen werden. Auf die iVLIW-Anweisungen
im VIM wird durch die Ausführungs-VLIW-(XV)-Anweisung
zur Ausführung
zugegriffen, wobei die Ausführungs-VLIW-XV)-Anweisung,
wenn sie als eine einzelne Ausführung ausgeführt wird,
die simultane Ausführung
der Simplex-Anweisungen, die an der VIM-Speicheradresse angeordnet sind, bewirkt.
Eine XV-Anweisung kann die simultane Ausführung von
- 1.
allen der Simplex-Anweisungen, die an einer individuellen VIM-Adresse
eines SP's oder
PE's angeordnet sind,
oder
- 2. allen Anweisungen, die in allen PEs an derselben relativen
VIM-Adresse angeordnet sind, oder
- 3. allen Anweisungen, die an einer Untermenge oder Gruppe von
allen PEs bei derselben relativen VIM-Adresse angeordnet sind
bewirken.
-
Nur
zwei Steuerungsanweisungen sind erforderlich, um iVLIW-Speicher zu laden/modifizieren
und, um iVLIW-Anweisungen auszuführen.
Diese sind:
- 1. Laden/Modifizieren-VLIW-Speicher-Adresse
(LV), die in 4A gezeigt ist und
- 2. VLIW-Ausführen
(XV), die in 4B gezeigt ist.
-
Die
in 4A gezeigte LV-Anweisung 400 dient dem
32-Bit-Kodieren,
wie im Kodierblock 410 gezeigt, und weist die gegenwärtig bevorzugte
Syntax/Operation auf, die im Syntax/Operation-Block 420 gezeigt
ist, wie weiter unten beschrieben ist. Die LV-Anweisung 400 wird
dazu verwendet, in dividuelle Anweisungslots des spezifizierten SP
oder PE-VLIW-Speicher
(VIM) zu laden und/oder zu deaktivieren. Die VIM-Adresse wird als die
Summe eines Basis-VIM-Adress-Registers
Vb (V0 oder V1) plus einem vorzeichenlosen 8-Bit-Offset VIMOFFS, der in den Bits 0-7,
dem Block von Bits 411, vom Kodierblock 410 in 4A,
gezeigt ist. Die VIM-Adresse muss im gültigen Bereich für die Hardwarekonfiguration
sein, ansonsten ist die Operation dieser Anweisung undefiniert.
-
Jegliche
Kombination von individuellen Anweisungslots kann über den
Slot-Deaktivierungsparameter 'd={SLAMD}' deaktiviert werden,
wobei S=Speicher-Einheit (SU), L=Lade-Einheit (LU), A=Arithmetisch-Logische-Einheit
(ALU), M=Multiplizieren-Akkumulieren-Einheit
(MAU) und D=Daten-Auswahl-Einheit (DSU). Ein leerer 'd='-Parameter deaktiviert
keinen Slot. Spezifizierte Slots sind deaktiviert, bevor irgendeine
Anweisung geladen wird.
-
Die
Anzahl zu ladender Anweisungen ist unter Verwendung eines InstrCnt-Parameters
spezifiziert. Für die
vorliegende Implementation sind Werte von 0-5 gültig. Die nächsten InstrCnt-Anweisungen, die
der LV folgen, werden in den spezifizierten VIM geladen. Der Unit-Affecting-Flags-(UAF)
(eine Einheit betreffendes Markierungszeichen)-Parameter 'F=[AMD]' wählt aus,
welchem Slot für
arithmetische Anweisungen (A=ALU, M=MAU, D=DSU) es gestattet ist,
Bedingungs-Flags für
den spezifizierten VIM zu setzen, wenn er ausgeführt wird. Ein leeres 'F=' wählt den
ALU-Anweisungslot aus. Während
der Verarbeitung der LV-Anweisung sind keine arithmetischen Flags
betroffen und die Anzahl an Zyklen ist eins plus der Anzahl geladener
Instruktionen.
-
Die
in 4B gezeigte XV=Anweisung 425 ist auch
für das
32-Bit-Kodieren
vorgesehen, wie im Kodierblock 430 gezeigt ist und weist
die gegenwärtig
bevorzugte im Syntax/Operation-B1ock 435 gezeigte
Syntax/Operation auf, wie weiter unten beschrieben ist. Die XV-Anweisung 425 wird
verwendet, um individuelle Anweisungsslots des spezifizierten SP
oder PE-VLIW-Speicher
(VIM) auszuführen.
Die VIM-Adresse wird als die Summe eines Basis-VIM-Adress-Registers
Vb (V0 oder V1) plus einem vorzeichenlosen 8-Bit-Offset VIMOFFS,
gezeigt in den Bits 0-7, dem Block von Bits 431, des Kodierblocks 430 von 4B,
berechnet. Die VIM-Adresse muss im gültigen Bereich für die Hardwarekonfiguration
sein, ansonsten ist die Operation dieser Anweisung undefiniert.
-
Jegliche
Kombination individueller Anweisungsslots kann durch den Anweisungsslot-Parameter 'E={SLAMD}' ausgeführt werden,
wobei S=Speicher-Einheit (SU), L=Lade-Einheit (LU), A=Arithmetisch-Logische-Einheit
(ALU), M=Multiplizieren-Akkumulieren-Einheit
(MAU), D=Daten-Auswahl-Einheit (DSU). Ein leerer 'E='-Parameter führt keinen
Slot aus. Der Unit-Affecting-Flags-(UAF)-Parameter 'F=[AMDN]' überschreibt den für das VLIW
spezifizierten UAF, wenn es durch die LV-Anweisung geladen wurde. Das Überschreiben wählt aus,
welchem arithmetischen Anweisungsslot (A=ALU, M=MAU, D=DSU) oder
keinem (N=NONE) es gestattet ist, Bedingungsflags für die Ausführung des
VLIW zu setzen. Das Überschreiben
betrifft nicht die UAF-Einstellung, die durch die LV-Anweisung spezifiziert
ist. Ein leeres 'F=' wählt das
UAF aus, das spezifiziert war, als das VLIW geladen wurde.
-
Bedingungsflags
werden durch die individuelle Simplex-Anweisung in dem Slot gesetzt, welcher
durch das Einstellen des 'F='-Parameters von der
ursprünglichen
LV-Anweisung oder nach Überschreiben
durch einen 'F=[AMD]'-Parameter in der
XV-Anweisung spezifiziert
ist. Bedingungs-Flags sind nicht betroffen, wenn 'F=N'. Eine Operation
läuft in
einem Zyklus ab. Pipeline-Betrachtungen müssen auf der Grundlage der
individuellen Simplex-Anweisungen in jedem der ausgeführten Slots
berücksichtigt
werden. Beschreibungen individueller Felder in diesen iVLIW-Anweisungen
sind in den 4C und 4D gezeigt.
Die 4C und 4D zeigen
Anweisungsfelddefinitionen 440, die nach Name 442,
Anzahl an Bits 444 und Beschreibungswerten 446 tabelliert
sind. 4E und 4F zeigen
eine gegenwärtig
bevorzugte ADD-Anweisung bzw. Slot-Speicherung für drei synchrone MIMD-iVLIWs
in einer 2 × 2-ManArray-Konfiguration.
-
Die
in 4E gezeigte ADD-Anweisung ist wieder für eine 32-Bit-Kodierung, wie
im Kodierblock 455 gezeigt, vorgesehen und weist die gegenwärtig bevorzugte
im Syntax/Operation-Block 460 gezeigte Syntax/Operation
auf, wie weiter unten beschrieben ist. Die ADD-Anweisung 450 wird
verwendet, um die Summe von Quellregistern Rx und
Ry im Zielregister Rt zu
speichern. Arithmetische skalare Flags sind bei am wenigsten signifikanter
Operation (least significant operation) betroffen, wo N = MSB der
sich ergebenden Summe ist, Z = 1, falls das Ergebnis Null ist und
andernfalls 0, V = 1, falls ein Überlauf
auftritt und andernfalls 0, C = 1, falls ein Übertrag auftritt und andernfalls
0. Das v-Bit ist für
vorzeichenbehaftete Operationen von Bedeutung, und das C-Bit ist
für vorzeichenlose
Operationen von Bedeutung. Die Anzahl von Zyklen ist eins.
-
Individuelle, Gruppen-
und "Synchrone MIMD"-PE-iVLIW-Operationen
-
Die
LV- und XV-Operationen können
verwendet werden, um iVLIW-Anweisungen
in individuellen PEs oder PE-Gruppen, die durch den Programmierer
definiert sind, zu laden, modifizieren, de aktivieren oder auszuführen. Um
dies durchzuführen,
werden individuelle PEs durch eine Anweisung aktiviert oder deaktiviert, welche
ein in jedem PE angeordnetes Steuerungsregister modifiziert, welches,
unter anderem, jedes PE aktiviert oder deaktiviert. Um ein individuelles
PE oder eine Gruppe von PEs zu laden und betreiben, werden die Steuerungsregister
modifiziert, um individuelle PE(s) zu aktivieren und alle anderen
zu deaktivieren. Normale iVLIW-Anweisungen werden dann nur auf den
PEs arbeiten, die aktiviert sind.
-
Bezugnehmend
auf 5 werden Aspekte der iVLIW-Laden- und -Holen-Pipeline
in Verbindung mit einem iVLIW-System 500 beschrieben. Neben
ihren anderen Aspekten zeigt 5 einen
Auswahlmechanismus, um eine Auswahl von Anweisungen vom VIM-Speicher heraus zu
ermöglichen.
Eine geholte Anweisung wird in ein erstes Anweisungsregister (IR1) 510 geladen.
Das Register 510 entspricht allgemein dem Anweisungsregister 20 von 2.
Der Ausgang vom IR1 wird früh
im Pipelinezyklus im Predekoder oder in der Predekodierfunktion 512 predekodiert,
bevor das zweite Anweisungsregister (IR2) 514 geladen wird.
Wenn die Anweisung im IR1 eine Laden-iVLIW-Anweisung (LV) mit einem
Nicht-Null-Anweisungs-Zähler
ist, erzeugt der Predekoder 512 ein LVc1 Steuerungssignal 515,
welches dazu verwendet wird, den LV-Operationszyklus einzurichten,
und die VIM-Adresse 511 wird
unter Verwendung des spezifizierten Vb-Registers 502, dem ein Addierer 504 zu
einem in der LV-Anweisung
beinhalteten Offsetwert über
den Pfad 503 addiert wurde. Die sich ergebende VIM-Adresse 511 wird
im Register 506 gespeichert und durch den Multiplexer 508 zum
Adressieren des VIM 516 übergeben. Der VIM 516 entspricht
allgemein dem VIM 106 von 1. Das Register 506 ist
erforderlich, um die VIM-Adresse 507 während der LV-Operationen zu
halten. Die VIM-Adresse 511 und der LV-Steuerungsszustand
gestatten das Laden der Anweisungen, die nach der LV-Anweisung empfangen
wurden, in den VIM 516. Am Ende des Zyklus', in welchem die
LV empfangen wurde, werden die in 4A gezeigten
Deaktivierungsbits 10-17 in das d-Bits-Register 518 für den Gebrauch
geladen, wenn Anweisungen in den VIM 516 geladen werden.
Auf den Empfang der nächsten
Anweisung im IR1 510, die ins VIM 516 zu laden ist,
wird das geeignete Steuerungssignal in Abhängigkeit vom Anweisungstyp
Storec1 519, Loadc1 521, ALUc1 523, MAUc1 525 oder
DSUc1 527 erzeugt. Die Predekodierfunktion 512 ist
vorzugsweise auf der Grundlage eines einfachen Dekodierens der Gruppenbits
(Bits 30 und 31), welche den in 4A,
B und E gezeigten Anweisungstyp definieren, und der in 4D und 4E gezeigten
Einheitsfeld-Bits (Bits 27 und 28, die den Ausführungseinheitstyp
spezifizieren) bereitgestellt. Unter Verwendung dieses Predekodierschritts kann
die Anweisung im IR1 510 in den VIM 516 in der
richtigen funktionalen Einheitsposition geladen werden. Beispielsweise
kann für
die ADD-Anweisung von 4E, die in der LV-Anweisungsliste enthalten
ist, wenn diese Anweisung im IR1 510 empfangen wird, durch
die Predekodierfunktion 512 bestimmt werden, dass diese Anweisung
in den ALU-Anweisungslot 520 im VIM 516 geladen
werden sollte. Zusätzlich
wird das geeignete d-Bit 531 für diese funktionelle Slotposition
in das Bit 31 dieses Slots geladen. Das geladene d-Bit
belegt eine der Gruppen-Code-Bit-Positionen von der ursprünglichen
Anweisung.
-
Auf
den Empfang einer XV-Anweisung im IR1 510 wird die VIM-Adresse 511 durch
Verwendung des spezifizierten Vb-Registers 502, dem ein
Addierer 504 zu dem in der XV-Anweisung beinhalteten Offsetwert über den
Pfad 503 addiert wurde, berechnet. Die sich ergebende VIM-Adresse 507 wird
durch den Multiplexer 508 zum Adressieren des VIM übergeben.
Das iVLIW an der spe zifizierten Adresse wird aus dem VIM 516 ausgelesen
und durch die Multiplexer 530, 532, 534, 536 und 538 zu
den IR2-Registern 514 übergeben.
Als eine Alternative, den kritischen Zeitpfad des Lesezugriffs auf
den VIM zu minimieren, kann der Ausgang des VIM 516 gemäß dem Latch-Prinzip
in ein Register übergeben
werden, dessen Ausgang durch einen Multiplexer vor der Dekodier-Status-Logik übergeben
wird.
-
Für die Ausführung der
XV-Anweisung bewirkt das IR2MUX1-Steuerungssignal 533 zusammen
mit dem Predekodier-XVc1-Steuerungssignal 517,
dass alle die IR2-Multiplexer 530, 532, 534, 536 und 538 die VIM-Ausgangspfade 541, 543, 545, 547 und 549 auswählen. An
diesem Punkt sind die fünf
individuellen Dekodier- und Ausführungsstufen
der Pipeline, 540, 542, 544, 546 und 548 synchron
vervollständigt,
wobei sie die parallele iVLIW-Ausführungs-Leistung bereitstellen,
Um es einer einzelnen 32-Bit-Anweisung zu gestatten, dass sie im
PE oder SP direkt selbst (execute by itself) ausgeführt wird,
ist der VIM-Bypass-Pfad 535 gezeigt. Wenn
beispielsweise eine Simplex-ADD-Anweisung
im IR1 510 für
eine parallele Array-Ausführung
empfangen wird, erzeugt die Predekodierfunktion 512 das
IR2MUX1-Steuerungssignal 533, welches in Verbindung mit
dem Predekodiersignal vom Anweisungstyp, 523 im Falle eines
ADD und Nichtvorliegen eines aktiven Steuerungssignals XV 517 oder
LV 515, bewirkt, dass der ALU-Multiplexer 534 den
Bypasspfad 535 auswählt.
-
Da
ein ManArray mit einer variierenden Anzahl von PEs konfiguriert
werden kann, zeigt 6 eine beispielhafte SIMD-iVLIW-Verwendung
eines iVLIW-Systems, wie beispielsweise des in 5 gezeigten
Systems 500. In 6 gibt es J + 1 PEs, wie durch
die PE-Nummerierung PE0 bis PEJ angezeigt ist. Ein Abschnitt von
LV-Code ist in 6 gezeigt und zeigt an, dass
drei Anweisungen an der VIM-Adresse 27 geladen werden sollen,
wobei der Lade-Einheits- und MAU-Anweisungs-Slot deaktiviert sind.
Diese Ladeoperation wird auf der Grundlage der in 4A gezeigten
Syntax von der LV-Anweisung 601 bestimmt. Unter der Annahme,
dass all PEs on maskiert sind, werden dann die angezeigten drei
Anweisungen 603, 605 und 607 an der VIM-Adresse 27 in
jedem der J + 1 PEs im Array geladen. Das Ergebnis dieses Ladens
ist in 6 gezeigt, indem gezeigt ist, dass die Anweisungen
in ihren geeigneten Ausführungsslots
in den VIMs gespeichert sind, Anweisung 603 im ALU-Slot,
Anweisung 605 im DSU-Slot und Anweisung 607 im
Speichern-Einheit-Slot.
-
Es
wird angemerkt, dass in der vorangegangenen Erläuterung, gestützt durch
die 3, 5 und 6, die Prekodierfunktion
es den mehreren Bit-31-Positionen der VIM-Slot-Felder gestattet,
mit den gespeicherten in 5 gezeigten d-Bits 518 geschrieben
zu werden, die von der LV-Anweisung erzeugt wurden, die die VIM-Lade-Abfolge
initiierte. Es wird ferner angemerkt, dass es für das Einheits-Feld, Bits 27 und 28,
in den arithmetischen Anweisungen, siehe beispielsweise 4E,
erforderlich ist, zu bestimmen, in welchen VIM-Slot eine arithmetische
Anweisung zu laden ist. Da die Anweisung im IR1 durch Verwendung
der Predekodierfunktion spezifisch dem Ausführungseinheitsslot im VIM zugeordnet
werden kann, ist es nicht nötig,
die Gruppenbits und die Einheitsfeldbits im VIM zu speichern und
sie können
für andere
Zwecke verwendet werden, wie durch die Verwendung des einzelnen
d-Bits in der vorangehenden Erläuterung
gezeigt wurde. Die spezifischen Bitpositionen in den VIM-Slots sind
im VIM 700 in 7 gezeigt, worin eines der Anweisungsgruppenbits,
Bit 30 von 4E, und die Anweisungseinheitsfeldbits,
Bits 27 und 28, im VIM 700 durch die Übersetzungserweiterungsoptionsbits "o" für
Opcodeerwei terungs-Bit 30, bezeichnet mit 721,
von 7, "r" für Registerdateierweiterungs-Bit 28,
bezeichnet mit 723, und "c" für Erweiterungs-Bit
für bedingte
Ausführung 27,
bezeichnet mit 725, ersetzt sind. Diese zusätzlichen
Bits sind separat in einem in 8A gezeigten
Register für
Verschiedenes 850 gespeichert, in das der Programmierer
laden kann oder von welchem er speichern kann. Diese Bits stellen
erweiterte Leistungsmerkmale bereit, die aufgrund eines Mangels
an Anweisungskodierbits in einem 32-Bit Anweisungsformats nicht
bereitgestellt werden konnten. Für
das Opcodeerweiterungs-Bit "o" ist es möglich, einen
Satz von Anweisungen auf einen neuen Satz von Anweisungen abzubilden. Für das Registererweiterungs-Bit "r" ist es möglich, den Registerdateiraum
zu verdoppeln und zwei Registerbänke
zu haben, die entweder zusätzlichen
Registerraum bereitstellen oder als ein Mechanismus für ein schnelles
Kontextumschalten wirken, so dass es zwei Registerbänken ermöglicht ist,
zwischen zwei Kontexten aufgeteilt zu sein. Für das Erweiterungs-Bit für bedingte
Ausführung "c" ist es möglich, unter der Kontrolle
eines Programmierers zwei verschiedene Sätze von Bedingungen zu spezifizieren
oder eine unterschiedliche bedingte Ausführungsfunktionalität zu spezifizieren.
-
8A zeigt
ein iVLIW-System 800, das Aspekte der iVLIW-Übersetzungserweiterungs-Laden-und-Holen-Pipeline
zeigt, wobei die Hinzufügung
des o-, r- und c-Bits-Registers 850 und des Satzes von Predekodier-Steuerungssignalen 815, 817, 819, 821, 823, 825, 827 und 833 gezeigt
ist. Es wird angemerkt, dass andere Verwendungen dieser freigestellten
Bits möglich
sind. Beispielsweise könnten
alle drei Bits für
Registerdateierweiterungen verwendet werden, die den Drei-Operandenanweisungen
entweder eine individuelle Steuerung be reitstellt oder bis zu acht
Bänke von
32 × 32
Registern bereitstellt.
-
Um
es einer einzelnen 32-Bit-Anweisung zu gestatten, im iVLIW-PE oder
iVLIW-SP direkt selbst (execute by itself) ausgeführt zu werden,
ist der Bypass-VIM-Pfad 835 in 8A gezeigt.
Wenn beispielsweise eine Simplex-ADD-Anweisung zur parallelen Array-Ausführung im
IR1 810 empfangen wird, erzeugt die Predekodierfunktion 812 das
IR2MUX2-833-Steuerungssignal, welches in Verbindung mit
dem Predekodiersignal vom Anweisungstyp, 823 im Falle eines
ADD, und Nichtvorliegen eines aktiven XV- 817 oder LV- 815 Steuerungssignals,
bewirkt, dass der ALU-Multiplexer 834 den Bypasspfad 835 auswählt. Da,
wie hier beschrieben, die Bypassoperation während einer vollständigen Stufe
der Pipeline auftreten soll, ist es möglich, die Gruppenbits und
die Einheitsfeldbits in den durch Bypass umgangenen Anweisungen
zu ersetzen, sobald sie die IR2-Latch-Stufe erreichen. Dies ist in der 8A durch
den "o-, r- und c-" Bitssignalpfad 851 dargestellt,
der verwendet wird, die geeigneten Bitpositionen am Eingang der
Multiplexer 830, 832, 834, 836 und 838 zu
ersetzen.
-
Es
wird angemerkt, dass alternative Formate für die VIMiVLIW-Speicherung
möglich
sind und in Abhängigkeit
von Technologie- und Entwurfs-Erwägungen vorteilhaft sein können. Beispielsweise
zeigt 8B eine von der in 7 und 8A gezeigten
alternative Form VIM 800'.
Die d-Bits pro Ausführungsslot
sind zusammen mit den zusätzlichen
Bits "o-, r-, c- und uaf-"-Bits gruppiert.
Diese zehn Bits sind separat von den in den Bits 0-26, 29 pro jedem
Slot definierten Ausführungseinheitsfunktionsbits
gruppiert. Es ist nötig,
dass die Unit-Affecting-Field-(uaf)-Bits 22 und 23 von 4A von
der LV-Anweisung an einer einzelnen iVLIW-VIM-Adresse gespeichert werden,
weil die "uaf"-Bits es betreffen,
welche arithmetische Einheit die Flags zum Ausführungszeitpunkt betrifft. Es
sind andere Speicherformate möglich,
beispielsweise die d-Bits
mit den Funktionsbits zu speichern und die Bits, die mit dem ganzen
iVLIW verbunden sind, wie beispielsweise die "uaf"-Bits,
sind separat gespeichert. Es wird auch angemerkt, dass es für einen
k-Slot-iVLIW nicht unbedingt erforderlich ist, dass k·32 Bits
im VIM gespeichert werden. Aufgrund der Dekodierfunktion ist es
nicht nur möglich,
zusätzliche
Bits in dem k·32-Bit-Raum
zu speichern, von dem angenommen wird, dass er erforderlich ist, die
k 32-Bit-Anweisungen zu speichern, sondern es ist auch möglich, den
k·32-Bit-Raum
zu reduzieren, wenn eine volle Verwendung der Bits nicht erfordert
ist. Dies ist in 8B gezeigt, wo die Gesamtzahl
an Speicherbits pro VIM-Adresse gegeben ist durch fünf mal der
pro Ausführungseinheitsslotposition
(0-26 und 29) erforderten 28 Bits plus fünf d-Bits, plus drei "o-, r- und c-"-Bits plus "uaf"-Bits für einen
Gesamtwert von 150 Bits pro iVLIW-Adresse, was um zehn weniger ist als
die 5·32
= 160 Bits, von denen man annehmen könnte, dass sie erforderlich
wären.
Eine erweiterte Funktionalität
ergibt sich, während
der VIM-Speicherraum
reduziert wird. Im allgemeinen können
zusätzliche
Informationen im VIM individuell pro Ausführungseinheit oder als separate
individuelle Bits, die die Steuerung über das an der VIM-Adresse
gespeicherte iVLIW betreffen, gespeichert werden. Beispielsweise
können
sechzehn zusätzliche
Bits für
unmittelbares Laden in einem separaten "konstanten" Register gespeichert und in eine VIM-Adresse
geladen werden, um die Leistung der Ladeeinheit zum Laden von 32
Bits unmittelbarer Daten zu erweitern. Um diese Erweiterung zu erreichen,
muss die VIM-Datenbreite geeignet erweitert werden. Auch die Größe der gespeicherten
iVLIW ist davon entkoppelt, ein Vielfaches der Anweisungsgröße zu sein,
so dass es auf der Grund lage von Anforderungen dem gespeicherten
iVLIW gestattet ist, größer als
oder kleiner als die k·32
Bits für
ein k-Anweisungs-iVLIW
zu sein.
-
In
einem Prozessor, der aus einer SP-Steuerung 102 wie in 1,
aber aus Gründen
der Klarheit nicht in 9 oder 10 gezeigt,
und einem Array von PEs, wie beispielsweise Prozessor 900 von 9 oder Prozessor 1000 von 10,
besteht, kann ein Problem angetroffen werden, wenn SMIMD-Operationen
implementiert werden, wenn man es mit Inter-PE-Kommunikationen (Kommunikationen zwischen
PEs) zu tun hat.
-
Der
typische SIMD-Kommunikationsmodus spezifiziert, dass alle PEs dieselbe
Inter-PE-Kommunikationsanweisung ausführen. Diese SIMD-Inter-PE-Anweisung,
die in jedem PE dieselbe ist, erfordert einen gemeinsamen Steuerungsmechanismus,
um eine Übereinstimmung
mit der zwischen den PEs definierten gemeinsamen Operation sicherzustellen.
Typischerweise wird ein Sende-Modell
verwendet, wo eine einzelne Anweisung, wie beispielsweise SEND-WEST,
an alle PEs im Array gesendet wird. Die SIMD-Inter-PE-Kommunikationsanweisung
bewirkt eine koordinierte Steuerung der Netzschnittstelle zwischen
den PEs, um es jedem PE zu gestatten, Daten an das durch die Inter-PE-Anweisung topologisch
definierte PE zu senden. Wie in 9 gezeigt,
kann durch ein einzelnes PE diese einzelne SIMD-Anweisung interpretiert werden und die
Netzschnittselle 911 gesteuert werden, da alle PEs dieselbe
Anweisung empfangen. Es wird angemerkt, dass der in 9 gezeigte
ManArray-2 × 2-Cluster-Schalter
aus vier 4-zu-1 Multiplexern 920, 922, 924 und 926 für die Schnittstellen-Eingangs-Ausgangs-(I/O)-Busse
zwischen den DSU zusammengesetzt ist. Diese Busse können ohne
Einschränkung
8-, 9-, 16-, 32-, 64-, oder eine andere Bitzahl, -Bitbusse sein.
Die Steuerung eines einzelnen 4-zu-1-Multiplexers erfordert nur zwei Steuerungsbits,
um einen der vier möglichen
Pfade auszuwählen.
Wenn es erforderlich ist, kann dies für größere PE-Cluster mit größeren Multiplexern
erweitert werden. Es ist auch in einem SIMD-System möglich, eine
zentralisierte Steuerung für
das Schnittstellennetz zwischen den PEs vorzusehen, wie in 10 gezeigt.
In 10 empfängt
eine zentralisierte Steuerung 1010 dieselbe gesendete Inter-PE-Kommunikationsanweisung 1011 von
der SP-Steuerung wie die anderen PEs im Netz. Dieser Mechanismus
gestattet es den Netzverbindungen auf einer zyklusbezogenen Basis
gewechselt zu werden. Zwei Attribute des SIMD-Sende-Modells sind
eine gemeinsame Anweisung an alle PEs und die Spezifikation von
sowohl dem Sender als auch dem Empfänger. Im SIMD-Modus ist diese
Vorgehensweise kein Problem.
-
Beim
Versuch, das Sende-Modell zum SMIMD-Modus zu erweitern, können andere
Probleme auftreten. Ein solches Problem ist, dass es im SMIMD-Modus
mehreren Verarbeitungselementen möglich ist, dass alle versuchen,
Daten an ein einzelnes PE zu senden, weil jedes PE eine unterschiedliche
Inter-PE-Kommunikationsanweisung
empfangen kann. Die zwei Attribute des SIMD-Sende-Modells brechen
unmittelbar zusammen, nämlich
eine gemeinsame Inter-PE-Anweisung zu haben und sowohl Quelle als
auch Ziel, oder, mit anderen Worten, sowohl Sender als auch Empfänger, zu
spezifizieren. Es ist ein Kommunikationsrisiko, in einem SIMD-Modell
bei Einzel-Zyklus-Kommunikationen
mehr als ein PE zu haben, das dasselbe PE als Ziel hat. Dieses Kommunikationsrisiko
ist in 9 gezeigt, worin die DSUs für PEs 1, 2 und 3 Daten an PE0
senden sollen, während
PE0 Daten an PE3 senden soll. Diese drei Dateneingaben an PE0 können nicht
empfangen werden. In anderen Systemen bewirkt die Lösung dieses
Problemtyps vielfach, dass das Einfügen von Schnittstellenpuffern
und Prioritätssteuerungslogik
einen oder mehrere der Konfliktpfade verzögert. Dies verletzt inhärent die
synchrone Natur der SMIMD-Verarbeitung, da die Planung der Einzel-Zyklus-Kommunikationsoperationen
während
der Programmierung der in den PEs auszuführenden iVLIW-Anweisungen erfolgen
muss. Um die Kommunikationsrisiken zu vermeiden, ohne die Anforderungen
an synchrone MIMD zu verletzen, wird vorteilhaft ein Empfangs-Modell
verwendet. Der einzelne Punkt von Netzsteuerung, ob er in einem
einzelnen PE oder in einem zentralisierten Steuerungsmechanismus
angeordnet ist, der durch das Sende-Modell ermöglicht ist, wird im Empfangs-Modell
durch verteilte Netzschnittstellensteuerung ersetzt. Jedes PE steuert
seinen eigenen Empfangsanschluss. Das Empfangs-Modell spezifiziert
den Empfangspfad durch die Netzschnittstelle. Im Falle des ManArray-Netzes
steuert jedes PE seinen eigenen Multiplexer-Eingangs-Pfad vom Cluster-Schalter.
-
Diese
Anordnung ist für
einen 2 × 2-Array-Prozessor 1100 in 11 gezeigt,
wo jedes PE seine eigene Steuerung seiner Eingangsmultiplexer 1120, 1122, 1124,
bzw. 1126 aufweist. Beispielsweise hat PE0 Steuerungssignale 1111 zur
Steuerung seines Eingangsmultiplexers 1120. Das Empfangsmodell
erfordert auch, dass Daten an den Ausgangsanschluss der PEs dem
Schnittstellen-Netz ohne eine Ziel-PE-Spezifikation verfügbar gemacht
werden. Für
jegliche bedeutsame Kommunikation, die zwischen PEs, die das Empfangs-Modell
verwenden, stattfinden soll, müssen
die PEs daher dazu programmiert sein, beim Empfang von verfügbar gemachten
Daten zusammenzuarbeiten. Bei Verwendung von synchronem MIMD ist
garantiert, dass diese Zusammenarbeit eintritt, wenn die Zusammenarbeitsanweisungen
am selben iVLIW-Ort liegen. Mit diesem Anweisungsort führen die
zusammenarbeitenden PEs, wenn eine XV-Anweisung ausgeführt wird,
die geeigneten Inter-PE-Kommunikationsanweisungen aus, um eine Datenbewegung
zwischen beliebigen zwei oder mehr PEs zu bewirken. Im allgemeinen
können
in einem Array von PEs mehrere Gruppen von PEs sein. In jeder solch
einen Gruppe können
ein oder mehr PEs Daten von einem anderen PE empfangen, während in
einer anderen Gruppe ein oder mehr PEs Daten von einem verschiedenen
PE empfangen kann. Eine Gruppe kann in ihrer Größe von zwei PEs bis zum gesamten
Array von PEs variieren. Während 11 zur
Erleichterung und Klarheit der Darstellung keinen SP zeigt, wie
beispielsweise die SP-Steuerung 102 von 1,
wird solch eine Steuerung vorzugsweise aufgenommen sein, obwohl
es zu erkennen ist, dass die SP-Funktionalität mit einem PE, wie beispielsweise
PE0, gemischt werden kann, wie es in der U.S. Provisional Application
Nr. 60/077,457 gelehrt wird, die zuvor durch Bezugnahme aufgenommen
wurde, oder die SP-Funktionalität
könnte allen
den PEs hinzugefügt
werden, obwohl solch eine erweiterte Funktionalität relativ
teuer sein würde.
-
4F zeigt die Definition 470 von
drei Synchron-MIMD-iVLIWs
in einer 2 × 2-ManArray-Konfiguration.
Der obere Abschnitt 480 gibt eine erläuternde Ansicht der Operationen.
Der untere Abschnitt 490 gibt die entsprechenden Anweisungsmnemonics,
die in der LU, MAU, ALU, DSU bzw. SU geladen werden. Jedes iVLIW
enthält
vier Reihen zwischen dicken schwarzen Linien, eine für jedes
PE. Die am weitesten linksstehende Spalte der Figur zeigt die Adresse,
wo das iVLIW im PE-iVLIW-Speicher
(VIM) geladen wird. Die nächste
Spalte zeigt die PE-Nummer.
Jedes iVLIW enthält
eine Reihe für
jedes PE und zeigt die Anweisungen, die in den VIM-Eintrag dieses
PE's geladen werden.
Die verbleibenden Spalten listen die Anweisung für jede der fünf Ausführungseinheiten
auf: Lade-Einheit (LU), Multiplizieren-Akkumulieren-Einheit (MAU),
Arithmetisch-Logische-Einheit
(ALU), Daten-Auswahl-Einheit (DSU) und Speicher-Einheit (SU).
-
Beispielsweise
wird die VIM-Eintragsnummer 29 im PE2 495 mit
den vier Anweisungen li.p.w R3, A1+, A7, fmpy.pm.1fw R5, R2, R31,
fadd.pa.1fw R9, R7, R5 und pexchg.pd.w R8, R0, 2 × 2 PE3
geladen. Diese Anweisungen sind diejenigen, welche in der nächsten bis
letzten Reihe von 4F gefunden werden.
Derselbe VIM-Eintrag (29) enthält verschiedene Anweisungen
in den PEs 0, 1 und 3, wie an den Reihen zu sehen ist, die diesen
PEs am VIM-Eintrag 29 für
PE0 491, PE2 493 und PE3 497 entsprechen.
-
Das
folgende Beispiel 1-1 zeigt die Abfolge von Anweisungen, die die
PE-VIM-Speicher laden, wie in 4F definiert.
Beachte, dass PE-Maskierung verwendet wird, um verschiedene Anweisungen
in verschiedene PE-VIMs an derselben Adresse zu laden.
-
Beispiel
1-1 Laden synchroner MIMD-iVLIWs in PE-VIMs
-
-
-
Das
folgende Beispiel 1-2 zeigt die Abfolge von Anweisungen, die die
PE-VIM-Einträge
ausführen,
die durch den Code vom Beispiel 1-1 in 4F geladen
sind. Es wird angemerkt, dass keine PE-Maskierung erforderlich ist.
Der spezifizierte VIM-Eintrag
wird in jedem der PEs, PE0, PE1, PE2 und PE3 ausgeführt.
-
Beispiel
1-2 Ausführen
synchroner MIMD-iVLIWs von PE-VIMs
-
-
Beschreibung des ausgeführten beispielhaften
Algorithmus'
-
Die
in 4F definierten iVLIWs werden verwendet,
um das Punktprodukt eines konstanten 3 × 1-Vektors mit einem Strom
von variablen 3 × 1-Vektoren,
die in lokalen PE-Datenspeichern gespeichert sind, zu berechnen.
Jedes PE speichert ein Element des Vektors. PE1 speichert die x-Komponente,
PE2 speichert die y-Komponente und PE3 speichert die z-Komponente.
PE0 speichert keine Komponente. Der konstante Vektor wird auf die
gleiche Weise in einem PE-Register gehalten, in diesem Falle im
Rechenregister R31.
-
Um
redundante Berechnungen oder leerlaufende PEs zu vermeiden, arbeiten
die iVLIWS an drei variablen Vektoren zu einer Zeit. Aufgrund der
Verteilung der Vektorkomponenten über die PEs ist es nicht durchführbar, PE0
zu verwenden, um ein 4tes Vektor-Punktprodukt zu berechnen. PE0
wird stattdessen vorteilhaft verwendet, um sich um das Einrichten
für eine
zukünftige
Algorithmenstufe zu kümmern.
Dies kann an den iVLIW-Ladeslots gesehen werden, wenn Vektor 1 im
iVLIW 27 (komponentenweise über
die PEs, wie oben beschrieben) geladen wurde, wird Vektor 2 im iVLIW
28 geladen und Vektor 3 im iVLIW 29 geladen (li.p.w R*, A1+, A7).
PE1 berechnet die x-Komponente des Punktprodukts für jeden
der drei Vektoren. PE2 berechnet die y-Komponente und PE3 berechnet die z-Komponente
(fmpy.pm.1fw R*, R*, R31). An diesem Punkt muss eine Kommunikation
zwischen den PEs eintreten, um die y- und z-Komponenten des Punktprodukts
vom Vektor 1 nach PE1 zu, die x- und z-Komponenten des Punktprodukts
vom Vektor 2 nach PE2 und die x- und y-Komponenten des Punktprodukts vom Vektor
3 nach PE3 bekommen. Diese Kommunikation tritt im DSU über die pexchg-Anweisung
auf. Auf diese Weise summiert jedes PE (fadd.pa.1fw R9, R7, R* und
fadd.pa.1fw R10, R9, R8) simultan die Komponenten eines einzelnen
Punktproduktergebnisses. Diese Ergebnisse werden dann in PE-Speichern
gespeichert (si.p.w R10, +A2, A6). Beachte, dass jedes PE jedes
dritte Ergebnis berechnen und speichern wird. Auf den letzten Satz
von Ergebnissen wird dann von den PEs 1, 2 und 3 gemäß einem Round-Robin-Verfahren
zugegriffen.
-
Zusätzlich führt jedes
PE einen Vergleich (fcmpLE.pa.1fw R10, R0) seines Punktproduktergebnisses mit
null (im PE-Register R0 vorgehalten) durch und speichert bedingt
eine null (t.sii.p.w R0, A2+, 0) anstelle des berechneten Punktprodukts,
wenn das Punktprodukt negativ war. Mit anderen Worten wird ermittelt,
ob der Vergleich ist R10 kleiner als R0? wahr ist. Diese Implementation
eines Punktprodukts unter Entfernung negativer Werte wird beispielsweise
bei Beleuchtungsberechnungen für
3D-Graphik-Anwendungen verwendet.
-
Während die
vorliegende Erfindung im Umfeld gegenwärtig bevorzugter Verfahren
und Geräte
zum Ausüben
der Erfindung offenbart wurde, werden dem Fachmann verschiedene
alternative Implementationen und Abwandlungen leicht offensichtlich
sein. Beispielsweise schließt
die vorliegende Erfindung nicht die Fähigkeit aus, eine Anweisung
in den VIM zu laden und die Anweisung auch auszuführen. Diese
Fähigkeit
wurde als unnötige
Komplikation für
das gegenwärtig
bevorzugte Programmiermodell angesehen, neben anderen Erwägungen wie
beispielsweise Anwei sungsformat und Hardwarekomplexität. Daher
wurde die Herangehensweise mit dem Laden-iVLIW-Trennsymbol gewählt.
