DE112013000654T5

DE112013000654T5 - Verzweigungsvorhersagelogik

Info

Publication number: DE112013000654T5
Application number: DE201311000654
Authority: DE
Inventors: c/o IBM Corporation Schardt Paul; c/o IBM Corporation Shearer Robert; c/o IBM Corporation Tubbs Matthew; c/o IBM Corporation Muff Adam
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-01-23
Filing date: 2013-01-02
Publication date: 2014-11-13
Also published as: US9032191B2; GB201412914D0; CN104067227A; US20130191824A1; GB2512011B; WO2013111022A1; GB2512011A; CN104067227B

Abstract

Ein Hypervisor und ein oder mehrere Gastbetriebssysteme, die sich resident in einem Datenverarbeitungssystem befinden und durch den Hypervisor gehostet werden, sind so gestaltet, dass eine Verzweigungsvorhersagelogik durch getrennte Hypervisormodus- und Gastmodus-Anweisungen selektiv aktiviert oder deaktiviert wird. Dadurch können unterschiedliche Verzweigungsvorhersagestrategien für unterschiedliche Betriebssysteme und von ihnen gehostete Benutzeranwendungen genutzt werden, um eine feiner abgestimmte Optimierung der Verzweigungsvorhersagelogik für unterschiedliche Betriebsszenarien bereitzustellen.

Description

Technisches Gebiet
Die Erfindung betrifft allgemein die Datenverarbeitung und insbesondere hierbei verwendete Prozessorarchitekturen und Verzweigungsvorhersagelogik.
Hintergrund
Da sich die Halbleitertechnologie langsam den praktischen Grenzen hinsichtlich der Erhöhung der Taktgeschwindigkeit nähert, konzentrieren sich Entwickler zunehmend auf die Parallelität bei Prozessorarchitekturen, um Leistungsverbesserungen zu erzielen. Auf der Chipebene sind mehrere Verarbeitungskerne oftmals auf demselben Chip angeordnet, sodass sie fast wie getrennte Prozessorchips oder bis zu einem gewissen Maß wie vollständig voneinander getrennte Computer funktionieren. Darüber hinaus wird selbst innerhalb von Kernen die Parallelität durch die Verwendung mehrerer Ausführungseinheiten genutzt, die auf die Bewältigung bestimmter Arten von Operationen spezialisiert sind. Auch wird in vielen Fällen das Pipelining verwendet, sodass bestimmte Operationen, die zur Durchführung unter Umständen mehrere Taktzyklen benötigen, in Stadien aufgeteilt werden, wodurch andere Operationen vor dem Abschluss früherer Operationen gestartet werden können. Multithreading wird ebenfalls genutzt, um mehrere Anweisungsdatenströme parallel verarbeiten zu können, sodass bei einem beliebigen vorgegebenen Taktzyklus insgesamt mehr Arbeitsaufgaben durchgeführt werden können.
Ein weiterer Bereich, in dem Fortschritte bei der Prozessorgestaltung gemacht worden sind, ist der Bereich der Verzweigungsvorhersage, die vor der Ausführung einer bedingten Verzweigungsanweisung auf der Grundlage des Ergebnisses eines bestimmten Vergleichs, der im Zusammenhang mit der Verzweigungsanweisung durchgeführt wird, vorherzusagen versucht, ob diese Verzweigungsanweisung zu einem anderen Codepfad verzweigt oder auf demselben Codepfad verbleibt. Eine Verzweigungsvorhersage kann zum Beispiel verwendet werden, um aus einem Cache-Zwischenspeicher oder aus einem Speicher unterer Ebenen Anweisungen vorab abzurufen, um die Latenz beim Laden und Ausführen dieser Anweisungen zu verringern, wenn die Verzweigungsanweisung endgültig aufgelöst wird. Außerdem kann die Verzweigungsvorhersage bei Architekturen mit stark ausgeprägtem Pipelining verwendet werden, um die Ausführung von Anweisungen aus einer vorhergesagten Verzweigung auszulösen, bevor eine Verzweigungsanweisung aufgelöst wird, sodass die Ergebnisse dieser Anweisungen sobald wie möglich festgeschrieben werden können, nachdem die Verzweigungsanweisung aufgelöst wurde.
Wenn eine Verzweigung korrekt vorhergesagt wird, können erhebliche Leistungsgewinne erzielt werden, da unter Umständen eine sehr kleine Latenz zwischen dem Ausführen der Verzweigungsanweisung und den Anweisungen besteht, die zur Ausführung nach der Verzweigungsanweisung vorhergesagt wurden. Wenn andererseits eine Verzweigung fehlerhaft vorhergesagt wird, müssen oftmals die Pipeline einer Ausführung geleert und der Zustand des Prozessors im Wesentlichen in einen früheren Zustand zurückversetzt werden, sodass die Anweisungen aus dem korrekten Pfad ausgeführt werden können.
Infolgedessen wurden in der Technik erhebliche Anstrengungen unternommen, um die Genauigkeit von Verzweigungsvorhersagen zu verbessern und daher die Häufigkeit fehlerhafter Vorhersagen durch eine Verzweigungsvorhersagelogik zu minimieren. Viele Realisierungsformen von Verzweigungsvorhersagelogik beruhen zum Beispiel auf Verlaufsinformationen sowie auf der Annahme, dass, wenn eine Verzweigung eingeschlagen wurde, als zum letzten Mal eine Verzweigungsanweisung ausgeführt wurde, eine Wahrscheinlichkeit besteht, dass die Verzweigung beim nächsten Mal eingeschlagen wird, wenn diese Verzweigungsanweisung ausgeführt wird. Bei vielen Realisierungsformen wird zum Beispiel eine Verzweigungsverlaufstabelle verwendet, um Einträge im Zusammenhang mit bestimmten Verzweigungsanweisungen zu speichern, sodass, wenn diese Verzweigungsanweisungen angetroffen werden, eine Vorhersage auf der Grundlage von Daten vorgenommen werden kann, die im Zusammenhang mit derartigen Verzweigungsanweisungen gespeichert sind.
Die Realisierung einer Verzweigungsvorhersagelogik in einem Prozessor ist jedoch mit einer Reihe von Problemen verbunden. Beispielsweise erfordert das Verbessern der Genauigkeit der Verzweigungsvorhersagelogik oftmals die Verwendung einer komplizierteren Logik, was die Verzweigungsvorhersage verlangsamen und den Umfang an Logikschaltungen erhöhen kann, der zur Realisierung der Logik erforderlich ist. Bei einer auf dem Verlauf beruhenden Verzweigungsvorhersagelogik ist die Genauigkeit oftmals direkt proportional zum Umfang von Verlaufsinformationen, die durch die Logik gespeichert wurden; das Erhöhen der Speicherkapazität einer Verzweigungsverlaufstabelle erfordert jedoch zusätzliche Logikschaltungen. Bei vielen Anwendungen besteht ein Wunsch, den Umfang von Logikschaltungen in einem für die Verzweigungsvorhersagelogik vorgesehenen Prozessorchip zu minimieren, um z. B. den Stromverbrauch und/oder die Kosten zu senken oder um zusätzlichen Platz zur Realisierung anderer Funktionalitäten zu schaffen.
Darüber hinaus wurde festgestellt, dass Verzweigungsvorhersagealgorithmen oftmals bei bestimmten Arten von Programmcode nicht gut funktionieren. Bestimmter Programmcode wie zum Beispiel Durchsuchungen von Binärbäumen, zeigt praktisch Eigenschaften von zufälligen Verzweigungen, und eine Verzweigungsentscheidung, die während einer Ausführung einer Verzweigungsanweisung vorgenommen wird, liefert unter Umständen keinen Einblick, welche Entscheidung das nächste Mal getroffen wird, wenn die Anweisung ausgeführt wird. Außerdem kann bei Multithreading-Umgebungen, bei denen mehrere Threads gleichzeitig in einem Verarbeitungskern ausgeführt werden, die begrenzte Größe einer Verzweigungsvorhersagetabelle, die von mehreren Threads gemeinsam benutzt wird, dazu führen, dass Verlaufsinformationen häufig verworfen werden, wenn neue Verzweigungsanweisungen angetroffen werden, sodass die Verlaufsinformationen zu einer bestimmten Verzweigungsanweisung unter Umständen zu dem Zeitpunkt nicht mehr in der Verzweigungsvorhersagetabelle vorhanden sind, an dem diese Verzweigungsanweisung später ausgeführt wird.
Tatsächlich wurde festgestellt, dass eine Verzweigungsvorhersagelogik in einigen Fällen die Leistung wirklich verringern kann, wenn der Prozentsatz fehlerhafter Vorhersagen ein bestimmtes Niveau erreicht, bei dem die Einbußen der fehlerhaften Vorhersagen größer als die Latenzen sind, die sonst auftreten würden, wenn der Verarbeitungskern auf die Auflösung von Verzweigungsanweisungen warten würde, bevor er versucht, die Anweisungen im ordnungsgemäßen Codepfad auszuführen.
Einige herkömmliche Gestaltungsformen von Prozessoren stellen eine Fähigkeit bereit, um eine Verzweigungsvorhersagelogik selektiv zu deaktivieren. Außerdem stellen einige herkömmliche Gestaltungsformen von Prozessoren eine Fähigkeit bereit, den Zustand einer Verzweigungsvorhersagelogik zu speichern und wiederherzustellen. Eine auf dem Verlauf beruhende Verzweigungsvorhersagelogik verbessert tendenziell die Genauigkeit im Lauf der Zeit, wenn mehr Verlaufsinformationen erfasst werden; wenn jedoch mehrere, voneinander unabhängige Threads bei begrenztem Speicherplatz auf eine Verzweigungslogik zugreifen, kann die Erfassung von Verlaufsinformationen für einen Thread dazu führen, dass Verlaufsformationen für andere Threads verworfen werden. Durch Speichern und Wiederherstellung des Zustands einer Verzweigungsvorhersagelogik kann die Verzweigungsvorhersagelogik oftmals für unterschiedliche Codeabschnitte „präpariert” werden, sodass die zu diesen Codeabschnitten in der Vergangenheit erfassten Verlaufsinformationen sehr wahrscheinlich beim nächsten Mal in der Verzweigungsvorhersagelogik vorliegen, wenn diese Codeabschnitte ausgeführt werden.
Obwohl die Fähigkeit, eine Verzweigungsvorhersagelogik selektiv zu deaktivieren und den Zustand einer Verzweigungsvorhersagelogik zu speichern/wiederherzustellen, einige der Mängel herkömmlicher Verzweigungsvorhersagelogik beseitigen kann, sind herkömmliche Schaltungsentwürfe dennoch durch eine fehlende Flexibilität zur Bewältigung unterschiedlicher Situationen gekennzeichnet, insbesondere bei komplexeren Datenverarbeitungssystemen und Hochleistungs-Datenverarbeitungssystemen, in denen unter Umständen zahlreiche unterschiedliche Arten von Anwendungen mit enorm unterschiedlichen Betriebseigenschaften ausgeführt werden.
Zum Beispiel nutzen viele Hochleistungs-Datenverarbeitungssysteme die Virtualisierung, sodass mehrere Betriebssysteme auf einer gemeinsamen Hardwareplattform unter der Verwaltung einer Überwachungsebenen-Software gehostet werden können, die oftmals als „Hypervisor” bezeichnet wird. Jedes Betriebssystem, das als Gast auf dem Hypervisor ausgeführt wird, kann wiederum eine oder mehrere Benutzeranwendungen hosten, die in der Betriebssystemumgebung in getrennten Prozessen ausgeführt werden. Eine Vielzahl unterschiedlicher Anwendungen, die unterschiedliche Algorithmen mit Eigenschaften ausführen, die sich vom Standpunkt der Verzweigungsvorhersagelogik aus betrachtet nicht gut zur Verallgemeinerung eignen, können in einem derartigen System nebeneinander vorliegen und die Bereitstellung einer Verzweigungsvorhersagestrategie erschweren, die bei allen Szenarien optimal funktioniert.
Daher besteht in der Technik nach wie vor ein erheblicher Bedarf an einer flexiblen und effizienten Art der Steuerung einer Verzweigungsvorhersagelogik in einem Prozessorkern.
Kurzdarstellung
Die Erfindung befasst sich mit einem oder mehreren der Probleme im Zusammenhang mit dem Stand der Technik durch Bereitstellen einer Virtualisierungsunterstützung, die es sowohl einem Hypervisor als auch einem oder mehreren Gastbetriebssystemen, die in einem Datenverarbeitungssystem resident vorliegen und durch den Hypervisor gehostet werden, ermöglicht, eine Verzweigungsvorhersagelogik durch getrennte Hypervisormodus-Anweisungen und Gastmodus-Anweisungen selektiv zu aktivieren oder deaktivieren. Dadurch können unterschiedliche Verzweigungsvorhersagestrategien für unterschiedliche Betriebssysteme und von ihnen gehostete Benutzeranwendungen genutzt werden, um eine feiner abgestimmte Optimierung der Verzweigungsvorhersagelogik bereitzustellen.
Gemäß einem Aspekt der Erfindung wird eine Verzweigungsvorhersagelogik in einem Datenverarbeitungssystem gesteuert, indem ein Aktivierungszustand einer Verzweigungsvorhersagelogik in mindestens einem Verarbeitungskern selektiv als Reaktion darauf gesetzt wird, dass ein Hypervisor auf dem Verarbeitungskern ausgeführt wird, der durch den Hypervisor gesetzte Aktivierungszustand selektiv als Reaktion darauf außer Kraft gesetzt wird, dass ein Gastbetriebssystem auf dem Verarbeitungskern ausgeführt und durch den Hypervisor gehostet wird, sodass das Gastbetriebssystem den Aktivierungszustand der Verzweigungsvorhersagelogik steuert, während der Verarbeitungskern das Gastbetriebssystem ausführt, und indem die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands der Verzweigungsvorhersagelogik selektiv aktiviert wird.
Diese und weitere Vorteile und Merkmale, die die Erfindung charakterisieren, sind in den hier beigefügten Ansprüchen dargelegt und bilden einen weiteren Teil hiervon. Jedoch sollte zum besseren Verständnis der Erfindung sowie der Vorteile und Zielsetzung, die durch ihre Anwendung erreicht werden, Bezug auf die Zeichnungen und die zugehörige Beschreibung genommen werden, in der beispielhafte Ausführungsformen der Erfindung beschrieben sind.
Kurzbeschreibung der Zeichnungen
Im Folgenden werden Ausführungsformen der Erfindung unter Bezugnahme auf die beigefügten Zeichnungen beispielhaft beschrieben, wobei:
1 ein Blockschema einer beispielhaften automatisierten Datenverarbeitungsmaschine ist, die bei der Datenverarbeitung gemäß Ausführungsformen der vorliegenden Erfindung verwendbar ist.
2 ein Blockschema eines beispielhaften NOC ist, das in dem Computer aus 1 realisiert ist.
3 ein Blockschema ist, das eine beispielhafte Realisierungsform eines Knotens aus dem NOC aus 2 ausführlicher veranschaulicht.
4 ein Blockschema ist, das eine beispielhafte Realisierungsform eines IP-Blocks aus dem NOC aus 2 veranschaulicht.
5 ein Blockschema eines Datenverarbeitungssystems ist, in dem eine Virtualisierungsunterstützung zur fein abgestimmten Steuerung einer Verzweigungsvorhersagelogik gemäß der Erfindung realisiert sein kann.
6 ein Blockschema eines beispielhaften Aktivierungsmodus-Steuerregisters in den Spezialregistern ist, auf die in 5 Bezug genommen wird.
7 ein Blockschema einer beispielhaften prozessspezifischen Aktivierungsmodus-Datenstruktur ist, die in dem Datenverarbeitungssystem aus 5 verwendet werden kann.
8 ein Blockschema einer beispielhaften Thread-spezifischen Aktivierungsmodus-Datenstruktur ist, die in dem Datenverarbeitungssystem aus 5 verwendet werden kann.
9 ein Flussdiagramm ist, das einen beispielhaften Ablauf von Operationen veranschaulicht, die durch das Datenverarbeitungssystem aus 5 durchgeführt werden, wenn mit selektiv aktivierter Verzweigungsvorhersagelogik Kontextumschaltungen zwischen einem Hypervisor, Gastbetriebssystem und Benutzermodus-Programmcode durchgeführt werden.
10 ein Blockschema eines beispielhaften Speicherungsmodus-Steuerregisters in den Spezialregistern ist, auf die in 5 Bezug genommen wird.
11 ein Blockschema einer beispielhaften Zustands-Lade/Speicherungseinheit ist, die in dem Datenverarbeitungssystem aus 5 verwendet werden kann, um Verzweigungsvorhersagelogik-Zustandsdaten zu speichern und wiederherzustellen.
12 ein Flussdiagramm ist, das einen beispielhaften Ablauf von Operationen veranschaulicht, die durch das Datenverarbeitungssystem aus 5 durchgeführt werden, wenn mit der Speicherung und Wiederherstellung eines Verzweigungsvorhersagelogik-Zustands Kontextumschaltungen zwischen einem Hypervisor, Gastbetriebssystem und Benutzermodus-Programmcode durchgeführt werden.
13 ein Flussdiagramm ist, das einen beispielhaften Ablauf von Operationen veranschaulicht, um einen Verzweigungsvorhersagelogik-Zustand zu speichern, auf den in 12 Bezug genommen wird.
14 ein Flussdiagramm ist, das einen beispielhaften Ablauf von Operationen veranschaulicht, um einen Verzweigungsvorhersagelogik-Zustand wiederherzustellen, auf den in 12 Bezug genommen wird.
Ausführliche Beschreibung
Ausführungsformen der Erfindung nutzen eine fein abgestimmte Steuerung einer Verzweigungsvorhersagelogik durch mehrere Ebenen eines Datenverarbeitungssystems, um eine Verzweigungsvorhersagelogik für unterschiedliche Anwendungen und Betriebslasten zu optimieren und dadurch das Gesamtbetriebsverhalten des Datenverarbeitungssystems bei der Verarbeitung unterschiedliche Arten von Betriebslasten zu verbessern.
Bei einigen Ausführungsformen sind zum Beispiel ein Hypervisor und ein oder mehrere Gastbetriebssysteme, die sich resident in einem Datenverarbeitungssystem befinden und durch den Hypervisor gehostet werden, so gestaltet, dass eine Verzweigungsvorhersagelogik durch verschiedene Hypervisormodus- und Gastmodus-Anweisungen selektiv aktiviert oder deaktiviert wird. Ebenso sind bei einigen Ausführungsformen ein Hypervisor und ein oder mehrere Programme, z. B. Gastbetriebssysteme und/oder Benutzerprozesse oder -anwendungen, die durch den Hypervisor gehostet werden, so gestaltet, dass der Zustand einer Verzweigungsvorhersagelogik durch mehrere Hypervisormodus- und Gastmodus-Anweisungen und/oder Benutzermodus-Anweisungen selektiv gespeichert und wiederhergestellt wird. Durch Steuern einer Verzweigungsvorhersagelogik auf eine oder beide dieser Arten können unterschiedliche Verzweigungsvorhersagestrategien für unterschiedliche Betriebssysteme und von diesen gehostete Benutzeranwendungen genutzt werden, um eine feiner abgestimmte Optimierung der Verzweigungsvorhersagelogik bereitzustellen, die in den Verarbeitungskernen des Datenverarbeitungssystems genutzt wird.
Ein Hypervisor kann in dieser Hinsicht eine beliebige Anzahl von Supervisormodus-Programmen aufweisen, die ein oder mehrere Gastbetriebssysteme virtualisieren oder hosten können, und er kann in verschiedenen Ebenen von Software, z. B. in Firmware, in einem Kern usw., realisiert sein. Ein Hypervisor virtualisiert normalerweise die unterlagerte Hardware in einem Datenverarbeitungssystem und stellt dem durch das Datenverarbeitungssystem gehosteten Betriebssystem eine Schnittstelle bereit, sodass jedes Betriebssystem so arbeitet, als sei es das einzige, in der physischen Hardware des Datenverarbeitungssystems residente Betriebssystem. Ein Gastbetriebssystem ist normalerweise ein Betriebssystem, eine logische Partition, eine virtuelle Maschine oder eine Kombination davon, das bzw. die durch einen unterlagerten Hypervisor gehostet wird und die Ausführung einer oder mehrerer Benutzeranwendungen unterstützt, die in einem oder mehreren gleichzeitigen Prozessen in der Betriebssystemumgebung ausgeführt werden. Ähnlich wie ein Hypervisor virtualisiert und ordnet ein Gastbetriebssystem einer oder mehreren Benutzeranwendungen bzw. einem oder mehreren Benutzerprozessen Hardwareressourcen zu, die dem Gastbetriebssystem zugewiesen sind. Eine Benutzeranwendung wiederum kann ein beliebiges Programm sein, das in einem Prozess in einem Gastbetriebssystem ausgeführt werden kann.
Es wird klar sein, dass bei vielen Datenverarbeitungsumgebungen die durch die Datenverarbeitungsumgebung genutzten Prozessorarchitekturen die gleichzeitige Ausführung unterschiedlicher Softwareebenen auf den Architekturen mit unterschiedlichen Prioritäts- und Zugriffsrechtsebenen unterstützen. In einer virtualisierten Umgebung wird Hypervisor-Programmcode normalerweise in einem Supervisor- oder Hypervisormodus ausgeführt, während Benutzeranwendungen normalerweise in einem Benutzermodus niedrigerer Priorität ausgeführt werden. Gastbetriebssysteme können ebenfalls in einem Supervisormodus ausgeführt werden, oder sie können in einem getrennten Gastmodus ausgeführt werden, bei dem es sich um einen Zwischenmodus zwischen dem Hypervisor- und Benutzermodus handelt.
Es wird klar sein, dass eine Verzweigungsvorhersagelogik eine beliebige Anzahl von Logikschaltungen mit dem vorrangigen Ziel einschließen kann, die Latenz im Zusammenhang mit Verzweigungsanweisungen zu minimieren. Viele Verzweigungsvorhersagelogik-Schaltungen nutzen Verzweigungsverlaufstabellen, und viele können andere Logik wie zum Beispiel G-Share-Logik, Link-Stack-Logik, Verzweigungszielpuffer usw. aufweisen.
Wie oben erwähnt wird bei einigen Ausführungsformen der Erfindung eine Verzweigungsvorhersagelogik durch eines oder alles aus einem Hypervisor, Gastbetriebssystemen und Benutzeranwendungen und -programmen selektiv aktiviert oder deaktiviert. In diesem Zusammenhang kann das Aktivieren oder Deaktivieren einer Verzweigungsvorhersagelogik das Aktivieren oder Deaktivieren aller oder nur einer Teilmenge von Komponenten aufweisen, die in einer bestimmten Verzweigungsvorhersagelogik-Schaltung realisiert sind. Darüber hinaus kann das Deaktivieren einer Verzweigungsvorhersagelogik einen Reset der Verzweigungsvorhersagelogik bewirken, z. B. um bei einigen Ausführungsformen Einträge aus einer Verzweigungsvorhersagetabelle zu löschen. Bei anderen Ausführungsformen kann das Deaktivieren einer Verzweigungsvorhersagelogik einem „Pausieren” der Logik entsprechen, sodass z. B. keine Vorhersagen getroffen und keine Verlaufsinformationen erfasst werden, aber dass die Verlaufsinformationen, die bereits erfasst wurden, und andere Eigenschaften des aktuellen Zustands der Verzweigungsvorhersagelogik aufrechterhalten werden, bis die Logik wieder aktiviert ist, sodass keine Zustands- oder Verlaufsinformationen verloren gehen.
Wie ebenfalls oben erwähnt kann bei einer Ausführungsform der Erfindung der Zustand einer Verzweigungsvorhersagelogik im Auftrag eines Hypervisors, eines Gastbetriebssystems und/oder einer Benutzeranwendung oder eines Benutzerprogramms selektiv gespeichert und wiederhergestellt werden. Der Zustand, der gespeichert oder wiederhergestellt werden kann, kann beliebige oder alle der in einer Verzweigungsvorhersagelogik verwalteten Daten aufweisen, die den Gesamtzustand der Logik charakterisieren, einschließlich von beispielsweise Verzweigungstabelleneinträgen, Verzweigungszielpuffer-Daten, Link-Stack-Einträgen, G-Share-Daten usw.
Andere Abänderungen und Variationen sind für den Fachmann klar. Daher ist die Erfindung nicht auf die hierin erörterten speziellen Realisierungsformen beschränkt.
Unter Bezugnahme auf die Zeichnungen, bei denen gleiche Nummern in den verschiedenen Ansichten gleiche Bauteile bezeichnen, veranschaulicht 1 eine beispielhafte automatisierte Datenverarbeitungsmaschine mit einem beispielhaften Computer 10, der bei der Datenverarbeitung gemäß Ausführungsformen der vorliegenden Erfindung verwendbar ist. Der Computer 10 aus 1 weist mindestens einen Computerprozessor 12 bzw. eine „CPU” sowie einen Direktzugriffsspeicher 14 („RAM”) auf, der über einen schnellen Speicherbus 16 und einen Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist.
Im RAM 14 ist ein Anwendungsprogramm 20 gespeichert, ein Modul aus Computerprogrammanweisungen auf Benutzerebene zum Ausführen bestimmter Datenverarbeitungsaufgaben wie zum Beispiel Textverarbeitung, Tabellenkalkulation, Datenbankoperationen, Videospiele, Aktienmarktsimulationen, Simulationen von Prozessen bei atomaren Quanten oder andere Anwendungen auf der Benutzerebene. Darüber hinaus ist im RAM 14 ein Betriebssystem 22 gespeichert. Dem Fachmann wird klar sein, dass zu den Betriebssystemen, die in Verbindung mit Ausführungsformen der Erfindung verwendbar sind, UNIX^TM, Linux^TM, Microsoft Windows XP^TM, AIX^TM, i5/OS^TM von IBM und andere gehören können. Das Betriebssystem 22 und die Anwendung 20 bei dem Beispiel aus 1 sind im RAM 14 dargestellt, aber viele Komponenten derartiger Software sind normalerweise auch in nichtflüchtigem Speicher wie z. B. auf einem Festplattenlaufwerk 24 gespeichert.
Wie nachstehend deutlicher wird, können Ausführungsformen gemäß der Erfindung in integrierten NOC-Schaltungseinheiten (NOC = Network an Chip) bzw. -Chips realisiert sein, und daher ist der Computer 10 so veranschaulicht, dass er zwei beispielhafte NOCs aufweist: einen Videoadapter 26 und einen Coprozessor 28. Der NOC-Videoadapter 26, der alternativ als Grafikadapter bezeichnet werden kann, ist ein Beispiel eines E/A-Adapters, der speziell zur Grafikausgabe an eine Anzeigeeinheit 30 wie zum Beispiel einen Anzeigebildschirm oder einen Computermonitor ausgelegt ist. Der NOC-Videoadapter 26 ist mit dem Prozessor 12 über einen schnellen Videobus 32, den Busadapter 18 und den Front-Side-Bus 34 verbunden, bei dem es sich ebenfalls um einen schnellen Bus handelt. Der NOC-Coprozessor 28 ist über den Busadapter 18 und die Front-Side-Busse 34 und 36, bei denen es sich ebenfalls um einen schnellen Bus handelt, mit dem Prozessor 12 verbunden. Der NOC-Coprozessor aus 1 kann optimiert sein, um zum Beispiel auf Veranlassung des Hauptprozessors 12 bestimmte Datenverarbeitungsaufgaben zu beschleunigen.
Der beispielhafte NOC-Videoadapter 26 und NOC-Coprozessor 28 aus 1 weisen jeweils einen NOC mit integrierten Prozessorblöcken (IP-Blöcken), Steuereinheiten für den Speicher-Datenaustausch und Netzwerkschnittstellen-Steuereinheiten auf, deren Einzelheiten in Verbindung mit den 2 bis 3 ausführlicher erörtert werden. Der NOC-Videoadapter und NOC-Coprozessor sind jeweils für Programme optimiert, die die Parallelverarbeitung nutzen und außerdem einen schnellen Direktzugriff auf gemeinsam genutzten Speicher erfordern. Für den Fachmann, der von der vorliegenden Offenbarung profitiert, wird jedoch klar sein, dass die Erfindung in anderen Einheiten und Einheitenarchitekturen als NOC-Einheiten und -Einheitenarchitekturen realisiert werden kann. Daher ist die Erfindung nicht auf die Realisierung in einer NOC-Einheit beschränkt.
Der Computer 10 aus 1 weist einen Festplattenlaufwerksadapter 38 auf, der über einen Erweiterungsbus 40 und den Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist. Dem Fachmann wird klar sein, dass der Festplattenlaufwerksadapter 38 nichtflüchtigen Datenspeicher in Form des Festplattenlaufwerks 24 mit dem Computer 10 verbindet und zum Beispiel unter Verwendung von IDE-Adaptern (IDE = Integrated Drive Electronics), SCSI-Adaptern (SCSI = Small Computer System Interface) und anderen realisiert sein kann. Dem Fachmann wird klar sein, dass nichtflüchtiger Computerspeicher auch als optisches Festplattenlaufwerk, elektrisch löschbarer programmierbarer Nur-Lese-Speicher (sogenannter EEPROM- oder Flash-Speicher), in Form von RAM-Laufwerken usw. realisiert sein kann.
Der Computer 10 weist zudem einen oder mehrere Eingabe/Ausgabe-Adapter (E/A-Adapter) 42 auf, die die benutzerorientierte Eingabe und Ausgabe mithilfe von z. B. Softwaretreibern und Computerhardware zum Steuern der Ausgabe auf Ausgabeeinheiten wie zum Beispiel Computer-Anzeigebildschirme sowie zum Steuern der Eingabe von Benutzereingabeeinheiten 44 wie zum Beispiel Tastaturen und Mäusen realisieren. Darüber hinaus weist der Computer 10 einen Datenübertragungsadapter 46 für den Datenaustausch mit anderen Computern 48 und für den Datenaustausch mit einem Datenübertragungsnetzwerk 50 auf. Dem Fachmann wird klar sein, dass dieser Datenaustausch seriell über RS232-Verbindungen, über externe Busse wie zum Beispiel einen Universal Serial Bus (USB), über Datenübertragungsnetzwerke wie zum Beispiel IP-Datenübertragungsnetzwerke und auf andere Weise durchgeführt werden kann. Datenübertragungsadapter realisieren die Hardwareebene des Datenaustauschs, über die ein Computer direkt oder über ein Datenübertragungsnetzwerk Daten an einen anderen Computer sendet. Zu Beispielen von Datenübertragungsadaptern, die zur Verwendung im Computer 10 geeignet sind, gehören Modems für kabelgebundene Einwählverbindungen, Ethernet-Adapter (IEEE 802.3) für die Verbindung zu kabelgebundenen Datenübertragungsnetzwerken und 802.11-Adapter für die Verbindung zu drahtlosen Datenübertragungsnetzwerken.
Zur weiteren Erläuterung ist in 2 ein Funktionsblockschema eines beispielhaften NOC 102 gemäß Ausführungsformen der vorliegenden Erfindung dargelegt. Das NOC in 2 ist auf einem „Chip” 100 realisiert, d. h. in einer integrierten Schaltung. Das NOC 102 weist integrierte Prozessorblöcke (IP-Blöcke) 104, Router 110, Steuereinheiten 106 für den Speicher-Datenaustausch und Netzwerkschnittstellen-Steuereinheiten 108 auf, die in untereinander verbundenen Knoten gruppiert sind. Jeder IP-Block 104 ist über eine Steuereinheit 106 für den Speicher-Datenaustausch und eine Netzwerkschnittstellen-Steuereinheit 108 an einen Router 110 angepasst. Jede Steuereinheit für den Speicher-Datenaustausch steuert den Datenaustausch zwischen einem IP-Block und einem Speicher, und jede Netzwerkschnittstellen-Steuereinheit 108 steuert den Datenaustausch zwischen IP-Blöcken über die Router 110.
Bei dem NOC 102 stellt jeder IP-Block eine wiederverwendbare Einheit aus synchroner oder asynchroner Logik dar, die als Baustein zur Datenverarbeitung im NOC verwendet wird. Die Bedeutung des Begriffs „IP-Block” wird manchmal als „Block aus geistigem Eigentum” (Intellectual Property Block) ausgelegt, um damit einen IP-Block wirksam als Entwicklung zu bezeichnen, die einer beteiligten Partei gehört, d. h. das geistige Eigentum einer beteiligten Partei ist, für das anderen Benutzern oder Entwicklern von Halbleiterschaltungen eine Lizenz erteilt werden muss. Im Schutzbereich der vorliegenden Erfindung liegt jedoch kein Erfordernis vor, dass IP-Blöcke einer bestimmten Eigentümerschaft unterliegen müssen, sodass der Begriff in dieser Spezifikation stets als „integrierter Prozessorblock” ausgelegt wird. IP-Blöcke sind im hierin angegebenen Sinne wiederverwendbare Gestaltungseinheiten von Logik, Zellen- oder Chip-Layout, die unter Umständen Gegenstand geistiger Eigentumsrechte sind. IP-Blöcke sind Logikkerne, die als ASIC-Chip-Entwicklungen oder FPGA-Logik-Entwicklungen ausgebildet sein können.
Eine Möglichkeit zur sinngemäßen Beschreibung von IP-Blöcken besteht darin, dass IP-Blöcke für NOCs sind, was eine Bibliothek für die Computerprogrammierung oder eine einzelne integrierte Schaltungskomponente für den Entwurf einer Leiterplatte ist. Dem Fachmann ist unter Umständen klar, dass bei NOCs gemäß Ausführungsformen der vorliegenden Erfindung IP-Blöcke als allgemeine Gatternetzlisten, als komplette Spezial- oder Mehrzweck-Mikroprozessoren oder in anderer Form realisiert sein können. Eine Netzliste ist eine Darstellung in Boolescher Algebra (Gatter, Standardzellen) einer Logikfunktion eines IP-Blocks, analog zu einem Assemblercode-Listing bei einer Anwendung in einer höheren Programmiersprache. Außerdem können NOCs zum Beispiel in synthetisierbarer Form realisiert, d. h. in einer Hardwarebeschreibungssprache wie zum Beispiel Verilog oder VHDL beschrieben sein. Außer der Realisierung als Netzliste oder in synthetisierbarer Form können NOCs auch in physischen Beschreibungen unterer Ebenen bereitgestellt sein. Analoge Elemente von IP-Blöcken wie zum Beispiel SERDES, PLL, DAU, ADU usw. können in einem Transistorlayout-Format GDSII verteilt sein. Digitale Elemente von IP-Blöcken werden manchmal ebenfalls im Layout-Format bereitgestellt. Außerdem wird klar sein, dass IP-Blöcke sowie andere Logikschaltungen, die gemäß der Erfindung realisiert sind, in Form von Computerdatendateien, z. B. von Programmcode zur Logikdefinition, verteilt sein können, die auf verschiedenen Detailebenen die Funktionalität und/oder das Layout der Schaltungsanordnungen zur Realisierung derartiger Logik festlegen. Daher wird für den Fachmann, der von der vorliegenden Offenbarung profitiert, klar sein, obwohl die Erfindung bisher im Kontext von Schaltungsanordnungen beschrieben wurde und nachstehend beschrieben wird, die in voll funktionsfähigen integrierten Schaltungseinheiten, Datenverarbeitungssystemen realisiert sind, die derartige Einheiten und andere materielle, physische Hardwareschaltungen nutzen, dass die Erfindung auch in einem Programmprodukt realisiert sein kann und dass die Erfindung gleichermaßen ungeachtet der jeweiligen Art des computerlesbaren Speichermediums gilt, das zur Verteilung des Programmprodukts verwendet wird. Zu Beispielen von computerlesbaren Speichermedien gehören, ohne darauf beschränkt zu sein, unter anderem physische beschreibbare Medien wie zum Beispiel flüchtige und nichtflüchtige Speichereinheiten, Disketten, Festplattenlaufwerke, CD-ROMs und DVDs.
Jeder IP-Block in dem Beispiel aus 2 ist über eine Steuereinheit 106 für den Speicher-Datenaustausch an einen Router 110 angepasst. Jede Steuereinheit für den Speicher-Datenaustausch ist eine Zusammenfassung aus synchronen und asynchronen Logikschaltungen, die so gestaltet ist, dass sie den Datenaustausch zwischen einem IP-Block und dem Speicher bereitstellt. Zu Beispielen eines derartigen Datenaustauschs zwischen IP-Blöcken und dem Speicher gehören Anweisungen zum Laden in den Speicher und Anweisungen zum Speichern im Speicher. Die Steuereinheiten 106 für den Speicher-Datenaustausch sind nachstehend unter Bezugnahme auf 3 ausführlicher beschrieben. Jeder IP-Block 104 ist außerdem über eine Netzwerkschnittstellen-Steuereinheit 108, die den Datenaustausch zwischen IP-Blöcken 104 über die Router 110 steuert, an einen Router 110 angepasst. Zu Beispielen des Datenaustauschs zwischen IP-Blöcken gehören Nachrichten, die Daten und Anweisungen transportieren, um bei parallel und im Pipelinesystem arbeitenden Anwendungen Daten zwischen IP-Blöcken zu verarbeiten. Die Netzwerkschnittstellen-Steuereinheiten 108 sind ebenfalls nachstehend unter Bezugnahme auf 3 ausführlicher beschrieben.
Die Router 110 und die entsprechenden Verbindungen 118 zwischen diesen realisieren die Netzwerkoperationen des NOC. Die Verbindungen 118 können Paketstrukturen sein, die auf physischen, parallelverdrahteten Bussen realisiert sind, die alle Router verbinden. Das heißt, dass jede Verbindung auf einem leitungsgebundenen Bus realisiert sein kann, der breit genug ist, um gleichzeitig ein ganzes Datenvermittlungspaket einschließlich aller Kopfinformationen und Nutzdaten aufzunehmen. Wenn eine Paketstruktur beispielsweise 64 Bytes einschließlich eines Acht-Byte-Kopfes und 56 Bytes Nutzdaten aufweist, ist der leitungsgebundene Bus, der sich zum gegenüberliegenden Ende der Verbindung erstreckt, 64 Bytes breit und weist 512 Leitungen auf. Außerdem kann jede Verbindung bidirektional sein, sodass der leitungsgebundene Bus tatsächlich 1024 Leitungen zwischen jedem Router und jedem seiner Nachbarn im Netzwerk enthält, wenn die Paketstruktur der Verbindung 64 Bytes aufweist. Bei einer derartigen Realisierungsform könnte eine Nachricht mehr als ein Paket aufweisen, aber jedes Paket würde exakt auf die Breite des leitungsgebundenen Busses passen. Als Alternative kann eine Verbindung auf einem leitungsgebundenen Bus realisiert sein, der nur breit genug ist, um einen Teil des Pakets aufzunehmen, sodass ein Paket auf mehrere Takte aufgeteilt würde, z. B. so, dass bei einer realisierten Verbindung mit einer Breite von 16 Bytes bzw. 128 Leitungen ein 64-Byte-Paket auf vier Takte aufgeteilt werden könnte. Es wird klar sein, dass auf der Grundlage physischer Begrenzungen in der Praxis sowie gewünschter Leistungseigenschaften unterschiedliche Realisierungsformen unterschiedliche Busbreiten nutzen können. Wenn die Verbindung zwischen dem Router und jedem Abschnitt des leitungsgebundenen Busses als Anschluss bezeichnet wird, weist jeder Router fünf Anschlüsse auf, einen für jede von vier Richtungen der Datenübertragung im Netzwerk und einen fünften Anschluss zum Anpassen des Routers an einen bestimmten IP-Block über eine Steuereinheit für den Speicher-Datenaustausch und eine Netzwerkschnittstellen-Steuereinheit.
Jede Steuereinheit 106 für den Speicher-Datenaustausch steuert den Datenaustausch zwischen einem IP-Block und dem Speicher. Zum Speicher können ein außerhalb des Chips angeordneter Haupt-RAM 112, ein Speicher 114, der über eine Steuereinheit 106 für den Speicher-Datenaustausch direkt mit einem IP-Block verbunden ist, auf dem Chip angeordneter Speicher, der als IP-Block 116 aktiviert ist, und auf dem Chip angeordnete Cache-Zwischenspeicher gehören. Bei dem NOC 102 können beispielsweise beide auf dem Chip angeordneten Speicher 114, 116 als auf dem Chip angeordneter Cache-Zwischenspeicher realisiert sein. Alle diese Formen von Speicher können unabhängig von physischen Adressen oder virtuellen Adressen im selben Adressraum angeordnet sein, was selbst für den Speicher gilt, der direkt mit einem IP-Block verbunden ist. Speicheradressierte Nachrichten können daher in Bezug auf IP-Blöcke vollständig bidirektional sein, da ein derartiger Speicher von einem beliebigen IP-Block von überallher im Netzwerk direkt adressiert werden kann. Der Speicher 116 an einem IP-Block kann von diesem IP-Block oder von einem beliebigen anderen IP-Block im NOC adressiert werden. Der Speicher 114, der direkt mit einer Steuereinheit für den Speicher-Datenaustausch verbunden ist, kann durch den IP-Block adressiert werden, der durch diese Steuereinheit für den Speicher-Datenaustausch an das Netzwerk angepasst ist – und er kann außerdem von einem beliebigen anderen IP-Block überall im NOC adressiert werden.
Das NOC 102 weist zwei Speicherverwaltungseinheiten (Memory Management Units, MMUs) 120, 122 auf, die gemäß Ausführungsformen der vorliegenden Erfindung zwei alternative Speicherarchitekturen für NOCs veranschaulichen. Die MMU 120 ist in einem IP-Block realisiert, wodurch ein Prozessor in dem IP-Block im virtuellen Speicher arbeiten kann, während die gesamte übrige Architektur des NOC in einem physischen Speicheradressraum arbeiten kann. Die MMU 122 ist außerhalb des Chips realisiert und über einen Datenübertragungsanschluss 124 mit dem NOC verbunden. Der Anschluss 124 weist die Kontaktstifte und andere Verbindungen auf, die zur Übertragung von Signalen zwischen dem NOC und der MMU erforderlich sind, sowie ausreichende Intelligenz, um Nachrichtenpakete aus dem NOC-Paketformat in das Busformat umzuwandeln, das die externe MMU 122 benötigt. Die externe Anordnung der MMU bedeutet, dass alle Prozesse in allen IP-Blöcken des NOC im virtuellen Speicheradressraum arbeiten können, wobei alle Umwandlungen in physische Adressen des außerhalb des Chips angeordneten Speichers durch die außerhalb des Chips angeordnete MMU 122 verarbeitet werden.
Außer den zwei mithilfe der MMUs 120, 122 veranschaulichten Speicherarchitekturen veranschaulicht ein Datenübertragungsanschluss 126 eine dritte Speicherarchitektur, die bei NOCs verwendbar ist, die bei Ausführungsformen der vorliegenden Erfindung genutzt werden können. Ein Anschluss 126 stellt eine direkte Verbindung zwischen einem IP-Block 104 des NOC und dem außerhalb des Chips angeordneten Speicher 112 bereit. Ohne MMU im Verarbeitungspfad stellt diese Architektur die Nutzung eines physischen Adressraums durch alle IP-Blöcke des NOC bereit. Bei gemeinsamer bidirektionaler Nutzung des Adressraums können alle IP-Blöcke des NOC durch speicheradressierte Nachrichten (einschließlich von Lade- und Speicherungsoperationen), die über den mit dem Anschluss 126 verbundenen IP-Block geleitet werden, auf Speicher im Adressraum zugreifen. Der Anschluss 126 weist die Kontaktstifte und andere Verbindungen auf, die zur Übertragung von Signalen zwischen dem NOC und dem außerhalb des Chips angeordneten Speicher 112 erforderlich sind, sowie ausreichende Intelligenz, um Nachrichtenpakete aus dem NOC-Paketformat in das Busformat umzuwandeln, das der außerhalb des Chips angeordnete Speicher 112 benötigt.
Bei dem Beispiel aus 2 ist einer der IP-Blöcke als Host-Schnittstellenprozessor 128 bezeichnet. Ein Host-Schnittstellenprozessor (HSP) 128 stellt eine Schnittstelle zwischen dem NOC und einem Host-Computer 10 bereit, in dem das NOC installiert sein kann, und er stellt außerdem Datenverarbeitungsdienste für andere IP-Blöcke auf dem NOC bereit, zu denen zum Beispiel das Empfangen der NOC-Datenverarbeitungsanforderungen vom Host-Computer und deren Verteilung unter den IP-Blöcken gehört. Ein NOC kann zum Beispiel einen Video-Grafikadapter 26 oder einen Coprozessor 28 auf einem größeren Computer realisieren, wie oben unter Bezugnahme auf 1 beschrieben. Bei dem Beispiel aus 2 ist der Host-Schnittstellenprozessor 128 über einen Datenübertragungsanschluss 130 mit dem größeren Host-Computer verbunden. Der Anschluss 130 weist die Kontaktstifte und andere Verbindungen auf, die zur Übertragung von Signalen zwischen dem NOC und dem Host-Computer erforderlich sind, sowie ausreichende Intelligenz, um Nachrichtenpakete vom NOC in das Busformat umzuwandeln, das der Host-Computer 10 benötigt. Bei dem Beispiel des NOC-Coprozessors im Computer aus 1 würde ein derartiger Anschluss die Umsetzung des Datenaustauschformats zwischen der Verbindungsstruktur des NOC-Coprozessors 28 und dem Protokoll bereitstellen, das für den Front-Side-Bus 36 zwischen dem NOC-Coprozessor 28 und dem Busadapter 18 benötigt wird.
3 veranschaulicht als Nächstes ein Funktionsblockschema, das die Komponenten ausführlicher veranschaulicht, die in einem IP-Block 104, in der Steuereinheit 106 für den Datenaustausch, in der Netzwerkschnittstellen-Steuereinheit 108 und im Router 110 im NOC 102 realisiert sind, die zusammenfassend bei 132 veranschaulicht sind. Der IP-Block 104 weist einen Computerprozessor 134 und eine E/A-Funktionalität 136 auf. Bei diesem Beispiel ist der Computerspeicher durch ein Segment eines Direktzugriffsspeichers („RAM”) 138 im IP-Block 104 dargestellt. Der Speicher kann wie oben unter Bezugnahme auf 2 beschrieben Segmente eines physischen Adressraums belegen, dessen Inhalt bei jedem IP-Block von einem beliebigen IP-Block im NOC aus adressierbar und zugriffsfähig ist. Die Prozessoren 134, die E/A-Fähigkeiten 126 und der Speicher 138 in jedem IP-Block realisieren die IP-Blöcke wirksam als allgemein programmierbare Mikrocomputer. Wie oben erläutert stellen jedoch die IP-Blöcke im Schutzbereich der vorliegenden Erfindung allgemein wiederverwendbare Einheiten aus synchroner und asynchroner Logik dar, die als Bausteine zur Datenverarbeitung im NOC verwendet werden. Das Realisieren von IP-Blöcken als allgemein programmierbare Mikrocomputer stellt daher keine Einschränkung der Erfindung dar, obwohl es als häufig verwendete Ausführungsform zu Erläuterungszwecken hilfreich ist.
Im NOC 102 aus 3 weist jede Steuereinheit 106 für den Speicher-Datenaustausch eine Vielzahl von Ausführungsmodulen 140 für den Speicher-Datenaustausch auf. Jedes Ausführungsmodul 140 für den Speicher-Datenaustausch ist so aktiviert, dass von einem IP-Block 104 kommende Anweisungen zum Speicher-Datenaustausch ausgeführt werden, einschließlich des bidirektionalen Anweisungsflusses 141, 142, 144 zwischen dem Netzwerk und dem IP-Block 104. Die Anweisungen für den Speicher-Datenaustausch, die durch die Steuereinheit für den Speicher-Datenaustausch ausgeführt werden, können nicht nur von dem IP-Block stammen, der über eine bestimmte Steuereinheit für den Speicher-Datenaustausch an einen Router angepasst ist, sondern auch von einem beliebigen IP-Block 104 irgendwo im NOC 102. Das heißt, dass ein beliebiger IP-Block im NOC eine Anweisung für den Speicher-Datenaustausch erzeugen und diese Anweisung für den Speicher-Datenaustausch über die Router des NOC zur Ausführung dieser Anweisung für den Speicher-Datenaustausch an eine andere Steuereinheit für den Speicher-Datenaustausch senden kann, die zu einem anderen IP-Block gehört. Zu derartigen Anweisungen für den Speicher-Datenaustausch können zum Beispiel Anweisungen zur Steuerung von Transaktions-Umsetzpuffern, Anweisungen zur Steuerung von Cache-Zwischenspeichern, Sperranweisungen und Lade- und Speicheranweisungen für Speicher gehören.
Jedes Ausführungsmodul 140 für den Speicher-Datenaustausch ist so aktiviert, dass eine vollständige Anweisung für den Speicher-Datenaustausch getrennt von und parallel zu anderen Ausführungsmodulen für den Speicher-Datenaustausch ausgeführt wird. Die Ausführungsmodule für den Speicher-Datenaustausch realisieren einen skalierbaren Speicher-Transaktionsprozessor, der für den gleichzeitigen Durchsatz von Anweisungen für den Speicher-Datenaustausch optimiert ist. Die Steuereinheit 106 für den Speicher-Datenaustausch unterstützt mehrere Ausführungsmodule 140 für den Speicher-Datenaustausch, von denen alle zwecks gleichzeitiger Ausführung mehrerer Anweisungen für den Speicher-Datenaustausch gleichzeitig ausgeführt werden. Durch die Steuereinheit 106 für den Speicher-Datenaustausch wird einem Modul 140 für den Speicher-Datenaustausch eine neue Anweisung für den Speicher-Datenaustausch zugeordnet, und die Ausführungsmodule 140 für den Speicher-Datenaustausch können gleichzeitig mehrere Antwortereignisse annehmen. Bei diesem Beispiel sind alle Ausführungsmodule 140 für den Speicher-Datenaustausch identisch. Das Skalieren der Anzahl von Anweisungen für den Speicher-Datenaustausch kann durch eine Steuereinheit 106 für den Speicher-Datenaustausch gleichzeitig vorgenommen werden und wird daher durch das Skalieren der Anzahl von Ausführungsmodulen 140 für den Speicher-Datenaustausch realisiert.
Im NOC 102 aus 3 ist jede Netzwerkschnittstellen-Steuereinheit 108 so aktiviert, dass Datenaustauschanweisungen zur Übertragung zwischen den IP-Blöcken 104 über die Router 110 aus dem Befehlsformat in das Netzwerkpaketformat umgewandelt werden. Die Datenaustauschanweisungen können durch den IP-Block 104 oder durch die Steuereinheit 106 für den Speicher-Datenaustausch im Befehlsformat formuliert und der Netzwerkschnittstellen-Steuereinheit 108 im Befehlsformat bereitgestellt werden. Das Befehlsformat kann ein natives (systemeigenes) Format sein, das den Architektur-Registerdateien des IP-Blocks 104 und der Steuereinheit 106 für den Speicher-Datenaustausch entspricht. Das Netzwerkpaketformat ist normalerweise das Format, das zur Übertragung über die Router 110 des Netzwerks erforderlich ist. Jede derartige Nachricht besteht aus einem oder mehreren Netzwerkpaketen. Zu Beispielen derartiger Datenaustausch Anweisungen, die in der Netzwerkschnittstellen-Steuereinheit aus dem Befehlsformat in das Paketformat umgewandelt werden, gehören Speicher-Ladeanweisungen und Speicher-Speicheranweisungen zwischen IP-Blöcken und Speicher. Zu derartigen Datenaustauschanweisungen können außerdem Datenaustauschanweisungen gehören, die Nachrichten zwischen IP-Blöcken senden, die Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in parallelen Anwendungen und in einem Pipelinesystem arbeitenden Anwendungen transportieren.
Im NOC 102 aus 3 ist jeder IP-Block so aktiviert, dass auf Speicheradressen beruhender Datenaustausch zum und vom Speicher über die Steuereinheit des IP-Blocks für den Speicher-Datenaustausch und anschließend auch über dessen Netzwerkschnittstellen-Steuereinheit an das Netzwerk gesendet wird. Ein auf Speicheradressen beruhender Datenaustausch ist eine Speicherzugriffsanweisung wie zum Beispiel eine Ladeanweisung oder eine Speicheranweisung, die durch ein Ausführungsmodul für den Speicher-Datenaustausch einer Steuereinheit für den Speicher-Datenaustausch eines IP-Blocks ausgeführt wird. Derartiger auf Speicheradressen beruhender Datenaustausch stammt normalerweise von einem IP-Block, ist im Befehlsformat formatiert und wird zur Ausführung an eine Steuereinheit für den Speicher-Datenaustausch übergeben.
Ein großer Teil des auf Speicheradressen beruhenden Datenaustauschs wird mit Nachrichtenverkehr abgewickelt, da sich beliebiger zu adressierender Speicher an einer beliebigen Stelle im physische Adressraum, auf dem Chip oder außerhalb des Chips befinden, direkt mit einer beliebigen Steuereinheit für den Speicher-Datenaustausch im NOC verbunden sein oder letztlich über einen beliebigen IP-Block des NOC darauf zugegriffen werden kann – unabhängig davon, von welchem IP-Block ein bestimmter auf Speicheradressen beruhender Datenaustausch stammt. Somit wird im NOC 102 der gesamte auf Speicheradressen beruhende Datenaustausch, der mit Nachrichtenverkehr ausgeführt wird, zwecks Umwandlung aus dem Befehlsformat in das Paketformat und Übertragung über das Netzwerk in einer Nachricht von der Steuereinheit für den Speicher-Datenaustausch an eine zugehörige Netzwerkschnittstellen-Steuereinheit übermittelt. Beim Umwandeln in das Paketformat erkennt die Netzwerkschnittstellen-Steuereinheit außerdem eine Netzwerkadresse für das Paket in Abhängigkeit von der Speicheradresse oder den Speicheradressen, auf die durch einen auf Speicheradressen beruhenden Datenaustausch zugegriffen werden soll. Auf Speicheradressen beruhende Nachrichten sind mit Speicheradressen adressiert. Jede Speicheradresse wird durch die Netzwerkschnittstellen-Steuereinheiten einer Netzwerkadresse zugeordnet, normalerweise dem Netzspeicherort einer Steuereinheit für den Speicher-Datenaustausch, die für einen bestimmten Bereich von physischen Speicheradressen zuständig ist. Der Netzspeicherort einer Steuereinheit 106 für den Speicher-Datenaustausch ist selbstverständlich auch der Netzspeicherort des zugehörigen Routers 110, der zugehörigen Netzwerkschnittstellen-Steuereinheit 108 und des zugehörigen IP-Blocks 104 dieser Steuereinheit für den Speicher-Datenaustausch. Die Anweisungs-Umwandlungslogik 150 in jeder Netzwerkschnittstellen-Steuereinheit kann zwecks Übertragung von auf Speicheradressen beruhendem Datenverkehr über Router eines NOC Speicheradressen in Netzwerkadressen umwandeln.
Nachdem von Routern 110 des Netzwerks kommender Nachrichtenverkehr empfangen wurde, untersucht jede Netzwerkschnittstellen-Steuereinheit 108 jedes Paket auf Speicheranweisungen. Jedes Paket, das eine Speicheranweisung enthält, wird an die zur empfangenden Netzwerkschnittstellen-Steuereinheit gehörende Steuereinheit 106 für den Speicher-Datenaustausch übergeben, die die Speicheranweisung ausführt, bevor die restlichen Nutzdaten des Pakets zur weiteren Verarbeitung an den IP-Block gesendet werden. Auf diese Weise sind Speicherinhalte stets darauf vorbereitet, die Datenverarbeitung durch einen IP-Block zu unterstützen, bevor der IP-Block die Ausführung von Anweisungen aus einer Nachricht beginnt, die vom jeweiligen Speicherinhalt abhängen.
Im NOC 102 aus 3 ist jeder IP-Block 104 so aktiviert, dass seine Steuereinheit 106 für den Speicher-Datenaustausch umgangen und netzwerkadressierter Datenaustausch 146 zwischen IP-Blöcken über die Netzwerkschnittstellen-Steuereinheit 108 des IP-Blocks direkt an das Netzwerk gesendet wird. Netzwerkadressierter Datenaustausch sind Nachrichten, die mithilfe einer Netzwerkadresse an einen anderen IP-Block gerichtet sind. Derartige Nachrichten übertragen Arbeitsdaten bei im Pipelinesystem arbeitenden Anwendungen, mehrere Daten zwischen IP-Blöcken zur Verarbeitung durch ein Programm in einer SIMD-Anwendung (SIMD = Single Instruction, Mutliple Data) usw., wie dem Fachmann klar sein wird. Derartige Nachrichten unterscheiden sich von Datenaustausch, der auf Speicheradressen beruht, dadurch, dass sie durch den IP-Block, von dem sie stammen, von Beginn an netzwerkadressiert sind, wobei der IP-Block die Netzwerkadresse kennt, an die die Nachricht über Router des NOC zu richten ist. Derartiger netzwerkadressierter Datenaustausch wird durch den IP-Block über E/A-Funktionen 136 im Befehlsformat direkt an die Netzwerkschnittstellen-Steuereinheit des IP-Blocks übermittelt, anschließend durch die Netzwerkschnittstellen-Steuereinheit in das Paketformat umgewandelt und über Router des NOC zu einem anderen IP-Block übertragen. Derartiger netzwerkadressierter Datenaustausch 146 ist bidirektional und verläuft je nach dessen Nutzung in einer bestimmten Anwendung unter Umständen zu und von jedem IP-Block des NOC. Jede Netzwerkschnittstellen-Steuereinheit ist jedoch so aktiviert, dass sie derartigen Datenaustausch sowohl an einen zugehörigen Router sendet als auch von einem zugehörigen Router empfängt, und jede Netzwerkschnittstellen-Steuereinheit ist so aktiviert, dass sie derartigen Datenaustausch sowohl an einen zugehörigen IP-Block sendet als auch von einem zugehörigen IP-Block empfängt, wobei eine zugehörige Steuereinheit 106 für den Speicher-Datenaustausch umgangen wird.
Jede Netzwerkschnittstellen-Steuereinheit 108 bei dem Beispiel aus 3 ist außerdem so aktiviert, dass sie virtuelle Kanäle auf dem Netz realisiert und dadurch Netzwerkpakete nach Typ charakterisiert. Jede Netzwerkschnittstellen-Steuereinheit 108 weist eine Logik 148 zur Realisierung virtueller Kanäle auf, die jede Datenaustauschanweisung nach Typ einteilt und den Typ der Anweisung in einem Feld des Netzwerkpaketformats aufzeichnet, bevor sie die Anweisung zwecks Übertragung auf dem NOC in Paketform an einen Router 110 übergibt. Zu Beispielen von Typen von Datenaustauschanweisungen gehören zwischen IP-Blöcken ausgetauschte, auf Netzwerkadressen beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, an Cache-Zwischenspeicher gerichtete Nachrichten zum Ungültigmachen; Nachrichten zum Laden in den Speicher und Speichern im Speicher; und Antworten auf Nachrichten zum Speichern im Speicher usw.
Jeder Router 110 in dem Beispiel aus 3 weist eine Weiterleitungslogik 152, eine Steuerlogik 154 für virtuelle Kanäle und Puffer 156 für virtuelle Kanäle auf. Die Weiterleitungslogik ist normalerweise als Netzwerk aus synchroner und asynchroner Logik realisiert, die einen Datenübertragungs-Protokollstack für den Datenaustausch in dem Netzwerk realisiert, das durch die Router 110, Verbindungen 118 und Busleitungen zwischen den Routern gebildet wird. Die Weiterleitungslogik 152 weist die Funktionalität auf, die fachkundige Leser bei außerhalb von Chips angeordneten Netzwerken mit Weiterleitungstabellen in Verbindung bringen könnten, wobei Weiterleitungstabellen bei mindestens einigen Ausführungsformen zur Verwendung in einem NOC als zu langsam und umständlich angesehen werden. Weiterleitungslogik, die als Netzwerk aus synchroner und asynchroner Logik realisiert ist, kann so gestaltet sein, dass Weiterleitungsentscheidungen im Zeitraum eines einzelnen Taktzyklus getroffen werden. Die Weiterleitungslogik leitet bei diesem Beispiel Pakete weiter, indem ein Anschluss zum Weiterleiten jedes Pakets ausgewählt wird, das in einem Router empfangen wurde. Jedes Paket enthält eine Netzwerkadresse, an die das Paket weiterzuleiten ist.
In der obigen Beschreibung des auf Speicheradressen beruhenden Datenaustauschs wurde jede Speicheradresse so beschrieben, dass sie durch Netzwerkschnittstellen-Steuereinheiten einer Netzwerkadresse, einem Netzspeicherort einer Steuereinheit für den Speicher-Datenaustausch, zugeordnet wird. Der Netzspeicherort einer Steuereinheit 106 für den Speicher-Datenaustausch ist selbstverständlich auch der Netzspeicherort des zugehörigen Routers 110, der zugehörigen Netzwerkschnittstellen-Steuereinheit 108 und des zugehörigen IP-Blocks 104 dieser Steuereinheit für den Speicher-Datenaustausch. Bei dem Datenaustausch zwischen IP-Blöcken bzw. dem auf Netzwerkadressen beruhenden Datenaustausch ist es daher auch bei der Datenverarbeitung auf der Anwendungsebene normal, dass Netzwerkadressen als Speicherort eines IP-Blocks innerhalb des aus den Routern, Verbindungen und Busleitungen des NOC gebildeten Netzwerks angesehen werden. 2 veranschaulicht, dass eine Organisation eines derartigen Netzwerks ein Netz aus Zeilen und Spalten ist, in dem jede Netzwerkadresse realisiert sein kann, zum Beispiel entweder als eindeutige Kennung für jede Gruppe aus zugehörigem Router, IP-Block, zugehöriger Steuereinheit für den Speicher-Datenaustausch und Netzwerkschnittstellen-Steuereinheit des Netzes oder als X-Y-Koordinaten jeder derartigen Gruppe in dem Netz.
Bei dem NOC 102 aus 3 realisiert jeder Router 110 einen oder mehrere virtuelle Datenaustauschkanäle, wobei jeder virtuelle Datenaustauschkanal durch einen Datenaustauschtyp charakterisiert ist. Zu Typen von Datenaustauschanweisungen und daher von Arten virtueller Kanäle gehören die oben erwähnten: zwischen IP-Blöcken ausgetauschte, auf Netzwerkadressen beruhende Nachrichten, Anforderungsnachrichten, Antworten auf Anforderungsnachrichten, an Cache-Zwischenspeicher gerichtete Nachrichten zum Ungültigmachen; Nachrichten zum Laden in den Speicher und Speichern im Speicher; und Antworten auf Nachrichten zum Speichern im Speicher usw. Zur Unterstützung virtueller Kanäle weist jeder Router 110 in dem Beispiel aus 3 auch die Steuerlogik 154 für virtuelle Kanäle und Puffer 156 für virtuelle Kanäle auf. Die Steuerlogik 154 für virtuelle Kanäle prüft jedes empfangene Paket auf seinen zugewiesenen Datenaustauschtyp und legt jedes Paket dieses Datenaustauschtyps zur Übertragung über einen Anschluss an einen benachbarten Router auf dem NOC in einem Ausgangspuffer für virtuelle Kanäle ab.
Jeder Puffer 156 für virtuelle Kanäle weist einen endlichen Speicherplatz auf. Wenn in einem kurzen Zeitraum viele Pakete empfangen werden, kann ein Puffer für virtuelle Kanäle volllaufen, sodass keine weiteren Pakete im Puffer abgelegt werden können. Bei anderen Protokollen würden Pakete verworfen werden, die auf einem virtuellen Kanal ankommen, dessen Puffer voll ist. Bei diesem Beispiel wird jeder Puffer 156 für virtuelle Kanäle jedoch mit Steuersignalen der Busleitungen so aktiviert, dass umliegende Router über die Steuerlogik für virtuelle Kanäle benachrichtigt werden, die Übertragung in einem virtuellen Kanal auszusetzen, das heißt, die Übertragung von Paketen eines bestimmten Datenaustauschtyps auszusetzen. Wenn ein virtueller Kanal auf diese Weise vorübergehend ausgesetzt ist, bleiben alle anderen Kanäle davon unberührt und können mit voller Leistung weiterarbeiten. Die Steuersignale sind auf der gesamten Länge über jeden Router zurück bis zur Netzwerkschnittstellen-Steuereinheit 108 verdrahtet, die zu jedem Router gehört. Jede Netzwerkschnittstellen-Steuereinheit ist so gestaltet, dass sie nach Empfang eines derartigen Signals von ihrer zugehörigen Steuereinheit 108 für den Speicher-Datenaustausch oder von ihrem zugehörigen IP-Block 104 die Annahme von Datenaustauschanweisungen für den ausgesetzten virtuellen Kanal verweigert. Auf diese Weise wirkt sich die Aussetzung eines virtuellen Kanals auf alle Hardware aus, die den virtuellen Kanal auf der gesamten Länge zurück bis zu den verursachenden IP-Blöcken realisiert.
Eine Auswirkung des Aussetzens von Paketübertragungen in einem virtuellen Kanal besteht darin, dass Pakete in keinem Fall verworfen werden. Wenn ein Router mit einer Situation in Berührung kommt, in der ein Paket in einem etwas unzuverlässigen Protokoll wie zum Beispiel dem Internetprotokoll verworfen werden könnte, können die Router bei dem Beispiel aus 3 durch ihre Puffer 156 für virtuelle Kanäle und ihre Steuerlogik 154 für virtuelle Kanäle alle Übertragungen von Paketen in einem virtuellen Kanal aussetzen, bis wieder genügend Pufferplatz zur Verfügung steht, wodurch jegliche Notwendigkeit zum Verwerfen von Paketen beseitigt wird. Das NOC aus 3 kann daher hochzuverlässige Netzwerk-Datenaustauschprotokolle mit einer extrem dünnen Schicht von Hardware realisieren.
Das beispielhafte NOC aus 3 kann außerdem so gestaltet sein, dass ein Zusammenhang zwischen Cache-Zwischenspeichern sowohl des auf dem Chip angeordneten Speichers als auch des außerhalb des Chips angeordneten Speicher aufrechterhalten wird. Jedes NOC kann mehrere Cache-Zwischenspeicher unterstützen, von denen jeder mit demselben unterlagerten Speicheradressraum zusammenarbeitet. Beispielsweise können Cache-Zwischenspeicher durch IP-Blöcke, durch Steuereinheiten für den Speicher-Datenaustausch oder durch außerhalb des NOC angeordnete Steuereinheiten für Cache-Zwischenspeicher gesteuert werden. Jeder der auf dem Chip angeordneten Speicher 114, 116 bei dem Beispiel aus 2 kann außerdem als auf dem Chip angeordneter Cache-Zwischenspeicher realisiert sein, und im Rahmen des Schutzbereichs der vorliegenden Erfindung kann Cache-Zwischenspeicher auch außerhalb des Chips realisiert sein.
Jeder in 3 veranschaulichte Router 110 weist fünf Anschlüsse auf, vier Anschlüsse 158A bis D, die über Busleitungen 118 mit anderen Routern verbunden sind, und einen fünften Anschluss 160, der jeden Router über eine Netzwerkschnittstellen-Steuereinheit 108 und eine Steuereinheit 106 für den Speicher-Datenaustausch mit seinem zugehörigen IP-Block 104 verbindet. Wie an den Veranschaulichungen in den 2 und 3 zu erkennen ist, bilden die Router 110 und die Verbindungen 118 des NOC 102 ein vermaschtes Netzwerk mit vertikalen und horizontalen Verbindungen, über die die vertikalen und horizontalen Anschlüsse in jedem Router miteinander verbunden sind. In der Veranschaulichung aus 3 werden beispielsweise die Anschlüsse 158A, 158C und 160 als „vertikale Anschlüsse” und die Anschlüsse 1586 und 158D als „horizontale Anschlüsse” bezeichnet.
4 veranschaulicht als Nächstes in anderer Weise eine beispielhafte Ausführungsform eines IP-Blocks 104 gemäß der Erfindung, der als Verarbeitungselement realisiert ist, das in eine Anweisungseinheit (Instruction Unit, IU) 162, Ausführungseinheit (Execution Unit, XU) 164 und eine Hilfsausführungseinheit (Auxiliary Execution Unit, AXU) 166 unterteilt ist. Bei der veranschaulichten Realisierungsform weist die IU 162 eine Vielzahl von Anweisungspuffern 168 auf, die Anweisungen von einem L1-Anweisungs-Cache-Zwischenspeicher (iCACHE) 170 empfangen. Jeder Anweisungspuffer 168 ist einem aus einer Vielzahl, z. B. vier, symmetrischen SMT-Hardware-Threads (SMT = Symmetric Multithreaded) fest zugeordnet. Eine iERAT-Einheit (iERAT = Effective-to-real Translation) 172 ist mit dem iCACHE 170 verbunden und dient dazu, Anweisungs-Abrufanforderungen von einer Vielzahl von Thread-Abrufablaufsteuerungen 174 in reale Adressen für den Abruf von Anweisungen aus Speicher niedrigerer Ordnung umzusetzen. Jede Thread-Abrufablaufsteuerung 174 ist einem bestimmten Hardware-Thread fest zugeordnet und soll gewährleisten, dass durch den zugehörigen Thread auszuführende Anweisungen in den iCACHE abgerufen werden, um zur entsprechenden Ausführungseinheit weiterbefördert zu werden. Wie ebenfalls in 4 dargestellt, können Anweisungen, die in den Anweisungspuffer 168 abgerufen wurden, auch durch eine Verzweigungsvorhersagelogik 176 überwacht werden, die jeder Thread-Abrufablaufsteuerung 174 Hinweise bereitstellt, um fehlgeschlagene Cache-Zugriffe zu minimieren, die aus Verzweigungen in Ausführungs-Threads entstehen.
Die IU 162 weist auch einen Abhängigkeits-/Ausgabelogikblock 178 auf, der jedem Hardware-Thread fest zugeordnet und so gestaltet ist, dass Abhängigkeiten aufgelöst und die Ausgabe von Anweisungen aus dem Anweisungspuffer 168 an die XU 164 gesteuert werden. Außerdem ist bei der veranschaulichten Ausführungsform in der AXU 166 eine getrennte Abhängigkeits-/Ausgabelogik 180 bereitgestellt, wodurch unterschiedliche Threads gleichzeitig getrennte Anweisungen an die XU 164 und die AXU 166 ausgeben können. Bei einer alternativen Ausführungsform kann die Logik 180 in der IU 162 angeordnet sein, oder sie kann in ihrer Gesamtheit weggelassen sein, sodass die Logik 178 Anweisungen an die AXU 166 ausgibt.
Die XU 164 ist als Festkomma-Ausführungseinheit mit einem Satz von Mehrzweckregistern (General Purpose Registers, GPRs) 182 realisiert, die mit einer Festkommalogik 184, einer Verzweigungslogik 186 und einer Lade-/Speicherungslogik 188 verbunden sind. Die Lade-/Speicherungslogik 188 ist mit einem L1-Daten-Cache (dCACHE) 190 mit der Effective-to-Real-Umsetzung verbunden, die durch eine dERAT-Logik 192 bereitgestellt wird. Die XU 164 kann so gestaltet sein, dass sie praktisch einen beliebigen Anweisungssatz realisiert, z. B. den gesamten 32-Bit- oder 64-Bit-Anweisungssatz des PowerPC oder einen Teil davon.
Die AXU 166 fungiert als Hilfsausführungseinheit und weist die fest zugeordnete Abhängigkeits-/Ausgabelogik 180 zusammen mit einem oder mehreren Ausführungsblöcken 194 auf. Die AXU 166 kann eine beliebige Anzahl von Ausführungsblöcken aufweisen, und sie kann praktisch jeden beliebigen Typ von Ausführungseinheit realisieren, z. B. eine Fließkommaeinheit, eine oder mehrere spezialisierte Ausführungseinheiten, Verschlüsselungs-/Entschlüsselungseinheiten, Coprozessoren, Vektorverarbeitungseinheiten, Grafikverarbeitungseinheiten, XML-Verarbeitungseinheiten usw. Bei der veranschaulichenden Ausführungsform weist die AXU 166 eine schnelle Hilfsschnittstelle zur XU 164 auf, z. B. um direkte Verschiebungen zwischen einem angelegten AXU-Zustand und einem angelegten XU-Zustand zu unterstützen.
Der Datenaustausch mit dem IP-Block 104 kann auf die oben im Zusammenhang mit 2 erläuterte Weise über die Netzwerkschnittstellen-Steuereinheit 108 verwaltet werden, die mit dem NOC 102 verbunden ist. Der auf Adressen beruhende Datenaustausch, z. B. zum Zugriff auf den L2-Cache-Zwischenspeicher, kann zusammen mit dem auf Nachrichten beruhenden Datenaustausch bereitgestellt sein. Zum Beispiel kann der IP-Block 104 einen fest zugeordneten Nachrichteneingang und/oder Nachrichtenausgang aufweisen, um den zwischen Knoten auftretenden Datenaustausch zwischen IP-Blöcken zu verarbeiten.
Ausführungsformen der vorliegenden Erfindung können innerhalb der Hardware- und Softwareumgebung realisiert sein, die oben im Zusammenhang mit den 1 bis 4 beschrieben wurde. Für den Fachmann, der von der vorliegenden Offenbarung profitiert, wird jedoch klar sein, dass die Erfindung in einer Vielzahl unterschiedlicher Umgebungen realisiert werden kann und andere Veränderungen an der oben erwähnten Hardware- und Softwareumgebung vorgenommen werden können, ohne vom Schutzbereich der Erfindung abzuweichen. Daher ist die Erfindung nicht auf die hierin offenbarte jeweilige Hardware- und Softwareumgebung beschränkt.
Wegen der Bedeutung, Verzweigungsvorhersagelogik-Daten wie zum Beispiel Verzweigungsverlaufstabellen-Daten aufzubewahren und/oder zu gewährleisten, dass diese Daten exakte Verzweigungsvorhersageergebnisse bereitstellen, stellen Ausführungsformen gemäß der Erfindung Gastmodus- und/oder Benutzermodus-Mechanismen bereit, um einen Betrieb der Verzweigungsvorhersagelogik zu aktivieren und zu deaktivieren, der in Verbindung mit Hypervisormodus-Mechanismen funktioniert.
Viele Mikroarchitekturen von Mikroprozessoren weisen Hardware-Verzweigungsvorhersagealgorithmen auf, die ganz oder teilweise durch eine oder mehrere Verzweigungsverlaufstabellen realisiert werden. Eine korrekte Vorhersage von Verzweigungsergebnissen (Verzweigung eingeschlagen oder nicht eingeschlagen) kann sich erheblich auf die CPU-Gesamtleistung auswirken, insbesondere bei einem Mikroprozessor außerhalb der Reihenfolge. Daher ist es wichtig, zu gewährleisten, dass die Inhalte der Verzweigungsverlaufstabelle und anderer Verzweigungsvorhersageinformationen korrekt und repräsentativ für zukünftige Code-Datenströme sind.
Ausführungsformen gemäß der Erfindung erweitern beliebige Mechanismen des Hypervisorcodes, um den Betrieb einer Verzweigungsvorhersagelogik zu steuern, z. B. von Steuerregistern, die durch den Hypervisor zugänglich sind und zum Beispiel eine Verzweigungsvorhersagelogik wie beispielsweise Verzweigungsverlaufstabellen global aktivieren und deaktivieren. Insbesondere wird Gastmodus-Mechanismen für das durch einen Hypervisor gehostete Gastbetriebssystem und wahlweise für durch ihn gehostete Benutzermodus-Anwendungen und -prozesse ermöglicht, die Verzweigungsvorhersagelogik zu steuern, da sie zu den eigenen Code-Datenströmen des Gastbetriebssystems und/oder des Benutzers gehört, und gleichzeitig einem Hypervisor zu ermöglichen, einen globalen Verzweigungsvorhersagebetrieb einzurichten.
Bei den hierin im Folgenden erörterten Ausführungsformen können mehrere Funktionalitäten unterstützt sein, zu denen neben anderen Merkmalen beispielsweise Benutzermodus- und/oder Gastmodus-Anweisungen gehören können, um Aktualisierungen der Verzweigungsvorhersagelogik, z. B. Aktualisierungen von Verzweigungsverlaufstabellen, zu aktivieren/deaktivieren; Hypervisormodus- und/oder Gastmodus-Anweisungen, um auf der Grundlage einer Prozesskennung Aktualisierungen der Verzweigungsvorhersagelogik, z. B. Aktualisierungen von Verzweigungsverlaufstabellen, zu aktivieren/deaktivieren; Aktivierung/Deaktivierung der Gastmodus- und/oder Benutzermodus-Anweisungen durch den Hypervisor, um das Gastbetriebssystem und/oder Benutzeranwendungen beim Steuern der Verzweigungsvorhersagelogik in Situationen einzuschränken, in denen eine derartige Steuerung zeitlich verzögert werden sollte; und Hypervisormodus-Reset von Benutzermodus-Steuerelementen.
Ebenso ist es wegen der Bedeutung, Verzweigungsvorhersagelogik-Daten wie zum Beispiel Verzweigungsverlaufstabellen-Daten aufzubewahren und/oder zu gewährleisten, dass diese Daten exakte Verzweigungsvorhersageergebnisse bereitstellen, bei einigen Ausführungsformen auch wünschenswert, einen fein abgestimmten Mechanismus zur Speicherung und Wiederherstellung eines Verzweigungsvorhersagelogik-Zustands vorzusehen.
Normalerweise ist eine Verzweigungsvorhersagelogik, z. B. eine Verzweigungsverlaufstabelle, eine Hardwareressource, die von allen Hardware-Threads und allen Softwareprozessen gemeinsam genutzt wird, die auf diesen Hardware-Threads in einem bestimmten Verarbeitungskern ausgeführt werden. Dies kann zu einem Problem führen, bei dem der Verzweigungsverlaufstabellen-Zustand zwangsweise beseitigt wird, wenn Softwareprozesse unterschiedliche Codesätze ausführen. Herkömmliche Hardware-Realisierungsformen nutzen Hash-Algorithmen, verschiedene Größen von Verzweigungsverlaufstabellen und andere Techniken, um die Auswirkungen der gemeinsamen Nutzung durch Prozesse zu verringern; viele dieser Techniken erhöhen jedoch in unerwünschter Weise die Größe und Komplexität einer Verzweigungsvorhersagelogik.
Im Gegensatz hierzu können Ausführungsformen gemäß der Erfindung eine fein abgestimmte Steuerung des Speicherns und Wiederherstellens des Zustands einer Verzweigungsvorhersagelogik vorsehen, wodurch die Aufwärmzeit der Logik zur Erfassung von Verlaufsinformationen verkürzt und dadurch die Genauigkeit einer Verzweigungsvorhersagelogik für verschiedene Arten von Software verbessert werden können, die im System ausgeführt werden. Auf diese Weise kann eine Kontextumschaltung einer Software ermöglichen, mit einer „aufgewärmten” Verzweigungsverlaufstabelle ausgeführt zu werden, die für diesen Prozess spezifisch ist. Darüber hinaus können durch Speichern von Zustandsdaten anstelle des Zulassens ihrer erzwungenen Beseitigung, wenn Zustandsdaten für mehrere Prozesse erfasst werden, die Größe und Komplexität einer Verzweigungsvorhersagelogik verringert werden.
Wie im Folgenden ausführlicher erörtert wird, können Ausführungsformen gemäß der Erfindung Anweisungen bereitstellen, die beispielsweise die Verzweigungsverlaufstabellen-Zustandsinformationen speichern und wiederherstellen, einschließlich von Hypervisormodus-Anweisungen zur Speicherung/Wiederherstellung des Verzweigungsvorhersagelogik-Zustands im Speicher oder auf einem anderen Speichermedium bzw. von diesen; Gastmodus- und/oder Benutzermodus-Anweisungen zur Speicherung/Wiederherstellung des Verzweigungsvorhersagelogik-Zustands im/vom Speicher; Hypervisormodus-Aktivierung/-Deaktivierung von Speicherungs-/Wiederherstellungsanweisungen des Gastmodus und/oder Benutzermodus; und Hypervisormodus-Reset eines Verzweigungsvorhersagelogik-Zustands.
Unter Bezugnahme auf 5 veranschaulicht diese Figur eine beispielhafte Hardware- und Softwareumgebung eines Datenverarbeitungssystems 200, in dem eine Virtualisierungsunterstützung zur fein abgestimmten Steuerung einer Verzweigungsvorhersagelogik gemäß der Erfindung realisiert sein kann. Aus einer Perspektive der Hardware 202 weist das Datenverarbeitungssystem 200 eine Vielzahl von Prozessoren oder Verarbeitungseinheiten 204 auf, von denen jede einen oder mehrere Hardware-Threads 206 aufweist, die durch eine Verzweigungsvorhersagelogik 208 unterstützt werden, und ein oder mehrere Spezialregister (Special Purpose Register, SPRs) 210, einen Speicher 212 und eine E/A-Schicht 214 aufweist, die das Datenverarbeitungssystem mit verschiedenen Hardwareressourcen verbindet, z. B. mit externen Netzwerken, Speichereinheiten und Speichernetzwerken usw.
Bei dieser beispielhaften Ausführungsform werden sowohl die selektive Aktivierung einer Verzweigungsvorhersagelogik als auch Speicherungen/Wiederherstellungen eines Verzweigungsvorhersagelogik-Zustands unterstützt. Daher und wie im Folgenden ausführlicher erörtert wird, können ein oder mehrere Steuerregister, die als SPRs realisiert sind, verwendet werden, um sowohl den Aktivierungszustand einer Verzweigungsvorhersagelogik als auch Speicherungs-/Wiederherstellungsoperationen im Zusammenhang mit einem Verzweigungsvorhersagelogik-Zustand zu steuern. Des Weiteren können gespeicherte Zustandsdaten 216 im Speicher 212 gespeichert sein und im Zusammenhang mit Wiederherstellungsoperationen abgerufen werden. Es wird jedoch klar sein, dass einige Datenverarbeitungssysteme gemäß der Erfindung unter Umständen nur die selektive Aktivierung einer Verzweigungsvorhersagelogik unterstützen, während andere unter Umständen nur Speicherungen/Wiederherstellungen eines Verzweigungsvorhersagelogik-Zustands unterstützen, sodass die hierin offenbarte Realisierungsform nicht die ausschließliche Art und Weise der Realisierung der Erfindung bildet.
Es wird klar sein, dass die Verteilung von Hardware-Threads, Verzweigungsvorhersagelogik und Prozessoren/Verarbeitungseinheiten bei unterschiedlichen Ausführungsformen variieren kann. Zum Beispiel können die Prozessoren 204 als Verarbeitungskerne in einem oder mehreren Mehrkern-Prozessorchips realisiert sein, und jeder Prozessor 204 kann eine beliebige Anzahl von Hardware-Threads aufweisen. Des Weiteren kann die Verzweigungsvorhersagelogik von mehreren Threads gemeinsam genutzt werden, oder sie kann für unterschiedliche Threads repliziert werden. Darüber hinaus kann die Verzweigungsvorhersagelogik zu einer bestimmten Ausführungseinheit in einem Prozessor gehören, oder sie kann für den ganzen Prozessor gelten. Bei einer Ausführungsform können die Prozessoren 204 zum Beispiel als IP-Blöcke realisiert sein, die untereinander in einer NOC-Anordnung verbunden sind, wie oben in Verbindung mit den 1 bis 4 offenbart. Wie klar sein wird, kann die Erfindung daher in praktisch jeder Hardwareumgebung genutzt werden, in der die Verzweigungsvorhersagelogik in einem Prozessor oder in einem Verarbeitungskern genutzt wird, und die Erfindung ist daher nicht auf die hierin offenbarte bestimmte Hardwareumgebung beschränkt.
Aus einer Software Perspektive betrachtet realisiert das Datenverarbeitungssystem eine virtualisierte Umgebung, in der ein Hypervisor 218, der oftmals auch als „Partitionsmanager” oder „Virtual Machine Manager” bezeichnet wird, ein oder mehrere Gastbetriebssysteme 220 hostet und eine Schnittstelle zwischen den Gastbetriebssystemen 220 und der Hardware 202 bereitstellt, sodass den Gastbetriebssystemen 220 ein Teil der Hardwareressourcen (z. B. Hardware-Threads, Verarbeitungskerne, Prozessoren, Speicher, E/A-Funktionalität usw.) in dem Datenverarbeitungssystem zugeordnet wird, und sodass die Gastbetriebssysteme 220 nahezu so funktionieren, als würden sie in einer nicht virtualisierten Umgebung arbeiten. Jedes Gastbetriebssystem 220 hostet eine oder mehrere Benutzeranwendungen oder ein oder mehrere Benutzerprogramme 222, die normalerweise in unabhängigen Prozessen arbeiten, um Konflikte zwischen unterschiedlichen Anwendungen zu minimieren.
Ausführbare Anweisungen im Zusammenhang mit dem Hypervisor 218, den Gastbetriebssystemen 220 und den Benutzeranwendungen 222 werden dementsprechend als „Hypervisormodus-Anweisungen”, „Gastmodus-Anweisungen” und „Benutzermodus-Anweisungen” bezeichnet, die die Aktivitäten jeder Softwareebene selektiv einschränken und ihre relativen Prioritäten steuern. Dem Hypervisor 218 insbesondere ist der Modus mit der höchsten Priorität zugeteilt, wobei den Gastbetriebssystemen 220 und Benutzeranwendungen 222 abnehmende Prioritäten zugewiesen sind.
Um die selektive Aktivierung einer Verzweigungsvorhersagelogik zu realisieren, unterstützt das Datenverarbeitungssystem 200 sowohl die Hypervisormodus- als auch die Gastmodus-Steuerung der Verzweigungsvorhersagelogik, sodass die Gastmodus-Steuerelemente verwendet werden können, um beliebige Hypervisormodus-Steuerelemente außer Kraft zu setzen. Darüber hinaus können bei einigen Ausführungsformen Benutzermodus-Steuerelemente verwendet werden, um beliebige Gastmodus- und/oder Hypervisormodus-Steuerelemente außer Kraft zu setzen. Bei einigen Ausführungsformen können derartige Steuerelemente auf alle Gastbetriebssysteme und/oder Benutzeranwendungen angewendet werden, sodass, sobald ein Prozessor oder ein Verarbeitungskern eine beliebige Gastmodus-/Benutzermodus-Anweisung ausführt, die Gastmodus-/Benutzermodus-Steuerelemente verwendet werden, um die Verzweigungsvorhersagelogik zu steuern, aber die Hypervisormodus-Steuerelemente für Hypervisormodus-Anweisungen verwendet werden. Alternativ können Gastmodus- und/oder Benutzermodus-Steuerelemente mit bestimmten Gastbetriebssystemen und/oder Benutzeranwendungen verknüpft werden, sodass zum Beispiel jedes Gastbetriebssystem und/oder jede Benutzeranwendung die Verzweigungsvorhersagelogik getrennt von anderen Gastbetriebssystemen und/oder Benutzeranwendungen steuern kann.
Darüber hinaus kann es wünschenswert sein, einem Hypervisor und/oder Gastbetriebssystem zu ermöglichen, die Steuerelemente beliebiger Software höherer Ebenen wirksam zu „sperren”, sodass die Fähigkeit eines Gastbetriebssystems oder einer Benutzer Anwendung zur Steuerung der Verzweigungsvorhersagelogik deaktiviert werden kann, entweder systemweit oder auf bestimmte Gastbetriebssysteme und/oder Benutzeranwendungen begrenzt.
Bei den veranschaulichten Ausführungsformen ist die Steuerung der selektiven Aktivierung einer Verzweigungsvorhersagelogik durch die Kontrolle über einen Aktivierungszustand der Verzweigungsvorhersagelogik realisiert. Wenn der Aktivierungszustand anzeigt, dass die Verzweigungsvorhersagelogik aktiviert ist, ist die Verzweigungsvorhersagelogik aktiv und arbeitet in einer normalen Art und Weise, während, wenn der Aktivierungszustand anzeigt, dass die Verzweigungsvorhersagelogik nicht aktiviert ist, die Verzweigungsvorhersagelogik im Wesentlichen „abgeschaltet” ist, sodass die Verzweigungsvorhersagelogik nicht versucht, das Ergebnis von Verzweigungsanweisungen vorherzusagen, und normalerweise keine Verlaufsdaten auf der Grundlage der überwachten Ausführung eines oder mehrerer Anweisungsdatenströme erfasst, die durch einen Prozessor oder Verarbeitungskern ausgeführt werden. Beispielsweise kann eine Verzweigungsvorhersagelogik, die eine Verzweigungsverlaufstabelle aufweist, so gestaltet sein, dass das Zwischenspeichern neuer Einträge in der Verzweigungsverlaufstabelle oder das Aktualisieren bestehender Einträge in der Tabelle unterbrochen wird.
Der Aktivierungszustand der Verzweigungsvorhersagelogik kann zum Beispiel unter Verwendung eines oder mehrerer, auf Hardware beruhender Steuerregister gesteuert werden, auf die die Verzweigungsvorhersagelogik zugreift, um zu ermitteln, ob die Verzweigungsvorhersagelogik gegenwärtig aktiv ist. Als Beispiel veranschaulicht 6 ein beispielhaftes Aktivierungsmodus-Steuerregister 230, das ein Hypervisor-Aktivierungsfeld 232, ein Gast-Aktivierungsfeld 234 und ein Benutzer-Aktivierungsfeld 236 aufweist, die jeweils steuern, ob die Verzweigungsvorhersagelogik aktiv ist, wenn Hypervisormodus-, Gastmodus-, und Benutzermodus-Anweisungen ausgeführt werden. Alle drei Felder 232 bis 236 sind durch den Hypervisor beschreibbar, während die Felder 234 und 236 durch ein Gastbetriebssystem beschreibbar sind und das Feld 236 durch eine Benutzeranwendung beschreibbar ist.
Darüber hinaus werden zwei Sperrfelder verwendet, das Gast-Sperrfeld 238 und das Benutzer-Sperrfeld 240, um die Fähigkeit eines Gastbetriebssystems (bei Feld 238) oder einer Benutzeranwendung (bei Feld 240) zu deaktivieren, in das entsprechende Aktivierungsfeld 234, 236 zu schreiben und somit die Verzweigungsvorhersagelogik zu steuern. Normalerweise sind die Sperrfelder 238 und 240 durch einen Hypervisor beschreibbar, und das Sperrfeld 240 ist durch ein Gastbetriebssystem beschreibbar, obwohl beide Sperrfelder durch alle Ebenen gelesen werden können, sodass beispielsweise ein Gastbetriebssystem oder eine Benutzeranwendung prüfen können, ob Rechte zur Steuerung der Verzweigungsvorhersagelogik gewährt wurden, bevor ein Versuch unternommen wird, um den Aktivierungszustand der Logik zu ändern.
Bei einigen Anwendungen kann es wünschenswert sein, den gesamten Zustand oder einen Teil des Zustands des Steuerregisters 230 in Verbindung mit Kontextumschaltungen zu speichern und wiederherzustellen, sodass beispielsweise die durch Gastbetriebssysteme und/oder Benutzeranwendungen gesetzten Aktivierungszustände nur verwendet werden, wenn Anweisungen für diese Gastbetriebssysteme und/oder Benutzeranwendungen ausgeführt werden, wodurch die Fähigkeit unterstützt wird, jedes Betriebssystem und/oder jede Benutzeranwendung zur Verfügung zu haben.
Alternativ kann es wie in 7 dargestellt wünschenswert sein, eine Datenstruktur wie zum Beispiel eine prozessspezifische Aktivierungsmodustabelle 250 zu verwenden, die eine Vielzahl von Einträgen 252 aufweist, die eine Prozesskennung 254 mit Benutzer-Aktivierungsfeldern und -Sperrfeldern 256, 258 verknüpfen, die eine prozessspezifische Anpassung einer Verzweigungsvorhersagelogik ermöglichen. Die Tabelle 250 kann durch einen Hypervisor oder ein Gastbetriebssystem verwaltet werden, um zu konfigurieren, welche Prozesse und welche Anwendungen in diesen Prozessen die Verzweigungsvorhersagelogik steuern können und diesen Prozessen das selektive Aktivieren und Deaktivieren der Verzweigungsvorhersagelogik zu ermöglichen oder das selektive Aktivieren und Deaktivieren einzuschränken, während die jeweiligen Prozesse ausgeführt werden. Eine ähnliche Datenstruktur kann bei einigen Ausführungsformen auch verwendet werden, um eine gastspezifische Kontrolle über mehrere Gastbetriebssysteme bereitzustellen.
Darüber hinaus kann wie oben erwähnt eine Verzweigungsvorhersagelogik durch mehrere Hardware-Threads gemeinsam genutzt werden, die in einem bestimmten Prozessorkern ausgeführt werden, und bei den in den 6 bis 7 veranschaulichten Ausführungsformen wirkt sich die Kontrolle über die Verzweigungsvorhersagelogik normalerweise auf alle Hardware-Threads aus, die die Verzweigungsvorhersagelogik in einem bestimmten Prozessorkern nutzen. Alternativ kann wie in 8 veranschaulicht eine Thread-spezifische Aktivierungsmodus-Datenstruktur wie zum Beispiel eine Tabelle 260 getrennte Einträge 262 aufweisen, die zu unterschiedlichen Threads gehören und getrennte Hypervisor-, Gast- und Benutzer-Aktivierungsfelder 264, 266, 268 und Gast- und Benutzer-Sperrfelder 270, 272 für jeden Hardware-Thread aufweisen, sodass unterschiedliche Aktivierungszustände für unterschiedliche Hardware-Threads gesetzt werden können. Die Verzweigungsvorhersagelogik kann anschließend so gestaltet sein, dass sie auf die Tabelle 260 zugreift, um zu ermitteln, ob die Logik aktiv sein sollte, wenn Anweisungen ausgeführt werden, die zu einem bestimmten Hardware-Thread gehören, der gegenwärtig einem bestimmten virtuellen Thread zugeordnet ist.
Als weitere Alternative können die Aktivierungssteuerelement-Datenstrukturen virtualisiert sein und zu bestimmten virtuellen Threads gehören, sodass, sobald ein bestimmter virtueller Thread durch einen bestimmten Hardware-Thread ausgeführt wird, die zu diesem virtuellen Thread gehörenden Aktivierungssteuerelemente für diesen virtuellen Thread verwendet werden. Beispielsweise kann ein virtuelles Thread-spezifisches Steuerregister in ein auf Hardware beruhendes Steuerregister für einen Verarbeitungskern geladen werden, dem die Ausführung eines derartigen virtuellen Threads während einer Kontextumschaltung auf diesen virtuellen Thread zugewiesen ist, sodass die Verzweigungsvorhersagelogik in dem Verarbeitungskern so gestaltet ist, dass sie in einer Weise arbeitet, die durch den virtuellen Thread angegeben ist.
Unabhängig davon, wie die auf den Aktivierungszustand bezogenen Steuerungsdaten verwaltet werden, kann die Verzweigungsvorhersagelogik während des Betriebs eines Datenverarbeitungssystems in der allgemeinen Weise selektiv aktiviert werden, die durch die Abfolge von Operationen 280 aus 9 veranschaulicht ist, in der die allgemeine Ausführung eines einzelnen Hardware-Threads in einem Datenverarbeitungssystem dargestellt ist. Es wird klar sein, dass andere, in einem Datenverarbeitungssystem residente Hardware-Threads in einer ähnlichen Weise ausgeführt werden können.
Auf der Hypervisorebene schaltet die Ausführung regelmäßig zwischen dem Hypervisor und einem oder mehreren Gastbetriebssystemen um, wie in den Blöcken 282 bis 294 dargestellt. Insbesondere der Block 282 aktiviert oder deaktiviert die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands des Gastbetriebssystems, dessen Ausführung durch den Thread bevorsteht. Es wird klar sein, dass dieser Aktivierungszustand durch das Gastbetriebssystem markiert werden kann, oder er kann durch den Hypervisor markiert werden, entweder, weil das Gastbetriebssystem daran gehindert wird, den Aktivierungszustand zu setzen, oder weil das Gastbetriebssystem einen durch den Hypervisor festgelegten Standardzustand nicht außer Kraft gesetzt hat.
Sobald die Verzweigungsvorhersagelogik selektiv aktiviert oder deaktiviert wurde, wird das Gastbetriebssystem eine bestimmte Zeit lang betrieben bzw. ausgeführt (Block 284), sodass die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands des gegenwärtig ausgeführten Gastbetriebssystems aktiviert oder deaktiviert wird. Die Ausführung wird fortgesetzt, entweder bis zu einem vorbeugenden Interrupt oder, wie in Block 286 dargestellt, bis das Gastbetriebssystem seine zugewiesene Zeitscheibe beendet hat, wodurch die Steuerung zu Block 288 übergeht, um die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands des Hypervisors zu aktivieren oder zu deaktivieren. Der Hypervisor wird anschließend eine Zeit lang betrieben bzw. ausgeführt (Block 290), und es wird in Block 292 eine Ermittlung dahingehend vorgenommen, ob eine Rückkehr zur Ausführung des letzten Betriebssystems durchzuführen oder zu einem anderen Gastbetriebssystem zu wechseln ist. Wenn eine Entscheidung getroffen wird, zu einem anderen Gastbetriebssystem zu wechseln, geht die Steuerung zu Block 294 über, um den Wechsel durchzuführen, und anschließend zurück zu Block 282, um das neue Gastbetriebssystem unter Verwendung des Aktivierungszustands des neuen Gastbetriebssystems auszuführen. Anderenfalls kehrt die Steuerung in Block 292 zu Block 282 zurück, um das Ausführen des aktuellen Gastbetriebssystems unter Verwendung des Aktivierungszustands des aktuellen Gastbetriebssystems fortzusetzen.
Auf der Gastbetriebssystemebene werden regelmäßig Kontextumschaltungen zwischen dem Gastbetriebssystem und einer oder mehreren Benutzeranwendungen durchgeführt, wie in den Blöcken 296 bis 308 dargestellt. Insbesondere der Block 296 aktiviert oder deaktiviert die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands der Benutzeranwendung, deren Ausführung durch den Thread bevorsteht. Es wird klar sein, dass dieser Aktivierungszustand durch die Benutzeranwendung markiert werden kann, oder er kann durch den Hypervisor oder durch das Gastbetriebssystem markiert werden, entweder, weil die Benutzeranwendung daran gehindert wird, den Aktivierungszustand zu setzen, oder weil die Benutzeranwendung einen durch den Hypervisor oder das Gastbetriebssystem festgelegten Standardzustand nicht außer Kraft gesetzt hat.
Sobald die Verzweigungsvorhersagelogik selektiv aktiviert oder deaktiviert wurde, wird die Benutzeranwendung eine bestimmte Zeit lang betrieben bzw. ausgeführt (Block 298), sodass die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands der gegenwärtig ausgeführten Benutzeranwendung aktiviert oder deaktiviert wird. Die Ausführung wird fortgesetzt, entweder bis zu einem vorbeugenden Interrupt oder, wie in Block 300 dargestellt, bis die Benutzeranwendung ihre zugewiesene Zeitscheibe beendet hat, wodurch die Steuerung zu Block 302 übergeht, um die Verzweigungsvorhersagelogik auf der Grundlage des Aktivierungszustands des Gastbetriebssystems zu aktivieren oder zu deaktivieren. Das Gastbetriebssystem wird anschließend eine Zeit lang betrieben bzw. ausgeführt (Block 304), und es wird in Block 306 eine Ermittlung dahingehend vorgenommen, ob eine Rückkehr zur Ausführung der letzten Benutzeranwendung durchzuführen oder zu einer anderen Benutzeranwendung zu wechseln ist. Wenn eine Entscheidung getroffen wird, zu einer anderen Benutzeranwendung zu wechseln, geht die Steuerung zu Block 308 über, um den Wechsel durchzuführen, und anschließend zurück zu Block 296, um die neue Benutzeranwendung unter Verwendung des Aktivierungszustands der neuen Benutzeranwendung auszuführen. Anderenfalls kehrt die Steuerung in Block 306 zu Block 296 zurück, um das Ausführen der aktuellen Benutzeranwendung unter Verwendung des Aktivierungszustands der aktuellen Benutzeranwendung fortzusetzen.
Wenn ein Anwendungsentwickler bei Ausführungsformen gemäß der Erfindung erkennt, dass bestimmte Abschnitte einer in der Entwicklungsphase befindlichen Anwendung oder die gesamte Anwendung dazu neigt, die Verzweigungsvorhersagelogik mit nutzlosen Verlaufsinformationen zu beschädigen, z. B. wegen des zufälligen und nicht vorhersagbaren Charakters der Betriebslast, kann der Entwickler daher die Anwendung so gestalten, dass die Verzweigungsvorhersagelogik für die Anwendung oder für beliebige problematische Abschnitte davon selektiv deaktiviert und dadurch eine Beschädigung der Verzweigungsvorhersagelogik vermieden wird, was zu einer verbesserten Verzweigungsvorhersage für andere Abschnitte der Anwendung sowie für beliebige andere Programme führt, die die Verzweigungsvorhersagelogik nutzen könnten. Wenn ein Gastbetriebssystem Kenntnis von bestimmten Anwendungen oder bestimmten Arten von Anwendungen hat, die in Verbindung mit einer aktivierten Verzweigungsvorhersagelogik nicht gut funktionieren, oder wenn ein Hypervisor Kenntnis von bestimmten Anwendungen oder Gastbetriebssystemen hat, die in Verbindung mit einer Verzweigungsvorhersage nicht gut funktionieren, können das Gastbetriebssystem und/oder der Hypervisor ebenso die Verzweigungsvorhersagelogik selektiv deaktivieren, wenn diese nicht kompatiblen Programme ausgeführt werden.
Als Nächstes ist in den veranschaulichenden Ausführungsformen die Kontrolle über das Speichern und Wiederherstellen des Zustands einer Verzweigungsvorhersagelogik durch die Verwendung von Hypervisormodus- sowie Gastmodus- und/oder Benutzermodus-Anweisungen realisiert, z. B. mithilfe von Verschiebeanweisungen zwischen adressierbaren Registern in der Verzweigungsvorhersagelogik oder mithilfe eines oder mehrerer durch die Verzweigungsvorhersage bereitgestellter Ports und eines Speichers oder anderen Puffers, der zwischengespeicherte Zustandsinformationen aufnehmen kann. Beispielsweise kann die Software bei einigen Ausführungsformen eine Speicheradresse in einem SPR bereitstellen und anschließend ein Startbit schreiben (z. B. ein Bit zum Speichern, ein Bit zum Wiederherstellen), um eine Mikrocodeeinheit oder eine Hardware-Unterstützungsablaufsteuerung darüber zu informieren, die Daten an der bereitgestellten Speicheradresse zu speichern bzw. von dieser wiederherzustellen. Bei einigen Ausführungsformen können die SPRs, in denen die Adresse und die Startbits gespeichert sind, durch den oben erwähnten Hypervisor-/Gast-/Benutzermechanismus zum Setzen des Aktivierungszustands geschützt werden. Darüber hinaus können, wenn keine Hardware-Unterstützungsablaufsteuerung verwendet wird, Softwareanweisungen Speicherungs- und Wiederherstellungsoperationen durchführen, indem eine Schleife zwischen Anweisungen durchlaufen wird, mit denen eine Speicheradresse festgelegt, ein Startbit geschrieben und die Adresse schrittweise erhöht werden, bis alle Daten übertragen wurden.
Bei einigen Ausführungsformen können, wie z. B. in 10 dargestellt, ein Speicherungsmodus-Steuerregister 310 einschließlich der Sperrfelder 312, 314 für Gastmodus- und Benutzermodus-Anweisungen verwendet werden, um Gastbetriebssysteme und/oder Benutzeranwendungen oder -prozesse selektiv zu aktivieren, um Verzweigungsvorhersagelogik-Zustandsdaten zu speichern und/oder wiederherzustellen. Das Aktivieren der Speicherungs-/Wiederherstellungsfunktionalität kann wie die Aktivierungs-/Deaktivierungsfunktionalität für alle Gastbetriebssysteme und/oder Benutzeranwendungen gelten, oder es kann bei einigen Ausführungsformen gemäß der Erfindung speziell für bestimmte Gastbetriebssysteme, Benutzeranwendung und und/oder Benutzerprozesse gelten.
Darüber hinaus kann, wie oben erwähnt, die Umsetzung von Speicherungs- und Wiederherstellungsoperationen hauptsächlich in Software realisiert sein, z. B. mithilfe von Schleifen aus Verschiebeanweisungen, oder sie kann alternativ auf einer zweckgebundenen Logik beruhen, die sich in der Verzweigungsvorhersagelogik befindet oder in anderer Weise mit der Verzweigungsvorhersagelogik verbunden ist, um Speicherungs- und Wiederherstellungsoperationen zu beschleunigen. Beispielsweise veranschaulicht 11 eine beispielhafte Verzweigungsverlaufstabelle 320 einschließlich einer Vielzahl von Einträgen 322, die mit einer Lade-/Speicherungseinheit 324 für Verzweigungsverlaufstabellen verbunden ist. Die Lade-/Speicherungseinheit 324 kann zum Beispiel verwendet werden, um einen oder mehrere Einträge 322 aus der Verzweigungsverlaufstabelle 320 als Zustandsdaten 326 in einen Speicher 328 zu kopieren, sowie, um die Verzweigungsverlaufstabelle 320 wiederherzustellen, indem Einträge in den Zustandsdaten 326 zurück in die Verzweigungsverlaufstabelle 320 kopiert werden.
Im Speicher 328 können mehrere Kopien von Zustandsdaten 326 verwaltet werden, z. B. auf der Grundlage unterschiedlicher Benutzeranwendungen, unterschiedlicher Gastbetriebssysteme usw. Der Speicher 328 kann Teil der Hauptspeicherarchitektur eines Datenverarbeitungssystems sein, oder er kann ein zweckgebundener Puffer sein, bei einigen Realisierungsformen z. B. ein zweckgebundener Puffer in einem Verarbeitungskern. Die Lade-/Speicherungseinheit 324 kann zum Beispiel als Ablaufsteuerungs- oder Mikrocodeeinheit realisiert sein, die auf Eingangsdaten reagiert, die durch einen Thread bereitgestellt werden, um eine Übertragung ausgewählter Daten zwischen der Verzweigungsverlaufstabelle 320 und dem Speicher 328 auszulösen.
Bei einigen Realisierungsformen können die gesamte Verzweigungsverlaufstabelle und wahlweise einschließlich anderer Zustandsdaten für die Verzweigungsvorhersagelogik als Zustandsdaten gespeichert/wiederhergestellt werden. Bei einigen Ausführungsformen kann es jedoch wünschenswert sein, nur eine Teilmenge von Daten zu speichern/wiederherzustellen, die den Zustand der Verzweigungsvorhersagelogik wiedergeben, z. B. Einträge 322 zu überspringen, die als ungültig markiert sind, oder nur die am meisten oder die zuletzt verwendeten Einträge zu speichern. Darüber hinaus kann es, wie durch ein Komprimierungs-/Dekomprimierungsmodul 330 in der Lade-/Speicherungseinheit 324 dargestellt, bei einigen Ausführungsformen wünschenswert sein, die Zustandsdaten im Speicher 328 zu komprimieren, um die Größe des Speicherplatzes zu verringern, der zur Verwaltung der Zustandsdaten erforderlich ist, und anschließend die komprimierten Daten zu dekomprimieren, während sie zurück in die Verzweigungsvorhersagelogik wiederhergestellt werden. Andere auf Hardware beruhende Arten des Beschleunigens oder anderenfalls des Verringerns der Auswirkung auf das Betriebsverhalten beim Speichern und Wiederherstellen der Zustandsdaten der Verzweigungsvorhersagelogik können als Alternative verwendet werden.
Unabhängig davon, wie die Verzweigungsvorhersagelogik-Zustandsdaten gespeichert und wiederhergestellt werden, veranschaulicht 12 eine Abfolge von Operationen 340, die zur allgemeinen Ausführung eines einzelnen Hardware-Threads in einem Datenverarbeitungssystem in Verbindung mit dem Speichern und Wiederherstellen von Verzweigungsvorhersagelogik-Zustandsdaten geeignet sind. Es wird klar sein, dass andere, in einem Datenverarbeitungssystem residente Hardware-Threads in einer ähnlichen Weise ausgeführt werden können.
Auf der Hypervisorebene schaltet die Ausführung regelmäßig zwischen dem Hypervisor und einem oder mehreren Gastbetriebssystemen um, wie in den Blöcken 342 bis 360 dargestellt. Insbesondere stellt der Block 342, z. B. als Reaktion auf eine Gastmodus-Anweisung im Gastbetriebssystem, gespeicherte Verzweigungsvorhersagelogik-Zustandsdaten für das Gastbetriebssystem wieder her. Sobald die Verzweigungsvorhersagelogik-Zustandsdaten wiederhergestellt sind, wird das Gastbetriebssystem eine bestimmte Zeit lang betrieben bzw. ausgeführt (Block 346), sodass die Verzweigungsvorhersagelogik den wiederhergestellten Zustand verwendet, während das Gastbetriebssystem ausgeführt wird. Die Ausführung wird fortgesetzt, entweder bis zu einem vorbeugenden Interrupt oder, wie in Block 348 dargestellt, bis das Gastbetriebssystem seine zugewiesene Zeitscheibe beendet hat, wodurch die Steuerung zu Block 350 übergeht, um den Zustand der Verzweigungsvorhersagelogik zu speichern, z. B. als Reaktion auf eine Gastmodus-Anweisung im Gastbetriebssystem. Als Nächstes stellt der Block 352, z. B. als Reaktion auf eine Hypervisormodus-Anweisung im Hypervisor, den gespeicherten Verzweigungsvorhersagelogik-Zustand für den Hypervisor wieder her. Der Hypervisor wird anschließend eine Zeit lang betrieben bzw. ausgeführt (Block 354), und danach speichert der Block 356 den Zustand der Verzweigungsvorhersagelogik, z. B. als Reaktion auf eine Hypervisormodus-Anweisung im Hypervisor. Als Nächstes wird im Block 358 eine Ermittlung dahingehend vorgenommen, ob eine Rückkehr zum letzten Gastbetriebssystem durchzuführen oder zu einem anderen Gastbetriebssystem zu wechseln ist. Wenn eine Entscheidung getroffen wird, zu einem anderen Gastbetriebssystem zu wechseln, geht die Steuerung zu Block 360 über, um den Wechsel durchzuführen, und anschließend zurück zu Block 342, um den Verzweigungsvorhersagelogik-Zustand für das Gastbetriebssystem wiederherzustellen. Anderenfalls kehrt die Steuerung in Block 358 zu Block 342 zurück, um den Verzweigungsvorhersagelogik-Zustand für das Gastbetriebssystem wiederherzustellen.
Auf der Gastbetriebssystemebene werden regelmäßig Kontextumschaltungen zwischen dem Gastbetriebssystem und einer oder mehreren Benutzeranwendungen durchgeführt, wie in den Blöcken 362 bis 380 dargestellt. Insbesondere stellt der Block 362, z. B. als Reaktion auf eine Benutzermodus-Anweisung in der Benutzeranwendung, gespeicherte Verzweigungsvorhersagelogik-Zustandsdaten für die Benutzeranwendung wieder her. Sobald die Verzweigungsvorhersagelogik-Zustandsdaten wiederhergestellt sind, wird die Benutzeranwendung eine bestimmte Zeit lang betrieben bzw. ausgeführt (Block 364), sodass die Verzweigungsvorhersagelogik den wiederhergestellten Zustand verwendet, während die Benutzeranwendung ausgeführt wird. Die Ausführung wird fortgesetzt, entweder bis zu einem vorbeugenden Interrupt oder, wie in Block 368 dargestellt, bis die Benutzeranwendung ihre zugewiesene Zeitscheibe beendet hat, wodurch die Steuerung zu Block 370 übergeht, um den Zustand der Verzweigungsvorhersagelogik zu speichern, z. B. als Reaktion auf eine Benutzermodus-Anweisung in der Benutzeranwendung. Als Nächsten stellt der Block 372, z. B. als Reaktion auf eine Gastmodus-Anweisung im Gastbetriebssystem, den gespeicherten Verzweigungsvorhersagelogik-Zustand für das Gastbetriebssystem wieder her. Das Gastbetriebssystem wird anschließend eine Zeit lang betrieben bzw. ausgeführt (Block 374), und danach speichert der Block 376 den Zustand der Verzweigungsvorhersagelogik, z. B. als Reaktion auf eine Gastmodus-Anweisung im Gastbetriebssystem. Als Nächstes wird im Block 378 eine Ermittlung dahingehend vorgenommen, ob eine Rückkehr zur letzten Benutzeranwendung durchzuführen oder zu einer anderen Benutzeranwendung zu wechseln ist. Wenn eine Entscheidung getroffen wird, zu einer anderen Benutzeranwendung zu wechseln, geht die Steuerung zu Block 380 über, um den Wechsel durchzuführen, und anschließend zurück zu Block 362, um den Verzweigungsvorhersagelogik-Zustand für die Benutzeranwendung wiederherzustellen. Anderenfalls kehrt die Steuerung in Block 378 zu Block 362 zurück, um den Verzweigungsvorhersagelogik-Zustand für die Benutzeranwendung wiederherzustellen.
Es wird klar sein, dass die Anweisungen zur Speicherung und/oder Wiederherstellung von Verzweigungsvorhersagelogik-Zustandsdaten innerhalb von Kontextumschaltroutinen realisiert sein können, die ausgeführt werden, um andere Zustandsdaten zu speichern oder wiederherzustellen, die zu einem bestimmten Kontext gehören, der gegenwärtig durch einen Hardware-Thread ausgeführt wird. Darüber hinaus wird klar sein, dass der Hypervisor, ausgewählte Gastbetriebssysteme und/oder ausgewählte Benutzeranweisungen keinen Bedarf zur Speicherung oder Wiederherstellung von Verzweigungsvorhersagelogik-Zustandsdaten haben, sodass diese ausgewählten Einheiten bei Kontextumschaltungen die Ausführung beliebiger Anweisungen übergehen können, um Verzweigungsvorhersagelogik-Daten für derartige Einheiten entweder zu speichern oder wiederherzustellen.
Die 13 bis 14 veranschaulichen ausführlicher die Operationen, die in Verbindung mit dem Speichern und Wiederherstellen der Verzweigungsvorhersagelogik-Zustandstabelle, z. B. von Einträgen der Verzweigungsverlaufstabelle, auftreten. 13 veranschaulicht zum Beispiel eine Verzweigungsverlaufstabellen-Speicherungsroutine 390, die durch ein Programm, z. B. einen Hypervisor, ein Gastbetriebssystem und/oder eine Benutzeranwendung, ausgeführt wird, um Verzweigungsvorhersagelogik-Zustandsdaten zu speichern. Zum Beispiel ermittelt der Block 392 zunächst, ob das Programm den Verzweigungsvorhersagelogik-Zustand speichern darf, z. B. durch Prüfen eines zugehörigen Sperrfeldes für das Programm. In einigen Fällen, z. B. bei einem Hypervisor, kann das Programm stets berechtigt sein, einen Verzweigungsvorhersagelogik-Zustand zu speichern, sodass der Block 392 ausgelassen werden kann. Wenn diese Erlaubnis durch den Block 392 nicht erteilt wird, wird die Routine 390 abgebrochen. Anderenfalls übergibt der Block 392 die Steuerung an den Block 394, um den Verzweigungsvorhersagelogik-Zustand zu speichern, und die Routine 390 ist abgeschlossen.
In ähnlicher Weise veranschaulicht 14 eine Verzweigungsverlaufstabellen-Wiederherstellungsroutine 400, die durch ein Programm, z. B. einen Hypervisor, ein Gastbetriebssystem und/oder eine Benutzeranwendung, ausgeführt wird, um Verzweigungsvorhersagelogik-Zustandsdaten wiederherzustellen. Zum Beispiel ermittelt der Block 402 zunächst, ob das Programm den Verzweigungsvorhersagelogik-Zustand wiederherstellen darf, z. B. durch Prüfen eines zugehörigen Sperrfeldes für das Programm. In einigen Fällen, z. B. bei einem Hypervisor, kann das Programm stets berechtigt sein, einen Verzweigungsvorhersagelogik-Zustand wiederherzustellen, sodass der Block 402 ausgelassen werden kann. Wenn diese Erlaubnis durch den Block 402 nicht erteilt wird, wird die Routine 400 abgebrochen. Anderenfalls übergibt der Block 402 die Steuerung an den Block 404, um den Verzweigungsvorhersagelogik-Zustand zurückzusetzen, z. B. durch Löschen aller alten Einträge der Verzweigungsverlaufstabelle, und anschließend an den Block 406, um den Verzweigungsvorhersagelogik-Zustand wiederherzustellen. Anschließend ist die Routine 400 abgeschlossen.
Daher ermöglichen Ausführungsformen gemäß der Erfindung eine feiner abgestimmte Steuerung einer Verzweigungsvorhersagelogik durch eine selektive Aktivierung/Deaktivierung und/oder durch ein selektives Speichern und Wiederherstellen von Verzweigungsvorhersagelogik-Zustandsdaten. Es wird angenommen, dass die Bereitstellung einer feiner abgestimmten Steuerung bei vielen Ausführungsformen ermöglicht, die Verzweigungsvorhersagelogik in Bezug auf unterschiedliche Arten von Programmen und Betriebslasten besser zu optimieren und in einigen Fällen die Verwendung einer kleineren und/oder weniger komplexen Verzweigungsvorhersagelogik ermöglichen kann, wodurch Kosten gespart und die Größe des Platzes verringert werden, den die Verzweigungsvorhersagelogik auf einem Prozessorchip benötigt.
An den offenbarten Ausführungsformen können verschiedene Abänderungen vorgenommen werden, ohne vom Schutzbereich der Erfindung abzuweichen, die in den hiernach beigefügten Ansprüchen definiert ist.

Claims

Verfahren zum Steuern einer Verzweigungsvorhersagelogik in einem Datenverarbeitungssystem, wobei das Verfahren aufweist: selektives Setzen eines Aktivierungszustands einer Verzweigungsvorhersagelogik in mindestens einem Verarbeitungskern als Reaktion darauf, dass ein Hypervisor auf dem Verarbeitungskern ausgeführt wird; selektives Außerkraftsetzen des Aktivierungszustands der Verzweigungsvorhersagelogik, der durch einen Hypervisor als Reaktion darauf gesetzt wurde, dass ein Gastbetriebssystem auf dem Verarbeitungskern ausgeführt und durch den Hypervisor gehostet wird, sodass das Gastbetriebssystem den Aktivierungszustand der Verzweigungsvorhersagelogik steuert, während der Verarbeitungskern das Gastbetriebssystem ausführt; und selektives Aktivieren der Verzweigungsvorhersagelogik auf Grundlage des Aktivierungszustands der Verzweigungsvorhersagelogik.
Verfahren nach Anspruch 1, wobei die Verzweigungsvorhersagelogik so gestaltet ist, dass Verzweigungsvorhersagedaten in einer Verzweigungsvorhersagelogik nur dann zwischengespeichert werden, wenn die Verzweigungsvorhersagelogik aktiviert ist, wobei das selektive Aktivieren der Verzweigungsvorhersagelogik das Deaktivieren der Verzweigungsvorhersagelogik aufweist, sodass die Verzweigungsvorhersagetabelle keine Verzweigungsvorhersagedaten zwischenspeichert, während die Verzweigungsvorhersagelogik deaktiviert ist.
Verfahren nach Anspruch 1, wobei das selektive Außerkraftsetzen des Aktivierungszustands ein Setzen des Aktivierungszustands für die Verzweigungsvorhersagelogik auf einen zum Gastbetriebssystem gehörenden Aktivierungszustand aufweist, sodass die Verzweigungsvorhersagelogik auf Grundlage des zum Gastbetriebssystem gehörenden Aktivierungszustands aktiviert wird, während der Verarbeitungskern das Gastbetriebssystem ausführt.
Verfahren nach Anspruch 1, wobei das Gastbetriebssystem ein erstes Gastbetriebssystem ist, wobei das Verfahren ferner ein Setzen des Aktivierungszustands für die Verzweigungsvorhersagelogik auf den durch den Hypervisor gesetzten Aktivierungszustand aufweist, während der Verarbeitungskern das zweite Gastbetriebssystem ausführt.
Verfahren nach Anspruch 3, ferner aufweisend ein selektives Aktivieren der Verzweigungsvorhersagelogik auf Grundlage des zum Gastbetriebssystem gehörenden Aktivierungszustandes, während der Verarbeitungskern mindestens einen Benutzerprozess ausführt, der durch das Gastbetriebssystem gehostet wird.
Verfahren nach Anspruch 5, wobei der Benutzerprozess ein erster Benutzerprozess ist, wobei das Verfahren ferner ein selektives Außerkraftsetzen des durch das Gastbetriebssystem gesetzten Aktivierungszustands als Reaktion auf einen zweiten, durch das Gastbetriebssystem gehosteten Benutzerprozess aufweist, sodass der zweite Benutzerprozess den Aktivierungszustand der Verzweigungsvorhersagelogik steuert, während der Verarbeitungskern den zweiten Benutzerprozess ausführt.
Verfahren nach Anspruch 6, ferner aufweisend beim Gastbetriebssystem das selektive Deaktivieren der Außerkraftsetzung des Aktivierungszustandes der Verzweigungsvorhersagelogik durch den zweiten Benutzerprozess.
Verfahren nach Anspruch 7, wobei das Gastbetriebssystem so gestaltet ist, dass die Außerkraftsetzung des Aktivierungszustandes der Verzweigungsvorhersagelogik einer Mehrzahl von Benutzerprozessen, die durch das Gastbetriebssystem gehostet werden, auf Grundlage von Prozesskennungen selektiv deaktiviert wird, die zu der Mehrzahl von Benutzerprozessen gehören.
Verfahren nach Anspruch 1, ferner aufweisend beim Hypervisor ein selektives Deaktivieren der Außerkraftsetzung des Aktivierungszustandes der Verzweigungsvorhersagelogik durch das Gastbetriebssystem.
Verfahren nach Anspruch 1, wobei das auf dem Aktivierungszustand der Verzweigungsvorhersageiogik beruhende selektive Deaktivieren der Verzweigungsvorhersagelogik ein Zugreifen auf ein Steuerregister aufweist, um den Aktivierungszustand der Verzweigungsvorhersagelogik zu ermitteln.
Verfahren nach Anspruch 10, wobei das Setzen des Aktivierungszustandes das Schreiben in das Steuerregister aufweist.
Verfahren nach Anspruch 11, wobei der Verarbeitungskern eine Mehrzahl von Hardware-Threads aufweist, wobei das Steuerregister einen Thread-spezifischen Aktivierungszustand für jeden Hardware-Thread speichert, und wobei die Verzweigungsvorhersagelogik auf Grundlage des Steuerregisters für jeden Hardware-Thread selektiv aktiviert wird.
Schaltungsanordnung, aufweisend: einen Verarbeitungskern; und in dem Verarbeitungskern angeordnete Verzweigungsvorhersagelogik; wobei der Verarbeitungskern so gestaltet ist, dass die Verzweigungsvorhersagelogik auf Grundlage eines Aktivierungszustandes der Verzweigungsvorhersagelogik selektiv aktiviert wird, wobei der Verarbeitungskern auf einen durch diesen ausgeführten Hypervisor reagiert, um den Aktivierungszustand der Verzweigungsvorhersagelogik selektiv zu setzen, und wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand der Verzweigungsvorhersagelogik selektiv außer Kraft gesetzt wird, der durch den Hypervisor als Reaktion darauf gesetzt wurde, dass ein Gastbetriebssystem auf dem Verarbeitungskern ausgeführt und durch den Hypervisor gehostet wird, sodass das Gastbetriebssystem den Aktivierungszustand der Verzweigungsvorhersagelogik steuert, während der Verarbeitungskern das Gastbetriebssystem ausführt.
Schaltungsanordnung nach Anspruch 13, wobei die Verzweigungsvorhersagelogik so gestaltet ist, dass Verzweigungsvorhersagedaten in einer Verzweigungsvorhersagelogik nur dann zwischengespeichert werden, wenn die Verzweigungsvorhersagelogik aktiviert ist, und wobei der Verarbeitungskern so gestaltet ist, dass die Verzweigungsvorhersagelogik selektiv aktiviert wird, indem die Verzweigungsvorhersagelogik deaktiviert wird, sodass die Verzweigungsvorhersagetabelle keine Verzweigungsvorhersagedaten zwischenspeichert, während die Verzweigungsvorhersagelogik deaktiviert ist.
Schaltungsanordnung nach Anspruch 13, wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand selektiv außer Kraft gesetzt wird, indem der Aktivierungszustand für die Verzweigungsvorhersagelogik auf einen zum Gastbetriebssystem gehörenden Aktivierungszustand gesetzt wird, sodass die Verzweigungsvorhersagelogik auf Grundlage des zum Gastbetriebssystem gehörenden Aktivierungszustandes aktiviert wird, während der Verarbeitungskern das Gastbetriebssystem ausführt.
Schaltungsanordnung nach Anspruch 13, wobei das Gastbetriebssystem ein erstes Gastbetriebssystem ist, und wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand für die Verzweigungsvorhersagelogik auf den durch den Hypervisor gesetzten Aktivierungszustand gesetzt wird, während der Verarbeitungskern das zweite Gastbetriebssystem ausführt.
Schaltungsanordnung nach Anspruch 15, wobei der Verarbeitungskern so gestaltet ist, dass die Verzweigungsvorhersagelogik auf Grundlage des zum Gastbetriebssystem gehörenden Aktivierungszustandes selektiv aktiviert wird, während der Verarbeitungskern mindestens einen Benutzerprozess ausführt, der durch das Gastbetriebssystem gehostet wird.
Schaltungsanordnung nach Anspruch 17, wobei der Benutzerprozess ein erster Benutzerprozess ist, und wobei der Verarbeitungskern so gestaltet ist, dass der durch das Gastbetriebssystem gesetzte Aktivierungszustand als Reaktion auf einen zweiten, durch das Gastbetriebssystem gehosteten Benutzerprozess selektiv außer Kraft gesetzt wird, sodass der zweite Benutzerprozess den Aktivierungszustand der Verzweigungsvorhersagelogik steuert, während der Verarbeitungskern den zweiten Benutzerprozess ausführt.
Schaltungsanordnung nach Anspruch 18, wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand der Verzweigungsvorhersagelogik als Reaktion auf das Gastbetriebssystem durch den zweiten Benutzerprozess selektiv außer Kraft gesetzt wird.
Schaltungsanordnung nach Anspruch 19, wobei das Gastbetriebssystem so gestaltet ist, dass die Außerkraftsetzung des Aktivierungszustands der Verzweigungsvorhersagelogik einer Mehrzahl von Benutzerprozessen, die durch das Gastbetriebssystem gehostet werden, auf Grundlage von Prozesskennungen selektiv deaktiviert wird, die zu der Mehrzahl von Benutzerprozessen gehören.
Schaltungsanordnung nach Anspruch 13, wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand der Verzweigungsvorhersagelogik als Reaktion auf den Hypervisor durch das Gastbetriebssystem selektiv außer Kraft gesetzt wird.
Schaltungsanordnung nach Anspruch 13, ferner aufweisend ein Steuerregister, das so gestaltet ist, dass der Aktivierungszustand der Verzweigungsvorhersagelogik gespeichert wird, wobei der Verarbeitungskern so gestaltet ist, dass die Verzweigungsvorhersagelogik selektiv aktiviert wird, indem auf das Steuerregister zugegriffen wird, um den Aktivierungszustand der Verzweigungsvorhersagelogik zu ermitteln, und wobei der Verarbeitungskern so gestaltet ist, dass der Aktivierungszustand durch Schreiben in das Steuerregister gesetzt wird.
Schaltungsanordnung nach Anspruch 22, wobei der Verarbeitungskern eine Mehrzahl von Hardware-Threads aufweist, wobei das Steuerregister einen Threadspezifischen Aktivierungszustand für jeden Hardware-Thread speichert, und wobei die Verzweigungsvorhersagelogik auf Grundlage des Steuerregisters für jeden Hardware-Thread selektiv aktiviert wird.
Datenverarbeitungssystem, aufweisend die Schaltungsanordnung nach Anspruch 13.
Programmprodukt, aufweisend: ein computerlesbares Medium; und auf dem computerlesbaren Medium gespeicherter Programmcode, wobei der Programmcode gestaltet ist, um zwecks Durchführung des Verfahrens nach einem beliebigen der Ansprüche 1 bis 12 durch einen Verarbeitungskern ausgeführt werden.