-
Diese Erfindung bezieht sich auf
das Gebiet der Optimierung von Compilern für Computersysteme. Im speziellen
ist diese Erfindung eine neue und brauchbare Optimierungsmethode,
Vorrichtung, System und Computerprogrammprodukt zur Optimierung
der Reihenfolge von Computeroperationscodes, welche aus der Compilierung
einer Programmschleife resultieren.
-
Frühe Computer wurden durch Verdrahtung programmiert.
Moderne Computer werden durch Anordnung einer Bitsequenz im Computerspeicher
programmiert. Diese Bits führen
eine gleiche (aber sehr viel nützlichere)
Funktion aus, wie Verdrahtung in frühen Computern. Somit arbeitet
ein moderner Computer gemäß den binären Anweisungen,
welche sich im Computerspeicher befinden. Diese binären Anweisungen
werden als Operationscodes (Opcodes) bezeichnet. Der Computer ruft
einen Opcode von einer Speicheradresse ab, auf die mittels einem
Befehlszähler
gezeigt wird. Die Zentraleinheit (CPU) eines Computers wertet den
Opcode aus und führt
die spezielle Operation aus, welche mit dem Opcode verbunden ist.
Direktes Laden binärer
Werte in die Speicher, um einen Computer zu programmieren, ist sowohl
zeitraubend wie auch speicherbelastend. Programmiersprachen vereinfachen
dieses Problem, indem einem Programmierer die Verwendung einer symbolischen,
textuellen Repräsentation
(der Quellcode) für
die Operationen ermöglicht
wird, welche der Computer auszuführen
hat. Diese symbolische Repräsentation
wird mittels Compilern oder Maschinensprachen in binäre Opcodes
konvertiert. Durch Verarbeitung des Quellcodes kreieren Compiler
und Maschinensprachen eine Objektdatei (oder Objektmodul), welche
die Opcodes enthält,
die dem Quellcode entsprechen. Dieses Objektmodul führt, wenn
es mit anderen Objektmodulen verbunden ist, zu ausführbaren
Anweisungen, welche in einen Spei cher des Computers geladen und
durch den Computer ausgeführt
werden können.
-
Die Quelle eines Zielprogramms besteht
aus einer geordneten Gruppierung von Zeichen (Anweisungen), welche
in eine binäre
Repräsentation
konvertiert werden (umfassend sowohl Opcodes als auch Daten), die
geeignet ist zur Ausführung
durch eine Zielcomputerarchitektur. Ein Quellprogramm stellt eine
symbolische Beschreibung der Operationen dar, welche ein Computer
durchführen
wird, wenn er die binären
Anweisungen ausführt,
die aus dem Compilieren und dem Binden der Quelle resultieren. Die
Konvertierung der Quelle ins Binäre
wird entsprechend den grammatischen und syntaktischen Regeln der
Programmiersprache ausgeführt,
die zum Schreiben der Quelle verwendet werden. Diese Konvertierung
von Quelle ins Binäre
wird sowohl durch Compiler als auch durch Maschinensprachen ausgeführt.
-
Ein signifikanter Unterschied zwischen
Maschinensprachen und Compilern ist, dass Maschinensprachen die
Quellcodeanweisungen in binäre Opcodes
in einer 1 : 1 Weise übersetzen
(obwohl einige "Macro"-Fähigkeiten
häufig
vorgesehen sind). Andererseits transformieren Compiler Quellcodeanweisungen
in Sequenzen binärer
Opcodes (Objektcode), welche die durch die Quelle beschriebene Operation
ausführen,
wenn sie in einem Computer ausgeführt werden. Einige Compiler
bieten auch eine Option, die Maschinensprachenquelle auszugeben, die
den Objektcode repräsentiert.
-
Die mittels einem Compiler abgearbeiteten symbolischen
Anweisungen sind allgemeiner als die mit einer Maschinensprache
durchgeführten,
und jede compilierte Anweisung kann eine Vielzahl von Opcodes hervorrufen,
die, wenn sie mittels eines Computers ausgeführt werden, die durch die symbolische
Anweisung beschriebene Operation implementieren. Entgegen einer
Maschinensprache, welche die wesentliche strukturelle Organisation
des Quellcodes beibehält,
wenn sie binäre
Opcodesequenzen herstellt, kann ein Compiler die strukturelle Organisation,
welche durch die Quelle repräsentiert wird,
wenn sie das kombinierte Binäre
herstellt, signifikant ändern.
Trotzdem, ganz gleich wieviel der Compiler diese Organisation ändert, ist
der Compiler insoweit be schränkt,
dass das compilierte Binäre
das gleiche Ergebnis darstellen muss, wenn es durch einen Computer
ausgeführt
wird, wie es der Programmierer unter Verwendung der Quellsprache
beschrieben hatte – ungeachtet
dessen, wie dieses Ergebnis erreicht wird.
-
Viele moderne Compiler können die
binären Opcodes
optimieren, welche aus dem Compilierungsprozeß resultieren. Aufgrund der
Gestaltung von Programmiersprachen kann ein Compiler die strukturelle
Information bestimmen, womit das Programm compiliert wird. Diese
Information kann durch den Compiler verwendet werden, um unterschiedliche
Versionen der Opcodesequenzen zu generieren, welche die gleichen
Operationen ausführen.
(Beispielsweise Ermöglichen
der Fehlersuchfähigkeit oder
Optimieren von Anweisungen abhängig
von der Version des Zielprozessors, für den der Quellcode compiliert
ist.) Einige Optimierungen minimieren die Menge benötigten Speichers,
um die Anweisungen durchzuführen;
andere Optimierungen reduzieren die benötigte Zeit, um Anweisungen
auszuführen.
-
Einige Vorteile der Optimierung sind,
dass der optimierende Compiler den Programmierer von der zeitaufwendigen
Aufgabe der manuellen des Quellcodes befreit. Dies erhöht die Programmiererproduktivität. Optimierende
Compiler halten den Programmierer auch dazu an, wartbaren Code zu
schreiben, da manuelles Abstimmen den Quellcode häufig für andere
Programmierer unverständlicher
macht. Letztendlich verbessert ein optimierender Compiler die Übertragbarkeit
von Code, da Quellcode, welcher auf eine Computerarchitektur abgestimmt
ist, auf einer anderen Computerarchitektur ineffizient sein kann.
Eine allgemeine Diskussion zur Optimierung von Compilern und verwandte
verwendete Techniken können
in Compilers gefunden werden: Principles, Techniques and Tools von
Alfred V. Aho, Ravi Sethi und Jeffrey D. Ullmann, Addison-Wesly
Publishing Co. 1988, ISBN 0-201-10088-6, insbesondere Kapitel 9
und 10, Seiten 513–723.
-
1 zeigt
die allgemeine Struktur eines modernen Compilers, wie durch ein
allgemeines Bezugszeichen 100 angezeigt. Solch ein Compiler 100 verrechnet
die Quellinformation 101 eines Zielprogramms mittels eines Compilerein gangssegments 103.
Dieses Compilereingangssegment 103 verarbeitet die Syntax
und Semantik der Quellinformation 101 entsprechend den Regeln der
Programmiersprache, welche auf die Quellinformation 101 anwendbar ist.
Das Compilereingangssegment 103 generiert mindestens eine
Version einer Zwischencoderepräsentation 104 der
Quellinformation 101. Für
Schleifenkonstrukte schließt
die Zwischencoderepräsentation
im allgemeinen Datenstrukturen ein, welche entweder Datenabhängigkeitsgraphen
(DDG, data dependency graph) repräsentieren oder zu deren Bildung
verwendet werden kann. Diese Zwischenrepräsentation 104 wird
dann mittels eines Zwischenrepräsentationsoptimierungssegments 105 optimiert.
Das Zwischenrepräsentationsoptimierungssegment 105 bearbeitet
und gleicht die Zwischencoderepräsentation 104 der
Quellinformation 101 an, um die Ausführung eines Programms in einer
Vielzahl von Arten zu optimieren, welche im Fachbereich wohl verstanden sind.
Das Zwischenrepräsentationsoptimierungssegment 105 generiert
eine optimierte Zwischenrepräsentation 106.
Ein Codegenerierungssegment 107 verrechnet die optimierte
Zwischenrepräsentation 106,
führt maschinenorientierte
Optimierungen aus, belegt physikalische Register und generiert ein
Maschinensprachenquellcode- und/oder ein Objektcodemodul 109 aus
der optimierten Zwischenrepräsentation 106.
Der Objektcode umfasst binäre
Computeranweisungen (opcodes) in einem Objektmodul. Der Maschinensprachenquellcode
stellt eine Reihe von symbolischen Anweisungen in einer Maschinensprachenquellsprache
dar. Sowohl der Maschinensprachenquellcode als auch der Objektcode
zielen auf eine spezielle Computerarchitektur ab (z. B. SPARC, X86,
IBM, etc.).
-
DDGs enthalten die Information, welche
für einen
Optimieren benötigt
wird um festzulegen, welche Anweisungen abhängig von anderen Anweisungen
sind. Die Knoten in dem Graphen repräsentieren Anweisungen in der
Schleife und Bögen
repräsentieren
die Datenabhängigkeiten
zwischen den Knoten. Speziell der Umfang einer Variablen erstreckt
sich von einem "def' der Variable zu
einem "use" der Variable. Ein "def' entspricht einer
Anweisung, die eine Variable modifiziert (eine Anweisung "definiert" eine Variable, wenn
die Anweisung in die Variable schreibt). Ein "use" entspricht
einer Anweisung, die den Inhalt der Variablen verwendet. Beispielsweise definiert
("def') die Anweisung "x = y + 1" "x" und
verwendet ("use") "y". Ein Bogen in dem DDG erstreckt sich
von dem "def' einer Variablen
zu dem "use" der Variablen. DDGs
sind in Kapitel 4 von Supercompilers for Parallel and Vector Computers,
von Hans Zima, ACM Druck, (ISBN-0-201-17560-6, 1991 beschrieben.
-
Wie oben erwähnt, führt das Codegenerierungssegment 107 maschinenorientierte
Optimierungen aus und generiert entweder Objektcode (in der Form
von Objektmodulen) oder Maschinensprachenquellcode (oder beides).
Die Zwischenrepräsentation des
Programms bezieht sich im allgemeinen auf virtuelle Register. D.
h., der Zwischenrepräsentationsoptimierer
nimmt an, dass der Zielcomputer eine unbegrenzte Anzahl von Registern
enthält.
Während der
Operation des Codegenerierungssegments 107, sind diese
virtuellen Register den physikalischen Registern des Zielcomputers
zugewiesen. Dieses Resourcenmanagement wird in dem Codegenerierungssegment 107 mittels
einem Registerbelegungsprozeß (Expansion)
ausgeführt.
Ein Aspekt des Registerbelegungsprozesses ist, dass die Inhalte
der physikalischen Register den Speicher an unterschiedlichen Punkten
während
der Ausführung
des Programms überlaufen
lassen, so dass die begrenzte Anzahl von physikalischen Registern
verwendet werden kann, um Werte mit höherer Relevanz für das Programm
an diesen unterschiedlichen Punkten zu halten. Diese Werte, welche über den
Speicher überlaufen,
werden häufig
wieder in die Register eingesetzt, wenn das Programm zu unterschiedlichen Punkten
der Anwendung fortschreitet.
-
Ein Programmierkonstrukt, welches
bedeutend optimiert werden kann, sind Einzelbasisblock-Schleifen
(SBB-Schleifen). SBB-Schleifen besitzen eine bestimmbare Anzahl
von Wiederholungen (beispielsweise eine berechenbare Compilierzeit oder
bekannten symbolischen Auslöserzähler). SBB-Schleifen
enthalten keinerlei Kontrollflußstrukturen,
Funktionen, Prozeduren, oder andere Konstrukte, welche den Ausführungsfluß innerhalb
der Schleife wechseln. Solche Schleifen haben nur einen Eintrittspunkt,
einen Austrittspunkt und keine Zweige innerhalb der Schleife.
-
Fließbandverarbeitung von Software
ist eine Technik zur Planung der Ausführung von Anweisungen in SBB-Schleifen.
Die Technik der Fließbandverarbei tung
von Software plant verschiedene überlappende
Wiederholungen des Schleifenkörpers
um die eigentlichen parallelen Recheneinheiten des Computers auszunutzen.
Der Ausführungsplan
enthält
einen Prolog, einen Kernel und einen Epilog. Der Prolog initiiert
die ersten p Wiederholungen, wodurch jede Wiederholung gestartet
wird. Ein stabiler Zustand wird nach den ersten p*II Zyklen erreicht,
wo II das Initiierungsintervall ist, in dem jede ausgelöste Wiederholung
Anweisungen parallel ausführt.
In diesem stabilen Zustand oder Kernel wird alle II Zyklen eine Wiederholung
der Schleife abgeschlossen. Sobald der Kernel die letzte Wiederholung
in der Schleife auslöst,
schließt
der Epilog die letzten p Wiederholungen der Schleife ab, welche
durch den Kernel ausgelöst
wurden.
-
Einige Computer enthalten Prädikatanweisungen.
Prädikatanweisungen
können
verwendet werden, um eine Schleife zu konvertieren, welche in eine
SBB-Schleife verzweigende
Opcodes enthält. Beispielsweise
bestimmt eine Fließkomma-Bedingungsauswertungsanweisung
eine Prädikatbedingung.
Eine Fließkomma-"Prädikatbedingungsmaßnahme"-Anweisung wertet
die Bedingung aus und führt
sie entsprechend aus – aber
ohne jegliche Verzweigungsoperation.
-
2a und 2b zeigen den Entwurf von SBB-Schleifen
und die Vorteile der Verwendung von Prädikatanweisungen, um Nicht-SBB-Schleifen
in SBB-Schleifen
umzuwandeln. 2a zeigt
eine Nicht-SBB-Schleife, die durch ein allgemeines Bezugszeichen 200 angezeigt
wird. Die Schleife initiiert bei einem Codeblock 201. Bei
der "bne"-Anweisung des Blocks 201 kann
die Anwendung entweder bei einem Codeblock 203 oder einem
Codeblock 205 fortfahren, welche davon abhängt, wie
die "bne"-Anweisung des Blocks 201 ihre
Argumente auswertet. Dieser Zweig innerhalb der Schleife missachtet
die SBB-Schleifenanforderungen.
Wenn die Anwendung zu dem Codeblock 203 fortfährt, muss
die Anwendung hinter den Code in dem Codeblock 205 springen.
Dies ist ein anderes Beispiel, welches die SBB-Schleifenanweisungen
missachtet. Ungeachtet davon, welcher Weg bei der "bne"-Anweisung des Blocks 201 genommen
wird, fährt
die Anwendung bei einem Codeblock 207 fort. Der Codeblock 207 schließt Anweisungen
ein, welche festlegen, ob eine weitere Wiederholung der Schleife
ausgeführt
werden sollte oder ob die Schleife abschließt.
-
2b zeigt,
wie Prädikatanweisungen
die Nicht-SBB-Schleife 200 in eine SBB-Schleife konvertieren
können,
wie durch ein allgemeines Bezugszeichen 210 gezeigt wird.
Ein Codeblock 211, welcher gleich dem Codeblock 201 ist,
wird modifiziert, um ein Prädikat
p zu definieren, welches mit einer Bedingung im Zusammenhang steht
(hier ist die Bedingung, dass r1 ungleich 0 ist). Die Anweisungen
innerhalb eines Codeblocks 213 bekommen ein Prädikat übertragen.
Ein Prädikat
enthält
eine Kennung und einen Typ. Das Prädikat für den Codeblock 413 ist
id = p und typ = F (falsch). Somit liegt keine Verzweigung innerhalb
der Schleife vor, obwohl die Anweisung in dem Codeblock 213 nur
ausgeführt
wird, wenn die Prädikatbedingung
falsch ist. Dasselbe geschieht in einem Codeblock 215,
bis auf wenn die erforderliche Prädikatbedingung für die Anwendung wahr
anstelle von falsch ist. Somit fährt
die Anwendung sequenziell durch die Basisblöcke 211, 213, 215 fort,
wo Anweisungen bedingt davon abhängig ausgeführt werden,
falls das Prädikat
befriedigt ist. Die Anwendung schließt bei einem Codeblock 217 ab,
wo das Prädikat
p verbraucht ist und die Schleife bedingt nochmals wiederholt wird.
Jeder der Basisblocks 211, 213, 215, 217 umfasst
nun eine SBB-Schleife 219, welche optimiert werden kann, wobei
existierende Modulo-Planungsmethoden für SBB-Schleifen verwendet werden.
-
Eine Schwierigkeit mit Prädikatanweisungen ist,
dass es eine begrenzte Anzahl von Prädikatregistern gibt und diese
Register häufig
nicht den Speicher überlaufen
lassen und wieder hergestellt werden können. Prädikatregister sind ein Beispiel
für nicht auslagerbare
Quellen. Prädikatregister
sind nicht auslagerbar, da die CPU-Anweisungsliste eine Lade- oder
Speicheranweisung vorsieht, welche von/zu dem Register gerichtet
ist. Die Registerinhalte sind ein Ergebnis einer Vergleichsanweisung.
Es gibt keinen Weg, die Inhalte des Registers zu nehmen und sie
in einem anderen allgemeinen Zielregister oder Speicher zu speichern.
Somit sind diese Prädikatregister
eine Quellimitierung für
den Planungsprozeß des
Compilers.
-
Kurze Zusammenfassung
von Modulo-Planung
-
Modulo-Planung ist im Fachbereich
bekannt und ist allgemein in der wissenschaftlichen Veröffentlichung
Some Scheduling Techniques and An Easily Schedulable Horizontal
Architectur for High Performance Scientific Computing by B. R. Rau
und C. D. Glaeser, Proceeding of the Fourteenth Annual Workshop
on Microprogramming Advanced Processor Technolgoy Group, ESL, (Inc.,
Oktober 1981, Seiten 183 – 198
beschrieben, welche durch Bezugnahme hierin ganz eingearbeitet ist.
Zusammenfassend plant die Modulo-Planungstechnik parallele Anweisungsverarbeitung
durch Starten einer neuen Wiederholung einer SBB-Schleife vor Abschluss
einer vorher initiierten Wiederholung der SBB-Schleife. Das Konzept
ist, eine neue Wiederholung der SBB-Schleife nach einem festen Zeitintervall
zu initiieren. Dieses Zeitintervall wird das Initiierungsintervall
oder das Iterationsintervall (II) genannt.
-
2c zeigt
eine Planung mit vier Stufen und sieben Wiederholungen, wie durch
ein allgemeines Bezugszeichen 250 angezeigt wird. Lassen
Sie eine einzige Wiederholung eine geplante Länge von TL 251 besitzen, welche
die benötigte
Zeit zur Ausführung
der gesamten Wiederholung ist. Lassen Sie die Wiederholung in Stufen
aufgeteilt sein, wobei jede eine Initiierungsintervallzeit II 253
benötigt.
Der Stufenzähler
(SC, stage count) wird als SC = [TL/II] definiert. Somit ist in
dem Zustand, der in 2c gezeigt
wird, TL = 4 und II = 1, so dass SC = 4 ist.
-
Die Schleifenanwendung beginnt mit
einer Stufe 0 255 einer ersten Wiederholung 257.
Keine andere Wiederholung wird gleichzeitig während dem ersten Initiierungsintervall 253 angewendet.
Nach dem ersten Initiierungsintervall betritt die erste Wiederholung 257 Stufe 1 und
eine zweite Wiederholung 259 betritt seine Stufe 0.
Neue Wiederholungen verbinden jedes II bis alle Stufen verschiedene
Wiederholungen gleichzeitig ausführen.
Erreicht die Schleife das Ende, werden keine neuen Wiederholungen
initiiert und diese, welche in verschiedenen Fortschrittsstufen
sind, schließen
Schritt für
Schritt ab, bis eine letzte Wiederholung 260 abschließt.
-
Die Schleifenanweisung hat drei Phasen, eine
Prologphase 261, eine Kernelphase 263 und eine
Epilogphase 265. Während
der Prologphase 261 und der Epilogphase 265 laufen
nicht alle Stufen aufeinander folgender Wiederholungen ab. Alle
Stufen aufeinander folgender Wiederholungen laufen während der
Kernelphase 263 ab. Der Prolog 261 und der Epilog 265 dauern
(SC – 1)*II
Zyklen. Wenn der Auslöserzähler der
Schleife lang ist, wird die Kernelphase 263 viel länger als
die Prolog-261 oder die Epilog-265 Phasen dauern. Die Anfangsleistungsmetrik
für eine
Modulo-Planungsschleife ist das Initiierungsintervall (II) 253.
Der Wert von II ist auch eine Messung des stabilen Zustandsdurchsatz
für Schleifenwiederholungen.
Kleinere II Werte implizieren höheren
Durchsatz. Deshalb versucht das Steuerprogramm eine Tabelle abzuleiten,
welche den Wert von II minimiert. Die Zeit um n-Wiederholungen auszuführen beträgt T(n)
= (n + SC – 1)*II.
Der Durchsatz nähert
sich II an, wenn n gegen Unendlich geht.
-
Der Modulo-Planungsprozeß bildet
zuerst einen Datenabhängigkeitsgraphen
(DDG) für
die Schleife. Knoten in diesem (gerichteten) Graph entsprechen Anweisungen;
und Bögen
entsprechen Abhängigkeiten
zwischen den Anweisungen. Bögen
besitzen zwei Attribute: Latenz und Omega. Latenz ist die Anzahl
von Prozessortaktsignalen, welche erforderlich sind, um die Quelle
und das Ziel zu separieren. Omega ist die Iterationsdistanz zwischen
der Quelle und dem Ziel. (z. B.: Ein Omega von 0 besagt, dass der
Wert in der laufenden Iteration verwendet wird; ein Omega von 1
besagt, dass die Quellanweisung einen Wert für die Zielanweisung berechnet,
der in der nächsten
Iteration verwendet werden soll; ein Omega von 2 besagt, dass der
Wert, zwei Iterationen nach dem er berechnet wurde, verwendet wird.)
Anschließend
legt der Modulo-Planungsprozeß das
Minimuminitiierungsintervall (MII) fest, indem er das Maximum von
zwei Durchsatzbeschränkungen nimmt.
Diese Beschränkungen
sind das Quellenminimuminitiierungsintervall (ResmII) und das Wiederholungsminimuminitiierungsintervall
(RecmII). Das ResmII ist eine Begrenzung an die minimale Zyklenanzahl,
welche zum Abschließen
einer Iteration der Schleife benötigt
wird und auf Prozessorresourcen basiert. Wenn beispielsweise eine
Schleife zehn Zusatzoperationen besitzt und der Prozessor bestenfalls
zwei Zusatzoperationen pro Prozessorzyklus ausführen kann, dann würde die
Zusatzeinheitenresource den Wiederholungsdurchsatz bestenfalls auf
einen alle fünf
Takte begrenzen. Der ResmII wird berechnet, indem jede Resource
der Reihe nach genommen wird und dann das Maximum der Begrenzungen
genommen wird, welches von jedem verhängt wird.
-
Das RecmII ist eine Begrenzung basierend auf
der minimalen Taktanzahl, welche zum Abschließen einer Iteration benötigt wird
und basiert auf Abhängigkeiten
zwischen Knoten in den DDG. Arbeitstakte in dem DDG implizieren,
dass ein Wert Xj, welcher in einigen Iterationen k berechnet wird,
in einer späteren
Iteration j verwendet wird und zur Berechnung des gleichermaßen verbreiteten
Werts in Iteration j benötigt
wird. Diese periodischen Abhängigkeiten
legen ein Limit fest, wie schnell Iterationen ausgeführt werden
können,
da das Berechnen der Werte, welche in den Zyklen benötigt werden,
Zeit benötigen.
Für jeden
einfachen Zyklus in dem DDG wird das Verhältnis der Summe der Latenzen
(I) zu der Summe der Omegas (d) berechnet. Dieser Wertbegrenzt den
Iterationsdurchsatz, da es (I) Takte benötigt Werte in einem Zyklus
zu berechnen, der d Iterationen umfasst.
-
Der feste Abstand zwischen überlappenden Iterationen
erzwingt eine Beschränkung
für das
Steuerprogramm, anders als die normalen Beschränkungen, welche durch die Bögen in dem
DDG verhängt werden.
Nehmen Sie zur Kenntnis, dass die Plazierung einer Operation zu
einer Zeit t impliziert, dass dort eine entsprechende Operation
in der k-ten folgenden Iteration bei t + (k*II) existiert. Operationen, welche
die gleiche Quelle verwenden, müssen
zu unterschiedlichen Zeiten platziert werden, Modulo der II. Dies
wird als "Modulo-Zwangsbedingung" bezeichnet. Sie
gibt an, dass wenn eine Operation eine Quelle zur Zeit t, verwendet
und eine andere Operation exakt die gleiche Quelle zur Zeit t2 verwendet, dann müssen t1 und
t2 "t1 Modulo II ist nicht gleich t2 Modulo
II" entsprechen.
Dieses Steuerprogrammschema verwendet eine Modulo-Reservierungstabelle
(MRT, modulo reservation table), um Quellverwendung zu verfolgen,
wenn Planung vorkommt.
-
Das Steuerprogramm beginnt, indem
es versucht einen Plan abzuleiten, wobei das Minimuminitiierungsintervall
verwendet wird, welches als II = mII = max(ResmII, RecmII) definiert
ist. Wenn ein Plan nicht gefunden wird, nimmt 11 zu. Der Prozess
wiederholt sich, bis ein Plan gefunden wird oder ein oberes Limit
für II
erreicht wird. Nach der Planung muss der Kernel aufgerollt werden
und "defs" umbenannt werden,
um Werte von nachfolgenden Iterationen daran zu hindern, sich gegenseitig
zu überschreiben. Aufrollen
des Kernels ist der Prozess der Bildung einer Vielzahl von Kopien
des Kernels in dem generierten Code. Der benötigte minimale Kernel-Aufrollfaktor
(KUF, kernel unroll factor) wird durch die längste Wertlebenszeit begrenzt,
welche durch die II geteilt wird, da entsprechende neue Lebenszeiten
alle II-Takte beginnen. Die Lebenszeit eines Werts ist gleich der
Zeit, für
die ein Wert existiert; d. h., von der Zeit, wo seine Generierung
festgelegt ist (die "def'), bis zum letzten
Zeitmoment, wenn er benutzt (die Benutzung) wird oder benutzt werden
könnte.
Restiterationen (bis zu KUF-1) verwenden eine Reinmachschleife.
-
Ein anderer Aspekt der oben erwähnten Modulo-Planung
ist, dass einige Computeranweisungen in einer bestimmten Computerarchitektur
nicht nacheinander verarbeitet werden können. Beispiele für diesen
Anwendungstyp für
einige Prozessoren sind Divisions- und Quadrat-Hauptanweisungen.
Somit kann eine doppelte Präzisionsteilung
eine beachtliche Anzahl von aufeinander folgenden Prozessorzyklen
aufnehmen, während
welcher keine anderen Divisionsanweisung initiieren kann. Somit
sperren diese Anweisungen die Quelle, welche sie verwenden.
-
Während
die mII-Berechnung beachtet, dass die Verwendung der Quelle alle
Anweisungen in der Schleife benötigt,
beachtet die mII-Berechnung keine Abhängigkeiten zwischen Anweisungen.
Obwohl somit die Modulo-Planungstechniken versichern werden, dass
es genügend
Zyklen zur Planung der Schleife gibt versichern diese Techniken
nicht, dass genügend
aufeinander folgende Zyklen zur Verfügung stehen, um Sperroperationen
wie die Quadratische- und die Divisionsoperation zu planen. Häufig, wenn
Planungsschleifen Sperroperationen enthalten, kann ein Plan bei
einem gegebenen II nicht gefunden werden, auch wenn solch ein Plan
existiert. Somit nimmt 11 zu und ein neuer Versuch zur Planung tritt ein.
Dieser Prozess endet mit längeren
Compilierungen des Zielprogramms und weniger effizienten Ausführungscodes.
-
2d zeigt
den Prozess, welcher in einem optimierenden Codegenerationssegment 107 (von 1) eines Compilers verwendet
wird, wie durch ein allgemeines Bezugszeichen 270 gezeigt
wird. Der Prozess 270 initiiert bei einem "Start-"Terminal 271,
wenn eine Schleifenanweisung ausgewertet wird. Der Prozess 270 dauert
bis zu einer initialisierenden Modulo-Reservierungstabelle (MRT,
modulo reservatin table) – Prozedur
272 an. Diese Prozedur 272 reserviert eine Tabelle geeignet
zur Planung der Iterationen der Schleife. Dann setzt sich der Prozess 270 zu
einer Optimierungsstufe 273 fort, welche im Fachbereich
bekannte Optimierungen durchführt. Nachdem
die Optimierungsstufe 273 abschließt, überprüft der Prozess 270 ob
ein iteratives Konstrukt, wie eine SBB-Schleife, in einer Entscheidungsprozedur 275 optimiert
wird. Wenn die Entscheidungsprozedur 275 kein SBB Iterativkonstrukt
entdeckt, fährt der
Prozess zu einer normalen Planungsprozedur 277 fort. Nachdem
die Planung abschließt,
fährt der Prozess
zu einer den virtuellen Register erweiternden Prozedur 279 fort.
Die den virtuellen Register erweiternde Prozedur 279 belegt
physikalische Register für
die virtuellen Register, welche durch die optimierte Zwischenrepräsentation 106 des
Programms verwendet wird, welches compiliert wird und welches die
Inhalte dieser physikalischen Register veranlasst, an geeigneten
Punkten innerhalb der Ausführung des
Programms in den Speicher ausgelagert zu werden.
-
Wenn die Entscheidungsprozedur 275 ein iteratives
Konstrukt entdeckt, fährt
der Prozess zu einer "SBB-Schleifen-SW-Fließbandverarbeitungs"-Prozedur 281 fort.
Die Operation dieser Prozedur 281 ist oben beschrieben
und kann in Abrollen des Kernels der Schleife mittels dem Kernel-Abrollfaktor
(KUF, kernel unroll factor) und Modulo-Planung der Schleifenanweisungen
resultieren. Die Ausführung
fährt bei
der den virtuellen Register erweiternden Prozedur fort.
-
Nach der Registerbelegungsprozedur 279 fährt der
Prozess zu einer Codegenerationsprozedur 283 fort, wo die
optimierte Zwischenrepräsentation 106 in
Objektcode konvertiert ist (oder optional Maschinensprachenquellcode,
ab hängig
von der Bevorzugung des Anwenders). Der Prozess schließt durch ein "End-"Terminal 285 ab.
-
Aus der obigen Beschreibung wird
ein Fachmann erkennen, dass der Software-Fließbandverarbeitungsprozeß vor dem
Registerbelegungsprozeß . ausgeführt wird.
Somit kann der Planungsprozeß nicht
festlegen, wie viele physikalische Register in der Schleife verwendet
werden. Für
viele Arten von physikalischen Registern erzeugt dies befriedigende Ergebnisse,
da die Inhalte der physikalischen Register in den Speicher ausgelagert
werden können
(und dann bei Bedarf in dem physikalischen Registern wieder hergestellt
werden können).
Trotzdem können Prädikatregister
nicht in Speicher ausgelagert werden. Somit muss der Planungsprozeß sowohl
die Computeroperationen der Schleife planen wie auch versichern,
dass ausreichend Prädikatregister
existieren, um die Planungsoperationen auszuführen.
-
Ein anderes Problem mit der obigen
Technologie ist, dass einige Computeranweisungen nicht nacheinander
verarbeitet werden (Sperranweisungen). Diese Anweisungen verursachen
längere
Compilierungszeiten aufgrund der Schwierigkeit, ausreichend aufeinanderfolgende
Zyklen in einer teilweise geplanten Iteration aufzufinden. Diese
Anweisungen resultieren auch in längere Wiederholungsintervalle, um
das Platzieren der Sperranweisungen in dem Plan aufzunehmen.
-
Die vorliegende Erfindung sieht ein
Verfahren und eine Vorrichtung zur Optimierung einer Basisblockschleife
mittels eines Compilers vor, wie in den angehängten Ansprüchen definiert wird. Ein Aspekt
der Erfindung ist eine Methode zur Optimierung einer Schleife (welche
nur einen Eintrittspunkt, einen Austrittspunkt und kein Verzweigen
des Ausführungsflusses
innerhalb der Schleife besitzt). innerhalb eines Zielprogramms.
Das Zielprogramm ist auf eine Zielcomputerarchitektur gerichtet,
die eine Vielzahl von Technikeinheiten besitzt, welche das Fließbandverarbeiten
von Anweisungen vereinfachen. Die Mehrfachrecheneinheiten erlauben,
dass zwei oder mehrere Anweisungen in einem einzigen Taktzyklus innerhalb
der Computerarchitektur ausgegeben werden. Die Schleife beschreibt
ein iteratives Konstrukt. Dieser Aspekt der Er findung erkennt, dass
eine Schleifenanweisung eine Hauptanweisung enthält, welche eine Definition
einer nicht auslagerbaren Quelle ergibt. Eine nicht auslagerbare
Quelle ist eine Quelle, welche nicht zu oder von einem Speicher transferiert
werden kann. Die Erfindung legt ein Control-Omega fest, cΩ-Wert für das iterative
Konstrukt, wobei der cΩ-Wert
die maximale Anzahl von gleichzeitigen Wiederholungen der Schleife
anzeigt. Anschließend
konvertiert sie die Definition in eine Datenabhängigkeitsrandbedingung durch
Verwendung des cΩ-Werts.
Schließlich
plant die Erfindung das iterative Konstrukt und belegt die nicht
auslagerbare Quelle abhängig
von der Datenabhängigkeitsrandbedingung.
-
Ein weiterer Aspekt der Erfindung
ist eine Optimierungsvorrichtung zur Optimierung einer Schleife
(wobei sie nur einen Eintrittspunkt, einen Austrittspunkt und keine
Verzweigung des Ausführungsflusses
innerhalb der Schleife besitzt. Die Vorrichtung enthält eine
CPU, welche an einen Speicher gekoppelt ist. Die Vorrichtung enthält des weiteren ein
Compilersystem, welches ein Codegenerierungssegment besitzt. Das
Zielprogramm (welches die Schleife enthält) ist auf eine Zielrechnerstruktur
gerichtet, welche mehrere Berechnungseinheiten besitzt, die die
Fließbandverarbeitung
von Anweisungen vereinfachen. Die mehrfachen Berechnungseinheiten
erlauben, zwei oder mehrere Anweisungen in einem einzigen Taktzyklus
innerhalb der Zielrechnerstruktur auszugeben. Die Schleife beschreibt
ein iteratives Konstrukt. Die Vorrichtung enthält eine Schleifenerkennungseinrichtung,
die erkennt, dass die Schleifenanweisung einen Anweisungsrumpf enthält, der
in einer Ausgestaltung einer nicht auslagerbaren Quelle resultiert.
Eine nicht auslagerbare Quelle ist eine Quelle, die nicht zu und
von einem Speicher übertragen
werden kann. Die Vorrichtung enthält auch eine Kontroll-Omega-Festlegungseinrichtung, welche
ein Ventil für
das Kontroll-Omega für
das iterative Konstrukt festlegt, wobei der Kontroll-Omega-Wert
die maximale Anzahl von gleichzeitigen Wiederholungen der Schleife
anzeigt. Die Vorrichtung enthält
auch eine Konvertierungseinrichtung, die die Ausgestaltung in eine
Datenabhängigkeitsrandbedingung
durch Verwendung des Wertes des Kontroll-Omega konvertiert. Das
System plant das iterative Konstrukt, wobei es die Datenabhängigkeitsrandbedingung
durch Verwendung einer Planungseinrichtung verwendet. Eine Belegungseinrichtung belegt
die nicht auslagerbare Quelle abhängig von der Datenabhängigkeitsrandbedingung.
Die vorliegende Erfindung wird nachfolgend mit Bezug auf die beispielhaften
Ausführungsbeispiele
und die beigefügten
Zeichnungen beschrieben.
-
1 zeigt
einen Compileraufbau;
-
2a–d zeigen
verschiedene Optimierungstechniken aus dem Stand der Technik;
-
3 zeigt
Elemente eines Computersystems, welches zur Unterstützung einer
Compileranwendung in Übereinstimmung
mit einem bevorzugten Ausführungsbeispiel
konfiguriert ist;
-
4 zeigt
einen modifizierten Codegenerationsprozeß in Übereinstimmung mit einem bevorzugten
Ausführungsbeispiel;
-
5 zeigt
einen Prozess zur Festlegung eines Kontroll-Omega (cΩ) für nicht
auslagenbare Prädikatregisterdefinitionen
in Übereinstimmung
mit einem bevorzugten Ausführungsbeispiel;
-
6 zeigt
einen Prozess, welcher verwendet wird, um Prädikatregister zu Ausgestaltungen
in Übereinstimmung
mit einem bevorzugten Ausführungsbeispiel
zuzuordnen; und
-
7a–b zeigen
Prozesse, welche zur Planung von Sperranweisungen in Übereinstimmung
mit einem bevorzugten Ausführungsbeispiel
verwendet werden.
-
Bezeichnungen und Nomenklatur Die
folgenden Beschreibungen und Nomenklatur sind vorgesehen, bei dem
Verstehen der vorliegenden Erfindung und deren bevorzugten Ausführungsbeispielen
behilflich zu sein.
-
Data Dependency Graph – Ein Datenabhängigkeitsgraph
(DDG) ist eine Datenstruktur in dem Computerspeicher, welche darstellt,
wie Anweisungen innerhalb einer Schleife von anderen Anweisungen
abhängen.
Diese Graphen enthalten Knoten, welche Computeroperationen repräsentieren,
und Bögen,
welche Abhängigkeiten
zwischen den Knoten repräsentieren.
Diese Abhängigkeiten
enthalten Ablaufabhängigkeiten,
Datenabhängigkeiten
und Gegenabhängigkeiten.
Datenstrukturen innerhalb des Compilers, die Datenabhängigkeitsgraphen
repräsentieren,
sind häufig
durch Diagramme repräsentiert,
welche Kreise anstelle von Knoten verwenden, welche Anweisungen
und Bögen
zwischen den Knoten entsprechen und welche Abhängigkeiten darstellen.
-
Loop – Eine Schleife ist ein Programmiersprachenkonstrukt,
welches einen iterativen Prozess beschreibt, wo Anweisungen innerhalb
des Rumpfes der . Schleife Operationen definieren, welche wiederholt
durch einen Computer ausgeführt
werden. Mit anderen Worten veranlasst eine kombinierte Schleife,
wenn sie in einem Computer ausgeführt wird, den Computer, sich
wiederholend durch die Operationen, welche durch in der Schleife
enthaltene Anweisungen beschrieben werden zu wiederholen, bis irgendeine
Abschlußbedingung
befriedigt ist. Schleifenanweisungen repräsentieren ein iteratives Konstrukt,
das einen iterativen Kontrollprozeß gekoppelt an andere Anweisungen
darstellt, wobei es im Schleifenrumpf (Anweisungsrumpf) enthalten
ist. Die Schleifen, wie sie mittels der Erfindung optimiert sind, sind
auf Einzelbasisblock-Schleifen (SBB-Schleifen) begrenzt. D. h.,
Schleifen, die keinerlei Kontrollablaufstrukturen, Funktionen, Verfahren
oder andere Konstrukte enthalten, die den Anwendungsablauf innerhalb
der Schleife ändern.
Solche Schleifen besitzen nur einen Eintrittspunkt, einen Austrittspunkt
und keine Verzweigung innerhalb der Schleife.
-
Loop operation – Eine Schleifenoperation veranlasst
den Computer, wenn sie in einem Computer compiliert wird und die
resultierenden Computeranweisungen auf einem Computer ausgeführt werden,
wiederholt die Anweisungen auszuführen, welche innerhalb der
Schleife eingeschlossen sind. Jede Wiederholung der eingeschlossenen
Anweisungen ist ein einzelner Schritt der Schleife.
-
Iterative construct – Ein iteratives
Konstrukt ist eine Reihe von Operationen, die eine Schleifenoperation
bewirken, welche durch eine Schleifenanweisung und den ihr beigefügten Anweisungsrumpf definiert
ist.
-
Instructions – Anweisungen sind die compilierten
binären
Operationscodes (opcodes) für
eine Zielrechnerstruktur, welche die durch die Anweisung beschriebene
Operation implementieren. Häufig
wird eine compilierte Anweisung eine Vielzahl von Operationen beschreiben
und viele Computeranweisungen generieren.
-
Iteration – Eine Wiederholung ist eine
einzige Wiederholung der innerhalb einer Schleife beigefügten Computerausführungsanweisungen.
-
Operation – Eine Operation wird durch
eine Anweisung beschrieben und wird durch den entsprechenden Zwischencode
dargestellt. Der Codegenerationsteil eines Compilers konvertiert
die Operationen, welche durch den Zwischencode geschrieben werden,
in Sequenzen von ausführbaren
Anweisungen für
eine Zielrechnerstruktur. Diese Anweisungen bewirken die Operation
wenn sie auf dem Zielrechner ausgeführt werden.
-
Procedure – Eine Prozedur ist eine in
sich einheitliche Sequenz von Stufen, welche zu einem gewünschten
Ergebnis führt.
Diese Stufen sind jene, welche physikalische Manipulation von physikalischen
Größen erfordern.
Gewöhnlicherweise
nehmen diese Größen die
Form von elektrischen oder magnetischen Signalen ein, weil sie gespeichert, übertragen,
kombiniert, verglichen und anderweitig manipuliert werden können. Diese
Signale beziehen sich auf Bits, Werte, Elemente, Symbole, Charakter, Begriffe,
Zahlen oder ähnliches.
Der Fachmann wird verstehen, dass alle diese und ähnliche
Begriffe mit den entsprechenden physikalischen Größen im Zusammenhang
stehen und lediglich geeignete Kennzeichnungen sind, welche auf
diese Größen angewandt
sind.
-
Übersicht
-
Die durch einen Computer bei der
Ausführung
durchgeführten
Manipulationen beziehen sich häufig
auf Begriffe wie r. B. Hinzufügen
oder Vergleichen, die landläufig
mit mentalen Operationen im Zusammenhang stehen, welche durch einen
menschlichen Benutzer ausgeführt
werden. In der vorliegenden Erfindung ist keine solche Fähigkeit
eines menschlichen Benutzers in einer der hierin beschriebenen Operationen
notwendig. Die Operationen sind Maschinenoperationen. Nützliche
Maschinen zur Ausführung
der Operationen der Erfindung beinhalten programmierte Mehrzweckdigitalcomputer
oder ähnliche
Geräte.
In allen Fällen
wird die Berechnungsmethode von der Operationsmethode bei Betreiben
eines Computers unterschieden. Die vorliegende Erfindung bezieht
sich auf Verfahrensstufen zum Betreiben eines Computers in der Verarbeitung elektrischer
oder anderer (z. B. mechanisch, chemisch) physikalischer Signale,
um andere gewünschte
physikalische Signale zu generieren.
-
Die Erfindung bezieht sich auch auf
eine Vorrichtung zur Ausführung
dieser Operationen. Diese Vorrichtung kann speziell für den gewünschten Zweck
konstruiert sein oder sie kann einen Mehrzweckcomputer umfassen,
also durch ein Computerprogramm gezielt aktiviert oder re-konfiguriert
werden, welches im Speicher eines Computers gespeichert ist. Die
hierin vorgestellten Verfahren beziehen sich nicht schon von Natur
aus auf einen speziellen Computer oder eine andere Vorrichtung.
Im Speziellen können
verschiedene Mehrzweckmaschinen mit Programmen verwendet werden,
welche im Zusammenhang mit dem hierin gelehrten geschrieben stehen,
oder es kann noch zweckmäßiger geprüft werden,
um spezialisiertere Vorrichtungen zu konstruieren, um die erforderlichen
Verfahrensstufen auszuführen.
Die erforderliche Struktur für
eine Auswahl dieser Maschinen wird aus der folgenden Beschreibung
erscheinen. Die Erfindung kann auch in einem durch einen Computer
lesbaren Speicher medium ausgeführt
werden, welches mit einem Programm codiert ist, das den Computer
veranlasst, die programmierte Logik auszuführen.
-
Arbeitsumgebung
-
Die Erfindung kann mit jeder Programmiersprache
betrieben werden, die Schleifenkonstrukte verwendet. Zu einigen
dieser Programmiersprachen zählen
FORTRAN, PASCAL, C, C++, ADA und compiliertes BASIC, jedoch sind
sie nicht darauf beschränkt.
Beispielhafte Schleifenkonstrukte in C und C++ sind die "for", die "do-while" und die "while" Anweisungen. Die
durch die Erfindung bereitgestellte Optimierung findet Anwendung
bei Einzelbasisblock-Schleifen. Diese Schleifen haben nur einen Eintrittspunkt,
einen Austrittspunkt und keine Verzweigung des Anwendungsablaufs
innerhalb der Schleife.
-
Einige der Elemente eines Computersystems,
welche zur Unterstützung
einer Compileranwendung konfiguriert sind, sind in 3 gezeigt, wie durch ein allgemeines
Bezugszeichen 301 gezeigt wird. Das Computersystem 301 umfasst
einen Prozessor 303 mit einem Input/Output ("I/O") Abschnitt 305,
eine Zentraleinheit (CPU, centra/processing unit) 307 und einem
Speicherabschnitt 309. Der I/O Abschnitt 305 ist
mit einer Tastatur 311, einer Plattenspeichereinheit 313,
einer Anzeigeeinheit 315 und einer CD-ROM Laufwerkseinheit 317 verbunden.
Die CD-ROM Laufwerkseinheit 317 kann ein CD-ROM Medium 319 lesen,
welches typischerweise Programme und Daten 321 enthält. Die
CD-ROM Laufwerkseinheit 317,
wenn sie das CD-ROM Medium 319 enthält, und die Plattenspeichereinheit 313 umfassen
einen Dateispeichermechanismus. Solch ein Computersystem ist zur
Ausführung
von Compileranwendungen fähig,
welche die Erfindung enthalten.
-
4 zeigt
einen modifizierten Codegenerationsprozeß, der durch ein allgemeines
Bezugszeichen 270' angezeigt
wird, welcher die Erfindung einschließt. 4 ist gleich der 2d und die Bezugszeichen, welche in 4 verwendet werden und welche
den gleichen Aspekten der 2d entsprechen, verwenden
das gleiche Bezugszeichen wie in 2d verwendet,
bis auf wenn diese Bezugszeichen mit einem Strich versehen sind.
Somit entspricht ein "Start" Terminal 271' in 4 dem "Start" Terminal 271 in 2d. Eine initialisierende
MRT Prozedur 272' schließt Aspekte
der Erfindung ein und wird im folgenden beschrieben. Eine Optimierungsprozedur 273' bietet die
gleichen Operationen wie die Optimierungsprozedur 273 der 2d. Des weiteren besitzen
eine Entscheidungsprozedur 275' und eine "Nicht-SBB-Schleifensteuerungs"-Prozedur 277' die gleichen
Operationen wie die entsprechenden Prozeduren 275, 277 der 2d.
-
Eine modifizierte "SBB-Schleifen-SW-Fließbandverarbeitungs"-Prozedur 281', welche die
Erfindung verwendet, umfasst eine "lege cΩ für Prädikat-Defs fest"-Prozedur 401.
Diese Prozedur 401 legt einen Kontroll-Omega (cΩ) für Prädikatregister
fest und wird im folgenden beschrieben. Sobald die Prädikatregister
ihren "defs" cΩ-Bögen (Prädikatbögen) in
dem DDG hinzugefügt
haben, fährt
der Prozess zu einem "lege
Minimum II fest"-Prozess
403 fort, der einen MII generiert, wobei er die cΩ-Bögen beachtet. Als
nächstes
fährt der
Prozess 270' zu
einer "Planungsschleifen"-Prozedur 405 fort,
welche die Schleife steuert, wobei beide gut bekannten Planungstechniken
und erfinderischen Techniken (wie im folgenden beschrieben) auf
den DDG angewendet werden.
-
Eine modifizierte "Virtuellregisterexpansion"-Prozedur 279' verarbeitet den
DDG in einer "Für DDG"-Prozedur 407.
Diese Prozedur bearbeitet jeden Bogen und Knoten in dem DDG. Wenn
der DDG komplett verarbeitet ist, fährt der Prozess zu einer Codegenerationsprozedur 283' fort, wie durch
einen Pfeil 408 angezeigt wird. Wie oben erwähnt, bearbeitet
der Compiler jeden Bogen und Knoten in dem DDG. Eine "wähle die Bogenart aus"-Prozedur 409 prüft die Art
des Bogens und wählt
die entsprechende Prozedur. Wenn der Bogen kein Prädikatbogen
ist, fährt
der Prozess 270' zu
einer "arbeite anderen
Bogen ab"-Prozedur 411 fort,
welche Methoden aus dem Stand der Technik verwendet, um physikalische Register
für virtuelle
Register zu belegen. Ist der Bogen jedoch ein Prädikatbogen, fährt der
Prozess 270' zu
einer "arbeite Prädikatbogen
ab"-Prozedur 413 fort,
welche im folgenden beschrieben wird. Der Prozess kehrt zu der "Für DDG"-Prozedur 407 zurück, um mit dem Verarbeiten
des DDG fortzufahren, nachdem jeder Bogen durch die entsprechende
Prozedur 411, 413 verarbeitet ist.
-
Die "Codegenerierungs"-Prozedur 283' stellt die gleiche Operation wie die "Codegenerierungs"-Prozedur 283 der 2d dar. Der Prozess 270' schließt durch
ein "End"-Terminal 285' ab.
-
5 zeigt
den Prozess, welcher in der "lege cΩ für Prädikat-Defs
fest"-Prozedur 401 der 4 verwendet wird. Dieser
Prozess wird durch ein allgemeines Bezugszeichen 500 angezeigt.
Der Prozess 500 läuft
bei einem "Start"-Terminal 501 an
und fährt zu
einer "identifiziere
alle eindeutigen prädikatdefinierenden
Anweisungen"-Prozedur
503 fort. Diese Prozedur 503 wertet die Anweisungen in
der Schleife aus und identifiziert jene, welche eindeutig prädikatdefinierende
Anweisungen sind -ein "def' eines bestimmten
Prädikatregisters.
Mehrfach sich nicht widersprechende Definitionen eines Prädikatregisters sind
erlaubt und enden mit nur einem definierten Prädikatregister (d. h., nur ein
Prädikatregister
wird geschrieben). Der Wert NDEF ist die Anzahl von Prädikatregistern,
welche in der Schleife definiert werden (d. h., die Anzahl der Prädikatregister,
welche innerhalb der Schleife gesetzt werden). In einer "lege die Anzahl verfügbarer Prädikatregister
fest"-Prozedur 505
legt der Prozess 500 die Anzahl der Prädikatregister fest, welche
den Anweisungen in der Schleife zur Verfügung stehen – die Anzahl
der freien Prädikatregister.
Dieser Positiv- oder
Null-Wert ist NREG. NREG ist die gesamte Anzahl der Prädikatregister weniger
der Anzahl der Prädikatregister,
welche am Leben sind (in Verwendung), wobei sie einen Bereich besitzen,
welcher die Schleife weniger NDEF umfaßt. D. h., die Anzahl von Prädikatregistern,
welche für
die Expansion zur Verfügung
stehen, ist: NREG = Total#PredRegs – #LiveRegsAroundLoop – NDEF;
-
Als nächstes legt der Prozess den
Kontroll-Omega (cΩ)
in einer "lege cΩ fest" -Prozedur 507 fest
als: cΩ =
floor (NREG/NDEF) + 1;
-
Der Wert von cΩ ist der größte Integer nicht größer als
der Wert von NREG/NDEF, plus 1. Daher, wenn die Zielrechnerarchitektur
vier Prädikatregister anbietet
und nur ein Prädikatregister
in der Schleife verwendet wird, dann ist cΩ, im folgenden nur noch als
cΩ benannt,
gleich 4 und die Architektur unterstützt vier gleichzeitige Wiederholungen.
Ist der cΩ jedoch
gleich 1 (so wenn drei oder vier Prädikatregister für die Schleife
benötigt
werden), ist nur eine Wiederholung der Schleife erlaubt.
-
Als nächstes prüft der Prozess bei einer "für jedes Def in der Schleife"-Prozedur 509 jedes "def' innerhalb der Schleife.
Nachdem alle "defs" in der Schleife
geprüft
wurden, schließt
der Prozess durch ein "End"-Terminal 511 ab.
Somit legt eine Entscheidungsprozedur 513 für jedes "def' in der Schleife
fest, ob das "def' ein Prädikatregister "def' ist. Wenn die Entscheidungsprozedur 513 festlegt,
dass das "def' kein Prädikatregister "def' ist, fährt der
Prozess zu dem nächsten "def' in der Schleife
durch die "für jedes
Def in der Schleife"-Prozedur
509 fort. Legt die Entscheidungsprozedur 513 jedoch fest,
dass das "def' ein Prädikatregister "def" ist, fährt der
Prozess zu einer "füge cΩ Bogen zu
Def'-Prozedur 515
fort. Die Prozedur 515 fügt dem "def' einen
Selbstausgabebogen 517 zu, wo die Abhängigkeitsdistanz des Bogens
der Wert des Kontroll-Omega cΩ ist.
Das Hinzufügen
des Selbstausgabebogens 517 konvertiert eine Quellbedingung
in eine Datenabhängigkeitsrandbedingung.
Der Prozess 500 fährt
zu der Prozedur 509 fort, um zu dem nächsten "def' in
der Schleife fortzufahren. Dieser Prozess endet mit einem Plan für die Schleife,
welche eine Belegung der Prädikatregister
ohne Registerauslagerung garantiert.
-
6 zeigt
die "arbeite Prädikatbogen ab"-Prozedur 414 der 4. Die Prozedur wird durch ein
allgemeines Bezugszeichen 600 angezeigt. Die Prozedur 600 läuft bei
einem "Start"-Terminal 601 an und
fährt zu
einer "für jede Schleife"-Prozedur 603 fort,
welche sich durch jede Schleife in der Zwischenrepräsentation
wiederholt. Nachdem alle Schleifen verarbeitet wurden, schließt die Prozedur
durch ein "End"-Terminal 605 ab.
-
Für
jede Schleife fährt
die Prozedur 600 zu einer "lege nicht verwendete Prädikatregister fest"-Prozedur 607 fort,
die die Anzahl unbenutzter Prädikatregister
festlegt, die zur Verfügung
stehen, um zur Expansion verwendet zu werden. Diese Festlegung ist
gleich der einen, welche für
die "lege die Anzahl
verfügbarer
Prädikatregister
fest"-Prozedur 505
verwendet wurde, welche oben beschrieben wurde. Bei einer "lege cΩ fest"-Prozedur 609, gleich der "lege cΩ fest"-Prozedur 507 wie
oben beschrieben, legt die Prozedur 600 dann den cΩ für die zu verarbeitende
Schleife fest. Als nächstes
fährt die Prozedur 600 zu
einer "für jedes
Def eines Prädikatregisters"-Prozedur 611 fort,
welche den DDG abfragt, welcher die Schleife für jedes "def',
welches ein Prädikatregister
repräsentiert,
repräsentiert.
Ist die gesamte Schleife einmal abgefragt und jedes Prädikat "def' verarbeitet, schließt die Prozedur 611,
wie durch einen Pfeil 613 angezeigt, durch die "für jede Schleife"-Prozedur 603 ab.
-
Jedes Prädikat "def' wird
durch eine "generiere
Tabelle von möglichen
Erweiterungen"-Prozedur
615 verarbeitet, welche eine Tabelle von Vektoren mit der Länge cΩ bildet.
Diese Tabelle verknüpft die
Prädikatregister
mit den erweiterten virtuellen Registernamen, welche für jede gleichzeitig
ausgeführte Wiederholung
verwendet werden. Wenn somit nur ein Prädikatregister in der Schleife
benötigt
würde (also
cΩ = 4),
dann würde
die Tabelle ein Prädikatregister
zur Verwendung für
jede der vier gleichzeitig ausgeführten Wiederholungen verbinden
(angenommen andere Begrenzungen schränken die Anzahl gleichzeitig
ausgeführter
Wiederholungen unterhalb 4 nicht ein).
-
Bei einer "weise Registererweiterung für jedes
Def an"-Prozedur
617 verwendet der Prozess die Tabelle möglicher Expansionen, welche
durch die Prozedur 615 generiert wurden, um Prädikatregister zu
jedem "def' für jede gleichzeitig
ausgeführte
Wiederholung zuzuordnen. Dann sind die Prädikatregister, welche den "defs" zugeordnet sind,
durch eine "verbreite
zu Anwendungen des Def'-Prozedur
619 für
die Benutzungen des "def' unabhängig für jede Wiederholung
verbreitet und der Prozess kehrt zu der Prozedur 611 zurück, wie
durch einen Pfeil 621 angezeigt wird, um den nächsten "def' zu verarbeiten.
-
Durch Festlegung eines cΩ, welcher
die Anzahl gleichzeitig ausgeführter
Wiederholungen anzeigt, welche durch die nicht auslagerbare Quelle
zugelassen werden und durch Anhängen
eines Selbstausgabe-Bogens der Ordnung cΩ an die "defs",
welcher eine nicht auslagerbare Quelle ansteuert, wird die Quelle
somit in eine Datenrandbedingung konvertiert.
-
Somit konvertiert cΩ eine Quellbedingung (wie
r. B. einen nicht auslagerbaren Prädikatregister) in eine Datenwiederholungsrandbedingung.
Diese Datenwiederholungsrandbedingung begrenzt dann die Anzahl der
gleichzeitig ausgeführten
Wiederholungen (wenn die Anzahl der gleichzeitig ausgeführten Wiederholungen
noch nicht fest begrenzt ist). Diese Technik erlaubt dem Plansegment
des Compilers Registerexpansion geeignet zu begrenzen, wobei sie
von der erreichbaren nicht auslagerbaren Quelle abhängt.
-
7a und 7b zeigen die Prozesse, um
Planungssperroperationen zu bestimmen, wie z. B. die Divisions-
und Quadratwurzeloperationen, ohne Erfordernis eines Anstiegs in
der II, aufgrund der Aufteilung der MRT. Dieser Prozess reserviert
Platz in der MRT für
die Sperroperationen in der Schleife vor, so dass nachfolgende Planungsoperationen
von Nicht-Sperroperationen die MRT nicht so aufteilen werden, dass
die II erhöht
werden muss, um eine Planung zu erlauben.
-
7a zeigt
den Prozess, welcher zur Initialisierung des MRT für die Schleife
verwendet wird, wie durch das allgemeine Bezugszeichen 700 gezeigt
wird. Dieser Prozess wird durch die initialisierte MRT Prozedur 272' der 4 aufgerufen. Der Prozess
initiiert bei einem "Start"-Terminal 701 und
fährt zu
einer Prozedur 703 fort, welche die Anzahl von Sperroperationen
in der Schleife festlegt. Eine "bilde Modulo-Reservierungstabelle"-Prozedur 704 verwendet
den Wert, welcher in der Prozedur 703 festgelegt wird und
bildet eine Modulo-Reservierungstabelle
(MRT, Modulo Reservation Tabel) mit ausreichend Einschüben, wie
für die
II der Schleife angebracht ist. Als nächstes fährt der Prozess zu einer Prozedur 707 fort,
die einen bestimmten Planungsbereich (d. h. aufeinander folgende
Einschübe)
in der MRT vorbelegt (reserviert), um die Sperroperationen innerhalb
der Schleife zu enthalten. Durch Vorbelegung der bestimmten Planungsbereiche
in der MRT für
die Sperroperationen werden nachfolgende aneinander gereihte Operationen
in diesen reservierten bestimmten Planungsbereich nicht geplant;
daher wird Planung von Sperroperationen nicht aufgrund der nachfolgenden
Unterteilung der MRT aufgrund aneinander gereihter Operationen beeinträchtigt.
Der Fachmann wird verstehen, dass der bestimmte Planungsbereich
für Sperroperationen
als eine Gruppe bestimmt ist, nicht für spezifische Sperroperationen. Letztendlich
wird der Prozess durch ein "End"-Terminal 709 abgeschlossen.
-
Jede Operation wird bei einer Sperroperation-Entscheidungsprozedur 775 ausgewertet
um festzulegen, ob die Operation eine Sperroperation oder eine Nicht-Sperroperation
ist. Wenn die Operation eine Nicht-Sperroperation ist, fährt der
Prozess zu einer "Planungsoperation"-Prozedur 759 fort,
die eine Restklassenbestimmung der Operation durchführt. Wenn
die Operation jedoch eine Sperroperation ist, fährt der Prozess 750 von
der Entscheidungsprozedur 757 zu einer Prozedur 761 fort,
welche die früheste
Operation in der MRT feststellt, welche reserviert wurde und welche
für Planungssperroperationen
zugänglich
ist. Sobald dieser MRT Ort gefunden ist, fährt der Prozess zu einer Prozedur 763 fort,
welche die Operation innerhalb dieses frühest reservierten Bereichs
des MRT plant. An einer "aktualisiere die
MRT'-Prozedur 765,
markiert der Prozess als nächstes
den reservierten Bereich, welcher nun durch die Sperranweisung belegt
ist und der Prozess fährt
bei der "für jede Operation"-Prozedur 753 fort.
-
Der Fachmann wird verstehen, dass
die Erfindung wie oben beschrieben ein Verfahren, Vorrichtung, System
und computerprogrammiertes Produkt lehrt, welches die Optimierungsfähigkeiten
von Compilern verbessert.
-
Obwohl die vorliegende Erfindung
mit Begriffen der vorliegend bevorzugten Ausführungsbeispiele beschrieben
wurde, wird der Fachmann verstehen, dass unterschiedliche Modifikationen
und Veränderungen
vorgenommen werden können,
ohne von dem Bereich der Erfindung abzuweichen. Dementsprechend
ist der Bereich der Erfindung nicht auf die hierin diskutierten
jeweiligen Aus führungsbeispiele der
Erfindung begrenzt, sollten aber nur durch die angefügten Ansprüche definiert
werden.