-
Die
Erfindung bezieht sich auf VLIW-Prozessoren (Very Large Instruction
Word) und insbesondere auf Befehlsformate für derartige Prozessoren sowie
ein Gerät
und Verfahren zur Verarbeitung derartiger Befehlsformate.
-
Die
Erfindung bezieht sich insbesondere auf einen VLIW-Prozessor gemäß dem Teil
des Anspruchs 1, der den Worten "dadurch
gekennzeichnet, dass" vorangestellt
ist.
-
Ein
Verfahren zum Komprimieren von VLIW-Befehlen wurde in den US-amerikanischen Patentschriften
5.179.680 und 5.057.837 vorgeschlagen. Dieses Kompressionsverfahren
sorgt für
ein Befehlswort, aus dem unbenutzte Operationen beseitigt wurden,
und ein Maskenwort, das angibt, welche Operationen beseitigt wurden.
-
VLIW-Prozessoren
haben Befehlswörter,
die eine Vielzahl so genannter "Issueslots"" ("Ausgabesschlitze") umfassen. Außerdem umfassen
die Prozessoren eine Vielzahl von Funktionseinheiten. Jede Funktionseinheit
dient zum Ausführen
einer Reihe von Operationen einer vorgegebenen Art. Jede Funktionseinheit gleicht
darin einer RISC-Architektur,
dass sie bei jedem Maschinenzyklus einen Befehl im Fließbandverfahren ("Pipelining") beginnen kann.
Jeder Issueslot dient zum Halten einer jeweiligen Operation. Alle
Operationen in demselben Befehlswort müssen an der Funktionseinheit
in einem einzigen Zyklus des Prozessors parallel begonnen werden.
Auf diese Weise realisiert der VLIW-Prozessor eine feingranulare
Parallelität.
-
So
beinhaltet ein Befehl auf einer VLIW-Maschine typischerweise eine
Vielzahl von Operationen. Bei herkömmlichen Maschinen kann auf
jede Operation als separater Befehl Bezug genommen werden. Bei der VLIW-Maschine
setzt sich jeder Befehl allerdings aus Operationen oder "No-Operations" ("NOPs", Dummy-Operationen)
zusammen.
-
Wie
herkömmliche
Prozessoren verwenden VLIW-Prozessoren eine Speichervorrichtung,
wie beispielsweise ein Festplattenlaufwerk, um mit dem Prozessor
auszuführende
Befehlsströme
zu speichern. Ein VLIW-Prozessor kann auch wie konventionelle Prozessoren
Cache-Speicher verwenden, um Teile von Befehlsströmen zu speichern,
die mit hoher Bandbreite für
den Prozessor zugänglich
sind.
-
Die
Befehle in der VLIW-Maschine werden durch einen Programmierer oder
Compiler aus diesen Operationen erstellt. Die Ablaufplanung im VLIW-Prozessor
ist daher softwaregesteuert.
-
Der
VLIW-Prozessor ist mit anderen Arten von parallelen Prozessoren
vergleichbar, beispielsweise mit Vektorprozessoren und Superskalar-Prozessoren,
wie nachfolgend erläutert.
Vektorprozessoren haben Einzeloperationen, die an zahlreichen Datenelementen
gleichzeitig ausgeführt
werden. Wie der VLIW-Prozessor realisieren Superskalar-Prozessoren
feingranulare Parallelität,
die Ablaufplanung ist im Gegensatz zum VLIW-Prozessor jedoch hardwaregesteuert.
-
Aufgrund
der langen Befehlswörter
hat der VLIW-Prozessor verstärkt
Probleme mit der Benutzung des Cache-Speichers. Durch die beträchtliche
Codegröße kommt
es insbesondere zu Cache-Fehltreffern, d. h. Situationen, in denen
benötigte
Befehle nicht im Cache-Speicher vorhanden sind.
-
Das
Problem der beträchtlichen
Codegröße kann
durch folgende Faktoren verstärkt
werden.
- – Zur
Feinabstimmung für
einen optimalen Programmbetrieb werden Verfahren wie Grafting, "Loop Unrolling" (Schleifen auf/entrollen)
und "Procedure Inlining" (Prozedurersetzung)
eingesetzt. Diese Verfahren erhöhen
die Codegröße.
- – Nicht
alle Issueslots werden in jedem Befehl benutzt. Ein guter Optimierungs-Compiler
kann die Anzahl der unbenutzten Issueslots reduzieren; eine bestimmte
Anzahl von NOPs (Dummy-Befehle) bleibt jedoch in den meisten Befehlsströmen weiterhin
vorhanden.
- – Um
die Nutzung der Funktionseinheiten zu optimieren, werden Operationen
an bedingten Programmverzweigungen üblicherweise vor Ablauf der
Verzweigungsverzögerung
("Branch Delay") begonnen, d. h.
bevor bekannt ist, welche Verzweigung genommen werden muss. Um herauszubekommen,
welche Ergebnisse tatsächlich
zu benutzen sind, enthalten die Befehle Schutzbits.
- – Größere Registerdateien,
die vorzugsweise in neueren Prozessortypen eingesetzt werden, erfordern
längere
Adressen, die in die Operationen aufgenommen werden müssen.
-
Ein
Verfahren zum Komprimieren von VLIW-Befehlen wurde in den US-amerikanischen Patentschriften
5.179.680 und 5.057.837 vorgeschlagen. Dieses Kompressionsverfahren
beseitigt unbenutzte Operationen in einem Befehlswort mit Hilfe
eines Maskenwortes, wobei jedoch mehr Platz vorhanden ist, um den
Befehl zu komprimieren.
-
Weitere
Informationen über
den technischen Hintergrund zu dieser Patentanmeldung sind in folgenden
früheren
Patentanmeldungen zu finden:
- – US-amerikanische
Patentanmeldung mit der Seriennummer 998.090, eingereicht am 29.
Dezember 1992 (PHA 21.777), die eine VLIW-Prozessorarchitektur zur Implementierung
feingranularer Parallelität
zeigt;
- – US-amerikanische
Patentanmeldung mit der Seriennummer 142.648, eingereicht am 25.
Oktober 1993 (PHA 1205), US-A-5.450.556, die die Benutzung von Schutzbits
zeigt; und
- – US-amerikanische
Patentanmeldung mit der Seriennummer 366.958, eingereicht am 30.
Dezember 1994 (PHA 21.932), EP-A-0748.477, die eine Registerdatei
für die
Benutzung mit einer VLIW-Architektur zeigt.
-
Bibliografie von Programmkompressionsverfahren
-
- – J.
Wang et al., "The
Feasibility of Using Compression to Increase Memory System Performance", Proc. 2nd Int.
Workshop on Modeling Analysis, and Simulation of Computer and Telecommunication
Systems, S. 107–113
(Durham, NC, ZSA 1994);
- – H.
Schröder
et al., "Program
compression on the instruction systolic array", Parallel Computing, Band 17, Nr. 2–3, Juni
1991, S. 207–219;
- – A.
Wolfe et al., "Executing
Compressed Programs on an Embedded RISC Architecture", J. Computer and Software
Engineering, Band 2, Nr. 3, S. 315–327, (1994);
- – M.
Kozuch et al., "Compression
of Embedded Systems Programs",
Proc. 1994 IEEE Int. Conf. on Computer Design: VLSI Computers and
Processors (Oct. 10–12,
1994, Cambridge MA, USA), S. 270–277.
-
Der
in diesen Dokumenten übernommene
Ansatz bestand typischerweise in dem Versuch, ein Programm als Ganzes
oder Blöcke
eines Programmcodes zu komprimieren. Darüber hinaus erfordern diese
Ansätze
typischerweise einige Tabellen mit Befehlsspeicherstellen oder Speicherstellen
von Befehlsblöcken.
-
Die
Erfindung hat zur Aufgabe, die Codegröße in einem VLIW-Prozessor
zu reduzieren.
-
Die
Erfindung hat weiterhin zur Aufgabe, einen VLIW-Prozessor zu schaffen,
der stärker
komprimierte Befehle verarbeitet.
-
Der
erfindungsgemäße Prozessor
ist dadurch gekennzeichnet, dass die Dekompressionseinheit dafür eingerichtet
ist, Operationen mit jeweils aus einer Vielzahl endlicher Längen gewählten komprimierten
Operationslängen
zu dekomprimieren, wobei die endlichen Längen mindestens zwei Längen enthalten,
die nicht Null sind. Der Satz verfügbarer Operationslängen besteht
beispielsweise aus 0, 26, 34 und 42 Bit langen komprimierten Operationen.
Welche Operationen auf eine bestimmte Länge komprimiert werden, hängt in erster
Linie von einer Untersuchung der Häufigkeit des Auftretens der
Operationen ab. Dies kann je nach Art der geschriebenen Software
variieren. Darüber
hinaus kann die Länge
davon abhängig
gemacht werden, ob die Operation geschützt oder ungeschützt ist,
ob sie ein Ergebnis hervorbringt, ob sie einen direkten Parameter
verwendet und wie viele Operanden sie verwendet.
-
Der
erfindungsgemäße Prozessor
hat eine Ausführungsform,
bei der die Dekompressionseinheit dafür eingerichtet ist, dem Speichermedium
für komprimierte
Befehle ein Formatfeld zu entnehmen, wobei das Formatfeld die jeweilige
komprimierte Operationslänge
für jede
Operation des komprimierten Befehls spezifiziert, und die Dekompressionseinheit
die Operationen des komprimierten Befehls gemäß dem Formatfeld dekomprimiert.
Vorzugsweise spezifiziert das Formatfeld auch, welche Issueslots
des Prozessors von dem Befehl zu verwenden sind.
-
In
einer weiteren Ausführungsform
des erfindungsgemäßen Prozessors
hat das Formatfeld N Teilfelder, wobei N die Anzahl der Issueslots
ist und jedes Teilfeld eine komprimierte Operationslänge für einen
jeweiligen Issueslot spezifiziert, dadurch gekennzeichnet, dass
die Teilfelder jeweils mindestens zwei Bits enthalten. Wenn vier
unterschiedliche Operationslängen
verwendet werden, kann das Teilfeld beispielsweise 2 Bits lang sein.
-
In
einer weiteren erfindungsgemäßen Ausführungsform
ist die Dekompressionseinheit dafür eingerichtet,
- – dem
Speichermedium für
komprimierte Befehle zusammen mit dem Formatfeld einen vorhergehenden komprimierten
Befehl zu entnehmen,
- – mit
dem Dekomprimieren des vorhergehenden komprimierten Befehls zu beginnen
und anschließend
- – dem
Speicher für
komprimierte Befehle den komprimierten Befehl zu entnehmen und mit
dem Dekomprimieren des komprimierten Befehls gemäß dem Formatfeld zu beginnen,
das dem Speichermedium für
komprimierte Befehle zusammen mit dem vorhergehenden komprimierten
Befehl entnommen wurde. Dadurch ist das Formatfeld vor dem Laden
des komprimierten Befehls verfügbar,
und es kann vor dem Laden des komprimierten Befehls mit Vorbereitungen
zum Dekomprimieren gemäß dem Formatfeld
begonnen werden.
-
In
einer erfindungsgemäßen Ausführungsform
entnimmt die Dekompressionseinheit das Formatfeld dem Speichermedium
für komprimierte
Befehle in einer Speicherzugriffseinheit, wobei die Speicherzugriffseinheit
weiterhin mindestens ein Operationsteilfeld umfasst und die Dekompressionseinheit
das Operationsteilfeld in mindestens eine der Operationen des dekomprimierten
Befehls einbezieht. Dies erhöht
die Abrufeffizienz und ermöglicht
eine Fließbandverarbeitung
von Befehlsabrufen. Dies kann in einem Prozessor verwendet werden,
der jede Anzahl verfügbarer
Operationslängen
dekomprimieren kann, auch zwei Längen
(z. B. 0 und 32). Dadurch wird die Dekompressionseinheit darauf
aufmerksam gemacht, wie viele Issueslots in dem nachfolgenden Befehl
zu erwarten sind, bevor der betreffende Befehl abgerufen wird. Für jeden
Befehl, bei dem es sich nicht um Sprungziele handelt, kann zusammen
mit einem vorhergehenden Befehl ein Feld gespeichert werden, mit
dem das Format spezifiziert wird.
-
Die
Erfindung bezieht sich weiterhin auf ein Verfahren zur Erzeugung
eines komprimierten Codes, der auf einem VLIW-Prozessor nach Anspruch
7 abläuft.
Dieses Verfahren erzeugt Befehle, die für den Prozessor nützlich sind.
-
Das
erfindungsgemäße Verfahren
hat eine Ausführungsform,
bei der das Verfahren auf einen Befehlsstrom angewendet wird, der
den genannten Befehl enthält,
wobei das Verfahren den Schritt umfasst, für jeden Befehl zu bestimmen,
ob dieser Befehl das Sprungziel einer Verzweigung von einem anderen
Befehl des Befehlsstroms ist, und nur solche Befehle zu komprimieren,
die keine Sprungziele sind. Dadurch braucht ein Sprung ziel nicht
während
der Ausführung
eines Programms durch den Prozessor dekomprimiert zu werden, und
nach Ausführung
eines Befehls ist keine Dekompressionsverzögerung erforderlich.
-
KURZE BESCHREIBUNG DER
ZEICHNUNG
-
Die
Erfindung wird im Folgenden anhand von nicht einschränkenden
Beispielen sowie unter Bezugnahme auf die folgenden Figuren beschrieben.
Es zeigen:
-
1a einen Prozessor für die Benutzung
des komprimierten Befehlsformats der Erfindung;
-
1b die CPU des Prozessors
aus 1a detaillierter;
-
die 2a–2e zeigen
mögliche
Positionen von Befehlen im Cache-Speicher;
-
3 einen Teil des erfindungsgemäßen Kompressionsverfahrens;
-
die 4a–4f Beispiele
komprimierter Befehle gemäß der Erfindung;
-
die 5a–5b eine
Tabelle mit komprimierten Befehlsformaten gemäß der Erfindung;
-
6a schematisch die Funktionsweise
des Befehls-Cache-Speichers 103 bei der Eingabe;
-
6b schematisch die Funktionsweise
eines Teils des Befehls-Cache-Speichers 103 bei
der Ausgabe;
-
7 schematisch die Funktionsweise
des Befehls-Cache-Speichers 103 bei der Ausgabe;
-
8 das Kompilieren und Verknüpfen von
Codes gemäß der Erfindung;
-
9 ein Ablaufdiagramm von
Kompressions- und Umordnungsmodulen (engl. „shuffling modules");
-
10 eine Vergrößerung des
Kastens 902 aus 9;
-
11 eine Vergrößerung des
Kastens 1005 aus 10;
und
-
12 den Dekomprimierungsvorgang.
-
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN
AUSFÜHRUNGSFORM
-
1a zeigt die allgemeine
Struktur eines erfindungsgemäßen Prozessors.
Ein erfindungsgemäßer Mikroprozessor
enthält
eine CPU 102, einen Befehls-Cache-Speicher 103 und einen Daten-Cache-Speicher 105.
Die CPU ist über
breitbandige Busse mit den Cache-Speichern verbunden. Der Mikroprozessor
enthält weiterhin
einen Speicher 104, in dem ein Befehlsstrom gespeichert
wird.
-
Der
Cache-Speicher 103 ist für 512-Bit-Doppelwörter strukturiert.
Die einzelnen Bytes in den Wörtern sind
adressierbar, die Bits jedoch nicht. Die Bytes sind 8 Bits lang.
Vorzugsweise kann auf die Doppelwörter als ein einzelnes Wort
in einem einzelnen Taktzyklus zugegriffen werden.
-
Der
Befehlsstrom wird in Form von Befehlen in einem komprimierten Format
gemäß der Erfindung
gespeichert. Das komprimierte Format wird sowohl im Speicher 104 als
auch im Cache-Speicher 103 gespeichert.
-
1b zeigt den erfindungsgemäßen VLIW-Prozessor
detaillierter. Der Prozessor enthält eine Multiport-Registerdatei 150,
eine Anzahl von Funktionseinheiten 151, 152, 153 ...
sowie ein Befehlsausgaberegister 154. Die Multiport-Registerdatei
speichert Ergebnisse von den Funktionseinheiten und Operanden für die Funktionseinheiten.
Das Befehlsausgaberegister enthält
eine Vielzahl von Issueslots zur Aufnahme von Operationen, mit denen
in einem einzelnen Taktzyklus parallel an den Funktionseinheiten 151, 152, 153 ...
begonnen werden soll. Eine Dekompressionseinheit 155, die
nachfolgend ausführlicher
beschrieben wird, wandelt die komprimierten Befehle aus dem Befehls-Cache-Speicher 103 in
eine für
den IIR-Filter 154 verwendbare Form um.
-
KOMPRIMIERTES BEFEHLSFORMAT
-
1. Allgemeine Merkmale
-
Die
bevorzugte Ausführungsform
des anspruchsgemäßen Befehlsformats
wird für
die Verwendung in einer VLIW-Maschine mit einem Befehlswort optimiert,
das 5 Issueslots enthält.
Das Format hat folgende Eigenschaften:
- – nicht
ausgerichtete Befehle variabler Länge;
- – einer
variable Anzahl von Operationen pro Befehl;
- – drei
mögliche
Operationsgrößen: 26,
34 oder 42 Bits (auch 26/34/42-Format genannt);
- – die
32 am häufigsten
verwendeten Operationen werden kompakter als andere Operationen
codiert;
- – Operationen
können
geschützt
oder ungeschützt
sein;
- – Operationen
können
entweder nullwertig, unär
oder binär
sein, d. h. sie haben 0, 1 oder 2 Operanden;
- – Operationen
können
ergebnislos sein;
- – Operationen
können
direkte Parameter mit 7 oder 32 Bits enthalten;
- – Sprungziele
werden nicht komprimiert; und
- – Formatbits
für einen
Befehl befinden sich in dem vorhergehenden Befehl.
-
2. Befehlsausrichtung
-
Mit
Ausnahme von Sprungzielen werden Befehle im Cache-Speicher und im
Hauptspeicher an Bytegrenzen ausgerichtet gespeichert. Befehle sind
weder im Cache-Speicher
noch im Hauptspeicher hinsichtlich Wort- oder Blockgrenzen ausgerichtet.
Es muss daher auf den Cache-Speicher mit nicht ausgerichteten Befehlen
zugegriffen werden.
-
Um
nicht ausgerichtete Befehle abzurufen, ruft der Prozessor ein Wort
pro Taktzyklus aus dem Cache-Speicher ab.
-
Wie
aus dem nachstehend beschriebenen Kompressionsformat hervorgeht,
müssen
die Sprungziele unkomprimiert sein und in ein einzelnes Wort im
Cache-Speicher fallen, so dass sie in einem einzelnen Taktzyklus
abgerufen werden können.
Sprungziele werden vom Compiler oder Programmierer gemäß der folgenden
Regel ausgerichtet:
wenn eine Wortgrenze in das Sprungziel
oder genau an das Ende des Sprungziels fällt, wird durch zusätzliches Auffüllen ("Padding") dafür gesorgt,
dass das Sprungziel an der nächsten
Wortgrenze beginnt.
-
Da
der bevorzugte Cache-Speicher Doppelwörter in einem einzelnen Taktzyklus
abruft, lässt
sich die oben genannte Regel dahingehend modifizieren, dass Doppelwortgrenzen
durch Wortgrenzen ersetzt werden.
-
Die
normalen, nicht ausgerichteten Befehle werden so abgerufen, dass
nachfolgende Befehle aus dem Endteil des aktuellen Worts und einem
Anfangsteil des nachfolgenden Worts zusammengesetzt werden. Auf ähnliche
Weise können
alle späteren
Befehlen aus zwei Cache-Wörtern
zusammengesetzt werden, wobei in jedem Taktzyklus ein zusätzliches
Wort abgerufen wird.
-
Das
bedeutet, dass wann immer Codesegmente (zum Beispiel im Programmbinder
oder Programmlader) neu zugeordnet werden, die Ausrichtung aufrechterhalten
bleiben muss. Dies erreicht man durch Verschiebung der Codesegment-Basisadressen
zu Vielfachen der Cache-Blockgröße.
-
Die 2a–e zeigen
eine nicht ausgerichtete Befehlsspeicherung im Cache gemäß der Erfindung.
-
2a zeigt zwei Cache-Wörter mit
drei Befehlen il, i2 und i3 gemäß der Erfindung.
Die Befehle sind in Bezug auf die Wortgrenzen nicht ausgerichtet.
Die Befehle il und i2 können
Sprungziele sein, weil sie vollständig in ein Cache-Wort fallen.
Der Befehl i3 überschreitet
eine Wortgrenze und darf daher kein Sprungziel sein. Anlässlich dieser
Beispiele wird jedoch angenommen, dass einzig und allein il ein
Sprungziel ist.
-
2b zeigt eine unzulässige Situation.
Das Sprungziel il überschreitet
eine Wortgrenze. Dementsprechend muss der Compiler oder Programmierer
den Befehl i1 an eine Wortgrenze verschieben und den offenen Bereich
wie in 2c gezeigt mit
Füllbytes
auffüllen.
-
2d zeigt eine weitere unzulässige Situation.
Der Sprungzielbefehl i1 endet exakt an der Wortgrenze. In dieser
Situation muss il erneut über
eine Wortgrenze verschoben und der offene Bereich wie in 2e gezeigt mit Füllbytes
aufgefüllt
werden.
-
Sprungziele
müssen
Befehle sein und nicht Operationen innerhalb von Befehlen. Durch
die nachfolgend beschriebenen Befehlskompressionsverfahren werden
NOPs (Dummy-Befehle) im Allgemeinen eliminiert. Da die Sprungzielbefehle
jedoch nicht komprimiert sind, müssen
sie NOPs enthalten, um die Issueslots aufzufüllen, die nicht vom Prozessor
benutzt werden.
-
3. Anordnung der Bits
und Bytes
-
In
dieser gesamten Patentanmeldung haben die Bits und Bytes eine Little-Endian-Anordnung.
Die Bits und Bytes werden jeweils mit den geringstwertigen Bits
zuerst aufgelistet, wie nachstehend gezeigt:
-
-
4. Befehlsformat
-
Der
komprimierte Befehl kann bis zu sieben Arten von Feldern haben.
Diese sind nachstehend aufgeführt.
Die Formatbits sind die einzigen obligatorischen Felder.
-
Die
Befehle sind aus nach Bytes ausgerichteten Abschnitten zusammengesetzt.
Die ersten beiden Bytes enthalten die Formatbits sowie die erste
Gruppe von 2-Bit-Operationsteilen.
Alle anderen Felder sind ganzzahlige Vielfache eines Bytes, ausgenommen
die zweiten 2-Bit-Operationsteile, die die Füllbits enthalten.
-
Die
Operationen können
wie oben erläutert
26, 34 oder 42 Bits haben. 26-Bit-Operationen
werden in einen 2-Bit-Teil, der zusammen mit den Formatbits gespeichert
wird, und einen 24-Bit-Teil aufgeteilt. 34-Bit-Operationen werden
in einen 2-Bit-Teil, einen 24-Bit-Teil und eine 1-Byte-Erweiterung
aufgeteilt. 42-Bit-Operationen werden in einen 2-Bit-Teil, einen
24-Bit-Teil und eine 2-Byte-Erweiterung aufgeteilt.
-
A Formatbits
-
Diese
werden nachstehend in Abschnitt 5 beschrieben. Bei einer Maschine
mit fünf
Issueslots sind zehn Formatbits erforderlich. Somit werden ein Byte
plus zwei Bits benutzt.
-
B. 2-Bit-Operationsteile,
erste Gruppe
-
Da
der überwiegende
Teil jeder Operation wie unten erläutert im 24-Bit-Teil gespeichert
wird, d. h. drei Bytes, waren bei dem bevorzugten Befehlsatz 24
Bits nicht angemessen. Die kürzesten
Operationen erforderten 26 Bits. Entsprechend stellte sich heraus,
dass die restlichen sechs Bits in den Bytes für das Formatbitfeld vorteilhaft
genutzt werden könnten,
um zusätzliche
Bits von Operationen, zwei Bits für jede der drei Operationen,
zu speichern. Falls die für
die 2-Bit-Teile vorgesehenen sechs Bits nicht benötigt werden,
können
sie mit Füllbits
aufgefüllt
werden.
-
C. 24-Bit-Operationsteile,
erste Gruppe
-
Die
Anzahl der 24-Bit-Operationsteile entspricht der Anzahl von 2-Bit-Operationsteilen
in den 2-Bit-Operationsteilen der ersten Gruppe. Anders ausgedrückt können hier
bis zu drei 3-Byte-Operationen gespeichert werden.
-
D. 2-Bit-Operationsteile,
zweite Gruppe
-
Bei
Maschinen mit mehr als drei Issueslots ist eine zweite Gruppe von
2-Bit- und 24-Bit-Operationsteilen
erforderlich. Die zweite Gruppe von 2-Bit-Teilen besteht aus einem
Byte mit vier Sätzen
von 2-Bit-Teilen. Falls ein Issueslot nicht benutzt wird, werden
seine Bit-Positionen mit Füllbits
aufgefüllt.
Die Füllbits
befinden sich auf der linken Seite des Bytes. Bei einer Maschine
mit fünf
Issueslots, bei der alle Slots benutzt werden, würde dieser Abschnitt vier Füllbits gefolgt
von zwei Gruppen mit 2-Bit-Teilen enthalten. Die fünf Issueslots
sind über
die beiden Gruppen verstreut: drei Issueslots in der ersten Gruppe
und zwei Issueslots in der zweiten Gruppe.
-
E. 24-Bit-Operationsteile,
zweite Gruppe
-
Auf
die Gruppe der 2-Bit-Teile folgt eine entsprechende Gruppe mit 24-Bit-Operationsteilen.
Bei einer Maschine mit fünf
Issueslots, bei der alle Slots benutzt werden, würden sich in dieser Gruppe
zwei 24-Bit-Teile befinden.
-
F. Weitere Gruppen von
2-Bit- und 24-Bit-Teilen
-
In
einer sehr breiten Maschine, d. h. mit mehr als sechs Issueslots,
sind weitere Gruppen mit 2-Bit- und 24-Bit-Operationsteilen erforderlich.
-
G. Operationserweiterung
-
Am
Ende jedes Befehls befindet sich eine nach Bytes ausgerichtete Gruppe
von optional 8- oder 16-Bit-Operationserweiterungen, die jeweils
nach Bytes ausgerichtet sind. Die Erweiterungen werden benutzt, um
die Größe der Operationen
von den grundlegenden 24 Bits je nach Bedarf auf 34 oder 42 Bits
zu erweitern.
-
Die
formale Spezifikation für
das Befehlsformat lautet:
<Befehl> :: =
<Befehlsanfang>
<Befehlsmitte>
<Befehlsende>
<Befehlserweiterung>
<Befehlsanfang> :: =
<Format:2*N> {<Auffüllen:1>}V2{<2-Bit-Operationsteil:2>}V1{<24-Bit-Operationstei1:24>}V1
<Befehlsmitte> :: = {{<2-Bit-Operationsteil:2>}4{<24-Bit-Operationsteil:24>}4}V3
<Befehlsende> :: = {<Auffüllen:1>}V5{<2-Bit-Operationsteil:2>}V4{<24-Bit-Operationstei1:24>}V4
<Befehlserweiterung> :: = {<Operationserweiterung:0/8/16>}S<Auffüllen> :: = "0"
wobei die oben
benutzten Variablen wie folgt definiert sind:
N = die Anzahl
der Issueslots der Maschine, N > 1
S
= die Anzahl der in diesem Befehl benutzten Issueslots (0 ≤ S ≤ N)
C1
= 4 – (N
mod 4)
Wenn (S ≤ C1)
dann V1 = S und V2 = 2*(C1 – V1)
Wenn
(S > C1) dann V1 =
C1 und V2 = 0
V3 = (S – V1)
div 4
V4 = (S – V1)
mod 4
Wenn (V4 > 0)
dann V5 = 2*(4 – V4)
andernfalls V5 = 0
-
Erläuterung
der Schreibweise
-
Beispiele
komprimierter Befehle sind in den 4a–f dargestellt.
-
4a zeigt einen Befehl ohne
Operationen. Die Befehl enthält
zwei Bytes, einschließlich
zehn Bits für
das Formatfeld und sechs Bits, die nur zum Auffüllen dienen. Erstere sind in
allen Befehlen vorhanden. Letztere entsprechen normalerweise den
2-Bit-Operationsteilen. Die Xe oben im Bitfeld deuten an, dass die Felder
Füllbits
ent halten. In den nachfolgenden Figuren wird durch ein 0 angedeutet,
dass die Felder benutzt werden.
-
In 4b ist ein Befehl mit einer
26-Bit-Operation dargestellt. Die Operation enthält einen 24-Bit-Teil an den
Bytes 3–5
und einen 2-Bit-Teil im Byte 2. Die jeweils benutzten beiden Bits
sind oben mit einem O gekennzeichnet.
-
In 4c ist ein Befehl mit zwei
26-Bit-Operationen dargestellt. Bei der ersten 26-Bit-Operation
befinden sich der 24-Bit-Teil in den Bytes 3–5 und die beiden zusätzlichen
Bits im letzten der 2-Bit-Teil-Felder. Bei der zweiten 26-Bit-Operation
befinden sich der 24-Bit-Teil in den Bytes 6–8 und die beiden zusätzlichen
Bits im vorletzten der 2-Bit-Teil-Felder.
-
In 4d ist ein Befehl mit drei
26-Bit-Operationen dargestellt. Die 24-Bit-Teile befinden sich in den Bytes
3–11 und
die 2-Bit-Teile in umgekehrter Reihenfolge zu den 24-Bit-Teilen
in Byte 2.
-
In 4e ist ein Befehl mit vier
Operationen dargestellt. Die zweite Operation hat eine 2-Byte-Erweiterung.
Die vierte Operation hat eine 1-Byte-Erweiterung. Die 24-Bit-Teile
der Operationen sind in den Bytes 3–11 und 13–15 untergebracht. Die 2-Bit-Teile der ersten
drei Operationen befinden sich in Byte 2. Der 2-Bit-Teil der vierten
Operation befindet sich in Byte 12. Eine Erweiterung für Operation
2 befindet sich in den Bytes 16–17.
Eine Erweiterung für
Operation 4 befindet sich in Byte 18.
-
4f zeigt einen Befehl mit
fünf Operationen,
von denen jede eine 1-Byte-Erweiterung
hat. Die Erweiterungen erscheinen alle am Ende der Befehl.
-
Obwohl
im Beispiel Erweiterungen nur nach der zweiten Gruppe von 2-Bit-Teilen erscheinen,
könnten sie
genauso gut am Ende eines Befehls mit drei oder weniger Operationen
erscheinen. In einem solchen Fall würde die zweite Gruppe von 2-Bit-Teilen
nicht benötigt.
-
Es
besteht keine feste Beziehung zwischen der Position von Operationen
in dem Befehl und dem Issueslot, in den sie ausgegeben werden. Dies
ermöglicht
es, einen Befehl zu kürzen,
wenn nicht alle Issueslots benutzt werden. Die Operationspositionen
werden von links nach rechts aufgefüllt. Der Formatabschnitt des Befehls
gibt an, zu welchem Issueslot eine bestimmte Operation gehört. Wenn
ein Befehl zum Beispiel nur eine Operation enthält, dann befindet sie sich
an der ersten Operationsposition und kann an einen beliebigen Issueslot
ausgegeben werden, nicht nur an Slot 1. Die Dekompressions-Hardware sorgt dafür, dass
die Operation an die richtigen Issueslots geleitet wird.
-
Zwischen
Befehlen, die einen sequentiellen Codeblock bilden, sind keine Füllblocks
erlaubt. Füllblocks sind
nur zwischen unterschiedlichen Codeblocks zulässig.
-
5. Formatbits
-
Das
erfindungsgemäße Befehlskompressionsverfahren
ist dadurch gekennzeichnet, dass ein Formatfeld verwendet wird,
mit dem spezifiziert wird, welche Issueslots von dem komprimierten
Befehl zu benutzen sind. Für
eine optimale Abrufeffizienz werden die Formatbits in dem Befehl
vor demjenigen Befehl gespeichert, auf den sich die Formatbits beziehen.
Dies ermöglicht
einen Befehlsabruf im Fließbandverfahren.
Der Dekompressionseinheit wird vor dem Abrufen dieses Befehls mitgeteilt,
wie viele Issueslots in dem nachfolgenden Befehl zu erwarten sind.
Die Speicherung von Formatbits, die den ihnen zugehörigen Operationen
jeweils vorangehen, ist in 3 dargestellt.
Befehl 1, bei dem es sich um ein nicht komprimiertes Sprungziel
handelt, enthält ein
Formatfeld, das angibt, welche Issueslots von den in Befehl 2 spezifizierten
Operationen benutzt werden. Die Befehle 2 bis 4 sind komprimiert.
Jeder enthält
ein Formatfeld, das angibt, welche Issueslots von den Operationen
des nachfolgenden Befehls zu benutzten sind.
-
Die
Formatbits sind wie folgt codiert. Es gibt 2*N Formatbits für eine Maschine
mit N Issueslots. Im Fall der bevorzugten Ausführungsform gibt es fünf Issueslots.
Demzufolge gibt es zehn Formatbits. Auf die Formatbits wird hierbei
Bezug genommen in einer Matrixschreibweise als Format[j], wobei
j die Bitzahl ist. Die Formatbits sind in N Gruppen zu 2 Bits organisiert.
Die Bits Format[2i] und Format[2i + 1] geben Formatangaben zu dem
Issueslot i an, wobei 0 ≤ i ≤ N. Die Bedeutung
der Formatbits wird in der folgenden Tabelle erläutert:
-
-
-
Operationen
entsprechen den Issueslots von links nach rechts. Werden beispielsweise
zwei Issueslots benutzt und das Format = {1, 0, 1, 1, 1, 1, 1, 0,
1, 1}, dann enthält
der Befehl zwei 34-Bit-Operationen. Die äußerst linke wird an Issueslot
0 geleitet und die äußerst rechte
an Issueslot 3. Ist das Format = {1, 1, 1, 1, 1, 0, 1, 0, 1, 0},
dann enthält
der Befehl drei 34-Bit-Operationen, wobei die äußerst linke an Issueslot 2
geleitet wird, die zweite Operation für den Issueslot 3 vorgesehen
ist, und die äußerst rechte
zu Issueslot 4 gehört.
-
Das
zum Dekomprimieren von Sprungzielbefehlen verwendete Format ist
eine Konstante. Konstante Format = {0, 1, 0, 1, 0 1, 0, 1, 0, 1}
für die
bevorzugte Maschine mit fünf
Issueslots.
-
6. Operationsformate
-
Das
Format einer Operation hängt
von den folgenden Eigenschaften ab:
- – nullwertig,
unär oder
binär;
- – parametrisch
oder nicht parametrisch. Parametrische Befehle enthalten einen direkten
Operanden im Code. Die Parameter können unterschiedliche Größen haben.
Hier gibt es param7, d. h. 7-Bit-Parameter, und param32, d. h. 32-Bit-Parameter.
- – ergebnisbehaftet
oder ergebnislos;
- – langer
oder kurzer Opcode. Die kurzen Opcodes sind die 32 häufigsten
Opcodes und fünf
Bits lang. Die langen Opcodes sind acht Bits lang und enthalten
alle Op codes, einschließlich
derjenigen, die sich in einem kurzen Format ausdrücken lassen.
Die Opcodes 0 bis 31 sind für
die 32 kurzen Opcodes reserviert.
- – geschützt oder
ungeschützt.
Ein ungeschützter
Befehl hat einen konstanten Schutzwert WAHR.
- – Latenz.
Ein Formatbit gibt an, ob die Latenz von Operationen gleich oder
größer 1 ist.
- – vorzeichenbehaftet/vorzeichenlos.
Ein Formatbit gibt für
parametrische Operationen an, ob der Parameter ein Vorzeichen oder
kein Vorzeichen hat.
-
Die
geschützte
oder ungeschützte
Eigenschaft wird im nicht komprimierten Befehlsformat mit Hilfe
der speziellen Registerdateiadresse der Konstanten 1 festgelegt.
Wenn ein Schutzadressfeld die Adresse der Konstanten 1 enthält, dann
ist die Operation ungeschützt,
andernfalls ist sie geschützt.
Die meisten Operationen können
sowohl in geschützten
als auch in ungeschützten
Formaten auftreten. Eine direkte Operation, d. h. eine Operation,
die eine Konstante an ein Register überträgt, hat kein Schutzfeld und
ist immer ungeschützt.
-
Welche
Opcodes in der Liste der 32 kurzen Opcodes enthalten sind, hängt von
einer Untersuchung der Auftrittshäufigkeit ab, die je nach Art
der geschriebenen Software variieren kann.
-
In
der Tabelle II unten sind von der Erfindung verwendete Operationsformate
aufgeführt.
Sofern nichts anderes angegeben ist, sind alle Formate: nicht parametrisch,
ergebnisbehaftet, geschützt,
und ein langer Opcode. Um die Tabellen und Zeichnungen möglichst
einfach zu halten, sind in der folgenden Tabelle keine spezielle
Form für
Latenz und keine Eigenschaften bezüglich eines vorgesehenen oder
nicht vorgesehenen Vorzeichens aufgeführt. Diese sind in den Formatbeschreibungen
mit L und S angedeutet. Für
nicht-parametrische Nullwert-Operationen wird das unäre Format
verwendet. In diesem Fall ist das Feld für das Argument undefiniert.
-
-
-
Für alle Operationen
ist ein 42-Bit-Format für
die Benutzung in Sprungzielen verfügbar. Für ergebnislose unäre und binäre Operationen
kann das Format <binär> verwendet werden.
In diesem Fall haben die unbenutzten Felder im binären Format
undefinierte Werte. Kurze 5-Bit-Opcodes werden in lange 8-Bit-Opcodes umgewandelt,
indem die höchstwertigen
Bits mit Nullen aufgefüllt
werden. Ungeschützte
Operationen erhalten die Registerdateiadresse der Konstanten WAHR
als Schutzadresswert. Für
Speicheroperationen wird an Stelle des regulären 34-Bit-Formats <binär-param7-ergebnislos-kurz> das 42-Bit-Format <binär-param7-ergebnislos> verwendet (davon ausgehend,
dass Speicheroperationen zur Gruppe der kurzen Operationen gehören).
-
Operationstypen,
die in Tabelle II nicht erscheinen, werden gemäß der nachstehenden Alias-Tabelle auf
die in der Tabelle II erscheinenden abgebildet:
-
-
-
Das
Folgende ist eine Tabelle der Felder, die in Operationen erscheinen:
-
-
5 enthält eine vollständige Spezifikation
der Codierung von Operationen.
-
7. Erweiterungen des Befehlsformats
-
Innerhalb
des Befehlsformats besteht eine gewisse Flexibilität, um neue
Operationen und Operationsformen hinzuzufügen, solange eine Codierung
bis zu einer maximalen Größe von 42
Bits möglich
ist.
-
Das
Format basiert auf einer 7-Bit-Registerdateiadresse. Bei Registerdateiadressen
unterschiedlicher Größen müssen das
Format und die Dekompressions-Hardware umgestaltet werden.
-
Das
Format kann bei Maschinen mit einer veränderlichen Anzahl von Issueslots
verwendet werden. Die maximale Größe des Befehls wird jedoch
durch die Wortgröße im Befehls-Cache-Speicher
beschränkt.
Bei einer Maschine mit vier Issueslots beträgt die maximale Befehlsgröße 22 Bytes
(176 Bits), wobei vier 42-Bit-Operationen plus acht Formatbits verwendet
werden. Bei einer Maschine mit fünf
Issueslots beträgt
die maximale Befehlsgröße 28 Bytes
(224 Bits), wobei fünf
42-Bit-Operationen plus zehn Formatbits verwendet werden.
-
Bei
einer Maschine mit sechs Issueslots würde die maximale Befehlsgröße 264 Bits
betragen, wobei sechs 42-Bit-Operationen plus zwölf Formatbits verwendet werden.
Wäre die
Wortlänge
auf 256 Bits begrenzt und würden
sechs Issueslots gewünscht,
kann die Ablaufsteuerung gezwungen werden, höchstens fünf Operationen im 42-Bit-Format in einem Befehl
zu verwenden. Das feste Format für
Sprungziele müsste
fünf Issueslots
von 42 Bits und einen Issueslot von 34 Bits verwenden.
-
KOMPRIMIEREN DER BEFEHLE
-
8 zeigt in einem Diagramm,
wie der Quellcode zu einem ladbaren, komprimierten Objektmodul wird.
Zunächst
muss der Quellcode 801 durch einen Compiler 802 kompiliert
werden, um einen ersten Satz von Objektmodulen 803 zu erzeugen.
Diese Module werden durch einen Progammbinder 804 verknüpft, um einen
zweiten Typ von Objektmodulen 805 zu erzeugen. Dieses Modul
wird dann komprimiert und an 806 geschoben, um ein ladbares
Modul 807 zu erhalten.
-
Es
kann jeder standardmäßige Compiler
oder Progammbinder verwendet werden. Objektmodule II enthalten eine
Anzahl standardmäßiger Datenstrukturen.
Dazu gehören:
ein Anfangsblock, globale und lokale Symboltabellen, eine Referenztabelle
für Verschiebungsinformationen,
eine Abschnittstabelle und Fehlersuchinformationen, von denen einige
vom Kompressions- und Umordnungsmodul 807 verwendet werden.
Ferner hat das Objektmodul II Partitionen, einschließlich einer
Textpartition, in der sich die zu verarbeitenden Befehle befinden,
und eine Quellpartition, die verfolgt, aus welchen Quelldateien
der Text stammt.
-
In 9 ist ein Ablaufdiagramm
des Kompressions- und Umordnungsmoduls auf hoher Ebene dargestellt.
Bei 901 wird das Objektmodul II eingelesen. Bei 902 wird
die Textpartition verarbeitet. Bei 903 werden die anderen
Abschnitte verarbeitet. Bei 904 wird der Anfangsblock aktualisiert.
Bei 905 wird das Objektmodul ausgegeben.
-
10 zeigt eine Erweiterung
des Kastens 902. Bei 1001 wird die Referenztabelle,
d. h. die Verschiebungsinformation, zusammengefasst. Bei 1002 werden
die Sprungziele gesammelt, weil diese nicht komprimiert werden sollen.
Bei 1003 prüft
die Software, ob sich noch mehr Dateien in der Quellpartition befinden.
Ist dies der Fall, wird bei 1004 der zur nächsten Datei
gehörende
Teil abgerufen. Anschließend
wird dieser Teil bei 1005 komprimiert. Bei 1006 werden
die Dateiinformationen in der Quellpartition aktualisiert. Bei 1007 wird
die lokale Symboltabelle aktualisiert.
-
Wenn
sich keine Dateien mehr in der Quellpartition befinden, wird die
globale Symboltabelle bei 1008 aktualisiert. Danach werden
bei 1009 die Adressreferenzen im Textabschnitt aktualisiert.
Anschließend
wird bei 1010 eine 256-Bit-Umordnung durchgeführt. Der
Grund für
eine derartige Umordnung wird im Folgenden erläutert.
-
11 zeigt eine Erweiterung
des Kastens 1005. Zunächst
wird bei 1101 bestimmt, ob noch weitere Befehle komprimiert
werden müssen.
Ist dies der Fall, wird bei 1102 ein weiterer Befehl abgerufen.
Anschließend
wird bei 1103 jede Operation in dem Befehl entsprechend
den Tabellen in den 5a und 5b komprimiert und bei 1108 eine
Streutabelle aktualisiert. Die Streutabelle ist eine neue Datenstruktur,
die als Folge der Kompression und Umordnung erforderlich ist, wie
weiter unten erläutert
wird. Dann werden bei 1104 alle Operationen in einem Befehl
sowie die Formatbits eines nachfolgenden Befehls gemäß den 4a–4e miteinander kombiniert.
Anschließend
müssen
bei 1105 die Verschiebungsinformationen in der Referenztabelle
aktualisiert werden, wenn der aktuelle Befehl eine Adresse enthält. Bei 1106 werden
die zum Aktualisieren der Adressreferenzen im Textabschnitt erforderlichen
Informationen gesammelt. Bei 1107 wird der komprimierte
Befehl an das Ende des Ausgabe-Bit-Strings angehängt, und die Steuerung kehrt
zum Kasten 1101 zurück.
Wenn keine Befehle mehr vorhanden sind, kehrt die Steuerung zum
Kasten 1006 zurück.
-
Funktionen
für die
Kompressionsabwicklung werden in den verschiedenen Modulen realisiert,
wie nachstehend aufgeführt:
-
-
Die
Streutabelle, die als Folge der erfindungsgemäßen Kompression und Umordnung
erforderlich ist, lässt
sich wie folgt erläutern.
-
Die
Referenztabelle enthält
eine Liste von Speicherstellen der vom Befehlsstrom verwendeten
Adressen und eine entsprechende Liste der tatsächlichen Adressen, die an diesen
Stellen aufgeführt
sind. Wenn der Code komprimiert wird, und wenn er geladen wird,
müssen
diese Adressen aktualisiert werden. Entsprechend wird die Referenztabelle
zu diesen Zeitpunkten benutzt, um eine Aktualisierung zu ermöglichen.
-
Wenn
der Code jedoch komprimiert und umgeordnet wird, werden die aktuellen
Bits der Adressen voneinander getrennt und neu angeordnet. Daher
ist in der Streutabelle für
jede Adresse in der Referenztabelle aufgelistet, wo sich JEDES BIT
befindet. In der bevorzugten Ausführungsform ist in der Tabelle
die Breite eines Bitfeldes aufgeführt, ein Versatz vom zugehörigen Index
der Adresse im Quelltext, und ein entsprechender Versatz vom zugehörigen Index
in der Adresse im Zieltext.
-
Wenn
das Objektmodul III in den Prozessor geladen wird, können die
in der Referenztabelle aufgeführten
Adressen mit Hilfe der Streutabelle aktualisiert werden, noch bevor
die Bits restrukturiert werden.
-
Die
Streutabelle enthält
beispielsweise einen Satz Streu-Deskriptoren. Jeder Streu-Deskriptor
enthält einen
Satz Tripel (Zielversatz, Breite, Quellversatz) sowie eine Ganzzahl
ohne Vorzeichen, die die Anzahl der Tripel im Deskriptor angibt.
-
Angenommen,
man hat einen Streu-Deskriptor mit drei Tripeln (0, 7, 3), (7, 4,
15), (11, 5, 23). Weiterhin angenommen, das Quellfeld befindet sich
an der Position 320 im Bitfeld des Textabschnitts. Um die Bits des aktuellen
Adressfelds zu erhalten, tun wir Folgendes: die Bits 0 bis 6 (7
Bits) des Adressfelds reichen von Position 323 (320 + 3) bis 329
des Bitstrings, die Bits 7 bis 10 des Adressfelds reichen von Bit
335 bis 338 des Bitstrings, und die Bits 11 bis 15 des Adressfelds
reichen von Bit 343 bis 347 des Bitstrings. Damit hat das Adressfeld
die Länge
16.
-
Im
Objektmodul gehört
zu einem Bitstring eine Liste mit Referenz-Deskriptoren. Jeder Referenz-Deskriptor
bezieht sich auf ein Bitfeld im Bitstring. Ferner hat jeder Referenz-Deskriptor
einen Index in der Streutabelle, wo wir denjenigen Streu-Deskriptor finden
können,
der Informationen darüber
hat, auf welche Weise die Bits des Bitfelds im Bitstring verstreut
sind. Wenn beispielsweise ein Bitfeld die Position 11 in einem Bitstring hat
und der zu diesem Bitfeld gehörende
Streu-Deskriptor einen einzelnen Eintrag (0, 18, 0) hat, dann erhält man den
aktuellen Quellversatz, indem man die Position und den Quellversatz
addiert: 11 + 0.
-
DEKOMPIRIMIEREN DER BEFEHLE
-
Damit
der VLIP-Prozessor die wie oben beschrieben komprimierten Befehle
verarbeiten kann, müssen die
Befehle dekomprimiert werden. Nach der Dekompression füllen die
Befehle das Befehlsregister, das N Issueslots hat, wobei N im Fall
der bevorzugten Ausführungsform
5 ist. 12 zeigt eine
schematische Darstellung des Dekompressionsvorgangs. Die Befehle
kommen vom Speicher 1201, d. h. entweder vom Hauptspeicher 104 oder
vom Befehls-Cache-Speicher 105. Bevor die Befehle dekomprimiert
werden 1203, müssen
sie zunächst
restrukturiert werden 1201, was nachfolgend erläutert wird.
Nach dem Dekomprimieren 1203 können die Befehle an die CPU
weitergeleitet werden 1204.
-
Jede
dekomprimierte Operation hat zwei Formatbits und eine 42-Bit-Operation. Die beiden
Formatbits geben eine von vier möglichen
Operationslängen
an (nicht benutzter Issueslot, 26-Bit, 34-Bit oder 42-Bit). Diese
Formatbits haben dieselben Werte wie "Format" in Abschnitt 5 oben. Wenn eine Operation
eine Größe von 26
oder 34 Bits hat, sind die oberen 8 oder 16 Bits nicht definiert.
Wenn ein Issueslot unbenutzt ist, wie von den Formatbits angegeben,
dann sind alle Operationsbits undefiniert, und die CPU muss den
Opcode durch einen NOP-Opcode ersetzen (oder den Funktionseinheiten
anderenfalls NOP anzeigen).
-
Formal
lautet das Format des dekomprimierten Befehls:
<dekomprimierter
Befehl> :: = {<dekomprimierte Operation>}N
<dekomprimierte Operation> :: = <Operation:42><Format:2>
-
Operationen
haben das in Tabelle III (oben) dargestellte Format.
-
Anhang
A enthält
einen VERILOG-Code, der die Funktionsweise der Dekompressionseinheit
spezifiziert. Der VERILOG-Code ist ein Standardformat, das als Eingabe
in den von Cadence Design Systems, Inc. aus San Jose, Kalifornien,
USA, hergestellten VERILOG-Simulator benutzt wird. Der Code kann
auch direkt in den von Synopsys aus Mountain View, Kalifornien,
USA, hergestellten Design-Compiler eingegeben werden, um Schaltkreisdiagramme
einer Dekompressionseinheit zu erzeugen, die den Code dekomprimiert.
Der VERILOG-Code spezifiziert eine Liste von Stiften der Dekompressionseinheit;
dies sind:
-
-
Data512
ist ein Doppelwort, das einen Befehl enthält, die derzeit von Interesse
ist. In der Tabelle oben wird der Programmzähler (PC) benutzt, um data512
gemäß folgendem
Algorithmus zu bestimmen:
A: = {PC[31:8],8'b0}
wenn PC[5] = 0 dann
data512' : = {M(A), M(A +
32)}–
sonst
data512' : = {M(A
+ 32), M(A)}
wobei
A die Adresse eines einzelnen Wortes
im Speicher ist, der einen interessierenden Befehl enthält;
8'b0 8 Bits bedeutet,
die auf Null gesetzt sind;
M(A) ein von A adressiertes Speicherwort
ist;
M(A + 32) ein von A + 32 adressiertes Speicherwort ist;
data512' die umgeordnete
Version von data 512 ist.
-
Das
heißt,
dass Wörter
ausgetauscht werden, wenn ein ungeradzahliges Wort adressiert wird.
-
Operationen
werden von der Dekompressionseinheit in nur teilweise dekomprimierter
Form geliefert, weil sich die Operationsfelder nicht immer in derselben
Bitposition befinden. Um die Operationsfelder aus ihrer Bitposition
zu extrahieren, ist eine weitergehende Verarbeitung erforderlich,
die größtenteils
in der Befehls-Decodierungsstufe des CPU-Fließbandverfahrens durchgeführt werden
sollte. Nachfolgend wird dies für
jedes Operationsfeld erläutert:
-
src1
-
Das
Feld "src1" befindet sich an
einer festen Position und kann direkt als Adresse an die Registerdatei geleitet
werden. Nur die 32-Bit-Direktoperation verwendet das Feld src 1
nicht. In diesem Fall verwendet die CPU-Steuerung den src1-Operanden
von der Registerdatei nicht.
-
src2
-
Sofern
verwendet, befindet sich das Feld "src2" an
einer festen Position und kann direkt als Adresse an die Registerdatei
geleitet werden. Wenn es nicht verwendet wird, hat es einen undefinierten
Wert. Die CPU-Steuerung stellt sicher, dass kein aus der Registerdatei
ausgelesener "Dummy"-src2-Wert verwendet wird.
-
guard
-
Sofern
verwendet, befindet sich das Feld "guard" an einer festen Position und kann direkt
als Adresse an die Registerdatei geleitet werden. Gleichzeitig mit
dem Registerdateizugriff überprüft die CPU-Steuerung den
Opcode und die Formatbits der Operation. Wenn die Operation ungeschützt ist,
wird der aus der Registerdatei (RF) ausgelesene "guard"-Wert durch die Konstante WAHR ersetzt.
-
op code
-
Kurze
und lange Opcodes und Formatbits sind an einer festen Position in
der Operation verfügbar.
Sie befinden sich an Bit-Position 21–30 plus die beiden Formatbits.
Sie können
mit maximaler Zeit zur Decodierung direkt zur Opcode-Decodierung
geleitet werden.
-
dst
-
Im
Fall einer 32-Bit-Direktoperation mit Latenz 0 wird das Feld "dst" sehr schnell benötigt. Dieser
spezielle Fall wird von der CPU-Steuerung schnell erkannt, indem
sie das Bit 33 und die Formatbits überprüft. In allen anderen Fällen steht
im Fließband-Status
für die
Befehlsdecodierung ein voller Taktzyklus zur Verfügung, um
zu decodieren, an welcher Stelle sich das Feld "dst" in
der Operation befindet, (es kann an vielen Stellen sein) und es
zu extrahieren.
-
32-bit immediate
-
Falls
ein 32-Bit-Direktwert vorhanden ist, befindet es sich an einer festen
Position in der Operation. Die sieben niedrigstwertigen Bits befinden
sich im Feld "src2" an derselben Stelle,
an der sich ein 7-Bit-Parameter befinden würde.
-
7-bit parameter
-
Falls
ein 7-Bit-Parameter vorhanden ist, befindet er sich im Feld "src2" der Operation. Es
gibt eine Ausnahme: die Speicherung mit Offset-Operation. Bei dieser
Operation kann sich der 7-Bit-Parameter an verschiedenen Stellen
befinden und wird auf einen speziellen 7-Bit-Direktbus zum Daten-Cache-Speicher multiplexiert.
-
"BIT SWIZZLING"
-
Bei
langen Befehlen, z. B. 512-Bit-Doppelwörtern, werden Cache-Speicherstrukturen
komplex. Vorteilhaft ist es, die Bits der Befehl umzusetzen ("Swizzling"), um das Chip-Layout
zu vereinfachen. Die verwendeten Ausdrücke "swizzle" (umsetzen) und "shuffle" (umordnen) haben hier dieselbe Bedeutung.
Das Folgende ist ein Algorithmus für das „Bit-Swizzling".
wobei
i, j und k ganzzahlige Indizes sind; "word_shuffled" eine Matrix zur Speicherung der Bits
eines umgeordneten Wortes ist; und "word_unshuffled" eine Matrix zur Speicherung der Bits
eines nicht umgeordneten Wortes ist.
-
CACHE-STRUKTUR
-
6a zeigt die Funktionsweise
bei der Eingabe einer Cache-Struktur, die nützlich bei der effizienten Verarbeitung
von VLIW-Befehlen ist. Dieser Cache-Speicher enthält 16 Bänke 601–616 zu
jeweils 2 kB. Diese Bänke
teilen sich einen gemeinsamen Eingabebus 617. Die Cache-Speicher
sind in zwei Stapel aufgeteilt. Der Stapel links wird als "niedrig" bezeichnet, und
der Stapel rechts als "hoch".
-
Die
Eingabe in den Cache-Speicher kann immer nur für eine Bank und jeweils mit
nur 4 Bytes gleichzeitig erfolgen. Mittels Adressierung wird festgelegt,
welche 4 Bytes von welcher Bank aufgefüllt werden. Für jedes
in dem Cache-Speicher zu speichernde 512-Bit-Wort werden in jeder
Bank 4 Bytes gespeichert. In jeder Bank ist ein Teil schraffiert
dargestellt, der entsprechende Teile jeder Bank zum Laden eines
gegebenen Wortes angibt. Diese schraffierten Teile dienen lediglich
zur Veranschaulichung. In jeden Satz entsprechender Teile der Bänke kann
ein beliebiges gegebenes Wort geladen werden.
-
Nach
dem „Bit-Swizzling" gemäß dem oben
angegebenen Algorithmus werden aufeinander folgende 4-Byte-Teile
des umgesetzten Wortes in folgender Reihenfolge in die Bänke geladen: 608, 616, 606, 614, 604, 612, 602, 610, 607, 615, 605, 613, 603, 611, 601, 609.
Die Reihenfolge, in der die 4-Byte-Abschnitte des umgesetzten Wortes
ge laden werden, wird durch die römischen
Zahlen in den Kästen
angegeben, die die Bänke darstellen.
-
6b zeigt, wie das umgesetzte
Wort aus dem Cache-Speicher ausgelesen wird. 6b zeigt nur die schraffierten Teile
der Bänke
des niedrigen Stapels. Der hohe Teil ist analog. Jeder schraffierte
Teil 601a–608a hat
32 Bits. Die Bits werden mit Hilfe der gezeigten Verbindungen auf
den Ausgabebus geladen, genannt bus256low, d. h. in folgender Reihenfolge: 608a – Bit 0, 607a – Bit 0,
..., 601a – Bit
0, 608a – Bit
1, 607a – Bit
1, 601a – Bit
1, ..., 608a – Bit
31, 607a – Bit
31, ..., 601a – Bit
31. Mit Hilfe dieser Verbindungen wird das Wort automatisch zurück in seine
korrekte Bitfolge umgesetzt.
-
Die
Leitungsbündel, 620, 621,
..., 622 bilden zusammen den Ausgabebus "bus256low". Diese Leitungen
führen
kreuzungslos durch den Cache-Speicher zum Ausgang.
-
Am
Ausgang sieht der Cache-Speicher wie in 7 aus. Die Bits werden unter der Steuerung
einer Steuereinheit 704 aus dem Stapel "niedrig" 701 und dem Stapel "hoch" 702 durch
ein Verschiebenetzwerk 703 ausgelesen, das sicherstellt,
dass sich die Bits in der oben angegebenen Reihenfolge befinden.
Auf diese Weise wird die gesamte Ausgabe des 512-Bit-Wortes ohne
sich kreuzende Bündel 620, 621,
..., 622 und analoge Leitungen sichergestellt.
-
Im
Vorstehenden wurde ein VLIW-Prozessor beschrieben, der komprimierte
Befehle verwendet. Der VLIW-Prozessor hat ein Befehlsausgaberegister
mit einer Vielzahl von Issueslots, wobei jeder Issueslot zur Speicherung
einer jeweiligen Operation dient und alle Operationen in demselben
Taktzyklus mit der Ausführung
beginnen. Der VLIW-Prozessor
hat eine Vielzahl von Funktionseinheiten zur Ausführung der
im Befehlsregister gespeicherten Operationen. Der VLIW-Prozessor
hat eine Dekompressionseinheit, um das Befehlsausgaberegister mit
dekomprimierten Befehlen zu versorgen, wobei die Dekompressionseinheit
die komprimierten Befehle einem Speichermedium für komprimierte Befehle entnimmt
und die komprimierten Befehle dekomprimiert. Mindestens einer der
komprimierten Befehlen enthält
mindestens eine Operation, wobei jede Operation gemäß einem
Kompressionsschema komprimiert wird, das der betreffenden Operation
eine komprimierte Operationslänge
zuordnet. Die komprimierte Operationslänge wird aus einer Vielzahl
endlicher Längen ausgewählt, wobei
die endlichen Längen
mindestens zwei Längen
ungleich Null umfassen und die Auswahl einer der endlichen Längen von
mindestens einem Merkmal der Operation abhängt.
-
Der
Satz von Operationslängen
ist vorzugsweise {0, 26, 34, 42}. Auch das mindestens eine Merkmal ist
vorzugsweise mindestens eines der Folgenden:
- -
abgekürzter
Opcode;
- – geschützt oder
ungeschützt;
- – ergebnislos;
- – Direktparameter
mit fester Anzahl von Bits; und
- – nullwertig,
unär oder
binär.
-
Die
feste Anzahl ist vorzugsweise entweder 7 oder 32. Der Prozessor
umfasst vorzugsweise eine Vielzahl derartiger Befehle, von denen
ein Befehl ein Sprungziel ist und dieser Befehl nicht komprimiert
wird. Vorzugsweise enthält
jedes Operationsfeld innerhalb jedes Befehls ein Teilfeld, das mindestens
eines der Folgenden spezifiziert: die Registerdateiadresse eines
ersten Operanden, die Registerdateiadresse eines zweiten Operanden,
die Registerdateiadresse von Schutzinformationen, die Registerdateiadresse
eines Ergebnisses, einen Direktparameter, und einen Opcode. Vorzugsweise
umfasst jeder Befehl ein Formatfeld zur Spezifizierung einer Vielzahl
entsprechender Formate, ein entsprechendes Format für jede Operation
eines nachfolgenden Befehls. Vorzugsweise umfasst das komprimierte
Format ein Formatfeld, das die von einigen Befehlen zu verwendenden
Issueslots des VLIW-Prozessors spezifiziert.
-
Vorzugsweise
spezifiziert mindestens ein Feld die Operation. Das die Operation
spezifizierende Feld umfasst mindestens ein Byte-ausgerichtetes
Teilfeld. Vorzugsweise befindet sich mindestens ein Operationsteilfeld
in demselben Byte mit dem Formatfeld. Dadurch können Befehle mit einer Byte-Grenze
und nicht nur mit Wortgrenzen ausgerichtet werden. Vorzugsweise
kann das Formatfeld spezifizieren, dass mehr als eine Schwellenwertmenge
von Issueslots zu verwenden ist, und hat ferner mindestens ein erstes
Operationsteilfeld in desselben Byte mit dem Formatfeld, eine Vielzahl
von Operationen spezifizierende Teilfelder, und mindestens ein zweites
Operationsteilfeld, das sich in einem von den anderen Teilfeldern
getrennten Byte befindet.
-
Text
in der Zeichnung
Figur 5A
