DE10393481B4

DE10393481B4 - Verfahren und Vorrichtung zum Management einer Cache-Umgehung

Info

Publication number: DE10393481B4
Application number: DE10393481T
Authority: DE
Inventors: Youfeng Palo Alto Wu; Li-Ling Cupertino Chen
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-10-22
Filing date: 2003-09-12
Publication date: 2009-02-12
Anticipated expiration: 2023-09-13
Also published as: US20040078790A1; GB2410582A; US7467377B2; AU2003288904A8; US20040133886A1; WO2004038583A3; US7448031B2; CN1717663A; GB0508442D0; WO2004038583A2; HK1074686A1; GB2410582B; AU2003288904A1; DE10393481T5; WO2004038583A9; CN1717663B

Abstract

Verfahren zum Kompilieren eines Software-Programms für einen Prozessor mit einer Speicherhierarchie mit einem ersten Cache-Speicher mit einer ersten Speicherzugriffs-Latenz und einem zweiten Cache-Speicher mit einer zweiten Speicherzugriffs-Latenz, wobei die erste Speicherzugriffs-Latenz kleiner ist als die zweite Speicherzugriffs-Latenz, wobei das Verfahren dazu dient, Fehlzugriffe auf den ersten Cache-Speicher zu reduzieren, und die folgenden Schritte aufweist:
a) Identifizieren einer Ladeanweisung in dem Software-Programm, die eine maximale Verzögerungszeit aufweist, die größer oder gleich der Speicherzugriffs-Latenz des zweiten Cache-Speichers ist, wobei
die maximale Verzögerungszeit als die Zeitdifferenz zwischen einem möglichst späten Takt, der zur Ladeanweisung zugehörigen Verwendungsanweisung und einem möglichst frühen Takt der Ladeanweisung in einem Abhängigkeitsgraphen zu einem Steuerungsablaufgraph-Pfad des Software-Programms berechnet wird;
b) Zeitliches Einplanen des Software-Programms, wobei versucht wird, die identifizierte Ladeanweisung möglichst mit einer Latenz entsprechend der zweiten Speicherzugriffs-Latenz zeitlich einzuplanen;
c) Kennzeichnen der identifizierten, eingeplanten Ladeanweisung für ein Umgehen des ersten Cache-Speichers, wenn die Latenz...

Description

ERFINDUNGSGEBIET
Diese Offenlegung betrifft allgemein Computer und insbesondere Verfahren und eine Vorrichtung zum Management einer Cache-Umgehung.
STAND DER TECHNIK
Der gewöhnliche Computer weist eine Speicherhierarchie mit wahlfreiem Zugriff einschließlich eines oder mehrerer Ebenen eines Cache-Speichers auf dem Prozessor, eines Hauptspeichers (vom Prozessorchip getrennt angeordnet) und eines Massenspeichergeräts (z. B. ein Festplattenlaufwerk usw.) auf. Gewöhnlich ist der Zugriff auf die erste Ebene des Cache-Speichers (L1-Cache) am schnellsten (d. h., er weist die niedrigste Latenz auf), und der Zugriff auf den Massenspeicher ist am langsamsten. Die mit dem Zugriff auf die mittleren Ebenen der Speicherhierarchie verbundenen Latenzen liegen zwischen diesen beiden Extremen der Speicherzugriff-Latenzen. Zusätzlich zum Anwachsen der Latenzzeit nehmen die verschiedenen Ebenen der Speicherhierarchie gewöhnlich an Größe von der höchsten Ebene der Speicherhierarchie zur niedrigsten Ebene der Speicherhierarchie hin zu.
Moderne Hochleistungsprozessoren (z. B. die Intel-Itanium^TM-Prozessorenfamilie und andere EPIC-(Explicitly Parallel Instruction Computing))-Prozessoren) weisen mehrere Ebenen eines Cache-Speichers auf dem Chip auf. Der Itanium^TM-Prozessor zum Beispiel enthält drei Ebenen eines Cache auf dem Chip. Da die Arbeitsfrequenz von zukünftigen Prozessoren außerordentlich hoch ist, ist die erste Ebene des Cache (d. h. der L1-Cache, der hier als „μCache" bezeichnet wird) gewöhnlich klein in der Speichergröße, um ein taktweises Laden aus dem Speichersystem in ein Register eines Hochgeschwindigkeitsprozessors zu unterstützen. Zum Beispiel weist ein μCache gewöhnlich die Kapazität zum Speichern von 1 KByte (Kilobyte) oder weniger Daten auf.
Ein geeignetes Management des kleinen und schnellen μCache ist wichtig für die Gesamtleistungsfähigkeit des Host-Prozessors, dem er dient. Insbesondere muß in vielen Fällen eine beträchtliche Anzahl von Ladeanweisungen unverzüglich Daten aus dem Speichersystem abrufen, um die Programmausführung zu befördern, ohne daß eine Pipeline-Blockierung verursacht wird. Für solche Anweisungen ist es vorteilhaft, wenn die Daten, die sie benötigen, im μCache gespeichert sind.
In dem typischen Fall weist der Cache-Speicher einen Inklusiv-Charakter auf. Somit werden beim Abrufen von Daten aus einer gegebenen Ebene des Speichersystems (z. B. dem μCache) diese in alle niedrigeren Ebenen des Cache (z. B. in den Cache der Ebene 2 (L2), den Cache der Ebene 3 (L3) usw.) geschrieben. Diese Praxis maximiert die Wahrscheinlichkeit, daß die für eine spätere Anweisung benötigten Daten in der höchsten Ebene des Cache vorliegen, wodurch die Anzahl von Zugriffen auf langsamere Speicherhilfsmittel und die Anzahl von Speicher-Verfehlungen (d. h. eines fehlgeschlagenen Versuchs zum Auslesen von Daten aus einer Cache-Ebene, welche die gewünschten Daten nicht enthält) abnimmt.
Chi, C.-H. et al.: "Improving Cache Performance by Selective Cache Bypass", in Proceedings of the 22^nd Annual Hawaii International Conference an System Sciences, 1989, Vol I: Architecture Track, 3–6. Jan 1989, Seiten 277–285 offenbart eine Technik, um zu verhindern, daß selten verwendete Elemente in den Cache zurückkehren, nachdem sie daraus entfernt wurden. Hierfür wird eine Hardware verwendet, die aus Bypass-Cache bezeichnet wird, die bestimmt, ob unter bestimmten Umständen der Cache umgangen und direkt aus dem Hauptspeicher geladen werden soll. Hierbei wird der Cache umgangen, wenn der Oberhead eines Setzen/Ersetzens einer Zeile in einem Cache größer als oder gleich der Zeitersparnis durch Anordnung der Zeile im Cache, bevor sie ersetzt wird, unter Berücksichtigung der Anzahl von Verweisen auf die Zeile ist.
Abraham S. G. et al.: Predictability of Load/Store Instruction Latencies. In: Proceedings of the 26^th Annual International Symposium an Microarchitecture, 1993. pp. 139–152 offenbart ein Verfahren zum Kompilieren eines Software-Programms, um die Verfehlungen eines ersten Cache zu reduzieren, mit den Schritten: a) Identifizieren einer Ladeanweisung, die eine erwartete Latenz aufweist, die größer oder gleich einem vorgegebenen Schwellwert ist; b) zeitliches Planen des Software-Programms, wobei gefordert wird, die identifizierte Ladeanweisung zeitlich derart einzuplanen, dass sie eine vorgegebene Latenz aufweist; c) Vergleichen einer tatsächlichen Latenz, die mit der identifizierten Ladeanweisung im zeitlich geplanten Software-Programm verbunden ist, mit der vorgegebenen Latenz; d) Kennzeichnen der identifizierten Ladeeinweisung für ein Umgehen des ersten Cache, wenn das Vergleichen in Schritt c) ergibt, dass die tatsächliche Latenz größer als oder gleich der vorgegebenen Latenz ist; und e) Umwandeln des zeitlich festgelegten Software-Programms in ausführbaren Objektcode, wobei der Objektcode die identifizierte Ladeanweisung enthält, die in Schritt d) gekennzeichnet wurde, den ersten Cache zu umgehen.
Der Erfindung liegt somit die Aufgabe zugrunde, ein effizienteres kompiliertes Programm zu erhalten, d. h. eine möglichst effiziente Ausführung von Anweisungen zur Laufzeit zu ermöglichen, mit deutlich reduzierten Verfehlungen des Cache bei der Programmausführung.
Die Aufgabe wird gelöst durch die nebengeordneten Ansprüche 1, 12 und 21.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist eine schematische Darstellung eines exemplarischen Computers.
2 ist eine schematische Darstellung einer exemplarischen Vorrichtung für das Management der μCache-Umgehung.
3 ist ein Flußdiagramm zum Veranschaulichen eines Programmbeispiels, das die Vorrichtung von 2 verwirklicht.
4 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Finde_WB_Ladevorgänge, die durch das Programm von 3 aufgerufen wird.
5 ist eine schematische Darstellung eines exemplarischen Steuerungsablaufs.
6 ist eine schematische Darstellung eines weiteren exemplarischen Steuerungsablaufs.
7 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Finde_FQ_Ladevorgänge_in_Region, die durch das Programm von 3 aufgerufen wird.
8 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine FQ_Identifizieren (Einzelpfad), die durch das Programm von 7 aufgerufen wird.
9 ist eine Veranschaulichung eines exemplarischen Abhängigkeitsgraphen.
10 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Wähle_Ladevorgänge_aus_möglichen_Ladevorgängen, die durch das Programm von 8 aufgerufen wird.
11 ist eine Veranschaulichung eines exemplarischen reduzierten Abhängigkeitsgraphen.
12 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Finde_LU_Ladevorgänge_in_Region, die durch das Programm von 3 aufgerufen wird.
13 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Finde_LU_Ladevorgänge_in_Pfad, die durch das Programm von 12 aufgerufen wird.
14 ist ein Flußdiagramm zum Veranschaulichen einer exemplarischen Routine Finde_LU_Ladevorgänge, die durch das Programm von 3 aufgerufen wird.
AUSFÜHRLICHE BESCHREIBUNG
1 ist ein Blockdiagramm eines exemplarischen Computers 10, der in der Lage ist, die hier offengelegten Vorrichtungen und Verfahren zu verwirklichen. Der Computer 10 kann ein Personal-Digitalassistent (PDA), ein Laptop-Computer, ein Notebook-Computer, ein Desktop-Computer, ein Server, eine Internet-Anwendung oder ein beliebiger anderer Typ einer Rechenvorrichtung sein.
Der Computer 10 des Fallbeispiels enthält einen Prozessor 12, der zum Beispiel durch einen oder mehrere Intel^®-Mikroprozessoren realisiert ist. In dem dargestellten Beispiel ist der Prozessor 12 ein statisch zeitlich eingeplanter In-Order-Prozessor, wie z. B. ein Prozessor aus der Familie der Itanium^®-Prozessoren von Intel. Die Architekturen der Prozessoren in der Familie Intel-Itanium^® werden bevorzugt, weil sie ein Flag im Ladeanweisungsformat unterstützen. Wird das Flag nicht gesetzt, dann greift die Ladeanweisung auf den μCache zu. Anderenfalls umgeht die Ladeanweisung den μCache und greift direkt auf den L2-Cache zu.
Wie üblich steht der Prozessor 12 über einen Bus 18 mit einem Hauptspeicher einschließlich eines flüchtigen Speichers 14 und eines nicht-flüchtigen Speichers 16 in Verbindung. Der flüchtige Speicher 14 kann durch einen Synchron-Dynamik-Direktzugriffsspeicher (SDRAM), Dynamik-Direktzugriffsspeicher (DRAM), RAMBUS-Dynamik-Direktzugriffsspeicher (RDRAM) und/oder irgendeinen anderen Typ einer Direktzugriffsspeichervorrichtung realisiert werden. Der nicht-flüchtige Speicher 16 kann durch einen Flash-Speicher oder einen beliebigen anderen gewünschten Typ einer Speichervorrichtung realisiert werden. Der Zugriff auf den Hauptspeicher 14, 16 wird gewöhnlich durch eine (nicht dargestellte) Speichersteuerung in einer herkömmlichen Weise gesteuert.
Der exemplarische Computer 10 enthält auch einen herkömmlichen Schnittstellenschaltkreis 20. Der Schnittstellenschaltkreis 20 kann durch einen beliebigen Typ eines wohlbekannten Schnittstellenstandards, wie z. B. eine Ethernet-Schnittstelle und/oder einen universellen seriellen Bus (USB) und/oder eine Input/Output-Schnittstelle der dritten Generation (3GIO) (die auch als PCI-Expreß bezeichnet wird) realisiert werden.
An den Schnittstellenschaltkreis 20 sind eine oder mehrere Eingabevorrichtungen 22 angeschlossen. Die Eingabevorrichtung(en) 22 erlaubt(erlauben) dem Benutzer, Daten und Befehle in den Prozessor 12 einzugeben. Die Eingabevorrichtung(en) kann(können) zum Beispiel durch eine Tastatur, eine Maus, einen Berührungsbildschirm, ein Track-Pad, ein Track-Ball, einen Isopoint und/oder ein Spracherkennungssystem realisiert werden.
Am Schnittstellenschaltkreis 20 sind auch eine oder mehrere Ausgabevorrichtungen 24 angeschlossen. Die Ausgabevorrichtungen 24 können zum Beispiel durch Anzeigevorrichtungen (z. B. eine Flüssigkristallanzeige, eine Kathodenstrahlröhren(CRT)-Anzeige usw.), einen Drucker und/oder Lautsprecher realisiert werden. Der Schnittstellenschaltkreis 20 enthält somit gewöhnlich eine Graphik-Treiberkarte.
Der Schnittstellenschaltkreis 20 enthält auch eine Kommunikationsvorrichtung, wie z. B. ein Modem oder eine Netzschnittstellenkarte, um den Austausch von Daten mit äußeren Computer über ein Netz 26 (z. B. eine Ethernet-Verbindung, eine digitale Abonnentenleitung (DSL), eine Telefonleitung, ein Koaxialkabel, ein Mobilfunk-Telefonsystem usw.) zu ermöglichen.
Der Computer 10 enthält auch eine oder mehrere Massenspeichervorrichtungen 28 zum Speichern von Software und Daten. Beispiele für solche Massenspeichervorrichtungen 28 umfassen Diskettenlaufwerke, Festplattenlaufwerke, Compact-Disc-Laufwerke und Digital-Versatile-Disk(DVD)-Laufwerke.
Bekanntermaßen ist das Speichersystem des exemplarischen Computers 10 in einer hierarchischen Form angeordnet. Der(die) Prozessor(en) 12 enthalten zum Beispiel drei Ebenen eines systemeigenen Cache-Speichers. Die erste Ebene des Cache ist die höchste Speicherebene, welche die geringste Zugriffszeit aufweist. Die erste Ebene des systemeigenen Cache-Speichers ist auch der kleinste Cache, der hier als μCache bezeichnet wird. Die zusätzlichen Ebenen des Cache nehmen in Größe und Zugriffszeit stufenweise zu. In diesem Beispiel enthält der Prozessor 12 zweite und dritte Ebenen eines Cache auf dem Chip (d. h. L2- und L3-Cache) auf. Der Computer 10 enthält auch einen Cache vierter Ebene (L4), der auf demselben Chip wie der Prozessor 12 angeordnet sein oder seinen eigenen Chip aufweisen kann. Der L4-Cache ist größer und langsamer abrufbar als der μCache, der L2-Cache und der L3-Cache. Zum Beispiel kann der L4-Cache durch einen SRAM realisiert werden. Eine fünfte Ebene des Cache (Hauptspeicher) ist größer als der L4-Cache und weist langsamere Zugriffszeiten als dieser auf. Der Hauptspeicher kann zum Beispiel durch einen DRAM realisiert werden. In dem Beispiel von 1 werden der L4-Cache und der Hauptspeicher durch den Direktzugriffsspeicher 14 gebildet.
Zum Ausführen von Programmanweisungen veranlaßt der Prozessor 12 gewöhnlich das Laden beliebiger benötigter Daten aus einer Massenspeichervorrichtung in den Cache. Wenn die Daten in eine gegebene Ebene des Cache geladen werden, werden sie üblicherweise in alle niedrigeren Ebenen des Cache geschrieben, um die Wahrscheinlichkeit zu erhöhen, daß eine bestimmte Ebene die Daten bereithält, sollten sie in der Zukunft wieder benötigt werden. Dieses Redundanz- oder Inklusivmerkmal reduziert gewöhnlich die Anzahl von Zugriffen auf die Massenspeichervorrichtung 28, die üblicherweise die langsamste Zugriffszeit von einem beliebigen Teil des Speichers aufweist.
Wenn ein Prozessor 12 eine Anweisung ausführen muß, dann werden alle von der Anweisung benötigten Daten aus dem Cache (falls sie vorliegen) oder der Massenspeichervorrichtung 28 (falls sie im Cache nicht vorliegen) in ein oder mehrere Register im Prozessor 12 geladen, wo sie dann bearbeitet werden, wie durch die Anweisung vorgeschrieben ist.
In dieser Patentschrift wird durchgängig die Latenz des μCache mit T1, die Latenz des L2-Cache mit T2, die Latenz des L3-Cache mit T3 usw. bezeichnet. Beispielhafte Treffer-Latenzen (d. h., wenn die angeforderten Daten in dem entsprechenden Cache vorliegen) sind T1 = 1 Takt, T2 = 3 Takte und T3 = 10 Takte. In dieser Patentschrift bezeichnet eine Ladeanweisung durchgängig eine Ganzzahl-Ladeanweisung. Speicheroperationen und Gleitkomma-Ladevorgänge greifen direkt auf den L2-Cache zu (d. h., umgehen immer den μCache), da die Speicheroperationen gewöhnlich nicht zeitkritisch sind und Gleitkomma-Ladevorgänge immer Latenzen größer als T1 mit sich bringen. Wegen seiner geringen Größe sollte der μCache nur Daten speichern, welche durch die Caches niedrigerer Ebene (z. B. den L2-Cache-Hauptspeicher) nicht rechtzeitig zur Verfügung gestellt werden können. Mit anderen Worten, wenn die Daten, auf die durch eine gegebene Ladeanweisung zugegriffen wird, nicht in den nächsten T2 Takten verwendet werden, sollten sie unmittelbar aus dem L2-Cache abgerufen werden. Diese Faustregel verringert den Druck auf den μCache, so daß mehr zeitkritische Daten darin gespeichert werden können.
Außerdem sollte selbst bei einer sofortigen Verwendung eines geladenen Ergebnisses durch eine Verwendungsanweisung dann, wenn die zugehörige Initial-Ladeanweisung auf den μCache fehlschlägt (d. h., wenn die geladenen Daten nicht im μCache sind) und keine späteren Ladeanweisungen auf die geladene Cache-Leitung zugreifen, die Initial-Ladeanweisung den μCache umgehen und direkt auf den L2-Cache zugreifen. Der unmittelbare Zugriff auf den L2-Cache stellt sicher, daß die abgerufenen Daten nicht in den μCache geschrieben werden. Das Umgehen des μCache ist angebracht, weil die Initial-Ladeanweisung auf den L2-Cache zugreifen muß, um die Daten (d. h. die Daten, die anfänglich nicht im μCache vorliegen) zu erreichen und es keine Vorabholungseffekte gibt, die mit einem Abrufen der Daten zum μCache verbunden sind, so daß es nicht erwünscht ist, den μCache mit diesen Daten zu belasten. Ladevorgänge, diediese Merkmale aufweisen, werden hier als Verfehlungs-Umgehungs(VU)-Ladevorgänge bezeichnet.
Ferner sollten auch fortschreitende Ladeanweisungen, die bestimmte Merkmale aufweisen, den μCache umgehen. Eine fortschreitende Ladeanweisung ist eine Ladeanweisung, die in einer Schleife angeordnet ist, welche einen dominanten Schritt aufweist. Der Schritt für die Ladeanweisung ist die Differenz zwischen zwei aufeinanderfolgenden Datenadressen, welche durch die fortschreitende Ladeanweisung ausgegeben werden. Wenn der Durchlaufzählwert durch die Schleife und/oder die dominante Schrittgröße hinreichend groß im Vergleich zur Größe des μCache ist, sprengt die fortschreitende Ladeanweisung den μCache, wenn sie den μCache nicht umgeht. Demzufolge sollten diese fortschreitenden Ladeanweisungen gekennzeichnet werden, daß sie den μCache umgehen.
In 2 ist eine exemplarische Vorrichtung 40 zum Durchführen der μCache-Umgehung dargestellt, um die Verfehlungen des μCache zu reduzieren, wenn ein Software-Programm ausgeführt wird. Wie in 2 dargestellt ist, wirkt die exemplarische Vorrichtung 40 auf ein durchzuführendes Software-Programm ein, das aktuell zumindest teilweise in einem gewissen Teilbereich des Speichers 14 gespeichert ist.
Zum Zwecke der Identifizierung der Kandidaten-Ladeanweisungen im Software-Programm für ein mögliches Umgehen des μCache wird die Vorrichtung 40 mit einem Kandidaten-Ladeidentifikator 42 versehen. Der Kandidaten-Ladeidentifikator 42 durchsucht die Software nach Kandidaten-Ladeanweisungen, bevor die Software durch den Compiler zeitlich eingeplant wird. Der Kandidaten-Ladeidentifikator 42 identifiziert Ladeanweisungen, die (1) eine erwartete Latenz größer als oder gleich einem ersten vorgegebenen Schwellwert (z. B.
T2 Takte) und (2) eine Umgehungswahrscheinlichkeit größer als oder gleich einem zweiten vorgegebenen Schwellwert aufweisen, als Kandidaten-Ladeanweisungen. Der Kandidaten-Ladeidentifikator 42 bestimmt die erwartete Latenz einer gegebenen Ladeanweisung durch Bestimmen einer maximalen Verzögerungszeit der gegebenen Ladeanweisung im Abhängigkeitsgraphen. Wenn zum Beispiel die Subjekt-Ladeanweisung bereits im Takt 1 und die zugeordnete Verwendungsanweisung erst im Takt 10 ausgeführt werden könnte, dann beträgt die maximale Verzögerungszeit 10 Takte. Da die Anweisungen, die durch den Kandidaten-Ladeidentifikator 42 überprüft werden, noch nicht zeitlich durchgeplant sind, sind sie noch nicht mit absoluten Einplanungstakten verbunden. Statt dessen weisen diese Anweisungen das Potential auf, in der Ausführungsabfolge vorwärts und rückwärts mit Bezug auf die anderen Anweisungen verschoben zu werden. Die maximale Verzögerungszeit („slack") einer gegebenen Ladeanweisung besteht somit in den potentiellen Zeitdifferenzen, die möglicherweise zwischen der gegebenen Ladeanweisung und der Verwendungsanweisung, welche die geladenen Daten benötigt, zeitlich eingeplant werden können.
Die dargestellte Vorrichtung 40 ist auch mit einer Ablaufsteuerung 44 versehen. Die Ablaufsteuerung 44 arbeitet wie eine herkömmliche Ablaufsteuerung 44 in einem herkömmlichen Compiler mit einer Abwandlung. Insbesondere versucht die Ablaufsteuerung 44 von 2 den Ablauf der Kandidaten-Ladeanweisungen (d. h. der Ladeanweisungen, die durch den Kandidaten-Ladeidentifikator 42 identifiziert wurden) so zeitlich einzuplanen, daß sie eine Latenz größer als oder gleich einem vorgegebenen Schwellwert aufweisen. In diesem Beispiel ist der vorgegebene Schwellwert, der durch die Ablaufsteuerung 44 verwendet wird, gleich T2, der Latenz des L2-Cache. Während die Ablaufsteuerung 44 diesen Wert aufgreift, können andere Beschränkungen dazu führen, daß nicht alle Kandidaten-Ladeanweisungen die gewünschte Latenz aufweisen. Tatsächlich ist es möglich, daß alle, keine oder einige der Kandidaten-Ladeanweisungen so zeitlich eingeplant werden.
Zum Zwecke der Kennzeichnung von Ladeanweisungen für ein Umgehen des μCache ist die Vorrichtung 40 von 2 außerdem mit einem Final-Ladeidentifikator 46 ausgestattet. Der Final-Ladeidentifikator 46 bearbeitet den von der Ablaufsteuerung 44 zeitlich geplanten Code, um Final-Ladeanweisungen zu identifizieren. Der Final-Ladeidentifikator 46 identifiziert die Ladeanweisungen, die (1) eine tatsächliche (d. h. zeitlich geplante) Latenz größer als oder gleich einem ersten vorgegebenen Schwellwert (z. B. T2) und (2) eine Umgehungswahrscheinlichkeit größer als oder gleich einem zweiten vorgegebenen Schwellwert aufweisen, als Final-Ladeanweisungen. Der Final-Ladeidentifikator 46 bestimmt die tatsächliche Latenz einer gegebenen Ladeanweisung durch Bestimmen einer Zeitdifferenz zwischen der Zeit, zu der die Ausführung einer Ladeanweisung zeitlich eingeplant ist, und der Zeit, zu der die Ausführung einer Verwendungsanweisung, die mit den Daten arbeitet, welche durch diese Ladeanweisung geladen wurden, zeitlich eingeplant ist. Der Final-Ladeidentifikator 46 kennzeichnet Ladeanweisungen, den μCache zu umgehen, indem er in Ausführungen, die das Setzen eines solchen Flags unterstützen (d. h. Ausführungen, die einen Prozessor der Itanium^®-Familie verwenden), ein Flag in jede dieser Ladeanweisungensetzt.
Zur Objektcodeerzeugung aus dem zeitlich eingeplanten Software-Programm ist die Vorrichtung 40 von 2 außerdem mit einem Objektcodeerzeuger 48 ausgestattet. Der Objektcodeerzeuger 48 ist als ein herkömmlicher Compiler realisiert und arbeitet auf die herkömmliche Weise.
Um zu kennzeichnen, daß die fortschreitenden Ladeanweisungen den μCache zu umgehen haben, ist die Vorrichtung 40 von 2 außerdem mit einem Fortschreitend-Ladeidentifikator 50 ausgestattet. Der Fortschreitend-Ladeidentifikator 50 kennzeichnet einen fortschreitenden Ladevorgang als den μCache umgehend, wenn: (1) die fortschreitende Ladeanweisung in einer Schleife angeordnet ist und (2) die fortschreitende Ladeanweisung mehr als einen vorgegebenen Umfang des μCache verwendet, wenn die Schleife ausgeführt wird. Der Fortschreitend-Ladeidentifikator 50 legt fest, ob die fortschreitende Ladeanweisung beim Ausführen der Schleife mehr als den vorgegebenen Umfang des μCache verwendet, durch: (1) Bestimmen einer Anzahl von Durchläufen durch die Schleife, in der die fortschreitende Ladeanweisung ausgeführt wird; (2) Multiplizieren der Anzahl von Durchläufen mit einem der fortschreitenden Ladeanweisung zugeordneten Schritt, um einen Schrittgrößenwert abzuleiten; (3) Dividieren des Schrittgrößenwertes durch einen Wert, der repräsentativ für eine Größe des μCache ist, um einen Speichernutzungsprozentanteil abzuleiten; und (4) Vergleichen des Speichernutzungsprozentanteils mit dem vorgegebenen Umfang des μCache. In dem veranschaulichten Beispiel wirkt der Fortschreitend-Ladeidentifikator 50 vor dem Kandidaten-Ladeidentifikator 42 auf die Software ein, um dadurch potentiell den Umfang des Codes, der eine Analyse durch den Kandidaten-Ladeidentifikator 42 und den Final-Ladeidentifikator 46 erfordert, zu verringern, während die Aufgabe der Ablaufsteuerung 44 vereinfacht wird.
Wie in 2 dargestellt ist, ist die Vorrichtung 40 auch mit einem Verfehlungs-Umgehungs-Ladeidentifikator 52 versehen. Der Verfehlungs-Umgehungs-Ladeidentifikator 52 funktioniert nach dem Erarbeiten bestimmter Profildaten über ein ein- oder mehrmaliges Ausführen des Objektcodes unter der Annahme, daß die Ladevorgänge, die durch den Final-Ladeidentifikator 46 identifiziert wurden, den μCache umgehen. Der Verfehlungs-Umgehungs-Ladeidentifikator 52 identifiziert Ladeanweisungen, welche den μCache verfehlen und wobei die durch die Ladeanweisungen geladene Cache-Leitung nicht wiederverwendet wird. Für jede Ladeanweisung aus der vorhergehenden Identifizierungsphase, die den μCache nicht umgeht, dividiert der Verfehlungs-Umgehungs-Ladeidentifikator 52 (a) eine Zahl, wie oft die Ladeanweisung den μCache verfehlt, ohne daß die durch die Ladeanweisung geladene Cache-Leitung wiederverwendet wird, durch (b) eine Zahl, wie oft eine Ladeanweisung ausgeführt wird, um einen Verhältniswert zu erhalten. Ist der Verhältniswert größer als oder gleich einem vorgegebenen Verhältnis-Schwellwert, dann kennzeichnet der Verfehlungs-Umgehungs-Ladeidentifikator 52 die Ladeanweisung für ein Umgehen des μCache.
Sobald der Verfehlungs-Umgehungs-Ladeidentifikator 52 den gesamten Code analysiert hat, bearbeitet der Objektcodeerzeuger 48 den Programm- oder Zwischencode, der durch den Final-Ladeidentifikator 46, den Fortschreitend-Ladeidentifikator 50, die Ablaufsteuerung 44 und den Verfehlungs-Umgehungs-Ladeidentifikator 52 modifiziert wurde, um einen Objektcode zu erzeugen, der die Ladeanweisungen einschließt, die für ein Umgehen des μCache gekennzeichnet wurden. Das vollendet den Kompilierungsvorgang des Quellcodes in den Objektcode für das Management der μCache-Umgehung, um die Anzahl der Verfehlungen des μCache zu verringern.
Wie oben erläutert wurde, verwendet die dargestellte Vorrichtung 40 eine Anzahl von Kompilierungsverfahren, wie z. B. die Abhängigkeitsanalyse und das Profiling, um Ladevorgänge zu identifizieren, die den μCache umgehen und direkt auf den L2-Cache zugreifen sollten. Somit ist die exemplarische Vorrichtung 40 ein Compiler, der einen Zwischencode bearbeitet, um einen Objektcode zu erzeugen, der von einem effizienteren Einsatz des μCache und somit wenigeren μCache-Verfehlungen profitiert.
Ein exemplarisches Software-Programm zum Realisieren der Vorrichtung von 2 ist in den 3–14 dargestellt. In diesem Beispiel ist das Programm durch den Prozessor 12 auszuführen, und es ist in der Software enthalten, die auf einem dinghaften Medium, wie z. B. einer CD-ROM, einer Diskette, einem Festplattenlaufwerk, einem Digital-Versatile-Disk (DVD), oder einem mit dem Prozessor 12 verbundenen Speicher gespeichert ist, aber Durchschnittsfachleute werden leicht einsehen, daß das gesamte Programm oder Teile davon alternativ durch eine andere Vorrichtung als der Prozessor 12 ausgeführt werden und/oder in wohlbekannter Weise in Firmware und/oder zweckbestimmter Hardware enthalten sein könnten. Zum Beispiel könnten irgendeiner oder alle von den Kandidaten-Ladeidentifikatoren 42, Ablaufsteuerungen 44, Final- Ladeidentifikatoren 46, Objektcodeerzeugern 48, Fortschreitend-Ladeidentifikatoren 50 und/oder isolierten Ladeidentifikatoren 52 durch Software, Hardware und/oder Firmware realisiert werden. Außerdem werden Durchschnittsfachleute leicht einsehen, daß viele andere Verfahren zur Realisierung der Vorrichtung 40 von 2 alternativ verwendet werden können, obwohl das exemplarische Programm mit Bezug auf die in den 3–14 dargestellten Flußdiagramme beschrieben ist. Zum Beispiel kann die Ausführungsreihenfolge der Blöcke verändert werden, und/oder die beschriebenen Blöcke können verändert, entfernt oder kombiniert werden.
Mit Bezug auf 3 startet die Vorrichtung 40 einen ersten Kompilierungsdurchlauf (Block 100) durch Löschen der Gruppe Final_Umgehungs_Ladevorgänge zu einer Leermenge (Block 102). Dann wird der Fortschreitend-Ladeidentifikator 50 aktiviert (Block 104), um die fortschreitenden Ladeanweisungen für das Umgehen des μCache zu kennzeichnen (Block 104). Wie in 4 dargestellt ist, löscht insbesondere der Fortschreitend-Ladeidentifikator 50 zuerst die Gruppe WB-Ladevorgänge zu einer Leermenge (Block 110). Dann beginnt der Fortschreitend-Ladeidentifikator 50 mit der Durchsicht des Subjektprogramms, um Ladeanweisungen zu identifizieren. Liegen im Programm keine Ladeanweisungen vor (Block 112), dann gibt der Fortschreitend-Ladeidentifikator 50 die WB-Ladevorgänge als eine Leermenge zurück, und die Steuerung kehrt zum Block 130 (3) zurück.
Unter der Annahme, daß das bearbeitete Programm eine Ladeanweisung enthält (Block 112), ruft der Fortschreitend-Ladeidentifikator 50 die überprüfte Ladeanweisung auf (Block 114), um festzustellen, ob sie in einer Schleife liegt (Block 116). Liegt die Ladeanweisung nicht in einer Schleife (Block 116), dann setzt der Fortschreitend-Ladeidentifikator 50 die Durchsuchung des Programms nach der nächsten Ladeanweisung fort. Liegen keine weiteren Ladeanweisungen vor (Block 118), dann kehrt die Steuerung zum Block 130 von 3 zurück. Liegen weitere Ladeanweisungen vor, dann setzt die Steuerung das Durchlaufen der Schleife durch die Blocks 114–118 fort, bis es keine weiteren Ladeanweisungen mehr gibt (Block 118) oder bis eine in einer Schleife liegende Ladeanweisung identifiziert ist (Block 116).
Wird eine in einer Schleife liegende Ladeanweisung identifiziert (Block 116), dann bestimmt der Fortschreitend-Ladeidentifikator 50, ob die Ladeanweisung fortschreitend ist (Block 120). Eine Ladeanweisung ist fortschreitend, wenn sie einen dominanten Schritt aufweist. Ein dominanter Schritt ist ein Schritt, der weit häufiger auftritt als andere Schritte. Ein Schritt für eine Ladeanweisung ist die Differenz zwischen zwei aufeinanderfolgenden Adressen, die durch die Ladeanweisung ausgegeben werden. Ist die Ladeanweisung nicht fortschreitend (Block 120), dann setzt der Fortschreitend-Ladeidentifikator 50 die Suche nach fortschreitenden Ladeanweisungen fort (Blöcke 114–120) oder springt heraus, wenn die letzte Ladeanweisung untersucht worden ist (Block 118).
Ist die Ladeanweisung fortschreitend (Block 120), dann stellt der Fortschreitend-Ladeidentifikator 50 fest, ob die fortschreitende Ladeanweisung mehr als einen vorgegebenen Umfang des μCache verwendet, wenn die Schleife ausgeführt wird. Insbesondere berechnet der Fortschreitend-Ladeidentifikator 50 einen Schrittgrößenwert (SGW) durch Multiplizieren der Anzahl der Durchläufe, welche die Software durch die Schleife hindurch, in der die Ladeanweisung liegt, vornimmt (d. h. der Durchlaufzahl), mit dem dominanten Schritt der Ladeanweisung (Block 122). Der Fortschreitend-Ladeidentifikator 50 dividiert dann den Schrittgrößenwert (SGW) durch die Größe des μCache und vergleicht das Ergebnis mit einem vorgegebenen Schwellwert (z. B. einem Faktor 5 oder größer) (Block 124). Wenn der Quotient des Schrittgrößenwerts (SGW) und der Cachegröße über dem Schwellwert liegt (Block 124), dann identifiziert der Fortschreitend-Ladeidentifikator 50 die Ladeanweisung als einen Ladevorgang, der den μCache umgehen sollte, indem er ihn zur Gruppe WB_Ladevorgänge hinzufügt (Block 126). Die Steuerung kehrt dann zum Block 118 zurück. Wenn der Quotient des Schrittgrößenwerts (SGW) und der Cachegröße nicht über dem Schwellwert (Block 124), dann kehrt die Steuerung zum Block 118 zurück, ohne den Ladevorgang zur Gruppe WB_Ladevorgänge hinzuzufügen.
Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 114–126 fort, bis jede Ladeanweisung analysiert ist, um zu sehen, ob sie eine fortschreitende Ladeanweisung ist, die den μCache umgehen sollte. Ist dieser Einsatz beendet ist (Block 118), dann kehrt die Steuerung zum Block 130 von 3 zurück.
Beim Block 130 fügt der Final-Ladeidentifikator 46 die Gruppe von fortschreitenden Ladeanweisungen {WB_Ladevorgänge} zur Gruppe der finalen Umgehungs-Ladevorgänge {Final_Umgehungs_Ladevorgänge} hinzu.
Wie Durchschnittsfachleute anerkennen werden, weisen einige Programmabschnitte nur einen einzigen Ausführungspfad auf, während andere Parallelpfade aufweisen, die nach einer oder mehreren Entscheidungen, die unmittelbar den Steuerungsablauf durch den Abschnitt verzweigen, beschritten werden. In dieser Patentschrift wird ein Abschnitt eines Software-Programms, der einen oder mehrere Steuerungsablaufpfade, einen oder mehrere Exitpunkte und einen einzigen Eingangspunkt aufweist, als eine „Region" bezeichnet. Ein Abschnitt eines Programms, das nur einen Steuerungsablaufpfad zwischen einem einzigen Eingangspunkt und einem einzigen Exitpunkt aufweist, wird als ein „Pfad" bezeichnet. Eine Region kann einen oder mehrere Pfade enthalten.
Nach dem Block 130 beginnt die Vorrichtung 40 vom Start des Programms an, das Software-Programm hinsichtlich Kandidaten-Ladeanweisungen zu untersuchen, die eine Latenz größer als oder gleich einem vorgegebenen Schwellwert aufweisen. Compiler vom Stand der Technik nehmen gewöhnlich an, daß ein Ladevorgang den μCache trifft und planen den Ladevorgang mit einer Latenz T1 zeitlich ein. Weist der Ladevorgang eine maximale Verzögerungszeit von T2 Takten auf, dann kann der Ladevorgang mit einer Latenz von T2 Takten zeitlich eingeplant werden, ohne die kritische Pfadlänge zu beeinträchtigen. (Ein Ladevorgang, der eine solche maximale Verzögerungszeit aufweist, wird hier als ein „freiraumqualifizierter Ladevorgang" oder ein „Kandidaten-Umgehungsladevorgang" bezeichnet.) Nicht jeder Ladevorgang mit einer maximalen Verzögerungszeit T2 ist ein freiraumqualifizierter Ladevorgang. Wird ein Ladevorgang mit einer ausreichenden maximalen Verzögerungszeit als ein freiraumqualifizierter Ladevorgang identifiziert und wird seine Latenz vergrößert, dann können die maximalen Verzögerungszeiten der anderen Ladevorgänge beeinträchtigt werden (z. B. kann ein Ladevorgang, der ursprünglich eine maximale Verzögerungszeit von T2 Takten aufwies, keine maximale Verzögerungszeit von T2 Takten mehr aufweisen, wenn einem anderen freiraumqualifizierten Ladevorgang eine maximale Verzögerungszeit von T2 Zyklen zugewiesen wurde). In Abhängigkeit von der Reihenfolge, in der die freiraumqualifizierten Ladevorgänge identifiziert werden, können unterschiedliche Identifizierungsreihenfolgen unterschiedliche Gruppen von freiraumqualifizierten Ladevorgängen zur Folge haben. Somit hat die Vorrichtung 40 die folgenden Zielstellungen: (1) Maximieren der Anzahl von Freiraum-Umgehungs-Ladevorgängen (gewichtet durch ihre Ausführungsfrequenzen); (2) und Minimieren des Anwachsens der gesamten Ablauflänge.
Wie in 3 dargestellt ist, wird im Block 236 die Routine Finde_FQ_Ladevorgänge_in_Region aufgerufen. Liegt ein Ladevorgang auf Parallel-Steuerungsablaufpfaden einer zeitlich eingeplanten Region, dann wird zuerst bestimmt, ob er ein freiraumqualifizierter Ladevorgang für individuelle Pfade sein könnte, und dann werden die Informationen aus allen Pfaden kombiniert, um zu bestimmen, ob der Ladevorgang ein freiraumqualifizierter Ladevorgang für die Region sein könnte. Um das zu tun, wird ein Parameter FQ_PROB als ein Wert zwischen 0 und 1 definiert. Ein Ladevorgang ist dann und nur dann ein freiraumqualifizierter Ladevorgang für eine Region, wenn er auf einem Anteil FQ_PROB der Pfade, gewichtet durch die Pfadfrequenzen, umgangen werden kann. Genauer gesagt, die Region-Umgehungswahrscheinlichkeit (RUW) soll das Verhältnis der Gesamtfrequenz der Pfade, auf denen der Ladevorgang umgangen werden kann, zur Region-Eingangswahrscheinlichkeit sein. Ein Ladevorgang ist für eine gegebene Region dann und nur dann ein freiraumqualifizierter Ladevorgang, wenn RUW(Ladevorgang) > FQ_PROB.
Es gibt zwei weitere Fälle, wo ein Ladevorgang eine kleine RUW aufweisen und somit nicht umgangen werden kann. Der erste Fall ist in 5 dargestellt. Der Ladevorgang und seine Verwendungen liegen auf demselben Pfad in der dargestellten Region, aber die Frequenz ist niedrig im Vergleich zur Regionsfrequenz. In diesem Fall ist es unwahrscheinlich, daß die Anweisungs-Ablaufsteuerung 44 den Ladevorgang aus dem Niederfrequenzblock b3 in den Hochfrequenzblock b1 oder die Verwendung vom Block b3 nach b4 verschiebt, selbst wenn es eine maximale Verzögerungszeit für den Ladevorgang und die Verwendung gibt. Der zweite Fall ist in 6 dargestellt. Der Ladevorgang wird in Parallel-Pfaden verwendet, eine maximale Verzögerungszeit liegt jedoch nur bei dem selten durchlaufenen Pfad vor. In diesem Falle sollte der Ladevorgang nicht als ein freiraumqualifizierter Ladevorgang für die Region identifiziert werden, weil sonst die Ausführung des Ladevorganges auf dem häufiger durchlaufenen Pfad, in dem der Ladevorgang nicht umgangen werden sollte, benachteiligt würde.
Mit Bezug auf 7 startet die Routine Finde_FQ_Ladevorgänge_in_Region, wenn der Kandidaten-Ladeidentifikator 42 die Gruppe FQ_Ladevorgänge_Region zu einer Leermenge löscht (Block 240). Der Kandidaten-Ladeidentifikator 42 setzt dann die Regions-Frequenzvariable gleich der Frequenzvariablen, mit welcher der Eingangsblock der Region ausgeführt wird (Block 242). Für jede der Ladeanweisungen in der Region setzt dann der Kandidaten-Ladeidentifikator 42 eine zugehörige Umgehungs_Frequenz des Ladevorganges gleich Null (Block 244).
Der Kandidaten-Ladeidentifikator 42 wählt als nächstes einen der Pfade in der Region zur Analyse aus (Block 246). Er ruft dann die Routine FQ_Identifizieren (Einzelpfad) auf (Block 248). Die Routine FQ_Identifizieren (Einzelpfad) bildet dann eine Gruppe von Kandidaten-Ladevorgängen, die eine maximale Verzögerungszeit über einem bestimmten Schwellwert aufweisen. Diese Kandidaten-Ladevorgänge werden durch die Routine FQ_Identifizieren (Einzelpfad) der Gruppe FQ_Ladevorgänge zurückgegeben.
Mit Bezug auf 8 startet die Routine FQ-Identifizieren (Einzelpfad), wenn der Kandidaten-Ladeidentifikator 42 die Gruppe FQ-Ladevorgänge zu einer Leermenge löscht (Block 140), und setzt einen Schwellwert(T) für T2 ein (d. h. die Latenz des L2-Cache) (Block 142). Der Kandidaten-Ladeidentifikator 42 erzeugt dann einen Abhängigkeitsgraphen für den gerade analysierten Steuerungsablaufgraph-Pfad (Block 144). Ein exemplarischer Abhängigkeitsgraph ist in 9 dargestellt. In diesem Beispiel stellt jeder Kreis eine Anweisung dar. Numerierte Anweisungen sind zum Beispiel Verwendungsanweisungen (d. h. eine Anweisung, die Daten bearbeitet, welche zuvor in den Cache geladen wurden, wie z. B. eine Additionsanweisung). Anweisungen, die durch „Ld" gefolgt von einer Bezugsziffer gekennzeichnet sind, sind Ladeanweisungen. Eine Linie, die zwei Anweisungen verbindet, stellt eine Abhängigkeit der unteren Anweisung von der höher positionierten Anweisung im dem Graph dar. Zum Beispiel hängt in 9 die Anweisung 2 von der Anweisung 1 ab und kann somit nicht ausgeführt werden, bis die Anweisung 1 ausgeführt ist. Ist der Abhängigkeitsgraph einmal konstruiert, dann wird die Gruppe „Gesamtheit" definiert, die jede Ladeanweisung im Pfad (d. h. Ld1, Ld2, Ld3, Ld4 und Ld5) einschließt (Block 144).
Beim Block 146 bestimmt der Kandidaten-Ladeidentifikator 42, ob die Gesamtheit-Gruppe irgendwelche Glieder aufweist. Wenn nicht (Block 146), dann bricht die Routine FQ_Identifizieren (Einzelpfad) ab, und die Steuerung kehrt zum Block 250 von 7 zurück. Hat die Gesamtheit-Gruppe mindestens ein Glied (Block 146), dann löscht der Ladeidentifikator 42 die Gruppe Mögliche_Ladevorgänge zu einer Leermenge (Block 148).
Der Kandidaten-Ladeidentifikator 42 ruft einen Ladevorgang aus der Gesamtheit-Gruppe (z. B. Ld1) auf (Block 150) und berechnet die maximale Verzögerungszeit dieses Ladevorganges (Block 152). Die maximale Verzögerungszeit wird als die Differenz zwischen dem spätesten und dem frühesten Takt des Ladevorganges im Abhängigkeitsgraphen berechnet. Ist die maximale Verzögerungszeit einmal berechnet (Block 152), dann vergleicht der Kandidaten-Ladeidentifikator 42 die maximale Verzögerungszeit mit dem Schwellwert T (Block 154). Ist die maximale Verzögerungszeit größer als oder gleich dem Schwellwert T (Block 154), dann wird der Ladevorgang (z. B. Ld1) zur Gruppe Mögliche_Ladevorgänge hinzugefügt (Block 156). Ist die maximale Verzögerungszeit kleiner als der Schwellwert T (Block 154), dann ist der Ladevorgang (z. B. Ld1) kein möglicher Kandidaten-Ladevorgang und wird somit nicht zur Gruppe Mögliche-Ladevorgänge hinzugefügt. Nach dem Bestimmen, ob der Ladevorgang, der gerade analysiert wird (z. B. Ld1), eine ausreichende maximale Verzögerungszeit aufweist, um ein möglicher Kandidaten-Ladevorgang zu sein (Block 154), bestimmt der Kandidaten-Ladeidentifikator 42, ob es andere Ladeanweisungen im Abhängigkeitsgraphen gibt (Block 158). Gibt es dort andere Ladevorgänge, dann kehrt die Steuerung zum Block 150 zurück, wo die Analyse der maximalen Verzögerungszeit der nächsten Ladeanweisung beginnt. Anderenfalls, wenn die letzte Ladeanweisung analysiert worden ist (Block 158), fährt die Steuerung am Block 160 fort.
Beim Block 160 bestimmt der Kandidaten-Ladeidentifikator 42, ob die Gruppe Mögliche_Ladevorgänge irgendwelche Glieder aufweist. Weist sie keinerlei Glieder auf (Block 160), dann fährt die Steuerung am Block 172 fort, wo der Schwellwert T zum Beispiel um 1 Takt herabgesetzt wird. Der Kandidaten-Ladeidentifikator 42 bestimmt dann, ob der Schwellwert T unter einen vorgegebenen Minimalwert gefallen ist (Block 174). Wenn das so ist, dann bricht die Routine FQ_Identifizieren (Einzelpfad) ab, und die Steuerung kehrt zum Block 250 von 7 zurück. Anderenfalls kehrt die Steuerung zum Block 146 zurück. Wie Durchschnittsfachleute anerkennen werden, erhöht ein Herabsetzen des Schwellwertes T potentiell die Anzahl der Ladeanweisungen, die als mögliche Kandidaten-Ladevorgänge identifiziert werden können, weil eine geringere maximale Verzögerungszeit erforderlich ist, um so gekennzeichnet zu werden (siehe Block 154). Ein Einbringen von mehr Ladeanweisungen in die Gruppe der möglichen Kandidaten durch Herabsetzen des Schwellwertes kann die zeitliche Einplanungslänge des Programms vergrößern. Ein Eintauschen von zeitlicher Einplanungslänge für Leistungsfähigkeit des Cache kann jedoch die Gesamtleistungsfähigkeit des Programms verbessern.
Zu Block 160 zurückkehrend wählt der Kandidaten-Ladeidentifikator 42 unter der Annahme, daß die Gruppe Mögliche_Ladevorgänge nicht leer ist, einen Ladevorgang aus der Gruppe der möglichen Kandidaten (d. h. der Gruppe Mögliche_Ladevorgänge) aus (Block 162). Die optimale Lösung für eine Auswahl zwischen den möglichen Kandidaten-Ladevorgängen scheint schwierig zu sein. Je weniger Abhängigkeiten jedoch ein möglicher Kandidaten-Ladevorgang bezüglich der anderen Kandidaten-Ladevorgänge aufweist, desto weniger mögliche Kandidaten-Ladevorgänge werden durch ein Anwachsen der Latenz des Kandidaten-Ladevorganges beeinträchtigt. Weist somit ein möglicher Kandidaten-Ladevorgang keine Abhängigkeit von einem anderen Kandidaten-Ladevorgang auf, dann kann er immer als ein Kandidaten-Ladevorgang ausgewählt werden. Unter Beachtung dieser Prinzipien wählt der Kandidaten-Ladeidentifikator 42 einen Ladevorgang aus den möglichen Kandidaten-Ladevorgängen aus, wie es in 10 dargestellt ist.
Mit Bezug auf 10 beginnt der Kandidaten-Ladeidentifikator 42 den Prozeß zur Auswahl eines Ladevorganges aus den möglichen Kandidaten durch Aufstellen eines reduzierten Abhängigkeitsgraphen, wobei nur Ladeanweisungen aus der Gruppe Mögliche_Kandidaten verwendet werden (Block 180). In 11 ist ein exemplarischer reduzierter Abhängigkeitsgraph dargestellt, der auf dem Beispiel von 9 basiert. Im Beispiel von 11 wird angenommen, daß die Ladeanweisungen Ld1–Ld4 (siehe 9) in der Gruppe Mögliche_Kandidaten liegen und daß die Ladeanweisung Ld5 (siehe 9) eine unzureichende maximale Verzögerungszeit aufweist, um in diese Gruppe eingeschlossen zu werden. Sobald der reduzierte Abhängigkeitsgraph konstruiert ist (Block 180), wählt der Kandidaten-Ladeidentifikator 42 eine Ladeanweisung mit den wenigsten Abhängigkeitsflanken aus dem Graphen aus, wobei ein herkömmlicher Sortieralgorithmus (Block 182) verwendet wird. In dem Beispiel von 11 weist jede Ladeanweisung Ld1 und Ld4 eine Abhängigkeitsflanke auf, wohingegen jede Ladeanweisung Ld2 und Ld3 ohne Abhängigkeitsflanke ist. Deshalb wird der Kandidaten-Ladeidentifikator 42 eine der Ladeanweisungen Ld2 und Ld3 auswählen. Kommt es vor, daß zwei oder mehrere Ladeanweisungen die gleiche Zahl von Abhängigkeitsflanken aufweisen, dann ist die Auswahl zwischen diesen Anweisungen willkürlich.
Zur 8 zurückkehrend fügt der Kandidaten-Ladeidentifikator 42 die Ladeanweisung (z. B. Ld2) die aus der Gruppe der Möglichen_Ladevorgänge ausgewählt wurde, zur Gruppe der Kandidaten- oder freiraumqualifizierten Ladevorgänge FQ_Ladevorgänge hinzu (Block 186). Er entfernt auch den ausgewählten Ladevorgang aus der „Gesamtheit"-Gruppe (Block 188). Der Kandidaten Ladeidentifikator 42 prüft dann, um zu sehen, ob die „Gesamtheit"-Gruppe leer ist (Block 146). Wenn nicht, dann kehrt die Steuerung zum Block 148 zurück, wo die Gruppe Mögliche_Ladevorgänge gelöscht und der Prozeß zur Berechnung der Freiräume für die Ladevorgänge, die in der Gesamtheit-Gruppe verblieben sind, wiederholt wird, um zu sehen, ob irgendwelche Ladevorgänge in der Gesamtheit-Gruppe im Hinblick auf die gestiegene Latenz aufgrund des(r) Ladevorgangs(gänge), der(die) zur Gruppe FQ_Ladevorgänge hinzugefügt wurde(n), als mögliche Kandidaten-Ladevorgänge identifiziert werden sollten.
Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 146–188 fort, bis die Gesamtheit-Gruppe leer (Block 146) ist oder bis bei der Gruppe „Mögliche_Ladevorgänge" festgestellt wird, daß sie beim Block 160 kein Glied aufweist. Im ersten Fall wird der Prozeß beendet. Im zweiten Fall wird der Schwellwert T um einen Takt herabgesetzt (Block 172) und mit dem vorgegebenen Schwellwert verglichen (Block 174), wie oben erläutert wurde. Wird der Schwellwert noch übertroffen (Block 174), dann durchläuft die Steuerung die Schleife zurück zum Block 146. Anderenfalls bricht die Routine FQ_Identifizieren (Einzelpfad) ab, und die Steuerung kehrt zum Block 250 (7) zurück.
Zu 7 zurückkehrend bestimmt der Kandidaten-Ladeidentifikator 42, nachdem die Routine FQ_Identifizieren (Einzelpfad) ausgeführt ist (Block 248), ob die Gruppe FQ_Ladevorgänge irgendwelche Glieder aufweist (Block 250). Gibt es keine Glieder in der Gruppe FQ_Ladevorgänge (Block 250), dann fährt die Steuerung am Block 260 fort. Anderenfalls fährt die Steuerung am Block 252 fort.
Wird als ein Beispiel angenommen, daß die Gruppe FQ_Ladevorgänge nicht leer ist (Block 250), dann ruft der Kandidaten-Ladeidentifikator 42 einen der Kandidaten-Ladevorgänge aus der Gruppe FQ_Ladevorgänge ab (Block 252). Er fügt dann die Frequenz, mit welcher der Pfad, auf dem der Ladevorgang angeordnet ist, ausgeführt wird, zur Umgehungsfrequenz des Ladevorgangs für den Subjekt-Ladevorgang hinzu (Block 254). Der Kandidaten-Ladeidentifikator 42 bestimmt dann, ob es irgendeine andere Ladeanweisung in der Gruppe FQ_Ladevorgänge gibt (Block 256). Wenn das so ist, dann durchläuft die Steuerung nochmals die Schleife durch die Blöcke 252–256. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 252–256 fort, bis alle Ladevorgänge in FQ_Ladevorgängen analysiert wurden (Block 256).
Der Kandidaten-Ladeidentifikator 42 fügt dann die Gruppe FQ_Ladevorgänge zur Gruppe FQ_Kandidaten hinzu (Block 258) und bestimmt, ob es in der Region noch weitere Pfade zu analysieren gibt (Block 260). Gibt es mehr zu analysierende Pfade (Block 260), dann kehrt die Steuerung zum Block 246 zurück, wo dann der nächste Pfad analysiert wird, wie oben erläutert wurde. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 246–260 fort, bis jeder Pfad in der Region auf Kandidaten-Ladevorgänge hin analysiert wurde (Block 260).
Wird zur Veranschaulichung angenommen, daß die Gruppe FQ-Kandidaten nicht leer ist (Block 262), dann tritt der Kandidaten-Ladeidentifikator 42 in eine Schleife (Blöcke 264–272) ein, wo er jeden Ladevorgang in der Gruppe FQ-Kandidaten überprüft, um zu sehen, ob er eine Umgehungswahrscheinlichkeit größer als oder gleich einem vorgegebenen Wahrscheinlichkeitsschwellwert aufweist. Insbesondere ruft der Kandidaten-Ladeidentifikator 42 einen ersten Ladevorgang aus der Gruppe FQ_Kandidaten ab (Block 264). Er berechnet dann die Region-Umgehungswahrscheinlichkeit (RUW) für den Ladevorgang, indem er die Ladevorgang_Umgehungsfrequenz durch die Frequenz der Region dividiert (Block 266). Der Kandidaten-Ladeidentifikator 42 vergleicht dann die berechnete RUW mit einem Wahrscheinlichkeitsschwellwert (FQ_PROB) (Block 268). FQ_Prob ist ein Wert zwischen 0 und 1 (z. B. 0,1).
Liegt die RUW des Ladevorganges über dem Schwellwert FQ_Prob (Block 268), dann identifiziert der Ladeidentifikator 42 den Ladevorgang als einen Kandidaten-Ladevorgang, indem er ihn zu der Gruppe FQ_Ladevorgänge_Region hinzufügt (Block 270). Liegt die RUW des Ladevorganges nicht über dem Schwellwert FQ_Prob (Block 268), dann fährt die Steuerung am Block 272 fort.
Gibt es in der Gruppe FQ_Kandidaten mehr Ladevorgänge zu analysieren (Block 272), dann durchläuft die Steuerung nochmals die Schleife durch die Blöcke 264–272. Anderenfalls bricht die Routine Finde_FQ_Ladevorgänge_in_Region ab, und die Steuerung kehrt zurück zum Block 280 von 3.
Zur 3 zurückkehrend, plant die Ablaufsteuerung 44 die Region (Block 280) zeitlich ein, wenn die Routine Finde_FQ_Ladevorgänge_in_Region zurückspringt (Block 236). Dabei versucht die Ablaufsteuerung 44, eine T2-Latenz für jeden der Kandidaten-Ladevorgänge in FQ_Ladevorgänge_Region zeitlich einzuplanen. Wie oben erläutert wurde, kann die Ablaufsteuerung wegen der verschiedenen Einschränkungen zeitlich einplanen, daß keiner, einige oder alle Kandidaten-Ladevorgänge in FQ_Ladevorgänge_Region eine T2-Latenz aufweisen.
Um zu bestimmen, welche von den Ladevorgängen in der zeitlich eingeplanten Region Latenz-Umgehungsladevorgänge sind, wird die Routine Finde_LU_Ladevorgänge_in_Region aufgerufen und die Rückgabeergebnisse werden in LU_Ladevorgänge_Region angeordnet (Block 282). Liegt ein Ladevorgang auf Parallel-Steuerungsablaufpfaden einer Terminierungsregion, dann wird zuerst bestimmt, ob er ein Latenz-Umgehungsladevorgang für die einzelnen Pfade sein könnte, und dann werden die Informationen aus allen Pfaden kombiniert, um festzulegen, ob der Ladevorgang ein Latenz-Umgehungsladevorgang für die terminierte Region sein könnte. Die Lade-Umgehungswahrscheinlichkeit (LUW) ist das Verhältnis aus der Gesamtfrequenz der Pfade, auf denen der Ladevorgang umgangen werden kann, zur Ladevorgangsfrequenz. Ein Ladevorgang ist dann und nur dann ein Latenz-Umgehungsladevorgang für eine Region, wenn LUW(Ladevorgang) > LU_PROB ist, wobei LU_PROB ein Wahrscheinlichkeitsschwellwert für das Identifizieren von Latenz_Umgehungsladevorgängen ist. Es ist zu beachten, daß sich LUW etwas von RUW unterscheidet. Für den in 5 dargestellten Fall ist LUW gleich 100% und RUW nur 10%. Selbst wenn die Pfadfrequenz des Ladevorgangs klein ist im Vergleich zur Regionsfrequenz, kann der Ladevorgang noch umgangen werden, sobald die Anweisungsterminierung bereits erledigt ist und der Ladevorgang und seine Verwendung durch mindestens T2 Takte getrennt sind. Für den in 6 dargestellten Fall sind sowohl LUW als auch RUW gleich 10%.
Mit Bezug auf 12 startet die Routine Finde_LU_Ladevorgänge_in_Region, wenn der Final-Ladeidentifikator 46 die Gruppe LU_Ladevorgänge_Region zu einer Leermenge löscht (Block 340). Für alle Ladeanweisungen in der Region setzt der Final-Ladeidentifikator 46 eine zugehörige Variable Ladevorgangs_Umgehungsfrequenz gleich Null (Block 344).
Der Final-Ladeidentifikator 46 wählt als nächstes einen der Pfade in der Region für die Analyse aus (Block 346). Er ruft dann die Routine Finde_LU_Ladevorgänge_in_Pfad auf (Block 348). Die Routine Finde_LU_Ladevorgänge_in_Pfad erzeugt eine Gruppe von Latenz-Umgehungsladevorgängen, die eine zeitlich eingeplante Latenz größer als oder gleich einem bestimmten Schwellwert aufweisen. Diese Latenz-Umgehungsladevorgänge werden durch die Routine Finde_LU_Ladevorgänge_in_Pfad in die Gruppe LU_Ladevorgänge_Pfad zurückgegeben.
Zusätzlich zu den Abhängigkeitseinschränkungen der Anweisungen untereinander können viele andere Architektur- und Mikroarchitektur-Einschränkungen, wie z. B. die Gerätebreite und die Bündelungsbeschränkungen, die abschließende Ablaufsteuerung beeinflussen, nachdem die Anweisungen zeitlich eingeplant wurden. Insbesondere kann ein Ladevorgang, der nicht als freiraumqualifizierter Ladevorgang identifiziert ist, in einer solchen Weise zeitlich eingeplant werden, daß seine Ergebnisse nicht in den nächsten T2 Takten verwendet werden. Diese Ladevorgänge sollten als Latenz-Umgehungsladevorgänge identifiziert werden, welche den μCache umgehen. Treten solche Umstände auf, dann wird ein Ladevorgang, der nicht durch den Kandidaten-Ladeidentifikator 42 identifiziert wurde, als ein Latenz-Umgehungsladevorgang ausgewählt. Andererseits ist für einen Kandidaten-Ladevorgang (d. h. freiraumqualifizierten Ladevorgang), der durch den Kandidaten-Ladeidentifikator 42 ausgewählt wurde, nicht sichergestellt, daß er durch die Ablaufsteuerung 44 mit einer Latenz T2 zeitlich eingeplant wird. Die Anweisungs-Ablaufsteuerung 44 kann wegen der mikroarchitekturellen oder anderer Einschränkungen nicht in der Lage sein, die verfügbare maximale Verzögerungszeit zu nutzen. Unter solchen Umständen wird der freiraumqualifizierte Ladevorgang nicht als ein Final-Umgehungsladevorgang identifiziert.
Das Identifizieren von Latenz-Umgehungsladevorgängen ist leichter als das Identifizieren von Kandidaten-Ladevorgängen, weil die Reihenfolge der Identifizierung unwichtig ist. Ein Ladevorgang ist dann und nur dann ein Latenz-Umgehungsladevorgang, wenn alle seine Verwendungen mindestens T2 Takte nach der Subjekt-Ladeanweisung zeitlich eingeplant sind, unabhängig von anderen Latenz-Umgehungsladevorgängen.
Mit Bezug auf 13 wird die Routine Finde_LU_Ladevorgänge_in_Pfad gestartet, wenn der Final-Ladeidentifikator 46 einen Abhängigkeitsgraphen für den Pfad erstellt (Block 200). Der Abhängigkeitsgraph ist ähnlich zu dem in 9 dargestellten, außer daß in diesem Beispiel der Abhängigkeitsgraph auf der zeitlichen Planung basiert, die durch die Ablaufsteuerung 44 entwickelt ist. Deshalb unterscheidet sich die Reihenfolge der Lade- und Verwendungsanweisungen in dem bei Block 202 entwickelten Abhängigkeitsgraphen üblicherweise von der Reihenfolge der Schritte im Abhängigkeitsgraphen, der bei Block 144 von 8 entwickelt wird.
Sobald der Abhängigkeitsgraph entwickelt ist (Block 200), löscht der Final-Ladeidentifikator 46 die Gruppe LU_Ladevorgänge_Pfad zu einer Leermenge (Block 202). Der Final-Ladeidentifikator 46 bestimmt dann, ob es irgendwelche Ladevorgänge auf dem Pfad gibt (Block 203). Gibt es keine Ladevorgänge auf dem Pfad (Block 203), dann bricht die Routine Finde_LU_Ladevorgänge_in_Pfad ab. Anderenfalls ruft der Final-Ladeidentifikator 46 den ersten zeitlich eingeplanten Ladevorgang auf dem Pfad ab, um zu bestimmen, ob er ein Latenz-Umgehungsladevorgang ist, wie unten erläutert wird (Block 204). Insbesondere wird die letzte Anweisung auf dem Pfad identifiziert (Block 206). Wenn die Anzahl der Takte zwischen der gerade analysierten Ladeanweisung und der letzten Anweisung (zuzüglich der Latenz der letzten Anweisung) kleiner ist als ein vorgegebener Schwellwert (z. B. T2) (Block 208), dann führt die Steuerung am Block 220 fort. Gibt es keine weiteren Ladeanweisungen auf dem Pfad (Block 220), dann bricht die Routine Finde_LU_Ladevorgänge_in_Pfad ab. Anderenfalls geht die Steuerung zum Block 204 zurück.
Unter der Annahme, daß die Anzahl von Takten zwischen der gerade analysierten Ladeanweisung und der letzten Anweisung (plus der Latenz der letzten Anweisung) größer als oder gleich dem Schwellwert ist (Block 208), bestimmt der Final-Ladeidentifikator 46, ob die durch die Subjekt-Ladeanweisung geladenen Daten durch eine Anweisung in dem Pfad verwendet werden (Block 210). Werden diese Daten nicht verwendet (Block 210), dann fährt die Steuerung am Block 222 fort, wo die Ladeanweisung als eine Latenz-Umgehungsladeanweisung identifiziert wird. Anderenfalls fährt die Steuerung am Block 212 fort.
Unter der Annahme, daß der Ladevorgang verwendet wird (Block 210), bestimmt der Final-Ladeidentifikator 46, ob die zeitlich eingeplante Latenz zwischen irgendeiner Anweisung, welche die durch die Ladeanweisung geladenen Daten verwendet, und der Ladeanweisung selbst kleiner ist als der Schwellwert (Block 214). Wenn ja, dann ist die Ladeanweisung keine Latenz-Umgehungsladeanweisung, so daß die Steuerung die durch die Blöcke 212–216 definierte Schleife verläßt, wobei der Final-Ladeidentifikator 46 bestimmt, ob es noch irgendwelche weiteren Ladeanweisungen im Abhängigkeitsgraphen gibt, die zu analysieren sind (Block 220). Wenn jedoch die Anzahl der Takte zwischen einer Ladeanweisung und jeder einzelnen Verwendungsanweisung auf dem Pfad, welche die von der Ladeanweisung geladenen Daten bearbeitet, größer als oder gleich dem Schwellwert (z. B. T2) ist (Block 216), dann fügt der Final-Ladeidentifikator 46 diese Ladeanweisung zu der Gruppe LU_Ladevorgänge_Pfad hinzu (Block 222). Die Steuerung fährt dann am Block 220 fort.
Genauer gesagt ruft der Final-Ladeidentifikator 46 beim Block 212 die erste Verwendungsanweisung ab, die mit den Daten arbeitet, welche durch die Subjekt-Ladeanweisung geladen wurden. Der Final-Ladeidentifikator 46 bestimmt dann, ob die Anzahl von Takten zwischen der Subjekt-Ladeanweisung und der Verwendungsanweisung größer als oder gleich dem Schwellwert (z. B. T2) ist (Block 214). Wenn ja, dann fährt die Steuerung am Block 220 fort. Anderenfalls bestimmt der Final-Ladeidentifikator 46, ob die durch die Ladeanweisung geladenen Daten durch irgendeine andere Verwendungsanweisung in dem Pfad verwendet werden (Block 216). Werden die Daten durch eine andere Anweisung verwendet (Block 218), dann kehrt die Steuerung zum Block 212 zurück, wo diese Verwendungsanweisung (Block 218) aufgerufen (Block 212) und analysiert wird (Block 214), wie oben erläutert wurde. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 204–222 fort, bis jede Ladeanweisung auf dem Pfad analysiert wurde (Block 220). Sobald diese Analyse abgeschlossen ist, endet die Routine LU_Ladevorgänge_in_Pfad, und die Steuerung kehrt zum Block 350 (12) zurück.
Nachdem die Routine Finde_LU_Ladevorgänge_in_Pfad ausgeführt ist (Block 348), bestimmt der Final-Ladeidentifikator 46, ob die Gruppe LU-Ladevorgänge_Pfad irgendwelche Glieder hat (Block 350). Gibt es in der Gruppe LU_Ladevorgänge_Pfad keine Glieder (Block 350), dann fährt die Steuerung am Block 360 fort. Anderenfalls fährt die Steuerung am Block 352 fort.
Wird als ein Beispiel angenommen, daß die Gruppe LU_Ladevorgänge_Pfad nicht leer ist (Block 350), dann ruft der Final-Ladeidentifikator 46 einen der finalen Ladevorgänge aus der Gruppe LU_Ladevorgänge_Pfad ab (Block 352). Er fügt dann die Frequenz, mit welcher der Pfad, auf dem der Ladevorgang angeordnet ist, ausgeführt wird, zur Umgehungs_Frequenz des Ladevorgangs (Block 354) hinzu. Der Final-Ladeidentifikator 46 bestimmt dann, ob es irgendeine andere Ladeanweisung in der Gruppe LU_Ladevorgänge_Pfad gibt (Block 356). Wenn ja, dann durchläuft die Steuerung erneut die Schleife durch die Blöcke 352–356. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 352–356 fort, bis alle Ladevorgänge in LU_Ladevorgänge_Pfad analysiert wurden (Block 356).
Der Final-Ladeidentifikator 46 setzt dann LU_Kandidaten auf LU_Ladevorgänge_Pfad (Block 358) und bestimmt, ob es noch weitere zu analysierende Pfade in der Region gibt (Block 360). Gibt es weitere zu analysierende Pfade (Block 360), dann kehrt die Steuerung zum Block 346 zurück, wo dann der nächste Pfad analysiert wird, wie oben erläutert wurde. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 346–360 fort, bis jeder Pfad in der Region nach Kandidaten-Ladevorgängen untersucht wurde (Block 360).
Wurden alle Pfade derart analysiert(Block 360), dann prüft der Final-Ladeidentifikator 46, um zu bestimmen, ob die Gruppe LU_Kandidaten irgendwelche Glieder enthält (Block 362). Enthält sie keine Glieder (Block 362), dann gibt es keine Kandidaten-Ladevorgänge in der Region, die Routine Finde_LU_Ladevorgänge_in_Region bricht ab, und die Steuerung kehrt zum Block 380 in 3 zurück.
Wird zur Veranschaulichung angenommen, daß die Gruppe LU_Kandidaten nicht leer ist (Block 362), dann tritt der Final-Ladeidentifikator 46 in eine Schleife (Blöcke 364–372) ein, wo er jeden Ladevorgang in der Gruppe LU_Kandidaten analysiert, um zu sehen, ob er eine Umgehungswahrscheinlichkeit größer als oder gleich einem vorgegebenen Schwellwert aufweist. Insbesondere ruft der Final-Ladeidentifikator 46 einen ersten Ladevorgang aus der Gruppe LU_Kandidaten ab (Block 364). Er berechnet dann die Region-Latenz-Umgehungswahrscheinlichkeit (LUP) für den Ladevorgang, indem er die Umgehungs_Frequenz des Ladevorgangs durch die Frequenz dividiert, mit welcher der Ladevorgang ausgeführt wird, Ladevorgang_Frequenz, (Block 366). Der Final-Ladeidentifikator 46 vergleicht dann die berechnete LUP mit einem Wahrscheinlichkeitsschwellwert (LU_PROB) (Block 368). LU_Prob ist ein Wert zwischen 0 und 1 (z. B. 0,1).
Wenn die LUP des Ladevorgangs den Schwellwert LU_Prob überschreitet (Block 368), dann identifiziert der Final-Ladeidentifikator 46 den Ladevorgang als einen Latenz-Umgehungsladevorgang, indem er ihn zu der Gruppe LU_Ladevorgänge_Region hinzufügt (Block 370). Überschreitet die LUP des Ladevorganges nicht den Schwellwert LU_Prob (Block 368), dann fährt die Steuerung am Block 372 fort.
Sind in der Gruppe LU_Kandidaten mehr Ladevorgänge zu analysieren (Block 372), dann durchläuft die Steuerung erneut die Schleife durch die Blöcke 364–372. Anderenfalls bricht die Routine Finde_LU_Ladevorgänge_in_Region ab, und die Steuerung kehrt zum Block 380 von 3 zurück. Der Final-Ladeidentifikator 46 identifiziert dann die Latenz-Umgehungsladevorgänge in der Gruppe LU_Ladevorgänge_Region als Final-Umgehungsladevorgänge, indem er diese Ladevorgänge in die Gruppe Final Umgehungs_Ladevorgänge einordnet (Block 380).
Wurde jede Region in dem Software-Programm analysiert (Block 381), dann fährt die Steuerung am Block 382 fort. Anderenfalls kehrt die Steuerung zum Block 236 zurück, wo die nächste Region analysiert wird, wie oben erläutert wurde. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 236–381 fort, bis das gesamte Software-Programm terminiert ist.
Unter der Annahme, daß das gesamte Software-Programm terminiert und nach Latenz-Umgehungsladevorgängen untersucht ist (Block 381), wandelt der Objektcodeerzeuger 48 dann terminierte Software-Programm in Objektcode um (Block 382). Der Objektcode wird dann ausgeführt. Das Programm ist profiliert, die Verfehlungs-Umgehungs-Ladevorgänge zu identifizieren, die häufig den μCache verfehlen und nicht wiederverwendet werden. Das Cache-Profiling erfaßt für jeden Ladevorgang die Zahl, wie oft der Ladevorgang den μCache verfehlt hat und die geladene Cache-Leitung nicht wiederverwendet wird. Es erfaßt auch die Gesamtzahl, wie oft der Ladevorgang ausgeführt wird. Der von Johnson u. a. vorgeschlagene Algorithmus Run-time cache bypassing, IEEE Transactions On Computers, Band 48, Nr. 12; Dez. 1999, wird verwendet, um Verfehlungs-Umgehungs-Ladevorgänge zu identifizieren, die den μCache verfehlen und nicht wiederverwendet werden. Die Gruppe von Ladevorgängen in Final_Umgehungs_Ladevorgänge ist nicht profiliert und greift während des Cache-Profiling nicht auf den μCache zu.
Ein Ladevorgang kann nur während eines Teils seiner Ausführung den μCache verfehlen und nicht wiederverwendet werden. Die Wahrscheinlichkeit für das Verfehlen und Nicht-Wiederverwenden (VNWP) ist das Verhältnis aus der Zahl, wie oft ein Ladevorgang den μCache verfehlt und nicht wiederverwendet wird, zur Gesamtzahl, wie oft der Ladevorgang ausgeführt wird. Ein Ladevorgang ist dann und nur dann ein Verfehlungs-Umgehungs-Ladevorgang, wenn VNWP(Ladevorgang) > VU_PROB ist, wobei VU_PROB ein Schwellwert für die Verfehlungs-Umgehungs-Ladevorgänge ist. Diesen Verfehlungs-Umgehungs-Ladevorgängen werden Latenzen T2 zugewiesen, und sie werden durch μCache-Umgehungsflags gekennzeichnet.
Es ist zu beachten, daß sich die Gruppe von Verfehlungs-Umgehungs-Ladevorgängen mit der Gruppe der fortschreitenden Ladevorgänge überlappen kann. Wenn eine Ladeanweisung, wie oben erläutert wurde, durch den μCache hindurchläuft, wird sie als ein fortschreitender Ladevorgang identifiziert. Fortschreitende Ladevorgänge sind leichter zu identifizieren als Verfehlungs-Umgehungs-Ladevorgänge.
Wenn die Profildaten kompiliert sind, wird der zweite Kompilierungsdurchlauf gestartet (Block 386), indem die Routine Finde_VU_Ladevorgänge aufgerufen wird (Block 388). Wie in 14 gezeigt ist, startet die Routine Finde_VU_Ladevorgänge, wenn der Verfehlungs-Umgehungs-Ladeidentifikator 52 entscheidet, ob es irgendwelche profilierten Ladeanweisungen im gerade analysierten Software-Programm gibt (Block 390). Gibt es keine solchen Anweisungen (Block 390), dann bricht die Routine Finde_VU_Ladevorgänge ab, und die Steuerung kehrt zum Block 408 von 3 zurück.
Wird zu Erläuterungszwecken angenommen, daß es in der Software profilierte Ladeanweisungen gibt (Block 390), dann löscht der Verfehlungs-Umgehungs-Ladeidentifikator 52 die Gruppe VU_Ladevorgänge zu einer Leermenge (Block 392). Er ruft dann die erste profilierte Ladeanweisung in dem Software-Programm auf (Block 394). Der Verfehlungs-Umgehungs-Ladeidentifikator 52 teilt dann die Zahl, wie oft die Ladeanweisung den μCache ohne ein Wiederverwenden der geladenen Daten verfehlt hat, durch die Frequenz, mit der diese Ladeanweisung ausgeführt worden ist (Ladevorgang_Frequenz), um eine Wahrscheinlichkeit für das Verfehlen und Nicht-Wiederverwenden (VNWP) zu bestimmen (Block 396).
Der Verfehlungs-Umgehungs-Ladeidentifikator 52 vergleicht dann den berechneten VNWP-Wert mit einem Schwellwert (VU_PROB) (Block 398). Liegt der VNWP des gerade analysierten Ladevorganges über dem Schwellwert (Block 398), dann ist die Ladeanweisung durch Hinzufügen des Ladevorganges als eine Verfehlungs-Umgehungs(VU)-Anweisung identifiziert, indem der Ladevorgang zu der Gruppe VU_Ladevorgänge hinzugefügt wird (Block 400). Liegt die VNWP des Ladevorganges nicht über dem Schwellwert LU_Prob (Block 398), dann wird der Block 400 übersprungen und die Steuerung fährt am Block 402 fort.
Beim Block 402 bestimmt der Verfehlungs-Umgehungs-Ladeidentifikator 52, ob es weitere profilierte Ladeanweisungen gibt, die zu analysieren sind. Wenn ja, dann kehrt die Steuerung zum Block 394 zurück. Anderenfalls bricht die Routine Finde_VU_Ladevorgänge ab. Die Steuerung setzt den Schleifendurchlauf durch die Blöcke 394–402 fort, bis alle Ladevorgänge analysiert sind (Block 402).
Zu 3 zurückkehrend werden nach dem Abbruch der Routine Finde_–VU_Ladevorgänge die Verfehlungs-Umgehungs(VU)-Ladevorgänge zu der Gruppe Final_Umgehungs_Ladevorgänge hinzugefügt (Block 408). Der Objektcodeerzeuger 48 erzeugt dann den Objektcode für die Software mit den in der Gruppe Final_Umgehungs_Ladevorgänge identifizierten Ladevorgängen, die für ein Umgehen des μCache gekennzeichnet sind. Der Prozeß von 3 ist dann abgeschlossen.
Die Gruppen von Kandidaten-Ladevorgängen und Latenz-Umgehungsladevorgängen sind – unabhängig von den Cache-Konfigurationen – intrinsisch für das Anwendungsprogramm und die verwendeten Compileroptimierungen. Andererseits sind die Gruppen von fortschreitenden und Verfehlungs-Umgehungs-Ladevorgängen eine Funktion der Cache-Konfigurationen. Mit einem kleineren μCache werden mehr Ladevorgänge eine fortschreitende Arbeitsgruppengröße aufweisen, die größer ist als die Größe des μCache, und potenziell können mehr fortschreitende Ladevorgänge identifiziert werden, daß sie den μCache umgehen. Ebenso werden bei einem kleineren μCache mehr Ladevorgänge den μCache verfehlen, und potenziell können mehr Verfehlungs-Umgehungs-Ladevorgänge identifiziert werden.
Es ist zu beachten, daß der Compiler einen Ladevorgang entweder als den μCache umgehend oder den μCache nicht umgehend, aber nicht beides kennzeichnen kann. Es kann vorkommen, daß eine Ladeanweisung nur längs einiger Ausführungspfade umgangen und längs anderer Pfade nicht umgangen werden kann. Mit anderen Worten, die Umgehungswahrscheinlichkeit eines Kandidaten-(freiraumqualifizierten)Ladevorganges und/oder eines Latenz-Umgehungsladevorganges kann kleiner als 100% sein. Experimentelle Ergebnisse weisen darauf hin, daß ein Ladevorgang gewöhnlich eine Umgehungswahrscheinlichkeit entweder größer als 90% oder kleiner als 10% aufweist. Diese bimodale Eigenschaft ermöglicht es, daß eine einfache Compiler-Heuristik, welche Ladevorgänge mit einer Umgehungswahrscheinlichkeit von 50% auswählt, gut funktioniert.
Ebenso kann das Cache-Profiling festlegen, daß eine Ladeanweisung zeitweise umgangen werden kann. Experimentelle Ergebnisse weisen darauf hin, daß die Umgehungswahrscheinlichkeit eines Verfehlungs-Umgehungs-Ladevorganges gewöhnlich gering ist. Nur ein geringer Prozentanteil der Ladevorgänge weist eine Umgehungswahrscheinlichkeit größer als 50% auf. Für den Rest der Ladevorgänge kann eine statische Kennzeichnung, daß sie den μCache umgehen, ineffektiv sein, und es kann ein dynamischeres Schema notwendig werden.
Eine interessante Beobachtung ist, daß trotz der Abnahme der μCache-Verfehlungen durch das μCache-Umgehen die umgeleiteten Ladevorgänge die Cache-Verfehlungen im L2- oder L3-Cache nicht steigern. Das ist von Bedeutung, weil ein Ladevorgang, der den μCache umgeht, immer auf den L2-Cache zugreifen wird. Damit das Umgehen des μCache die Leistungsfähigkeit verbessert, sollten die umgeleiteten Ladevorgänge nicht die L2- oder L3-Cache-Verfehlungen steigern. Ein Teil der Erklärung dieser Unabhängigkeitseigenschaft liegt im Inklusivcharakter der Cache-Konfiguration.
Experimente zeigen, daß das durch den Compiler organisierte Umgehen die Anzahl der Verfehlungen sowie die Verfehlungsrate des μCache verringern kann. Im Mittel wird bei etwa 40%, 30%, 24% und 22% von Referenz-Ladevorgängen nachgewiesen, daß sie die jeweiligen μCaches mit 256 Byte, 1 KByte, 4 KByte bzw. 8 KByte umgehen. Das verringert die Anzahl von μCache-Verfehlungen um 64%, 53%, 45% und 43%, die μCache-Verfehlungsraten um 39%, 32%, 28% und 26% sowie die Gesamtzahl von Ladevorgang-Verwendung-Haltetakten um 13%, 9%, 6% und 5%. Indessen wird die zeitliche Einplanungslänge des Programms in der vorläufigen Implementierung nur um 3% vergrößert, und die L2- sowie L3-Cache-Verfehlungen bleiben kaum verändert.
Obwohl hier eine bestimmte Vorrichtung beschrieben wurde, die in Übereinstimmung mit den Erkenntnissen der Erfindung konstruiert ist, ist der Geltungsbereich dieses Patentes nicht darauf beschränkt. Im Gegenteil, dieses Patent umfaßt alle Ausführungsformen der Erkenntnisse aus der Erfindung, die entweder wortwörtlich oder nach dem Äquivalenzprinzip in den Geltungsbereich der angefügten Ansprüche fallen.

Claims

Verfahren zum Kompilieren eines Software-Programms für einen Prozessor mit einer Speicherhierarchie mit einem ersten Cache-Speicher mit einer ersten Speicherzugriffs-Latenz und einem zweiten Cache-Speicher mit einer zweiten Speicherzugriffs-Latenz, wobei die erste Speicherzugriffs-Latenz kleiner ist als die zweite Speicherzugriffs-Latenz, wobei das Verfahren dazu dient, Fehlzugriffe auf den ersten Cache-Speicher zu reduzieren, und die folgenden Schritte aufweist: a) Identifizieren einer Ladeanweisung in dem Software-Programm, die eine maximale Verzögerungszeit aufweist, die größer oder gleich der Speicherzugriffs-Latenz des zweiten Cache-Speichers ist, wobei die maximale Verzögerungszeit als die Zeitdifferenz zwischen einem möglichst späten Takt, der zur Ladeanweisung zugehörigen Verwendungsanweisung und einem möglichst frühen Takt der Ladeanweisung in einem Abhängigkeitsgraphen zu einem Steuerungsablaufgraph-Pfad des Software-Programms berechnet wird; b) Zeitliches Einplanen des Software-Programms, wobei versucht wird, die identifizierte Ladeanweisung möglichst mit einer Latenz entsprechend der zweiten Speicherzugriffs-Latenz zeitlich einzuplanen; c) Kennzeichnen der identifizierten, eingeplanten Ladeanweisung für ein Umgehen des ersten Cache-Speichers, wenn die Latenz der identifizierten, eingeplanten Ladeanweisung größer als oder gleich der zweiten Speicherzugriffs-Latenz ist; und d) Umwandeln des Software-Programms in ausführbaren Objektcode, wobei der Objektcode die identifizierte Ladeanweisung enthält, die in Schritt c) gekennzeichnet wurde, den ersten Cache zu umgehen.
Verfahren nach Anspruch 1, wobei das Identifizieren der Ladeanweisung ferner ein Identifizieren der Ladeanweisungen in Schritt a) Ladeanweisungen, wenn eine Umgehungswahr scheinlichkeit der Ladeanweisung größer als oder gleich einem Wahrscheinlichkeitsschwellwert ist, umfaßt.
Verfahren nach Anspruch 1, wobei das Kennzeichnen der Ladeanweisung in Schritt c) ein Kennzeichnen der identifizierten Ladeanweisung, den ersten Cache zu umgehen, wenn eine Umgehungswahrscheinlichkeit der Ladeanweisung größer als oder gleich einem Wahrscheinlichkeitsschwellwert ist, umfasst.
Verfahren nach Anspruch 1, wobei das Kennzeichnen in Schritt c) ein Bestimmen einer Zeitdifferenz zwischen der Ladeanweisung und einer Verwendungsanweisung, welche die von der Ladeanweisung geladenen Daten verarbeitet, und das Vergleichen der bestimmten Zeitdifferenz mit der zweiten Speicherzugriffs-Latenz umfasst.
Verfahren nach Anspruch 1, wobei das Kennzeichnen der identifizierten Ladeanweisung in Schritt c) das Setzen eines Flag in der Ladeanweisung umfasst.
Verfahren nach Anspruch 1, außerdem mit den Schritten: e) Identifizieren einer fortschreitenden Ladeanweisung, die in einer Schleife angeordnet ist; f) Bestimmen, ob die identifizierte fortschreitende Ladeanweisung mehr als einen vorgegebenen Umfang des ersten Cache benutzt, wenn die Schleife ausgeführt wird; und g) Kennzeichnen der identifizierten fortschreitenden Ladeanweisung, den ersten Cache zu umgehen, wenn die fortschreitende Ladeanweisung mehr als den vorgegebenen Umfang des ersten Cache verwendet.
Verfahren nach Anspruch 6, wobei das Bestimmen in Schritt e) die folgenden Schritte umfasst: – Bestimmen einer Anzahl von Durchläufen durch die Schleife, in welcher die identifizierte fortschreitende Ladeanweisung ausgeführt wird; – Multiplizieren der Anzahl von Durchläufen mit einem Schritt, welcher der identifizierten fortschreitenden Ladeanweisung zugeordnet ist, um einen Schrittgrößenwert abzuleiten; – Dividieren des Schrittgrößenwertes durch einen Wert, der repräsentativ für eine Größe des ersten Cache ist, um einen Speichemutzungsprozentanteil abzuleiten; und – Vergleichen des Speichemutzungsprozentanteils mit dem vorgegebenen Umfang des ersten Cache.
Verfahren nach Anspruch 1, außerdem mit den Schritten: e) Ausführen des Objektcodes zum Entwickeln von Profildaten; f) Identifizieren einer zweiten Ladeanweisung, welche den ersten Cache verfehlt, und, g) wenn eine durch die zweite Ladeanweisung geladene Cache-Leitung nicht durch eine weitere Ladeanweisung verwendet wird; g1) Dividieren einer Zahl, wie oft die zweite Ladeanweisung den ersten Cache verfehlt, ohne dass die durch die zweite Ladeanweisung geladene Cache-Leitung durch eine weitere Ladeanweisung verwendet wird, durch eine Zahl, wie oft die zweite Ladeanweisung ausgeführt wird, um einen Verhältniswert abzuleiten; und g2) Kennzeichnen der zweiten Ladeanweisung, den ersten Cache zu umgehen, wenn der -Verhältniswert größer als oder gleich einem vorgegebenem Verhältnis-Schwellwert ist.
Verfahren nach Anspruch 8, außerdem mit dem Schritt: Erzeugen von Objektcode aus der Software, nachdem die zweite Ladeanweisung für ein Umgehen des ersten Cache gekennzeichnet wurde.
Verfahren nach einem der vorangehenden Ansprüche, wobei anstelle einer Ladeanweisung in Schritt a) eine Gruppe von Ladeanweisungen identifiziert wird und die Schritte b)–d) für die Gruppe von Ladeanweisungen durchgeführt werden.
Verfahren nach Anspruch 10, außerdem umfassend: Erfassen von Cache-Profiling-Daten durch Ausführen des Objektcodes; und Verwenden der Cache-Profiling-Daten, um zu versuchen, eine zusätzliche Ladeanweisung für ein Umgehen des ersten Cache zu identifizieren.
Vorrichtung zum Ausführen eines Verfahrens nach einem der vorangehenden Ansprüche, umfassend: – einen Kandidaten-Ladeidentifikator (42) zum Identifizieren von Kandidaten-Ladeanweisungen für ein mögliches Umgehen des ersten Cache, wobei jede der identifizierten Kandidaten-Ladeanweisungen eine maximale Verzögerungszeit aufweist, die größer oder gleich der Speicherzugriffs-Latenz des zweiten Cache-Speichers ist, wobei die maximale Verzögerungszeit als die Zeitdifferenz zwischen einem möglichst späten Takt, der zur Ladeanweisung zugehörigen Verwendungsanweisung und einem möglichst frühen Takt der Ladeanweisung in einem Abhängigkeitsgraphen zu einem Steuerungsablaufgraph-Pfad des Software-Programms berechnet wird; – eine Ablaufsteuerung (44) zum zeitlichen Planen des Software-Programms, wobei die Ablaufsteuerung (44) versucht, jede der identifizierten Ladeanweisungen derart zeit- lich einzuplanen, dass sie eine Latenz größer als oder gleich einem vorgegebenen Schwellwert aufweist; – einen Final-Ladeidentifikator (46) zum selektiven Kennzeichnen der zeitlich eingeplanten Ladeanweisungen für ein Umgehen des ersten Cache, wenn die Latenz der identifizierten, zeitlich eingeplanten Ladeanweisung größer als oder gleich der zweiten Speicherzugriffs-Latenz ist; und – einen Objektcodeerzeuger (48) zum Entwickeln von Objektcode aus dem zeitlich geplanten Software-Programm, wobei der Objektcode die Ladeanweisungen enthält, die durch den Final-Ladeidentifikator (46) gekennzeichnet wurden, den ersten Cache zu umgehen.
Vorrichtung nach Anspruch 12, wobei der Kandidaten-Ladeidentifikator (42) Ladeanweisungen als Kandidaten-Ladeanweisungen identifiziert, die eine Umgehungswahrscheinlichkeit größer als oder gleich einem zweiten vorgegebenen Schwellwert aufweisen.
Vorrichtung nach Anspruch 12, wobei der Final-Ladeidentifikator (46) die tatsächliche Latenz der identifizierten, eingeplanten Ladeanweisung bestimmt, indem er eine Zeitdifferenz zwischen der identifizierten, eingeplanten Ladeanweisung und einer Verwendungsanweisung bestimmt, welche die von der identifizierten, eingeplanten Ladeanweisung geladenen Daten verarbeitet.
Vorrichtung nach Anspruch 12, wobei der Final-Ladeidentifikator (46) die Ladeanweisungen für ein Umgehen des ersten Cache kennzeichnet, indem er ein Flag in jede der zu kennzeichnenden Ladeanweisungen setzt.
Vorrichtung nach Anspruch 12, außerdem einen Fortschreitend-Ladeidentifikator (50) umfassend, um eine fortschreitende Ladeanweisung zu kennzeichnen, den ersten Cache zu umgehen, wenn (1) die fortschreitende Ladeanweisung in einer Schleife angeordnet ist und (2) die fortschreitende Ladeanweisung mehr als einen vorgegebenen Umfang des ersten Cache verwendet, wenn die Schleife ausgeführt wird.
Vorrichtung nach Anspruch 16, wobei der Fortschreitend-Ladeidentifikator (50) ausgebildet ist, zu bestimmen, ob die fortschreitende Ladeanweisung mehr als den vorgegebenen Umfang des ersten Cache verwendet, wenn die Schleife ausgeführt wird, durch: – (1) Bestimmen einer Anzahl von Durchläufen durch die Schleife, in welcher die fortschreitende Ladeanweisung ausgeführt wird; – (2) Multiplizieren der Anzahl von Durchläufen mit einem der fortschreitenden Ladeanweisung zugeordneten Schritt, um einen Schrittgrößenwert abzuleiten; – (3) Dividieren des Schrittgrößenwertes durch einen Wert, der repräsentativ für eine Größe des ersten Cache ist, um einen Speichernutzungsprozentanteil abzuleiten; und – (4) Vergleichen des Speichernutzungsprozentanteils mit dem vorgegebenen Umfang des ersten Cache.
Vorrichtung nach Anspruch 12, außerdem einen Verfehlungs-Umgehungs-Ladeidentifikator (52) umfassend, um eine Verfehlungs-Umgehungs-Ladeanweisung zu identifizieren, welche den ersten Cache verfehlt und wobei eine durch Verfehlungs-Umgehungs-Ladeanweisung geladene Cache-Leitung nicht wiederverwendet wird.
Vorrichtung nach Anspruch 18, wobei der Verfehlungs-Umgehungs-Ladeidentifikator (52) (1) eine Zahl (a), wie oft die Verfehlungs-Umgehungs-Ladeanweisung den ersten Cache verfehlt, ohne dass die durch die Verfehlungs-Umgehungs-Ladeanweisung geladene Cache-Leitung wiederverwendet wird, durch eine Zahl (b), wie oft die Verfehlungs-Umgehungs-Ladeanweisung ausgeführt wird, dividiert, um einen Verhältniswert abzuleiten; und (2) die Verfehlungs-Umgehungs-Ladeanweisung kennzeichnet, den ers ten Cache zu umgehen, wenn der Verhältniswert größer als oder gleich einem vorgegebenen Verhältnis-Schwellwert ist.
Vorrichtung nach Anspruch 19, wobei der Objektcodeerzeuger (48) Objektcode erzeugt, der die gekennzeichnete Verfehlungs-Umgehungs-Ladeanweisung einschließt.
Medium, das maschinenlesbare Anweisungen speichert, die beim Ausführen durch einen Rechner ein Verfahren nach einem der Ansprüche 1 bis 11 durchführen.