DE10393260T5

DE10393260T5 - Nachdurchgangs-Binäranpassung für eine auf Software basierende spekulative Vorberechnung

Info

Publication number: DE10393260T5
Application number: DE10393260T
Authority: DE
Inventors: Steve Shih-Wei Palo Alto Liao; Perry San Jose Wang; Hong Fremont Wang; Geolf Santa Clara Hoflehner; Daniel Santa Clara Lavery; John San Jose Shen
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-09-17
Filing date: 2003-09-05
Publication date: 2005-09-01
Also published as: US8522220B2; WO2004027605A2; AU2003273282A1; GB2408126A; US20040054990A1; US8095920B2; WO2004027605A3; GB0502796D0; AU2003273282A8; US20100211940A1

Abstract

Verfahren zum Kompilieren eines Softwareprogramms, mit den folgenden Schritten:
Identifizieren einer säumigen Anweisung;
Identifizieren eines Anfangs-Slice für die säumige Anweisung;
dynamisches Erzeugen eines Ausführungs-Slice auf der Basis des Anfangs-Slice; und
dynamisches Erzeugen einer erweiterten Binärdatei, die das Ausführungs-Slice enthält.

Description

Hintergrund
Technisches Gebiet
Die vorliegende Erfindung betrifft allgemein Informationsverarbeitungssysteme und insbesondere das dynamische Anpassen einer binären Datei, um eine spekulative Vorberechnung zu erleichtern.
Allgemeiner Stand der Technik
Um die Leistungsfähigkeit von Informationsverarbeitungssystemen, wie zum Beispiel solchen, die Mikroprozessoren enthalten, zu vergrößern, wurden sowohl Hardware- als auch Softwaretechniken verwendet. Auf der Hardwareseite gehörten zu Mikroprozessorentwurfsansätzen zur Verbesserung der Mikroprozessorleistungsfähigkeit das Erhöhen von Taktgeschwindigkeiten, Pipelining, Verzweigungsprädiktion, Superskalarausführung, Ausführung außerhalb der Reihenfolge und Cache-Speicher. Viele solche Ansätze haben zu erhöhten Transistorzahlen und in bestimmten Fällen sogar einem Anstieg der Transistorzahl mit einer höheren Rate geführt als der der Leistungsfähigkeitssteigerung geführt.
Anstatt die Leistungsfähigkeit durch zusätzliche Transistoren zu erhöhen zu versuchen, werden bei anderen Verbesserungen der Leistungsfähigkeit Softwaretechniken benutzt. Ein Softwareansatz, der zur Verbesserung der Prozessorleistungsfähigkeit verwendet wurde, ist als "Threading" bekannt. Beim Software-Threading wird ein Anweisungsstrom in mehrere Anweisungsströme aufgeteilt, die parallel ausgeführt werden können. Bei einem Ansatz können mehrere Prozessoren in einem Mehrprozessorsystem jeweils gleichzeitig auf einen der mehreren Threads wirken.
Bei einem anderen Ansatz, der als Time-Slice-Multi-Threading bekannt ist, schaltet ein einziger Prozessor nach einem festen Zeitraum zwischen Threads um. Bei einem weiteren Ansatz schaltet ein einziger Prozessor zwischen Threads um, wenn ein Trigger-Ereignis eintritt, wie zum Beispiel eine Cache-Verfehlung mit langer Latenz. Der letztere Ansatz ist als Switch-On-Event-Multithreading bekannt. Obwohl sie unter bestimmten Umständen Gewinne bei der Leistungsfähigkeit erzielen, erzielen diese Ansätze keine optimale Überlappung vieler Quellen einer ineffizienten Betriebsmittelbenutzung, wie zum Beispiel Verzweigungsfehlvorhersagen und Anweisungsabhängigkeiten.

Auf der Suche nach weiteren Leistungsverbesserungen wurde das Multi-Threading-Konzept in einer als gleichzeitiges Multi-Threading ("SMT") bekannten Softwaretechnik verbessert. Bei SMT können mehrere Threads gleichzeitig auf einem einzigen Prozessor ohne Umschaltung ausgeführt werden. Bei diesem Ansatz wird bewirkt, daß ein einziger physischer Prozessor Betriebssystemen und Benutzerprogrammen als mehrere logische Prozessoren erscheint. Das heißt, jeder logische Prozessor führt einen vollständigen Satz des Architekturzustands, aber nahezu alle anderen Betriebsmittel des physischen Prozessors, wie zum Beispiel Cache-Speicher, Ausführungseinheiten, Verzweigungsprädiktoren, Steuerlogik und Busse werden gemeinsam benutzt. Die Threads werden gleichzeitig ausgeführt und nutzen gemeinsam benutzte Betriebsmittel besser aus als Time-Slice-Multithreading oder Switch-On-Event-Multithreading. Dennoch besteht immer noch ein Leistungskostenfaktor, der bei einer Cache-Verfehlung oder einer Operation mit langer Latenz, die während der Ausführung der Threads auftritt, zu begleichen ist.

Ausführungsformen des Verfahrens und der Vorrichtungen, die hier offengelegt werden, betreffen dieses und andere Probleme in bezug auf Latenzen und Multi-Threading.

Kurzbeschreibung der Zeichnungen

Die vorliegende Erfindung kann mit Bezug auf die folgenden Zeichnungen verstanden werden, in denen gleiche Elemente durch gleiche Zahlen bezeichnet sind. Diese Zeichnungen sollen nicht einschränkend sein, sondern werden statt dessen angegeben, um gewählte Ausführungsformen eines Verfahrens und einer Vorrichtung zur dynamischen Nachdurchgangs-Binäranpassung (post-pass binary adaptation) für eine auf Software basierende spekulative Vorberechnung zu illustrieren.

1 ist ein Flußdiagramm mindestens einer Ausführungsform zur dynamischen Binäranpassung für eine auf Software basierende spekulative Vorberechnung.

2 ist ein Datenflußdiagramm mindestens einer Ausführungsform einer Menge von Eingaben für ein auf Software basierendes Verfahren zur dynamischen Binäranpassung zur spekulativen Vorberechnung.

3 ist ein Flußdiagramm mindestens einer Ausführungsform eines Software-Kompilierungsprozesses.

4, einschließlich 4A, 4B und 4C, zeigt einen Binärcodeauszug ( 4A), einen Ausführungs-Slice (4B) und ein Abhängigkeitsdiagramm (4C) für eine beispielhafte Delinquent- bzw. säumige bzw. überfällige Ladeanweisung.

5 ist ein Flußdiagramm mindestens einer Ausführungsform eines Verfahrens zum Identifizieren eines säumigen Ladens.

6 ist ein Flußdiagramm mindestens einer Ausführungsform eines Verfahrens zum Berechnen eines Anfangs-Slice.

7 ist ein Flußdiagramm mindestens einer Ausführungsform eines Verfahrens zum Erzeugen eines Ausführungs-Slice.

8 ist ein Flußdiagramm mindestens einer Ausführungsform eines Verfahrens zum Erzeugen einer erweiterten Binärdatei.

9 ist ein Blockschaltbild zur Darstellung von Regionen für eine säumige Ladeanweisung gemäß einer Ausführungsform der Erfindung.

10 ist ein Blockschaltbild zur Darstellung von Verkettung-SP-Vorabrufschleifeniterationen gemäß einer Ausführungsform der Erfindung.

11 ist ein die Partitionierung von Verkettungs-P-Slices gemäß einer Ausführungsform der Erfindung darstellendes Blockschaltbild.

12 ist ein Blockschaltbild eines Verarbeitungssystems mit der Fähigkeit zur Durchführung mindestens einer Ausführungsform der dynamischen Binärerweiterung für eine auf Software basierendes ekulative Vorberechnung.

Detaillierte Beschreibung
1 ist ein Flußdiagramm mindestens einer Ausführungsform eines Verfahrens 100 zum dynamischen Anpassen einer Binärdatei zur Durchführung einer auf Software basierenden spekulativen Vorberechnung. Das Wort "dynamisch" hat hier die Bedeutung eines automatisierten Prozesses. Solche automatisierten Prozesse stehen zum Beispiel im Kontrast zu Verfahren, die per Hand eingefügten Code verwenden, um eine spekulative Vorberechnung zu erleichtern, und Verfahren, die manuell konstruierte Verkettungsausführungs-Slices benutzen. Bei mindestens einer Ausführungsform des Verfahrens 100 wird die mit Cache-Verfehlungen in einem Haupt-Threads assoziierte Latenz durch Verwendung eines gleichzeitigen Helfer-Threads vermindert. Der Helfer-Thread ist ein spekulativer Vorabruf-Thread zur Durchführung eines Speicher-Vorabrufens für den Haupt-Thread. Bei mindestens einer Ausführungsform ist der Helfer-Thread ein SMT-Thread, der durch einen zweiten logischen Prozessor auf demselben physischen Prozessor wie der Haupt-Thread ausgeführt wird. Für Fachleute ist erkennbar, daß das Verfahren 100 in einem beliebigen Multi-Threading-Ansatz verwendet werden kann, einschließlich SMT, Mehrprozessor-Multi-Threading oder beliebiger anderer bekannter Multi-Threading-Ansätze.
Traditionelle Techniken der Software-Programmparallelisierung arbeiten nicht gut bei irregulären oder nicht numerischen Anwendungen, wie zum Beispiel denjenigen, die Zugriffe auf Speicher auf der Basis von verbundenen Listenstrukturen erfordern. In solchen Fällen kann die Speicherstelle, auf die zugegriffen werden soll (z. B. durch eine Ladeanweisung) durch traditionelle Ansätze nicht leicht vorhergesagt werden. Das in 1 dargestellte Verfahren 100 verwendet das Softwareprogramm selbst, um die Adresse für einen Speicherabruf vorherzusagen. Bei mindestens einer Ausführungsform wird das Verfahren 100 von einem Compiler 1208 (12) durchgeführt. Bei einer solchen Ausführungsform repräsentiert das Verfahren 100 einen automatisierten Prozeß, bei dem ein Compiler dynamisch einen Spawn-Punkt (Erzeugungspunkt) für einen Helfer-Thread identifiziert und dynamisch den Helfer-Thread erzeugt, wobei ein Trigger an dem Spawn-Punkt in der Binärdatei des Haupt-Thread eingebettet wird. Der Helfer-Thread wird während eines Nachkompilierungsdurchgangs des Compilers dynamisch (zum Beispiel durch Anhängung) in die Binärdatei integriert. Bei mindestens einer Ausführungsform repräsentiert der Helfer-Thread eine Teilmenge der Anweisungen aus dem IR des gerade kompilierten Softwareprogramms (hier mit der Bezeichnung "Haupt-Thread"). Die Teilmenge von Anweisungen in dem Helfer-Thread ist in der Gestalt, daß der Helfer-Thread einen verringerten Satz von Anweisungen zur Berechnung der Adresse eines zukünftigen Speicherzugriffs in dem Haupt-Thread enthält. Der Helfer-Thread berechnet die Adresse der von dem Haupt-Thread benötigten Daten und ruft die Adresse aus dem Speicher (oder einem Cache auf höherer Ebene) rechtzeitig in eine niedrigere Speicherebene ab, um eine Cache-Verfehlung in dem Haupt-Thread zu verhindern. Wie die folgende Besprechung verdeutlicht, ist es manchmal wünschenswert, den Helfer-Thread zu optimieren, um genug Reserve (Slack) bereitzustellen, damit der Helfer-Thread rechtzeitig ausgeführt werden kann, um eine Cache-Verfehlung in dem Haupt-Thread zu verhindern. Diese Optimierung kann bei einem Ansatz, der hier als "verkettete spekulative Vorberechnung" oder "verkettete SP" bezeichnet wird, die Form zusätzlicher Helfer-Threads annehmen.
1 zeigt, daß das Verfahren 100 eine säumige Anweisung (delinquent instruction) identifiziert 10. Eine säumige Anweisung ist eine Anweisung, die wahrscheinlich während der Laufzeit in dem Cache verfehlen wird, wobei die säumige Anweisung in einer Schleifenstruktur enthalten ist. Das Verfahren berechnet 20 dann einen Anfangs-Slice für die säumige Anweisung. Um den Slice ordnungsgemäß einzuteilen, werden dann ein oder mehrere Ausführungs-Slices erzeugt 25. Das Ausführungs-Slice bzw. die Ausführungs-Slices wird bzw. werden in eine Binärdatei integriert, wie auch ein Trigger, um zu bewirken, daß das Ausführungs-Slice bzw. die Ausführungs-Slices ausgeführt wird bzw. werden, wenn eine erweiterte Binärdatei erzeugt wird 27. Jeder der Blöcke 10 (Identifizieren säumiger Anweisung), 20 (Berechnen des Anfangs-Slice), 25 (Erzeugen des Ausführungs-Slice) und 27 (Erzeugen der erweiterten Binärdatei) wird nachfolgend ausführlicher in Verbindung mit 5, 6, 7 und 8 besprochen.
2 zeigt, daß bei mindestens einer Ausführungsform des in 1 dargestellten Verfahrens 100 während der Ausführung des Verfahrens 100 bestimmte Daten konsultiert werden. 2 zeigt, daß auf eine Zwischenrepräsentation 220 ("IR") und Profil 225 zugegriffen wird, um bei der Identifikation 10 einer säumigen Anweisung zu helfen. Außerdem wird auf einen Steuerflußgraph 230 ("CFG") und Aufrufgraph 224 zugegriffen, um bei der Berechnung 20 des Anfangs-Slice für eine säumige Anweisung zu helfen.
3 zeigt, daß CFG 230, IR 220, das Profil 225 und der Aufrufgraph 224 typischerweise durch einen oder mehrere Kompilierungsdurchgänge 305, 310 vor der Ausführung des Verfahrens 100 erzeugt werden. In 3 ist ein typischer Kompilierungsprozeß 300 repräsentiert. Der Prozeß 300 umfaßt zwei vom Compiler durchgeführte Durchgänge 305, 310 und außerdem einen Testlauf 307, der typischerweise von einem Benutzer, zum Beispiel einem Software-Programmierer, eingeleitet wird. Während eines ersten Durchgangs 305 empfängt der Compiler 1208 (12) als Eingabe den Quellcode 315, für den eine Kompilierung erwünscht ist. Der Compiler erzeugt dann einen instrumentierten Binärcode 320, der dem Quellcode 315 entspricht. Der instrumentierte Binärcode 320 enthält zusätzlich zu der Binärversion für die Anweisungen des Quellcodes 315 zusätzlichen Binärcode, der während eines Ablaufens des instrumentierten Codes 320 bewirkt, daß Statistiken gesammelt und in einem Profil 225 und einem Aufrufgraphen 224 gesammelt und aufgezeichnet werden. Wenn ein Benutzer einen Testlauf 307 des instrumentierten Binärcodes 320 einleitet, werden das Profil 225 und der Aufrufgraph 224 erzeugt. Während des normalen Kompilierungsdurchgangs 310 dient das Profil 225 als Eingabe für den Compiler. Ein solches Profil 225 kann zum Beispiel während des normalen Kompilierungsdurchgangs 310 von dem Compiler verwendet werden, um bei den Verbesserungen der Leistungsfähigkeit, wie zum Beispiel einer spekulativen Verzweigungsvorhersage, zu helfen. Mit dem Profil 225 als Eingabe sowie dem ursprünglichen Quellcode 215 erzeugt der Compiler während des normalen Kompilierungsdurchgangs 310 einen Steuerflußgraphen (CFG) 230 und eine Zwischenrepräsentation (IR) 220 sowie den Binärcode 240 für den Quellcode 315.
Jeder der Durchgänge 305, 310 und der Testlauf 307 sind für das in 1 abgebildete Verfahren 100 in sofern optional, als jedes beliebige Verfahren zum Erzeugen der durch Aufrufgraph 224, Profil 225, CFG 230, IR 220 und Binärcode 240 repräsentierten Informationen verwendet werden kann. Folglich sind der erste Durchgang 305 und der normale Durchgang 310 sowie der Testlauf 307 in 3 gestrichelt abgebildet, um ihre optionale Beschaffenheit anzuzeigen. Für Fachleute ist erkennbar, daß jedes beliebige Verfahren zum Erzeugen der durch Profil 225, CFG 230, IR 220, Binärcode 240 und Aufrufgraph 324 repräsentierten Informationen verwendet werden kann und daß die in 3 abgebildeten Aktionen 305, 307, 310 nur zur Veranschaulichung angegeben sind.
5 zeigt die Identifikation 10 einer säumigen Anweisung. 5 zeigt, daß auf das Profil 225 (2) und IR 220 (2) in den Blöcken 502 bzw. 504 zugegriffen wird. Unter Verwendung dieser Informationen werden Ladeanweisungen identifiziert und es wird bestimmt 506, ob eine bestimmte Ladeanweisung in einer Schleife auftritt. Wenn die Ladeanweisung nicht in einer Schleife auftritt, dann kommt sie nicht für die auf Software basierende spekulative Vorberechnung in Frage und die Verarbeitung für die Ladeanweisung endet 508. Wenn die identifizierte Ladeanweisung in einer Schleife auftritt, wird die Verarbeitung im Block 510 fortgesetzt. Im Block 510 wird bestimmt, ob die Ladeanweisung wahrscheinlich eine Cache-Verfehlung verursacht. Diese Informationen lassen sich zum Beispiel aus dem Profil 225 (2) erhalten, oder aus Hardware-Zählern, die Cache-Verfehlungen während des Testlaufs 307 (3) verfolgen. Im Block 510 werden Ladeanweisungen, die wahrscheinlich eine Cache-Verfehlung verursachen werden, weiter verarbeitet, um zu bestimmen, ob sie eine "Ziel"-Cache-Verfehlung verursachen werden. Eine Ziel-Cache-Verfehlung ist eine antizipierte Cache-Verfehlung, von der erwartet wird, daß sie während der Ausführung einer der Ladeanweisungen in einem Zielsatz von Ladeanweisungen auftreten wird. Der Zielsatz von Ladeanweisungen ist der kleinste Satz von Ladeanweisungen, der mindestens zu einem vorbestimmten Prozentsatz der Cache-Verfehlungen führt, die während eines Laufs des Haupt-Thread antizipiert werden. Bei einer Ausführungsform, bei der der vorbestimmte Prozentsatz 90% beträgt, sind zum Beispiel die Ziel-Ladeanweisungen die Ladeanweisungen, die zu mindestens 90% der während des Testlaufs 307 (3) aufgezeichneten Cache-Verfehlungen beigetragen haben. Wenn im Block 510 keine Ladeanweisung als in dem Zielsatz von Ladeanweisungen befindlich identifiziert wird, dann ist sie kein Kandidat für die auf Software basierende spekulative Vorberechnung und die Verarbeitung für die Anweisung endet im Block 512. Andernfalls wird die Ladeanweisung als eine säumige Ladeanweisung identifiziert (Block 514). Diese Art des Identifizierens 10 einer säumigen Ladeanweisung basiert auf der Beobachtung, daß für viele Softwareprogramme nur eine kleine Anzahl statischer Ladeanweisungen für einen überwiegenden Teil von Cache-Verfehlungen während der Ausführung verantwortlich ist. Das Verfahren 100 verwendet also eine Profil-geführte Kompilierung zum Identifizieren der säumigen Ziel-Ladeoperationen, die Vorabrufgelegenheiten repräsentieren.
4, 6 und 9 sind für eine Erläuterung der Berechnung 20 eines Anfangs-Slice für eine säumige Anweisung relevant. 6 ist ein Flußdiagramm der Berechnung 20 eines Anfangs-Slice für eine säumige Anweisung, die im Block 10 identifiziert wird. Im allgemeinen wird das Slice so berechnet 20, daß es nur die Anweisungen aus dem Haupt-Thread enthält, die notwendig sind, um die durch die säumige Ladeanweisung abzurufende Speicheradresse zu berechnen.
6 wird der Klarheit halber in Verbindung mit einem in 4 und 9 dargestellten Beispiel besprochen. 4A zeigt einen beispielhaften Haupt-Thread-Binärcodeauszug 400 für eine beispielhafte säumige Ladeanweisung und 4C das Abhängigkeitsdiagramm 480 des Slice für die Anweisung. 9 ist ein Blockdiagramm einer beispielhaften Regions-Hierarchie für den Codeauszug von 4A.
Ein durch das Verfahren 100 berechnetes 20 Slice ist der Satz von Anweisungen, der zu der Berechnung der Speicheradresse beiträgt, auf die durch die säumige Ladeoperation zugegriffen werden soll. Mit dem Slice wird ein Helfer-Thread erzeugt, der die Ladedaten spekulativ vorabrufen kann, um eine Cache-Verfehlung in dem Haupt-Thread zu vermeiden. Das Slice ist deshalb eine Teilmenge von Anweisungen aus dem Haupt-Thread. Obwohl das Verfahren 100 hauptsächlich in Verbindung mit Ladeanweisungen verwendet werden kann und dementsprechend hier besprochen wird, ist zu beachten, daß die Nützlichkeit des Verfahrens nicht auf Ladeanweisungen beschränkt ist. Das Verfahren 100 kann dabei helfen, einen Helfer-Thread für eine beliebige Anweisung mit langer Latenz zu erzeugen.
Es können verschiedene Slicing-Ansätze benutzt werden, um zu bestimmen, welche Anweisungen aus dem Haupt-Thread in das Slice für die säumige Ladeanweisung aufgenommen werden sollten. Ein Slice, das zu wenig Reserve (Slack) enthält, führt zu einer Cache-Verfehlung, bevor der Helfer-Thread sein Vorabrufen abschließt, während ein Slice, das zuviel Reserve enthält, zu einer verfrühten Exmission der vorabgerufenen Daten führen kann. Reserve (Slack) ist die Ausführungsdistanz, die z. B. über Maschinenzyklen gemessen wird, zwischen der Ausführung der Vorabrufanweisung in dem Helfer-Thread und der Ausführung der säumigen Ladeanweisung in dem Haupt-Thread. Bei mindestens einer Ausführungsform des Verfahrens 100 wird Reserve für ein Vorabrufen in einem Helfer-Thread genauer folgendermaßen definiert:

Slack (load, prefetch)=timestamp_main (load)
-timestamp_spec (prefetch), wobei timestamp_main (load) und timestamp_spec (prefetch) angeben, wann die säumige Ladeanweisung in dem Haupt-Thread ausgeführt wird bzw. wann das Vorabrufen in dem spekulativen Thread ausgeführt wird. Mit ausreichender Reserve kann das Vorabrufen des Helfer-Thread während der Reserveperiode ausgeführt werden und können die gewünschten Daten in dem Cache ablegt werden, bevor der Haupt-Thread versucht, die Daten abzurufen, wodurch eine Cache-Verfehlung bzw. Cache-Fehler vermieden wird. Zuviel Reserve kann jedoch dazu führen, daß die vorabgerufenen Daten aus dem Cache exmittiert werden, bevor der Haupt-Thread auf sie zugreift.
Bei einem üblichen Slicing-Ansatz wird allen Steuer- und Datenabhängigkeitskanten, die von der gesliceten Ladeanweisung ausgehen, transitiv gefolgt. Ein solcher üblicher Ansatz kann zu unerwünscht großen Slices führen. Im Gegensatz dazu ist das Slicing auf Regionenbasis ein inkrementeller Slicing-Ansatz, der es dem Verfahren 100 ermöglicht, den Reservewert von einer Coderegion zur anderen inkrementell zu erhöhen, wobei von einer inneren Region zu einer äußeren Region übergegangen wird. Der inkrementelle Ansatz des Slicing auf Regionenbasis ermöglicht ein Erhöhen der Reserve in einem Slice, bis das Slice genug Reserve hat, um Cache-Verfehlungen in dem Haupt-Thread zu vermeiden, aber nicht soviel Reserve hat, daß eine verfrühte Cache-Exmission riskiert wird.
6 und 9 zeigen das Slicing auf Regionenbasis, das im Block 608 durchgeführt wird. Bei dem Slicing auf Regionenbasis repräsentiert eine Region eine Schleifenstruktur, eine Prozedur oder einen Schleifenhauptteil. Unter Verwendung von Informationen aus dem CFG 15, auf die im Block 602 zugegriffen wird, erzeugt 604 das Verfahren 100 einen Regionengraph. Ein Regionengraph ist eine hierarchische Programmrepräsentation, die Kanten zur Verbindung einer Parent-Region bzw. Stamm-Region mit ihren Child-Regionen bzw. Sohn-Regionen verwendet. Das heißt, Aufrufer werden mit Aufgerufenen verbunden und zwischen äußerem Umfang und innerem Umfang werden Kanten gezogen.
9 zeigt ein vereinfachtes Diagramm einer Regionenhierarchie 900, die in einem Regionengraph repräsentiert werden könnte. 9 zeigt zum Beispiel eine säumige Ladeanweisung, die als Anweisung C bezeichnet wird, die in eine Schleife fällt. Die Schleife repräsentiert die innerste Region 902 für die säumige Ladeanweisung C. Es ist zu beachten, daß wie oben besprochen nur die Ladeanweisungen, die in einer Schleifenstruktur auftreten, im Block 10 (1) als eine säumige Ladeanweisung identifiziert werden.
Die Schleife wird ihrerseits innerhalb der Prozedur Foo aufgerufen. Die Prozedur Foo repräsentiert eine Zwischenregion 904 für die säumige Ladeanweisung C. Die Prozedur Foo wird ihrerseits durch die Prozedur Bar aufgerufen. Die Prozedur Bar repräsentiert deshalb eine weitere Zwischenregion 906 für die säumige Ladeanweisung C. Die Prozedur Bar wird ihrerseits durch Main aufgerufen. Main repräsentiert die äußere Region 908 für die säumige Ladeanweisung C. Weil Foo auch von der Prozedur Bar 1 aufgerufen wird, die auch durch Main aufgerufen wird, ist zu beachten, daß die Prozedur Bar 1 ebenfalls eine Zwischenregion 910 für die säumige Ladeanweisung C repräsentiert. Da die säumige Ladeanweisung C im Kontext der Prozedur Bar identifiziert wurde, ist die Zwischenregion 910 jedoch eine Außer- Kontext-Region für die säumige Ladeanweisung C.
Wieder mit Bezug auf 6 ist zu sehen, daß das Verfahren 100 außerdem einen Abhängigkeitsgraphen aufbaut 606, der sowohl Steuer- als auch Datenabhängigkeitskanten enthält. 4C zeigt eine Repräsentation 480 eines Abhängigkeitsgraphen. Zur Erläuterung zeigt der Abhängigkeitsgraph 480 den Graphen, der für die säumige Ladeanweisung C aus dem in 4A dargestellten Haupt-Thread-Codeauszug 400 aufgebaut werden könnte. Das heißt, 4C zeigt ein Abhängigkeitsdiagramm 480, das die mit der säumigen Ladeanweisung C assoziierten Abhängigkeitskanten zeigt. Das durch das Abhängigkeitsdiagramm 480 repräsentierte Slice dient zur Erzeugung einer Anzahl von Vorabrufiterationen, und zwar eine für jede Iteration der Schleife 902 (9) in dem Haupt-Thread. Folglich wird die Ladeanweisung C aus dem Haupt-Thread-Codeauszug 400 durch eine Vorabrufanweisung C in dem in 4C gezeigten Slice repräsentiert. In 4C wird das Vorabrufen für die säumige Ladeanweisung als Anweisung C bezeichnet, repräsentieren die durchgezogenen Pfeile Datenabhängigkeitskanten und die gepunkteten Pfeile Steuerabhängigkeitskanten.
Für die zuvor identifizierte säumige Ladeanweisung (siehe Block 10 in 1) identifiziert 608 das Verfahren 100 das Rückwärts-Slice der Ladeadresse in dem Abhängigkeitsgraphen 480, beginnend von der innersten Region, in der die säumige Ladeanweisung in dem Haupt-Thread auftritt. Das Verfahren 100 durchquert den Abhängigkeitsgraphen von der inneren Region zur äußeren Region, wobei das Rückwärts-Slice der Ladeadresse identifiziert 608 wird, bis die mit dem Slice assoziierte Reserve groß genug ist.
Die obige Besprechung eignet sich für eine Charakterisierung, daß Anweisungen von zunehmend größeren Regionen hinzugefügt werden, bis genug Reserve in dem Slice existiert. Es ist jedoch auch eine andere Charakterisierung gültig. Das heißt, um das Slice für eine säumige Ladeanweisung zu erzeugen, werden unnötige Anweisungen aus der Binärversion des Haupt-Thread beseitigt, bis genug Reserve realisiert ist. Zum Beispiel enthält das in 4B und 4C dargestellte Slice nicht die Anweisungen des Haupt-Thread, die in 4A durch Ellipsen repräsentiert werden. Wenn durch Beseitigen von Anweisungen in der innersten Region nicht genug Reserve realisiert werden kann, werden Anweisungen von zunehmend äußeren Regionen beseitigt, bis genug Reserve realisiert ist.
Während ein auf Regionen basierender Slicing-Ansatz dabei hilft, unerwünscht große Slices zu vermeiden, kann er trotzdem unealisierbare Wege enthalten. Dieser Nachteil resultiert aus der Berechnung des Slice als Vereinigungsmenge aller Aussagen in dem Abhängigkeitsgraphen von allen In-Region-Wegen, die die Referenzladeanweisung ohne passende Herein- und Heraus-Parameter-Bindungen erreichen.
Um dieses Ungenauigkeitsproblem zu behandeln, verwendet mindestens eine Ausführungsform des Verfahrens 100 einen Kontextabhängigen Slicing-Ansatz zum Identifizieren 608, 610 von Anweisungen in dem Slice für eine säumige Ladeoperation. Auf diese Weise werden bei Verwendung des auf Regionen basierenden Slicing-Ansatzes keine Außer-Kontext-Anweisungen in das berechnete 608 Slice aufgenommen. Zusätzlich wird das Slice im Block 610 so berechnet, daß es Im-Kontext-Anweisungen außerhalb der äußersten Region enthält, die als Ergebnis des auf Regionen basierenden Slicing im Block 608 identifiziert werden. Ein Kontextabhängiges Slice einer Referenzanweisung r in bezug auf einen aufrufenden Kontext C wird folglich folgendermaßen erzeugt:
In Gl. 1 seien C = [c₁,..., c_n] die Aufruforte, die sich gerade auf einem (nicht gezeigten) Aufrufstapel befinden, der während der Ausführung des Verfahrens 100 geführt wird, wobei c_n das Element an der obersten Position des Aufrufstapels und F die Teilmenge der formalen Parameter der Prozedur, von denen r abhängt, ist. Die Funktion contextmap(f, c) gibt den tatsächlichen Parameter zurück, der zu einer formalen Variablen f an dem Aufrufort c weitergegeben wird. Slice(r/⌀) repräsentiert die Menge von Anweisungen, die gefunden wird, indem die Abhängigkeitskanten rückwärts in der Prozedur, in der sich r und seine Aufrufer befinden, transitiv durchquert werden. Kurzgefaßt, baut die Berechnung eines Kontextabhängigen Slice das Slice nur bis zu der Kette von Aufrufen auf dem Aufrufstapel auf, wodurch die Größe des Slice verringert wird. Um kleinere Slices zu erzeugen, ignoriert das Verfahren 100 außerdem schleifengeführte Anti-Abhängigkeiten und Ausgangsabhängigkeiten. In den Blöcken 608 und 610 wird der Kontextabhängige Slicing-Ansatz in Verbindung mit dem auf Regionen basierenden Slicing angewandt, um ein Kontextabhängiges Slice für die säumige Ladeoperation zu bestimmen, wobei das Slice eine gewünschte Menge an Reserve aufweist.
Im Block 612 stellt das Verfahren 100 sicher, daß keine Speicheranweisungen in dem Slice enthalten sind. Für Fachleute ist erkennbar, daß der Ausschluß von Speicheranweisungen zeitlich nicht nach dem auf Regionen basierenden und Kontextabhängigen Slicing auftreten muß und in einer beliebigen Reihenfolge in Bezug auf die Blöcke 608 und 610 durchgeführt werden kann.
2 und 6 zeigen, daß im Block 614 eine weitere Slicing-Optimierung durchgeführt wird. Im Block 614 führt das Verfahren 100 ein spekulatives Steuerfluß-Slicing durch, um unausgeführte Wege und unrealisierte Aufrufe herauszufiltern. Bei mindestens einer Ausführungsform der Slice-Berechnung 20 werden unter Verwendung des Aufrufgraphen 224 unausgeführte Wege und unrealisierte Aufrufe hervorgesagt. Wie bereits erläutert, besteht mindestens eine An und Weise der Erzeugung eines Aufrufgraphen 224 darin, alle indirekten prozeduralen Aufrufe so zu instrumentieren, daß sie während eines Testlaufs 307 (3) in dem Aufrufgraphen 224 erfaßt werden. Während des spekulativen Slicing 614 werden unausgeführte Wege und unrealisierte Aufrufe, wie durch Verwendung des Aufrufgraphen 224 vorhergesagt, aus dem Anfangs-Slice herausgefiltert.
Obwohl der Einfachheit halber die Berechnung 20 eines Anfangs-Slice in Verbindung mit einer einzigen säumigen Ladeanweisung besprochen wurde, ist das Verfahren 100 diesbezüglich nicht beschränkt. Zum Beispiel kann die Berechnung 20 von Slices während einer einzigen Nachdurchgangsiteration des Verfahrens 100 für jede säumige Ladeanweisung durchgeführt werden, die als Teil der Zielmenge von Ladeanweisungen identifiziert 10 wird.
4C und 7 zeigen die Erzeugung 25 eines Ausführungs-Slice, das hier auch als Vorberechnungs-Slice ("p-Slice") bezeichnet wird. 4C repräsentiert ein Anfangs-Slice für eine Ladeanweisung C, wobei das Slice durch einen Abhängigkeitsgraphen 480 repräsentiert wird. 4C zeigt, daß die Anweisung C in einer Schleife auftritt. Anweisungen in einer Vorabrufschleife können iterativ ausgeführt werden, um Daten für jede Iteration der ursprünglichen Schleife in dem Haupt-Thread vorabzurufen. Im Fall des in 4C dargestellten Abhängigkeitsgraphen 480 werden die Anweisungen A, B, C und D in mehreren Iterationen ausgeführt, bis der Wert der Variablen arc nicht weniger als K beträgt.
Die Erzeugung 25 des Ausführungs-Slice ("p-Slice") umfaßt also die Erzeugung mehrerer Iterationen der Anweisungen in dem Slice. Folglich umfaßt die Erzeugung 25 des p-Slice außerdem eine Einteilungskomponente (scheduling component) zum Bestimmen, wie jede Iteration des Slice ausgeführt werden soll. Bei der Erzeugung von p-Slice(s) berücksichtigen Einteilungsaspekte eine Kommunikation zwischen Threads, um eine rechtzeitige Vorausführung der p-Slices in Bezug auf den Haupt-Thread zu gewähren. Das heißt, es ist nützlich, ansonsten unbenutzte Hardware-Thread-Kontexte auszunutzen, um Vorabrufoperationen, die Cache-Verfehlungs-Latenzen in dem Haupt-Thread reduzieren, rechtzeitig einzuteilen.
7 zeigt, daß mindestens zwei Einteilungsmechanismen für p-Slice-Iterationen betrachtet werden können. Ein erster Ansatz, der hier als einfache spekulative Vorberechnung ("einfache SP") bezeichnet wird, erzeugt 704 ein einziges p-Slice, das sukzessive serielle Schleifeniterationen der Slice-Anweisungen enthält. Ein zweiter Ansatz, der hier als spekulative Verkettungs-Vorberechnung ("Verkettungs-SP") bezeichnet wird, erzeugt 714 mehrere p-Slices zur Ausführung der Slice-Iterationen. Jeder der beiden Einteilungsansätze wird unmittelbar nachfolgend ausführlicher besprochen.
Bei dem einfachen SP-Ansatz wird ein einziges p-Slice erzeugt. Bei mindestens einer Ausführungsform wird erwartet, daß das p-Slice durch einen einzigen Vorabruf-Thread ausgeführt wird. Folglich enthält das bei dem einfachen SP-Ansatz erzeugte p-Slice 704 serielle Anweisungen für die sukzessiven Slice-Iterationen. 7 zeigt, daß das Verfahren 100 bestimmt 702, ob einfache SP geeignet ist, indem ausgewertet wird, ob eine sequenzielle Ausführung der Vorabrufschleife genug Reserve zur Vermeidung von Cache-Verfehlungen in dem Haupt-Thread ergibt. Wenn dies der Fall ist, wird ein einziges Mehrfachiterations-Slice erzeugt 704. Andernfalls wird in den Blöcken 706 bis 714 Verkettungs-SP durchgeführt.
7, 10 und 11 sind für eine weitere Besprechung von Verkettungs-SP relevant. 10 zeigt mehrere verkettete p-Slices 1020, 1040. Verkettungs-SP erfaßt ein Erzeugen und Einteilen verketteter p-Slices 1020, 1040, wodurch es möglich wird, mindestens bis zu einem gewissen Grad zur selben Zeit den Unterbrechungs-Kostenfaktor (stall penalty) für sukzessive Vorabrufvorgänge zu bezahlen. Das heißt, es besteht mindestens eine gewisse Überlappung der mit Speichervorabrufvorgängen assoziierten Unterbrechungen (stalls) in den verketteten Threads 1020, 1040 einer Do-Across-Schleife.
Beim Erzeugen und Einteilen der verketteten Threads einer Do-Across-Schleife ist es effizient, die Verkettungs-Threads so einzuteilen, daß die nächste verkettete Iteration erst dann erzeugt (spawned) wird, nachdem das aktuelle p-Slice die Werte berechnet hat, die das nächste p-Slice benötigt. Das Einteilen verketteter spekulativer Threads bei der Erzeugung 27 von p-Slices wird somit erleichtert, indem die Verzögerungen zwischen den p-Slices für eine gegebene Gruppe von Abhängigkeiten verringert werden. Kleinere Verzögerungen führen zu größeren Reservewerten.
7 und 11 zeigen, daß mindestens ein Ansatz zur Erzielung einer Verzögerungsreduktion zwischen spekulativen p-Slices darin besteht, einen Abhängigkeitsgraphen gemäß eines Schemas "stark verbundener Komponenten" ("SCC") zu partitionieren 706. In einem stark verbundenen Subgraphen existiert ein Weg von jedem beliebigen Knoten zu jedem anderen beliebigen Knoten in dem Subgraphen. Ferner wird der SCC-Subgraph als der maximale stark verbundene Subgraph in dem Abhängigkeitsdiagramm definiert. Zum Beispiel zeigt 11 die stark verbundenen Komponenten in dem Abhängigkeitsgraphen 408 (4C) für ein beispielhaftes Slice. 11 zeigt, daß die Anweisungen A, D und E aus dem Abhängigkeitsgraphen 480 (4C) zu einem einzigen SCC-Knoten 1102, 1108 vereinigt werden. Die Pfeile in 11 repräsentieren Abhängigkeitskanten. Folglich kann man aus 11 sehen, daß SCC-Portionierung Zyklen in dem Abhängigkeitsgraphen strafft. Die einzelnen Anweisungsknoten 1106, 1110, 1112 und 1114 werden als degenerierte SCC-Knoten bezeichnet. In 11 repräsentieren die Anweisungen B und C degenerierte SCC-Knoten 1106, 1110, 1112, 1114, weil sie nicht Teil eines Abhängigkeitszyklus sind.
Das Auftreten eines nicht degenerierten SCC-Knotens, wie zum Beispiel des Knotens 1102 in dem Abhängigkeitsgraphen 480 (4C) zeigt die Existenz eines oder mehrerer Abhängigkeitszyklen an, wodurch die Existenz von schleifengeführten Abhängigkeiten impliziert wird.
Bei einer schleifengeführten Abhängigkeit verwendet eine spätere Iteration der Schleife einen Wert, der als Live-in-Wert bezeichnet wird, der durch eine vorherige Iteration der Schleife bestimmt wird. (Im Gegensatz dazu berechnet ein degenerierter SCC-Knoten keine Live-in-Werte für den nächsten Verkettungs-Thread).
10 und 11 zeigen die Plazierung von Spawning-Triggern für verkettete p-Slices, um die klare Auflösung von schleifengeführten Abhängigkeiten einzuteilen. Ein spekulativer Thread, der eine Vorabrufschleifeniteration ausführt (wie zum Beispiel die 1020, 1040, die in 10 dargestellt sind), löst die schleifengeführte Abhängigkeit in einem Abhängigkeitszyklus auf, bevor dem nächsten Verkettungs-Thread erlaubt wird, mit der Ausführung desselben Abhängigkeitszyklus in der nächsten spekulativen Vorabrufiteration zu beginnen. Diese Einteilungsnebenbedingung wird durch entsprechende Einbettung von Spawning-Triggern in die verketteten p-Slices auferlegt. Die Einbettung von Spawning-Triggern wird nachfolgend ausführlicher in Verbindung mit 8 besprochen.
11 zeigt, daß die Anweisungen in einem nicht degenerierten SSC-Knoten 1102 deshalb Anweisungen des Slice bilden, die insofern kritisch sind, als sie durchgeführt werden, bevor das nächste Verkettungs-Slice gespawned wird, um schleifengeführte Abhängigkeiten aufzulösen. Ähnlich sind degenerierte SCC-Knoten, wie zum Beispiel die Anweisungen B und C, insofern nicht kritisch, als sie keine Live-in-Werte für spätere Iterationen der Schleife berechnen und deshalb gleichzeitig mit den späteren Iterationen ausgeführt werden können. Bestimmte nachfolgend besprochene Techniken 710, 712 zur Abhängigkeitsreduktion helfen dabei, die Berechnung weiter in nicht kritische Sub-Slices zu schieben.
Nunmehr mit Bezug auf 7, 10 und 11 für eine weitere Besprechung der Einteilung für p-Slices ist es ersichtlich, daß im Block 708 eine Vorwärts-Zyklus-Einteilung durchgeführt wird. Bei mindestens einer Ausführungsform ist der als Ergebnis der Partitionierung im Block 706 erzeugte partitionierte Graph ein gerichteter azyklischer Graph ("DAG"). Das heißt, es gibt von keinem SCC-Knoten aus einen Weg zurück zu sich selbst. Zum Beispiel zeigt 11, daß, solange ein Spawning nach den Anweisungen in dem nicht degenerierten SCC-Knoten 1102 auftritt, die Anweisung D von dem durch Anweisung A in der vorherigen Iteration berechneten Wert abhängt. Wie für Fachleute erkennbar ist, kann ein DAG gemäß einem Listeneinteilungsalgorithmus eingeteilt werden. Bei mindestens einer Ausführungsform wird der als Ergebnis der Partitionierung im Block 706 erzeugte DAG gemäß einem Vorwärtszy klus-Einteilungsansatz mit maximalen kumulativen Kostenheuristiken eingeteilt 708. Da die Heuristiken die Kosten oder Latenz für jeden Weg akkumulieren, wird dem Knoten mit längerer Latenz zu den Astknoten des Slice eine höhere Priorität gegeben. Wenn zwei Knoten dieselben Kosten aufweisen, wird dem Knoten mit der niedrigeren Anweisungsadresse in der ursprünglichen Binärversion des Haupt-Thread eine höhere Priorität gegeben. Schließlich werden die Anweisungen in jedem nicht degenerierten SCC durch Ignorieren der schleifengeführten Abhängigkeitskanten listeneingeteilt. Der resultierende Binärcode 1104 für ein Verkettungs-p-Slice für das in 4 gezeigte Beispiel ist in 11 dargestellt.
Viele Do-Across-Schleifen können schleifengeführte Abhängigkeiten enthalten. Bei der Einteilung der verketteten spekulativen Threads 1020, 1040 berücksichtigt das Verfahren 100 die Synchronisation zwischen Threads durch Reduzieren der Anzahl solcher Abhängigkeiten. 7 zeigt, daß zwei Abhängigkeits-reduktionsoperationen 710, 712 durchgeführt werden. Bei der ersten solchen Operation 710 wird Schleifenrotation an den Iterationen der Vorabrufschleife durchgeführt. Bei der zweiten Abhängigkeitsoperation 712 wird an den Iterationen der Vorabrufschleife eine Bedingungsprädiktion durchgeführt. Jede Abhängigkeitsreduktionsoperation 710, 712 wird später ausführlicher beschrieben.
Im Block 710 wird an den Iterationen der Vorabrufschleife eine Schleifenrotation durchgeführt. Eine Schleifenrotation verringert die schleifengeführte Abhängigkeit von der untersten Position des Slice in einer Iteration bis zur obersten Position des Slice in der nächsten Iteration. Die Umordnung des Codes für das p-Slice beeinflußt den Haupt-Thread nicht, da der spekulative Thread einen anderen Binärcode als der Haupt-Thread ausführt. Die Schleifenrotation 710 macht eine neue Schleifengrenze aus, die rückwärtige schleifengeführte Abhängigkeiten in wahre Intra-Iterations-Abhängigkeiten umsetzt. Natürlich führt die neue Schleifengrenze selbst keine neuen schleifengeführten Abhängigkeiten ein. Da schleifengeführte Anti-Abhängigkeiten und Ausgangsabhängigkeiten (die als schleifengeführte "Falsch-Abhängigkeiten" bezeichnet werden) beim Einteilen des Verkettungs-SP-Codes während der Erzeugung 27 der p-Slices ignoriert werden, kann eine Verschiebung der Schleifengrenze mehr Parallelismus für Verkettungs-SP freilegen.
Ein weiterer Ansatz zur Verringerung von Abhängigkeiten ist Bedingungsprädiktion 712. Der Klarheit halber wird Bedingungsprädiktion 712 hier in Verbindung mit 7 und 11 besprochen. Bedingungsprädiktion umfaßt die Verwendung von Prädiktionstechniken an bestimm ten Konditionalausdrücken in dem Slice. Man denke zum Beispiel an den p-Slice-Code 1104, der in 11 dargestellt ist. Die Konditionalanweisung E hängt von dem in der Anweisung D erzeugten Inter-Schleifen-Wert ab. Das heißt, die Anweisung E hängt von dem Wert der Variable arc (wertvollen Bogens) ab, wie in der Anweisung D bestimmt. Um die Anzahl von Anweisungen in einem kritischen Sub-Slice zu verringern, könnte man die Konditionaloperation in der Anweisung E immer als True vorhersagen. In einem solchen Fall verschwindet die Abhängigkeitskante zwischen den Anweisungen D und E und die Anweisung E kann deshalb aus dem kritischen Sub-Slice heraus und in das nicht kritische Sub-Slice verlegt werden. Effektiv kann die Anweisung E nach dem Spawn-Punkt durchgeführt werden, sobald ihre Abhängigkeitskante über Konditions-prädiktion 712 beseitigt wurde. Das Ergebnis ist ein höherer Parallelismus auf Thread-Ebene, der mehr Reserve ergeben kann.
In der Operation 716 werden die mehreren p-Slices für die Verkettungs-SP-Vorabrufiterationen erzeugt, um eine spekulative Do-Across-Vorabrufschleife zu implementieren. Die p-Slices enthalten Binärcode, wie während der Ausführung der Blöcke 706, 708, 710 und 712 bestimmt und optimiert. Für Fachleute ist erkennbar, daß die Schleifenrotation 710 und die Konditionsprädiktion 712 Optimierungen sind, die für die Ausübung des Verfahrens 100 nicht notwendig sind. Eine dieser Optimierungen oder beide können beseitigt werden oder können in einer anderen Reihenfolge als in 7 dargestellt durchgeführt werden.
Außerdem können die im Block 714 erzeugten p-Slices außerdem Synchronisationscode enthalten. Der Zweck des Synchronisationscodes besteht darin, Threads, die schleifengeführte Abhängigkeiten enthalten, aufzusynchronisieren, so daß ein Thread, der einen Wert benutzt, der in einem früheren Thread berechnet wird, aufsynchronisiert wird und auf rechtzeitige und effiziente Weise mit dem früheren Thread kommuniziert. Die Plazierung von Synchronisationscode in den p-Slices für Verkettungs-SP bestimmt deshalb den Grad an Parallelismus auf Thread-Ebene und das Synchronisations-Overhead. Wenn es zum Beispiel mehr als einen nicht degenerierten SCC-Knoten in dem p-Slice gibt, wobei keine Synchronisationskosten angenommen werden, kann die Synchronisation über Verkettungs-Threads hinweg nach der Ausführung jedes nicht degenerierten SCC-Knotens zu kürzeren Verzögerungen über die Threads führen als das einmalige Synchronisieren nachdem alle nicht degenerierten SCC-Knoten ausgeführt wurden. Der erstere Ansatz erfordert jedoch mehr Fälle von Handshaking und die Implementierung schnellerer Snychronisationshardware. Bei einer Ausführungsform des Verfahrens 100 werden das Snychronisations-Overhead und Hardware-Support-Anforderungen verringert, indem nur eine Punkt-zu-Punkt-Kommunikation zwischen Threads erlaubt wird. Im Block 714 wird folglich zu den mehreren Verkettungs-p-Slices Synchronisationscode hinzugefügt, so daß Threads synchronisiert werden, nachdem die nicht degenerierten SCC-Knoten ausgeführt wurden. Folglich werden Live-in-Werte an den Spawn-Punkt weitergegeben. Bei mindestens einer Ausführungsform ermöglicht der in das p-Slice in Block 714 eingebettete Synchronisationscode ein Kopieren von Live-in-Werten in einem Puffer, der dem spekulativen Thread zugänglich ist, der Zugang zu dem Live-in-Wert ersucht.
8 zeigt die Erzeugung 27 einer erweiterten Binärdatei ausführlicher. Im allgemeinen werden die, wie oben in Verbindung mit 7 besprochen, erzeugten p-Slice(s) an das Ende der Haupt-Thread-Binärversion angehängt, wenn eine erweiterte Binärdatei erzeugt wird 27. Für Fachleute ist erkennbar, daß das p-Slice bzw. die p-Slices an beliebiger Stelle in der Haupt-Thread-Binärdatei integriert werden können und nicht unbedingt an das Ende der Haupt-Thread-Binärdatei angehängt werden muß bzw. müssen. Zusätzlich wird ein Laufzeittrigger in die Binärdatei eingebettet, so daß die p-Slices an einem entsprechenden Punkt während der Ausführung des Haupt-Thread ausgeführt werden.
Insbesondere zeigt 8, daß ein Spawning-Punkt als ein Punkt in dem Haupt-Thread identifiziert 802 wird, an dem der Vorabruf-Thread bzw. die Vorabruf-Threads gespawned werden sollten. Der Spawn-Punkt wird durch Durchqueren des Abhängigkeitsgraphen identifiziert 802. Das Verfahren 100 versucht, Triggerpunkte in dem Haupt-Thread zu finden, die genug Reserve sicherstellen würden, während die Kommunikation zwischen dem Haupt-Thread und dem spekulativen Thread bzw. den spekulativen Threads minimiert wird. Der Trigger wird an dem identifizierten Spawn-Punkt im Block 804 eingebettet.
Für einfaches SP verursacht ein (hier als Trigger bezeichnetes) Laufzeitereignis, das an dem identifizierten Spawn-Punkt eingebettet 804 wird, die Ausführung eines einzigen p-Slice. Es müssen keine weiteren Trigger identifiziert werden, weil einfaches SP nicht gewährleistet, daß ein spekulativer Thread einen anderen spekulativen Thread spawned; einfaches SP verwendet nur einen spekulativen Thread. Im Gegensatz dazu erfordert Verkettungs-SP Identifikation von Spawn-Punkten in mehreren verketteten Helfer-Threads. Wie einfaches SP verursacht die Einbettung 804 eines Triggers an dem identifizierten Spawn-Punkt die Ausführung des ersten verketteten p-Slice. Wie oben in Verbindung mit 7 besprochen, werden Spawn-Punkte für verkettete Threads identifiziert, wenn p-Slices für mehrere Verkettungs-p-Slices erzeugt 25 werden; die oben besprochenen Einteilungsgesichtspunkte helfen dabei, Verkettungs-Trigger früh zwischen mehreren Threads einzuteilen. Während der p-Slice-Erzeugung 25 wird in jeden (mit Ausnahme des letzten) Verkettungs-Thread an dem identifizierten Spawn-Punkt (zusätzlich zu dem in dem Haupt-Thread im Block 804 eingebetteten Trigger) ein Trigger eingebettet.
Im Block 808 werden die p-Slice(s) in die Binärdatei integriert, um eine erweiterte Binärdatei zu erzeugen. Bei mindestens einer Ausführungsform enthält die erweiterte Binärdatei folgendes: 1) die Anweisungen aus einer Binärdatei 240, die zum Beispiel durch einen normalen Kompilierungsdurchgang 310 erzeugt wird; sowie 2) einen Trigger in dem Haupt-Thread und 3) mindestens ein an das Ende der Binärdatei angehängtes p-Slice. Zusätzlich enthält für verkettete SP die erweiterte Binärdatei außerdem zusätzliche p-Slices für die Ketteniterationen der Do-Across-Schleife.
Zusammengefaßt, wurde ein Verfahren zum dynamischen Anpassen einer Binärdatei zur Durchführung einer spekulativen Vorberechnung beschrieben. Eine Ausführungsform des Verfahrens wird durch einen Compiler durchgeführt, der dynamisch zu Zieloperationen führende Anweisungen extrahiert, ordnungsgemäße Spawn-Punkte identifiziert, die Kommunikation zwischen Threads verwaltet und eine erweiterte Binärdatei erzeugt. Mindestens eine Ausführungsform des Verfahrens wird als Nachkompilierungsdurchgang des Compilers durchgeführt, so daß es den normalen Kompilierungsprozeß nicht stört.
In der vorausgehenden Beschreibung wurden verschiedene Aspekte der dynamischen Nachdurchgangserzeugung einer erweiterten Binärdatei für die auf Software basierende spekulative Vorberechnung beschrieben. Zur Erläuterung wurden spezifische Zahlen, Beispiele, Systeme und Konfigurationen angegeben, um ein sorgfältigeres Verständnis zu ermöglichen. Für Fachleute ist jedoch erkennbar, daß das beschriebene Verfahren ohne die spezifischen Einzelheiten ausgeübt werden kann. In anderen Fällen wurden wohlbekannte Merkmale ausgelassen oder vereinfacht, um das Verfahren nicht zu verdecken.
Ausführungsformen des Verfahrens können in Hardware, Software, Firmware oder einer Kombination solcher Implementierungsansätze implementiert werden. Ausführungsformen der Erfindungen können jedoch als Computerprogramme implementiert werden, die auf pro grammierbaren Systemen ausgeführt werden, die mindestens einen Prozessor, ein Datenspeichersystem (einschließlich flüchtigen und nicht flüchtigen Speichers und/oder Speicherelementen), mindestens ein Eingabegerät und mindestens ein Ausgabegerät enthalten. Programmcode kann auf Eingangsdaten angewandt werden, um die hier beschriebenen Funktionen durchzuführen und Ausgangsinformationen zu erzeugen. Die Ausgangsinformationen können auf bekannte Weise an ein oder mehrere Ausgabegeräte angelegt werden. Für die Zwecke der vorliegenden Anmeldung enthält ein Verarbeitungssystem ein beliebiges System mit einem Prozessor, wie zum Beispiel einem digitalen Signalprozessor (DSP), einer Mikrosteuerung, einer anwendungsspezifischen integrierten Schaltung (ASIC) oder einem Mikroprozessor.
Die Programme können in einer prozeduralen oder objektorientierten Programmiersprache auf hoher Ebene implementiert werden, um mit einem Verarbeitungssystem zu kommunizieren. Die Programme können auch gegebenenfalls in Assembler- oder Maschinensprache implementiert werden. Tatsächlich ist der Schutzumfang des hier beschriebenen dynamischen Verfahrens nicht auf irgendeine bestimmte Programmiersprache beschränkt. In jedem Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Die Programme können auf einem Speichermedium oder -gerät gespeichert werden (z. B. Festplattenlaufwerk, Floppy-Laufwerk, Nur-Lese-Speicher (ROM), CD-ROM-Gerät, Flash-Speichergerät, Digital Versatile Disk (DVD) oder ein anderes Speichergerät), das durch ein allgemeines oder spezialisiertes programmierbares Verarbeitungssystem lesbar ist. Die einem Prozessor in einem Verarbeitungssystem zugänglichen Anweisungen ermöglichen ein Konfigurieren und Betreiben des Verarbeitungssystems, wenn das Speichermedium oder -gerät durch das Verarbeitungssystem gelesen wird, um die hier beschriebenen Prozeduren durchzuführen. Ausführungsformen der Erfindung können auch als ein maschinenlesbares Speichermedium implementiert betrachtet werden, das für die Verwendung mit einem Verarbeitungssystem konfiguriert ist, wobei das so konfigurierte Speichermedium bewirkt, daß das Verarbeitungssystem auf eine spezifische und vordefinierte Weise arbeitet, um die hier beschriebenen Funktionen durchzuführen.
12 zeigt ein Beispiel für eine solche Art von Verarbeitungssystem. Das beispielhafte System 1200 kann zum Beispiel zur Ausführung der Verarbeitung für ein Verfahren zur dynamischen Erzeugung einer erweiterten Binärdatei für die auf Software basierende spekulati ve Vorberechnung, wie zum Beispiel die hier beschriebenen Ausführungsformen, verwendet werden. Das beispielhafte System 1200 kann außerdem gemäß mindestens einer Ausführungsform der hier beschriebenen Verfahren erzeugte erweiterte Binärdateien ausführen. Das beispielhafte System 1200 repräsentiert Verarbeitungssysteme auf der Basis der Mikroprozessoren Pentium^®, Pentium^® Pro, Pentium^® II, Pentium^® III, Pentium^® 4 und Itanium^® und Itanium^® II, die von der Intel Corporation erhältlich sind, obwohl auch andere Systeme verwendet werden können (einschließlich PCs (Personal Computers) mit anderen Mikroprozessoren, technische Workstations, Set-Top-Boxes und dergleichen). Bei einer Ausführungsform kann das beispielhafte System 400 eine Version des von der Microsoft Corporation erhältlichen Betriebssystems WINDOWS^TM ausführen, obwohl zum Beispiel auch andere Betriebssysteme und graphische Benutzeroberflächen benutzt werden können.
Mit Bezug auf 12 enthält das beispielhafte Verarbeitungssystem 1200 ein Speichersystem 1202 und einen Prozessor 1204. Das Speichersystem 1202 kann Anweisungen 1210 und Daten 1212 zur Steuerung der Funktionsweise des Prozessors 1204 speichern. Zum Beispiel können die Anweisungen 1210 ein Compiler-Programm 1208 enthalten, das, wenn es ausgeführt wird, bewirkt, daß der Prozessor 1204 ein (nicht gezeigtes) Programm, das in dem Speichersystem 1202 verankert ist, kompiliert. Der Speicher 1202 hält das zu kompilierende Programm, Zwischenformen des Programms und ein resultierendes kompiliertes Programm. Bei mindestens einer Ausführungsform enthält das Compiler-Programm 1208 Anweisungen, die bewirken, daß der Prozessor 1204 dynamisch eine erweiterte Binärdatei für das Programm erzeugt, um so eine auf Software basierende spekulative Vorberechnung zu ermöglichen. Bei einer solchen Ausführungsform können die Anweisungen 1210 außerdem eine gemäß mindestens einer Ausführungsform der vorliegenden Erfindung erzeugte erweiterte Binärdatei enthalten.
Das Speichersystem 1202 ist als verallgemeinerte Repräsentation von Speicher gedacht und ' kann vielfältige Formen von Speicher enthalten, wie zum Beispiel eine Festplatte, CD-ROM, Direktzugriffsspeicher (RAM), dynamischen Direktzugriffsspeicher (DRAM), statischen Direktzugriffsspeicher (SRAM) und diesbezügliche Schaltkreise. Das Speichersystem 1202 kann Anweisungen 1210 und/oder Daten 1212 speichern, die durch Datensignale repräsentiert werden, die durch den Prozessor 1204 ausgeführt werden können. Die Anweisungen 1210 und/oder Daten 1212 können Code zur Durchführung beliebiger oder aller der hier besprochenen Techniken enthalten. Mindestens eine Ausführungsform der dynamischen Nach durchgangs-Binärerweiterung für die auf Software basierende spekulative Vorberechnung betrifft die Verwendung des Compilers 1208 in dem System 1200, um zu bewirken, daß der Prozessor 1204 dynamisch eine erweiterte Binärdatei wie oben besprochen erzeugt.
Genauer gesagt zeigen 1, 5 und 12, daß der Compiler 1208 ein Identifizierermodul 1220 enthalten kann, das, wenn es durch den Prozessor 1204 ausgeführt wird, eine säumige Anweisung, wie oben in Verbindung mit 1 und 5 beschrieben, identifiziert 10. Der Compiler 1208 kann außerdem ein Anfangs-Slicer-Modul 1222 enthalten, das, wenn es durch den Prozessor 1204 ausgeführt wird, ein Anfangs-Slice, wie oben in Verbindung mit 1 und 6 beschrieben, berechnet 20. Der Compiler 1208 kann außerdem ein Ausführungs-Slicer-Modul enthalten, das, wenn es durch den Prozessor 1204 ausgeführt wird, Ausführungs-Slice(s), wie oben in Verbindung mit 1 und 7 beschrieben, erzeugt 25. Außerdem kann der Compiler 1208 ein Codegeneratormodul 1226 enthalten, das, wenn es durch den Prozessor 1204 ausgeführt wird, eine erweiterte Binärdatei, wie oben in Verbindung mit 1 und 8 beschrieben, erzeugt 27.
Obwohl konkrete Ausführungsformen der vorliegenden Erfindung gezeigt und beschrieben wurden, ist für Fachleute ersichtlich, daß Änderungen und Modifikationen vorgenommen werden können, ohne von der vorliegenden Erfindung in ihren allgemeineren Aspekten abzuweichen. Die angefügten Ansprüche sollen in ihrem Schutzumfang alle solchen Änderungen und Modifikationen, die in den wahren Schutzumfang der vorliegenden Erfindung fallen, umfassen.
Zusammenfassung
Die mit Cache-Verfehlungen oder anderen Anweisungen mit langer Latenz in einem Haupt-Thread assoziierten Latenzen werden durch Verwendung eines gleichzeitigen Helfer-Thread vermindert. Der Helfer-Thread ist ein spekulativer Vorabruf-Thread zur Durchführung eines Speicher-Vorabrufvorgangs für den Haupt-Thread. Die Anweisungen für den Helfer-Thread werden dynamisch während eines Nachdurchgangsbetriebs eines Compilers in die Haupt-Thread-Binärversion integriert.

Claims

Verfahren zum Kompilieren eines Softwareprogramms, mit den folgenden Schritten: Identifizieren einer säumigen Anweisung; Identifizieren eines Anfangs-Slice für die säumige Anweisung; dynamisches Erzeugen eines Ausführungs-Slice auf der Basis des Anfangs-Slice; und dynamisches Erzeugen einer erweiterten Binärdatei, die das Ausführungs-Slice enthält.
Verfahren nach Anspruch 1, wobei das dynamische Erzeugen der erweiterten Binärdatei ferner folgendes umfaßt: dynamisches Identifizieren eines Spawning-Punkts in einer Haupt-Thread-Binärdatei; und dynamisches Einbetten eines Triggers an dem Spawning-Punkt, wobei der Trigger dem Ausführungs-Slice entspricht.
Verfahren nach Anspruch 1, wobei das dynamische Erzeugen der erweiterten Binärdatei weiterhin ein dynamisches Integrieren des Ausführungs-Slice in eine Haupt-Thread-Binärdatei umfaßt.
Verfahren nach Anspruch 2, wobei das dynamische Erzeugen eines Ausführungs-Slice ferner ein dynamisches Erzeugen einer Vielzahl verketteter Ausführungs-Slices umfaßt, wobei die Vielzahl ein erstes verkettetes Ausführungs-Slice enthält; und das dynamische Einbetten eines Triggers an dem Spawning-Punkt ferner das dynamische Einbetten eines Triggers, der dem ersten verketteten Ausführungs-Slice entspricht, an dem Spawning-Punkt umfaßt.
Verfahren nach Anspruch 1, wobei das Identifizieren eines Anfangs-Slice weiterhin folgendes umfaßt: Identifizieren einer Anweisung in einer Haupt-Thread-Binärdatei, wobei die identifizierte Anweisung zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll.
Verfahren nach Anspruch 1, wobei das Identifizieren eines Anfangs-Slice weiterhin folgendes umfaßt: Identifizieren einer Vielzahl von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die identifizierten Anweisungen zur Berechnung einer Speicheradresse verwendet werden, auf die durch die säumige Anweisung zugegriffen werden soll.
Verfahren nach Anspruch 1, wobei das Identifizieren eines Anfangs-Slice weiterhin folgendes umfaßt: Identifizieren einer Übermenge von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die Übermenge von Anweisungen in einer Schleife der Haupt-Thread-Binärdatei auftritt, wobei die säumige Anweisung in der Schleife auftritt; Verwerfen einer Anweisung der Übermenge, wobei die verworfene Anweisung nicht zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll; und Identifizieren der übrigen Anweisungen der Übermenge als das Anfangs-Slice.
Verfahren nach Anspruch 6, wobei das Identifizieren einer Vielzahl von Anweisungen weiterhin folgendes umfaßt: Identifizieren einer Region in der Haupt-Thread-Binärdatei, die die säumige Anweisung enthält; Identifizieren von im-Kontext-Anweisungen in der Region; und Identifizieren der im-Kontext-Anweisungen als die Vielzahl von Anweisungen.
Verfahren nach Anspruch 1, wobei das dynamische Erzeugen eines Ausführungs-Slice weiterhin folgendes umfaßt: Bestimmen, ob von der sequenziellen Ausführung von Anweisungen in dem Anfangs-Slice vorhergesagt wird, daß sie mindestens einen vorbestimmten Reservewert ergibt; und wenn dies der Fall ist, dynamisches Erzeugen eines einzigen p-Slice, das Anweisungen für serielle Schleifeniterationen enthält.
Verfahren nach Anspruch 1, wobei das Identifizieren einer säumigen Anweisung weiterhin das Identifizieren einer säumigen Anweisung in einer Haupt-Thread-Binärdatei auf der Basis von Profildaten umfaßt; und das Identifizieren eines Anfangs-Slice für die säumige Anweisung ferner das Identifizieren einer Anweisung aus der Haupt-Thread-Binärdatei als die identifizierte Anweisung, mit der eine Speicheradresse für die säumige Anweisung berechnet wird, umfaßt.
Artikel umfassend: ein maschinenlesbares Speichermedium mit einer Vielzahl von maschinenzugänglichen Anweisungen; wobei, wenn die Ausführungen durch einen Prozessor ausgeführt werden, die Anweisungen folgendes gewährleisten: Identifizieren einer säumigen Anweisung; Identifizieren eines Anfangs-Slice für die säumige Anweisung; dynamisches Erzeugen eines Ausführungs-Slice auf der Basis des Anfangs-Slice; und dynamisches Erzeugen einer erweiterten Binärdatei, die das Ausführungs-Slice enthält.
Artikel nach Anspruch 11, wobei Anweisungen zum dynamischen Erzeugen der erweiterten Binärdatei weiterhin folgendes umfassen: Anweisungen zum dynamischen Identifizieren eines Spawning-Punkts in einer Haupt-Thread-Binärdatei; und Anweisungen zum dynamischen Einbetten eines Triggers an dem Spawning-Punkt, wobei der Trigger dem Ausführungs-Slice entspricht.
Artikel nach Anspruch 11, wobei Anweisungen zum dynamischen Erzeugen der erweiterten Binärdatei weiterhin Anweisungen zum dynamischen Integrieren des Ausführungs-Slice in eine Haupt-Thread-Binärdatei umfassen.
Artikel nach Anspruch 12, wobei Anweisungen zum dynamischen Erzeugen eines Ausführungs-Slice weiterhin Anweisungen zum dynamischen Erzeugen einer Vielzahl verketteter Ausführungs-Slices umfassen, wobei die Vielzahl ein erstes verkettetes Ausführungs-Slice enthält; und Anweisungen zum Einbetten eines Triggers an dem Spawning-Punkt weiterhin Anweisungen zum Einbetten eines Triggers, der dem ersten verketteten Ausführungs-Slice entspricht, an dem Spawning-Punkt umfassen.
Artikel nach Anspruch 11, wobei Anweisungen zum Identifizieren eines Anfangs-Slice ferner folgendes umfassen: Anweisungen zum Identifizieren einer Anweisung in einer Haupt-Thread-Binärdatei, wobei die identifizierte Anweisung zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll.
Artikel nach Anspruch 11, wobei Anweisungen zum Identifizieren eines Anfangs-Slice weiterhin folgendes umfassen: Anweisungen zum Identifizieren einer Vielzahl von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die identifizierten Anweisungen zur Berechnung einer Speicheradresse verwendet werden, auf die durch die säumige Anweisung zugegriffen werden soll.
Artikel nach Anspruch 11, wobei Anweisungen zum Identifizieren eines Anfangs-Slice weiterhin folgendes umfassen: Anweisungen zum Identifizieren einer Übermenge von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die Übermenge von Anweisungen in einer Schleife der Haupt-Thread-Binärdatei auftreten, wobei die säumige Anweisung in der Schleife auftritt; Anweisungen zum Verwerfen einer Anweisung der Übermenge, wobei die verworfene Anweisung nicht zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll; und Anweisungen zum Identifizieren der übrigen Anweisungen der Übermenge als das Anfangs-Slice.
Artikel nach Anspruch 16, wobei Anweisungen zum Identifizieren einer Vielzahl von Anweisungen ferner folgendes umfassen: Anweisungen zum Identifizieren einer Region in der Haupt-Thread-Binärdatei, die die säumige Anweisung enthält; Anweisungen zum Identifizieren von im-Kontext-Anweisungen in der Region; und Anweisungen zum Identifizieren der im-Kontext-Anweisungen als die Vielzahl von Anweisungen.
Artikel nach Anspruch 11, wobei Anweisungen zum dynamischen Erzeugen eines Ausführungs-Slice weiterhin folgendes umfassen: Anweisungen zum Bestimmen, ob von einer sequentiellen Ausführung von Anweisungen in dem Anfangs-Slice vorhergesagt wird, daß sie mindestens einen vorbestimmten Reservewert ergibt; und Anweisungen zum Erzeugen eines einzigen p-Slice, das Anweisungen für serielle Schleifeniterationen enthält, wenn von einer sequentiellen Ausführung von Anweisungen in dem Anfangs-Slice vorhergesagt wird, daß sie mindestens einen vorbestimmten Reservewert ergibt.
Artikel nach Anspruch 11, wobei Anweisungen zum Identifizieren einer säumigen Anweisung weiterhin Anweisungen zum Identifizieren einer säumigen Anweisung in einer Haupt-Thread-Binärdatei auf der Basis von Profildaten umfassen; und Anweisungen zum Identifizieren eines Anfangs-Slice für die säumige Anweisung ferner Anweisungen zum Identifizieren einer Anweisung aus der Haupt-Thread-Binärdatei umfassen, wobei die identifizierte Anweisung zur Berechnung einer Speicheradresse für die säumige Anweisung verwendet wird.
Verfahren zum Kompilieren eines Softwareprogramms, mit den folgenden Schritten: dynamisches Modifizieren einer Haupt-Thread-Binärdatei, so daß sie zusätzliche Anweisungen enthält; wobei die zusätzlichen Anweisungen das Durchführen einer spekulativen Vorberechnung einer mit einer säumigen Softwareanweisung assoziierten Speicheradresse gewährleisten, wobei die säumige Anweisung eine Anweisung in der Haupt-Thread-Binärdatei ist.
Verfahren nach Anspruch 21, wobei die säumige Anweisung eine Anweisung mit langer Latenz umfaßt.
Verfahren nach Anspruch 21, wobei die säumige Anweisung eine Anweisung umfaßt, von der vorhergesagt wird, daß sie während der Ausführung der Haupt-Thread-Binärdatei zu einer Cache-Verfehlung führen wird.
Verfahren nach Anspruch 21, wobei die zusätzlichen Anweisungen ein dynamisch erzeugtes Ausführungs-Slice enthalten, wobei das Ausführungs-Slice eine Vorabrufanweisung zum Erhalten von mit der säumigen Anweisung assoziierten Speicherdaten enthält.
Verfahren nach Anspruch 21, wobei die zusätzlichen Anweisungen eine Vielzahl dynamisch erzeugter Ausführungs-Slices enthalten, wobei die Ausführungs-Slices jeweils eine Vorabrufanweisung zum Erhalten von durch die säumige Anweisung spezifizierten Speicherdaten enthalten.
Verfahren nach Anspruch 24, wobei die zusätzlichen Anweisungen eine Triggeranweisung enthalten, die dafür ausgelegt ist, eine Ausführung des Ausführungs-Slice durch den Prozessor auszulösen.
Verfahren nach Anspruch 21, wobei die zusätzlichen Anweisungen Anweisungen aus der Haupt-Thread-Binärdatei umfassen, wobei die zusätzlichen Anweisungen eine Berechnung der durch die säumige Anweisung spezifizierten Speicheradresse gewährleisten.
Verfahren nach Anspruch 21, wobei die zusätzlichen Anweisungen eine Teilmenge der Anweisungen aus der Haupt-Thread-Binärdatei umfassen, in der Gestalt, daß von der Ausführung der Teilmenge von Anweisungen vorhergesagt wird, daß sie mindestens eine vorbestimmte Anzahl von Prozessorzyklen schneller als eine entsprechende Übermenge von Anweisungen in der Haupt-Thread-Binärdatei ausführt.
Artikel, umfassend: ein maschinenlesbares Speichermedium mit einer Vielzahl maschinenzugänglicher Anweisungen; wobei, wenn die Anweisungen durch einen Prozessor ausgeführt werden, die Anweisungen ein dynamisches Modifizieren einer Haupt-Thread-Binärdatei gewährleisten, so daß sie zusätzliche Anweisungen enthält, wobei die zusätzlichen Anweisungen das Durchführen einer spekulativen Vorberechnung einer mit einer säumigen Softwareanweisung assoziierten Speicheradresse gewährleisten, wobei die säumige Anweisung eine Anweisung in der Haupt-Thread-Binärdatei ist.
Artikel nach Anspruch 29, wobei die säumige Anweisung eine Anweisung mit langer Latenz umfaßt.
Artikel nach Anspruch 29, wobei die säumige Anweisung eine Anweisung umfaßt, von der vorhergesagt ist, daß sie während der Ausführung der Haupt-Thread-Binärdatei zu einer Cache-Verfehlung führt.
Artikel nach Anspruch 29, wobei die zusätzlichen Anweisungen ein dynamisch erzeugtes Ausführungs-Slice enthalten, wobei das Ausführungs-Slice eine Vorabrufanweisung zum Erhalten von mit der säumigen Anweisung assoziierten Speicherdaten enthält.
Artikel nach Anspruch 29, wobei die zusätzlichen Anweisungen eine Vielzahl dynamisch erzeugter Ausführungs-Slices enthalten, wobei die Ausführungs-Slices jeweils eine Vorabrufanweisung zum Erhalten von durch die säumige Anweisung spezifizierten Speicherdaten enthalten.
Artikel nach Anspruch 32, wobei die zusätzlichen Anweisungen eine Triggeranweisung enthalten, die dafür ausgelegt ist, eine Ausführung des Ausführungs-Slice durch den Prozessor auszulösen.
Artikel nach Anspruch 29, wobei die zusätzlichen Anweisungen Anweisungen aus der Haupt-Thread-Binärdatei umfassen, wobei die zusätzlichen Anweisungen die Berechnung der durch die säumige Anweisung spezifizierten Speicheradresse gewährleisten.
Artikel nach Anspruch 29, wobei die zusätzlichen Anweisungen eine Teilmenge der Anweisungen aus der Haupt-Thread-Binärdatei umfassen, in der Gestalt, daß von der Ausführung der Teilmenge von Anweisungen vorhergesagt wird, daß sie mindestens eine vorbestimmte Anzahl von Prozessorzyklen schneller als eine entsprechende Übermenge von Anweisungen in der Haupt-Thread-Binärdatei ausführt.
Compiler, umfassend: einen Identifizierer zum Identifizieren einer säumigen Anweisung; einen Anfangs-Slicer zur Berechnung eines Anfangs-Slice für die säumige Anweisung; einen Ausführungs-Slicer zum Erzeugen eines Ausführungs-Slice auf der Basis des Anfangs-Slice; und einen Codegenerator zur Erzeugung einer erweiterten Binärdatei, die das Ausführungs-Slice enthält.
Compiler nach Anspruch 37, wobei der Identifizierer eine säumige Anweisung mindestens durch die folgenden Schritte identifiziert: Bestimmen, ob eine Anweisung in einer Schleife auftritt; wenn die Anweisung in einer Schleife auftritt, weiteres Bestimmen, ob die Anweisung wahrscheinlich während ihrer Ausführung eine Cache-Verfehlung verursachen wird; und wenn dies der Fall ist, Bestimmen, ob die Anweisung eine Zielanweisung ist, wobei eine Zielanweisung eine in einer Zielmenge von Anweisungen enthaltene Anweisung ist, wobei die Zielmenge von Anweisungen eine Menge von Anweisungen ist, von der vorhergesagt wird, daß sie während der Ausführung einer Menge von Quellcodeanweisungen zu mindestens einem vorbestimmten Prozentsatz von Cache-Verfehlungen führt.
Compiler nach Anspruch 37, wobei der Anfangs-Slicer ein Anfangs-Slice für die säumige Anweisung mindestens durch den folgenden Schritt identifiziert: Identifizieren einer Anweisung in einer Haupt-Thread-Binärdatei, wobei die identifizierte Anweisung zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll.
Compiler nach Anspruch 37, wobei der Anfangs-Slicer ein Anfangs-Slice für die säumige Anweisung mindestens durch den folgenden Schritt identifiziert: Identifizieren einer Vielzahl von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die identifizierten Anweisungen zur Berechnung einer Speicheradresse verwendet werden, auf die durch die säumige Anweisung zugegriffen werden soll.
Compiler nach Anspruch 37, wobei der Anfangs-Slicer ein Anfangs-Slice für die säumige Anweisung mindestens durch die folgenden Schritte identifiziert: Identifizieren einer Übermenge von Anweisungen in einer Haupt-Thread-Binärdatei, wobei die Übermenge von Anweisungen in einer Schleife der Haupt-Thread-Binärdatei auftritt, wobei die säumige Anweisung in der Schleife auftritt; Verwerfen einer Anweisung der Übermenge, wobei die verworfene Anweisung nicht zur Berechnung einer Speicheradresse verwendet wird, auf die durch die säumige Anweisung zugegriffen werden soll; und Identifizieren der übrigen Anweisungen der Übermenge als das Anfangs-Slice.
Compiler nach Anspruch 40, wobei der Anfangs-Slicer eine Vielzahl von Anweisungen mindestens durch die folgenden Schritte identifiziert: Identifizieren einer Region in der Haupt-Thread-Binärdatei, die die säumige Anweisung enthält; Identifizieren von im-Kontext-Anweisungen in der Region; und Identifizieren der im-Kontext-Anweisungen als die Vielzahl von Anweisungen.
Compiler nach Anspruch 37, wobei der Ausführungs-Slicer ein Ausführungs-Slice mindestens durch die folgenden Schritte erzeugt: Bestimmen, ob von der sequenziellen Ausführung von Anweisungen in dem Anfangs-Slice vorhergesagt wird, daß sie mindestens einen vorbestimmten Reservewert ergibt; und wenn dies der Fall ist, dynamisches Erzeugen eines einzigen p-Slice, das Anweisungen für serielle Schleifeniterationen enthält.
Compiler nach Anspruch 37, wobei der Identifizierer ferner eine säumige Softwareanweisung mindestens durch Identifizieren einer säumigen Anweisung in einer Haupt-Thread-Binärdatei unter Verwendung von Profildaten identifiziert; und der Anfangs-Slicer ferner ein Anfangs-Slice mindestens durch Identifizieren von Anweisungen aus der Haupt-Thread-Binärdatei identifiziert, die für die Berechnung einer Speicheradresse für die säumige Softwareanweisung relevant sind.
Compiler nach Anspruch 37, wobei der Codegenerator eine erweiterte Binärdatei mindestens durch die folgenden Schritte erzeugt: Identifizieren eines Spawning-Punkts in der Haupt-Thread-Binärdatei; und Einbetten eines Triggers an dem Spawning-Punkt, wobei der Trigger dem Ausführungs-Slice entspricht.
Compiler nach Anspruch 37, wobei der Codegenerator eine erweiterte Binärdatei mindestens durch den folgenden Schritt erzeugt: Integrieren des Ausführungs-Slice in die Haupt-Thread-Binärdatei.
Compiler nach Anspruch 45, wobei der Ausführungs-Slicer ein Ausführungs-Slice mindestens durch Erzeugen einer Vielzahl von verketteten Ausführungs-Slices erzeugt, wobei die Vielzahl ein erstes verkettetes Ausführungs-Slice enthält; und der Codegenerator einen Trigger an dem Spawning-Punkt einbettet, indem mindestens ein Trigger, der dem ersten verketteten Ausführungs-Slice entspricht, an dem Spawning-Punkt eingebettet wird.