DE102013200503A1 - Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik - Google Patents

Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik Download PDF

Info

Publication number
DE102013200503A1
DE102013200503A1 DE102013200503A DE102013200503A DE102013200503A1 DE 102013200503 A1 DE102013200503 A1 DE 102013200503A1 DE 102013200503 A DE102013200503 A DE 102013200503A DE 102013200503 A DE102013200503 A DE 102013200503A DE 102013200503 A1 DE102013200503 A1 DE 102013200503A1
Authority
DE
Germany
Prior art keywords
branch prediction
hypervisor
state
prediction logic
logic
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102013200503A
Other languages
English (en)
Inventor
Adam J. Muff
Paul E. Schardt
Robert A. Shearer
Matthew R. Tubbs
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE102013200503A1 publication Critical patent/DE102013200503A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G06F9/3848—Speculative instruction execution using hybrid branch prediction, e.g. selection between prediction techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30181—Instruction operation extension or modification
    • G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3802—Instruction prefetching
    • G06F9/3804—Instruction prefetching for branches, e.g. hedging, branch folding
    • G06F9/3806—Instruction prefetching for branches, e.g. hedging, branch folding using address prediction, e.g. return stack, branch history buffer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3842—Speculative instruction execution
    • G06F9/3844—Speculative instruction execution using dynamic branch prediction, e.g. using branch history tables
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
    • G06F9/3851—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution from multiple instruction streams, e.g. multistreaming
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
    • G06F9/3863—Recovery, e.g. branch miss-prediction, exception handling using multiple copies of the architectural state, e.g. shadow registers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Microcomputers (AREA)
  • Logic Circuits (AREA)

Abstract

Ein Hypervisor und ein oder mehrere Programme, z. B. Guest-Betriebssysteme und/oder Benutzerprozessoren oder von dem Hypervisor gehostete Anwendungen sind so konfiguriert, dass sie selektiv über separate Hypervisor-Modus- und Guest-Modus- und/oder Benutzermodus-Anweisungen die Zustände der Sprungvorhersage-Logik speichern und wiederherstellen. Dadurch können unterschiedliche Sprungvorhersage-Strategien für unterschiedliche gehostete Betriebssysteme und Benutzeranwendungen verwendet werden, wodurch ein differenzierteres Optimieren der Sprungvorhersage-Logik gewährleistet werden kann.

Description

  • Gebiet der Erfindung
  • Die Erfindung betrifft im Allgemeinen Datenverarbeitung und insbesondere Prozessorarchitekturen sowie Sprungvorhersage-Logik, die darin verwendet wird.
  • Hintergrund der Erfindung
  • Da die Halbleitertechnologie in der Praxis weiterhin zunehmend an ihre Grenzen im Hinblick auf Erhöhung der Taktfrequenz stößt, lenken die Entwickler ihr Augenmerk immer mehr auf Parallelismus in Prozessorarchitekturen, um Leistungsverbesserungen zu erzielen. Auf der Chipebene werden oftmals mehrere Verarbeitungskerne auf demselben Chip angeordnet, die zum Großteil auf dieselbe Weise wie separate Prozessoren oder bis zu einem gewissen Grad wie vollständig voneinander getrennte Computer arbeiten. Darüber hinaus wird sogar innerhalb der Kerne Parallelismus durch den Einsatz mehrerer Ausführungseinheiten umgesetzt, die auf die Bearbeitung bestimmter Typen von Operationen spezialisiert sind. In vielen Fällen wird des Weiteren Pipelining angewendet, so dass bestimmte Operationen, die zu ihrer Ausführung mehrere Taktzyklen benötigen, in Verarbeitungsstufen unterteilt werden, wodurch andere Operationen vor Abschluss von vorhergehenden Operationen gestartet werden können. Es wird auch Multithreading angewendet, so dass mehrere Anweisungsströme parallel verarbeitet werden können, wodurch in jedem beliebigen Taktzyklus eine höhere Gesamtleistung erzielt werden kann.
  • Ein weiterer Bereich, in dem Fortschritte bei der Entwicklung von Prozessoren erzielt wurden, ist der Bereich der Sprungvorhersage, mit der versucht wird, vor der Ausführung einer konditionellen Sprunganweisung vorherzusagen, ob durch diese Sprunganweisung ein anderer Code-Thread genommen wird oder ausgehend vom Ergebnis einiger Vergleiche, die im Zusammenhang mit der Sprunganweisung durchgeführt wurde, weiterhin auf demselben Code-Thread verbleibt. Die Sprungvorhersage kann beispielsweise zum Vorabruf (prefetch) von Anweisungen aus einem Cachespeicher oder einem Speicher einer niedrigeren Ebene verwendet werden, um die Latenzzeit beim Laden und Ausführen dieser Anweisungen zu verringern, wenn die Sprunganweisung schließlich ausgeführt wird. Darüber hinaus kann in Architekturen mit stark ausgeprägtem Pipelining die Sprungvorhersage verwendet werden, um die Ausführung von Anweisungen von einem vorhergesagten Sprung (predicted branch) zu initiieren, bevor eine Sprunganweisung ausgeführt wird, so dass die Ergebnisse dieser Anweisungen so bald wie möglich nach dem Abschließen der Sprunganweisung übergeben werden können.
  • Wird ein Sprung richtig vorhergesagt, können erhebliche Leistungsgewinne unter Berücksichtigung der Tatsache erzielt werden, dass die Latenzzeit zwischen dem Ausführen der Sprunganweisung und den Anweisungen gering ist, für die die Ausführung nach der Sprunganweisung vorhergesagt wurde. Wenn im Gegensatz dazu ein Sprung nicht richtig vorhergesagt wird, muss oftmals die Pipeline einer Ausführung geleert (flushed) und der Zustand des Prozessors im Wesentlichen zurückgesetzt werden, so dass die Anweisungen von dem richtigen Thread ausgeführt werden können.
  • Infolgedessen wurden auf dem Gebiet der Technik große Anstrengungen unternommen, um die Genauigkeit der Sprungvorhersagen zu verbessern und dementsprechend die Häufigkeit von falschen Sprungvorhersagen durch die Sprungvorhersage-Logik zu minimieren. Viele Implementierungen für Sprungvorhersagen greifen beispielsweise auf Historie-Daten zurück und beruhen auf der Annahme dass, wenn ein Sprung das letzte Mal beim Ausführen genommen wurde als eine Sprunganweisung durchgeführt wurde, eine Wahrscheinlichkeit besteht, dass der Sprung auch das nächste Mal durchgeführt wird, wenn die Sprunganweisung ausgeführt wird. In vielen Implementierungen wird beispielsweise eine Sprung-Historie-Tabelle (Branch History Table, BHT) zum Speichern von Einträgen verwendet, die zu bestimmten Sprunganweisungen gehören, so dass, wenn auf diese Sprunganweisungen getroffen wird, eine Vorhersage auf der Grundlage von zu solchen Sprunganweisungen gehörenden gespeicherten Daten getroffen werden kann.
  • Das Implementieren einer Sprungvorhersage-Logik in einem Prozessor bringt jedoch eine Reihe von Problemen mit sich. So muss beispielsweise für ein Erhöhen der Genauigkeit der Sprungvorhersage-Logik oftmals komplexere Logik verwendet werden, wodurch möglicherweise die Sprungvorhersage verlangsamt und die Menge an Logikschaltung, die zum Implementieren der Logik erforderlich ist, erhöht wird. Mit einer auf Historie beruhenden Sprungvorhersage-Logik ist die Genauigkeit oftmals direkt proportional zu der Menge an der von der Logik gespeicherten Historie-Daten; dennoch erfordert die Vergrößerung der Speicherkapazität einer Sprung-Historie-Tabelle (BHT) zusätzliche Logikschaltungen. In vielen Anwendungen besteht der Wunsch nach Minimierung der Menge von zur Sprungvorhersage-Logik verwendeten Logikschaltungen in einem Prozessor, z. B. zum Verringern des Stromverbrauchs und/oder der Kosten oder zum Freimachen zusätzlichen Speicherplatzes für das Implementieren anderer Funktionen.
  • Darüber hinaus wurde herausgefunden, dass Sprungvorhersage-Algorithmen für bestimmte Programmcodetypen oftmals nicht gut funktionieren. Einige Programmcodes wie beispielsweise binäre Baumsuchvorgänge weisen praktisch zufällige Sprungcharakteristiken auf, und eine während der Ausführung einer Sprunganweisung getroffene Sprungentscheidung liefert möglicherweise keine Erkenntnisse darüber, welche Entscheidung das nächste Mal getroffen werden wird, wenn die Anweisung ausgeführt wird. Darüber hinaus kann in Multithread-Umgebungen, in denen mehrere Threads gleichzeitig in dem Verarbeitungskern ausgeführt werden, die begrenzte Größe einer Sprungvorhersage-Tabelle, die gemeinsam von mehreren Threads verwendet wird, dazu führen, dass Historie-Daten entfernt werden, wenn auf neue Sprunganweisungen getroffen wird, so dass sich die Historie-Daten für eine bestimmte Sprunganweisung möglicherweise zum Zeitpunkt, zu dem diese Sprunganweisung später ausgeführt wird, nicht mehr in der Sprungvorhersage-Tabelle befinden.
  • Es wurde sogar herausgefunden, dass in einigen Fällen die Sprungvorhersage die Leistung in der Tat verschlechtern kann, wenn der prozentuale Anteil an falschen Vorhersagen auf ein Maß ansteigt, bei dem die Nachteile (penalties) durch falsche Vorhersagen die Vorteile kürzerer Latenzzeiten überwiegen, die anderenfalls aufgetreten wären, wenn der Verarbeitungskern zum Ausführen der Sprunganweisungen warten würde, ehe er versucht, die Anweisungen in dem richtigen Code-Thread auszuführen.
  • Bei einigen herkömmlichen Prozessor-Ausgestaltungen wird eine Fähigkeit zum selektiven Deaktivieren der Sprungvorhersage-Logik bereitgestellt. Darüber hinaus wird bei einigen herkömmlichen Prozessor-Ausgestaltungen eine Fähigkeit zum Speichern und Wiederherstellen des Zustandes der Sprungvorhersage-Logik bereitgestellt. Eine auf Historiedaten beruhende Sprungvorhersage-Logik verbessert normalerweise im Verlauf der Zeit die Genauigkeit, wenn mehr Historie-Daten erfasst werden; greifen jedoch mehrere unabhängige Threads mit einer begrenzten Speicherkapazität auf die Sprungvorhersage-Logik zu, kann das Erfassen von Historie-Daten für einen Thread dazu führen, dass Historie-Daten für andere Threads entfernt werden. Durch Speichern und Wiederherstellen des Zustandes der Sprungvorhersage-Logik kann die Sprungvorhersage-Logik jedoch oftmals für unterschiedliche Codeabschnitte betriebsbereit gemacht („primed”) werden, so dass die in der Vergangenheit für jene Codeabschnitte erfassten Historie-Daten das nächste Mal, wenn diese Codeabschnitte ausgeführt werden, mit einer größeren Wahrscheinlichkeit in der Sprungvorhersage-Logik vorhanden sind.
  • Obgleich durch die Fähigkeit zum selektiven Deaktivieren der Sprungvorhersage-Logik und zum Speichern/Wiederherstellen des Zustandes der Sprungvorhersage-Logik einige der Unzulänglichkeiten der herkömmlichen Sprungvorhersage ausgeglichen werden können, sind herkömmliche Ausgestaltungen dennoch durch eine fehlende Flexibilität beim Umgang mit unterschiedlichen Situationen, insbesondere in komplexeren und Hochleistungs-Datenverarbeitungssystemen gekennzeichnet, in denen eine große Zahl unterschiedlicher Typen von Anwendungen mit zum Großteil unterschiedlichen Betriebseigenschaften in solchen Systemen ausgeführt werden können.
  • So setzen beispielsweise viele Hochleistungs-Datenverarbeitungssysteme Virtualisierung ein, so dass mehrere Betriebssysteme auf einer gemeinsamen Hardware-Plattform unter Verwaltung einer Supervisory-Level-Software, die oftmals als Hypervisor bezeichnet wird, gehostet werden können. Jedes Betriebssystem, das als Guest des Hypervisor läuft, kann wiederum eine oder mehrere Benutzeranwendungen hosten, die in separaten Prozessen in der Betriebssystemumgebung ausgeführt werden. In solch einem System kann eine Vielzahl verschiedener Anwendungen laufen, die unterschiedliche Algorithmen mit Charakteristiken ausführen, die sich hinsichtlich der Sprungvorhersage-Logik nicht gut verallgemeinern lassen, wodurch das Bereitstellen einer Sprungvorhersage-Strategie erschwert wird, die für alle Szenarien optimal funktioniert.
  • Demzufolge besteht auf dem Gebiet der Technik weiterhin ein großer Bedarf an einer Methode zum Steuern der Sprungvorhersage-Logik in einem Verarbeitungskern auf flexible und effiziente Weise.
  • Zusammenfassung der Erfindung
  • Mit der Erfindung werden diese sowie weitere Probleme des Standes der Technik durch Bereitstellen eines Virtualisierungs-Support behandelt, der es sowohl einem Hypervisor als auch einem oder mehreren Programmen, z. B. Guest-Betriebssystemen und/oder Benutzerprozessen oder -anwendungen, die von dem Hypervisor gehostet werden, gestattet, über separate Hypervisor-Modus- und Guest-Modus- und/oder Benutzermodus-Anweisungen selektiv den Zustand der Sprungvorhersage-Logik zu speichern und wiederherzustellen. Dadurch können unterschiedliche Sprungvorhersage-Strategien für unterschiedliche gehostete Betriebssysteme und Benutzeranwendungen eingesetzt werden, wodurch ein differenziertes Optimieren der Sprungvorhersage-Logik gewährleistet werden kann.
  • Gemäß einem Aspekt der Erfindung wird die Sprungvorhersage-Logik in einem Datenverarbeitungssystem gesteuert durch: Speichern eines ersten Zustandes einer Sprungvorhersage-Logik in dem Verarbeitungskern in Reaktion auf eine erste, Hypervisor-Modus-Anweisung, die von dem Verarbeitungskern für einen in dem Datenverarbeitungssystem vorhandenen Hypervisor ausgeführt wird, Wiederherstellen des ersten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine zweite, Hypervisor-Modus-Anweisung, die von dem Verarbeitungskern für den Hypervisor ausgeführt wird, Speichern eines zweiten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine dritte Anweisung, die von dem Verarbeitungskern für ein von dem Hypervisor gehostetes Programm ausgeführt wird und Wiederherstellen des zweiten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine vierte Anweisung, die von dem Verarbeitungskern ausgeführt und von dem Hypervisor gehostet wird.
  • Diese sowie weitere die Erfindung charakterisierende Vorteile und Leistungsmerkmale werden in den hieran angehängten Ansprüchen dargestellt, welche einen weiteren Bestandteil dieser Beschreibung bilden. Für ein besseres Verständnis der Erfindung und der durch ihren Einsatz erreichten Vorteile und Aufgaben sollte Bezug auf die Zeichnungen und den Beschreibungstext genommen werden, in dem die beispielhaften Ausführungsformen der Erfindung beschrieben sind.
  • Kurze Beschreibung der Zeichnungen
  • 1 ist ein Blockschaltbild einer beispielhaften automatisierten Datenverarbeitungsmaschine, aufweisend einen beispielhaften Computer, der bei der Datenverarbeitung gemäß Ausführungsformen der vorliegenden Erfindung nützlich ist.
  • 2 ist ein Blockschaltbild eines beispielhaften NoC (Network an Chip), das in dem Computer von 1 dargestellt ist.
  • 3 ist ein Blockschaltbild, das eine beispielhafte Implementierung eines Knotens von dem NoC von 2 detaillierter darstellt.
  • 4 ist ein Funktionsschaubild, das eine beispielhafte Implementierung eines IP-Blockes von dem NoC von 2 darstellt.
  • 5 ist ein Blockschaubild eines Datenverarbeitungssystems, in dem der Virtualisierungs-Support für differenzierte Steuerung einer Sprungvorhersage-Logik gemäß der Erfindung implementiert werden kann.
  • 6 ist ein Blockschaubild eines beispielhaften Aktivierungsmodus-Steuerregisters in den Spezial-Registern, auf die in 5 verwiesen wird.
  • 7 ist ein Blockschaubild einer beispielhaften prozessspezifischen Aktivierungsmodus-Datenstruktur, die in dem Datenverarbeitungssystem von 5 verwendet werden kann.
  • 8 ist ein Blockschaubild einer beispielhaften threadspezifischen Aktivierungsmodus-Datenstruktur, die in dem Datenverarbeitungssystem von 5 verwendet werden kann.
  • 9 ist ein Ablaufplan, der eine beispielhafte Sequenz von Operationen veranschaulicht, die von dem Datenverarbeitungssystem von 5 ausgeführt werden, wenn Kontextumschaltungen zwischen Hypervisor-, Guest-Betriebssystem- und Benutzermodus-Programmcode mit einer selektiv ausgewählten Sprungvorhersage-Logik durchgeführt werden.
  • 10 ist ein Blockschaubild eines beispielhaften Speichermodus-Steuerregisters in den Spezialregistern, auf die in 5 verwiesen wird.
  • 11 ist ein Blockschaubild einer beispielhaften Zustands-Lade/Speichereinheit, die in dem Datenverarbeitungssystem von 5 zum Speichern und Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik verwendet werden kann.
  • 12 ist ein Ablaufplan, der eine beispielhafte Sequenz von Operationen veranschaulicht, die von dem Datenverarbeitungssystem von 5 ausgeführt werden, wenn Kontextumschaltungen zwischen Hypervisor-, Guest-Betriebssystem- und Benutzermodus-Programmcode mit Speichern und Wiederherstellen eines Zustandes einer Sprungvorhersage-Logik durchgeführt werden.
  • 13 ist ein Ablaufplan, der eine beispielhafte Sequenz von Operationen veranschaulicht, die zum Speichern eines Zustandes einer Sprungvorhersage-Logik gemäß Beschreibung in 12 durchgeführt werden.
  • 14 ist ein Ablaufplan, der eine beispielhafte Sequenz von Operationen veranschaulicht, die zum Wiederherstellen eines Zustandes einer Sprungvorhersage-Logik gemäß Beschreibung in 12 durchgeführt werden.
  • Ausführliche Beschreibung
  • Ausführungsformen gemäß der Erfindung verwenden eine differenzierte Steuerung der Sprungvorhersage-Logik über mehrere Ebenen eines virtualisierten Datenverarbeitungssystems zum Optimieren der Sprungvorhersage für unterschiedliche Anwendungen und Verarbeitungsprozesse (workloads), wodurch die allgemeine Leistung des Datenverarbeitungssystems beim Bearbeiten unterschiedlicher Typen von Verarbeitungsprozessen verbessert wird.
  • In einigen Ausführungsformen sind beispielsweise ein Hypervisor und ein oder mehrere in einem Datenverarbeitungssystem vorhandene und von dem Hypervisor beherbergte Guest-Betriebssysteme so konfiguriert, dass sie über separate Hypervisor-Modus- und Guest-Modus-Anweisungen selektiv eine Sprungvorhersage-Logik aktivieren oder deaktivieren. Auf ähnliche Weise sind in einigen Ausführungsformen ein Hypervisor und ein oder mehrere Programme, z. B. Guest-Betriebssysteme und/oder Benutzerprozesse oder Anwendungen, die von dem Hypervisor gehostet werden, so konfiguriert, dass sie über separate Hypervisor-Modus- und Guest-Modus- und/oder Benutzermodus-Anweisungen selektiv den Zustand der Sprungvorhersage-Logik speichern und wiederherstellen. Durch Steuern der Sprungvorhersage-Logik auf die eine oder andere Weise können unterschiedliche Sprungvorhersage-Strategien für unterschiedliche Betriebssysteme und davon gehostete Benutzeranwendungen eingesetzt werden, wodurch ein differenzierteres Optimieren der Sprungvorhersage-Logik gewährleistet wird, die in den Verarbeitungskernen eines Datenverarbeitungssystems verwendet wird.
  • In dieser Hinsicht kann ein Hypervisor jede beliebige Anzahl von Supervisory-Modus-Programmen aufweisen, die zum Virtualisieren oder Rosten eines oder mehrerer Guest-Betriebssysteme in der Lage sind und auf verschiedenen Ebenen von Software, z. B. Firmware, einem Kernel usw. implementiert werden können. Ein Hypervisor virtualisiert normalerweise die zugrundeliegende Hardware in einem Datenverarbeitungssystem und präsentiert den dadurch gehosteten Betriebssystemen eine Schnittstelle, so dass jedes Betriebssystem so funktioniert, als ob es sich dabei um das einzige in der physischen Hardware des Datenverarbeitungssystems vorhandene Betriebssystem handelt. Bei einem Guest-Betriebssystem handelt es sich normalerweise um ein Betriebssystem, eine logische Partition, virtuelle Maschine oder Kombination davon, das von einem zugrundeliegenden Hypervisor gehostet wird und die Ausführung von einer oder mehreren Benutzeranwendungen unterstützt, die in einem oder mehreren gleichzeitigen Prozessen in der Betriebssystemumgebung laufen. Ähnlich einem Hypervisor virtualisiert ein Guest-Betriebssystem im Wesentlichen Hardware-Ressourcen und ordnet dem Guest-Betriebssystem zugewiesene Hardware-Ressourcen einer oder mehreren Anwendungen und Prozessen zu. Bei einer Benutzeranwendung kann es sich wiederum um ein beliebiges Programm handeln, das innerhalb eines Prozesses in einem Guest-Betriebssystem laufen kann.
  • Es ist ersichtlich, dass die in vielen Datenverarbeitungsumgebungen verwendeten Prozessorarchitekturen unterschiedliche Softwareebenen zur gleichzeitigen Ausführung darauf und zwar mit unterschiedlichen Prioritätsstufen und Zugriffsrechten unterstützen. In einer virtualisierten Umgebung läuft ein Hypervisor-Programmcode für gewöhnlich in einem Supervisor- oder Hypervisor-Modus, wohingegen Benutzeranwendungen für gewöhnlich in einem Benutzermodus mit niedrigerer Priorität laufen. Guest-Betriebssysteme können ebenfalls in einem Supervisor-Modus laufen oder sie können in einem separaten Guest-Modus, das heißt zwischen dem Hypervisor- und dem Benutzermodus angeordnet, laufen.
  • Es ist ersichtlich, dass Sprungvorhersage-Logik eine beliebige Anzahl von Logikstrukturen mit dem vorrangigen Ziel des Minimierens der mit den Sprunganweisungen verbundenen Latenz aufweisen kann. Viele Sprungvorhersage-Logikstrukturen verwenden Sprung-Historie-Tabellen (Branch History Tables, BHTs), und viele können eine andere Logik wie beispielsweise eine g-share-Logik, Linkstapel-Logik, Sprungzielpuffer (Branch-Target-Buffers, BTB) usw. aufweisen.
  • Wie dies vorstehend beschrieben wurde, wird in einigen Ausführungsformen der Erfindung die Sprungvorhersage-Logik von einem oder von allen der folgenden selektiv aktiviert und deaktiviert: ein Hypervisor, Guest-Betriebssysteme, Benutzeranwendungen und -programme. In dieser Hinsicht kann davon ausgegangen werden, dass Aktivieren oder Deaktivieren der Sprungvorhersage-Logik Aktivieren oder Deaktivieren aller oder lediglich einer Teilmenge von in einer bestimmten Sprungvorhersage-Logikstruktur implementierten Komponenten aufweist. Darüber hinaus kann in einigen Ausführungsformen durch Deaktivieren der Sprungvorhersage-Logik ein Zurücksetzen der Sprungvorhersage-Logik z. B. zum Löschen von Einträgen aus einer Sprungvorhersage-Tabelle veranlasst werden. In anderen Ausführungsformen kann Deaktivieren der Sprungvorhersage-Logik jedoch analog zum „vorrübergehenden Anhalten” (pausing) der Logik erfolgen, so dass z. B. keine Vorhersagen getroffen und keine Historie-Daten erfasst werden, aber die bereits erfassten Historie-Daten und weitere Charakteristiken des aktuellen Zustandes der Sprungvorhersage-Logik so lange verwaltet werden, bis die Logik erneut aktiviert wird, so dass kein Zustand oder keine Historie-Daten verloren gehen.
  • Wie dies ebenfalls vorstehend beschrieben wurde, kann in einigen Ausführungsformen der Erfindung der Zustand der Sprungvorhersage-Logik selektiv im Auftrag eines Hypervisor, Guest-Betriebssystems und/oder einer Benutzeranwendung oder eines Benutzerprogramms gespeichert und wiederhergestellt werden. Der Zustand, der gespeichert oder wiederhergestellt werden kann, kann beliebige oder alle der in der Sprungvorhersage-Logik verwalteten Daten umfassen, die den Gesamtzustand der Logik charakterisieren, unter anderem beispielsweise Sprung-Tabelleneinträge, Sprungzielpuffer-Daten, Linkstapet-Einträge, g-share-Daten usw.
  • Den Fachleuten sind weitere Abwandlungen und Modifizierungen ersichtlich. Dementsprechend ist die Erfindung nicht auf die speziellen hierin beschriebenen Implementierungen beschränkt.
  • Hardware- und Softwareumgebung
  • In Bezug auf die Zeichnungen, in denen in den mehreren Ansichten gleiche Zahlen gleiche Teile bezeichnen, veranschaulicht 1 eine beispielhafte automatisierte Datenverarbeitungsmaschine mit einem beispielhaften Computer 10, der bei der Datenverarbeitung gemäß Ausführungsformen der vorliegenden Erfindung nützlich ist. Der Computer 10 von 1 weist wenigstens einen Computerprozessor 12 oder ,CPU' sowie einen Arbeitsspeicher 114 (,RAM') auf, der über einen Hochgeschwindigkeits-Speicherbus 16 und einen Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist.
  • In dem RAM 14 sind ein Anwendungsprogramm 20, ein Modul von Computerprogrammanweisungen auf Benutzerebene zum Ausführen bestimmter Datenverarbeitungsaufgaben wie beispielsweise Word-Verarbeitung, Arbeitsblätter, Datenbankoperationen, Videospiele, Aktienmarktsimulationen, Atomquantumprozess-Simulationen oder andere Benutzerebenen-Anwendungen gespeichert. In dem RAM 14 ist des Weiteren ein Betriebssystem 22 gespeichert. Zu Betriebssystemen, die im Zusammenhang mit Ausführungsformen der Erfindung nützlich sind, gehören UNIXTM, LinuxTM, Microsoft Windows XPTM, AIXTM, i5/OSTM von IBM und weitere, wie den Fachleuten ersichtlich ist. Im dem Beispiel von 1 sind das Betriebssystem 22 und die Anwendung 20 in dem RAM 14 dargestellt, es sind normalerweise jedoch viele Komponenten solcher Software auch in nichtflüchtigen Speichern z. B. auf einem Plattenlaufwerk 24 gespeichert.
  • Wie im Folgenden ersichtlich wird, können Ausführungsformen gemäß der Erfindung in einem als integrierte Schaltungseinheiten oder Chips ausgeführten NoC („Network an Chip”) implementiert sein, und in dieser Form wird der Computer 10 mit zwei beispielhaften NoCs veranschaulicht: einem Videoadapter 26 und einem Coprozessor 28. Der NOC-Videoadapter 26, der alternativ auch als Grafikadapter bezeichnet werden kann, ist ein Beispiel eines E/A-Adapters, der speziell für eine Grafikausgabe zu einer Anzeigeeinheit 30 wie beispielsweise einem Anzeigebildschirm oder einen Computermonitor eingerichtet ist. Der NoC-Videoadapter 26 ist über einen Hochgeschwindigkeits-Videobus 32, einen Busadapter 18 und einen Front-Side-Bus 34, bei dem es sich ebenfalls um einen Hochgeschwindigkeitsbus handelt, mit dem Prozessor 12 verbunden. Der NOC-Coprozessor von 1 kann beispielsweise zum Beschleunigen bestimmter Datenverarbeitungsaufgaben auf Anweisung des Haupt-Prozessors optimiert werden.
  • Der beispielhafte NoC-Videoadapter 26 und der NOC-Coprozessor 28 von 1 weisen jeweils ein NoC auf, aufweisend Integrated-Prozessor-(,IP')Blöcke, Router, Speicherkommunikations-Controller und Netzwerkschnittstellen-Controller, deren Einzelheiten nachstehend im Zusammenhang mit den 2 bis 3 ausführlicher beschrieben werden. Der NoC-Videoadapter und der NoC-Coprozessor sind jeweils für Programme optimiert, die Parallelverarbeitung anwenden und die darüber hinaus schnellen wahlfreien Zugriff auf einen gemeinsam genutzten Speicher erfordern. Den Fachleuten ist zudem auch mit dem Vorteil der vorliegenden Offenbarung ersichtlich, dass die Erfindung in Einheiten und Einheitenarchitekturen implementiert werden kann, bei denen es sich nicht um NoC-Einheiten und Einheitenarchitekturen handelt. Dementsprechend ist die Erfindung nicht auf die Implementierung mit einer NoC-Einheit beschränkt.
  • Der Computer 10 von 1 weist einen Plattenlaufwerk-Adapter 38 auf, der über einen Erweiterungsbus 40 und einen Busadapter 18 mit dem Prozessor 12 und anderen Komponenten des Computers 10 verbunden ist. Der Plattenlaufwerk-Adapter 38 verbindet einen nichtflüchtigen Datenspeicher mit dem Computer 10 in Form eines Plattenlaufwerkes 24 und kann beispielsweise unter Verwendung von Integrated Drive Electronics(,IDE')-Adaptern, Small-Computer-System-Interface(,SCSI')Adaptern und anderen implementiert sein, wie den Fachleuten bekannt ist. Nichtflüchtige Computerspeicher können auch als optisches Plattenlaufwerk, elektronisch löschbare programmierbare Nur-Lese-Speicher (so genannte ,EEPROM' oder „Flash-Speicher”), RAM-Laufwerke und so weiter implementiert sein, wie den Fachleuten bekannt ist.
  • Der Computer 10 weist des Weiteren einen oder mehrere Eingabe/Ausgabe-(,E/A-')Adapter 42 auf, die benutzerorientierte Eingaben/Ausgabe beispielsweise über Software-Treiber und Computerhardware zum Steuern von Ausgaben an Anzeigeeinheiten wie beispielsweise Anzeigebildschirme sowie Benutzereingabe n von Benutzereingabeeinheiten 44 wie beispielsweise Tastaturen und Mäusen implementieren. Zusätzlich dazu weist der Computer 10 einen Kommunikationsadapter 46 zum Austausch von Daten mit anderen Computern 48 und zum Austausch von Daten mit einem Datenübertragungsnetzwerk 50. Solch eine Datenübertragung kann seriell über RS-232-Verbindungen, über externe Busses wie beispielsweise einen Universal Serial Bus (,USB'), über Datenübertragungsnetzwerke wie beispielsweise IP-Datenübertragungsnetzwerke und auf andere den Fachleuten bekannte Weise ausgeführt werden. Kommunikationsadapter implementieren die Hardware-Ebene von Datenübertragungen, über die ein Computer Datenübertragungen an einen anderen Computer, direkt oder über ein Datenübertragungsnetzwerk, sendet. Zu Beispielen von Kommunikationsadaptern, die für die Verwendung in Computer 10 geeignet sind, gehören Modems für leitungsgebundene Wählverbindungen, Ethernet-(IEEE 802.3)Adapter für leitungsgebundene Daten- und Netzwerkübertragung und 802.11-Adapter für drahtlose Daten- und Netzwerkübertragungen.
  • Zur weiteren Erklärung stellt 2 ein funktionales Blockschaltbild eines beispielhaften NoC 102 gemäß Ausführungsformen der vorliegenden Erfindung dar. Das NoC in 2 ist auf einem ,Chip' 100, das heißt, auf einer integrierten Schaltung implementiert. NoC 102 weist Integrated Processor (,IP')-Blöcke 104, Router 110, Speicherkommunikations-Controller 106 und Netzwerkschnittstellen-Controller 108 auf, die in miteinander verbundene Knoten gruppiert sind. Jeder IP-Block 104 ist über einen Speicherkommunikations-Controller 106 und einen Netzwerkschnittstellen-Controller 108 auf einen Router 110 eingerichtet. Jeder Speicherkommunikations-Controller steuert die Datenübertragung zwischen einem IP-Block und einem Speicher, und jeder Netzwerkschnittstellen-Controller 108 steuert den Datenübertragung zwischen IP-Blöcken über den Router 110.
  • In dem NoC 102 stellt jeder IP-Block eine wiederverwendbare Einheit aus einem synchronem oder einem asynchronem Logikaufbau dar, der als Baustein zur Datenverarbeitung innerhalb des NoC verwendet wird. Der Begriff ,IP-Block' wird mitunter zum ,intellectual property block' („Block geistigen Eigentums”) erweitert und bezeichnet so eigentlich einen IP-Block als Aufbau, der einem Besitzer gehört und der das geistiges Eigentum eines Besitzers ist, für das andere Benutzer oder Entwickler von Halbleiterschaltungen eine Lizenz erlangen müssten. Innerhalb des Umfangs der vorliegenden Erfindung ist es jedoch nicht erforderlich, dass IP-Blöcke irgendeiner bestimmten Eigentümerschaft unterliegen, dementsprechend wird der Begriff in dieser Spezifikation immer zu einem ,Integrated Prozessor-Block' erweitert. IP-Blöcke sind gemäß ihrer hierin beschriebenen Spezifizierung wiederverwendbare Einheiten von Logik, Zellen- oder Chiplayout-Ausgestaltungen, die gegebenenfalls einem geistigen Eigentum unterliegen. IP-Blöcke sind Logikkerne, die als ASIC-Chipaufbauten oder FPGA-Logikaufbauten ausgebildet sein können.
  • Beschreibt man IP-Blöcke im Sinne einer Analogie, so heißt das, dass IP-Blöcke für das NoC-Design das sind, was eine Bibliothek beim Programmieren eines Computers oder was eine diskrete integrierte Schaltung für den Aufbau einer gedruckten Schaltung ist. In NoCs gemäß Ausführungsformen der vorliegenden Erfindung können IP-Blöcke als generische Gatternetzlisten, als komplette Spezial- oder Universal-Mikroprozessoren oder in anderer den Fachleuten bekannter Form implementiert sein. Bei einer Netzliste handelt es sich um eine Boolesche-Algebra-Darstellung (Gatter, Standardzellen) einer Logikfunktion eines IP-Blocks, analog zu einem Assembly-Code-Listing für eine Programmanwendung auf höherer Ebene. NoCs können beispielsweise auch in synthetisierbarer Form, beschrieben in einer Hardware-Deskriptionssprache wie beispielsweise Verilog oder VHDL, implementiert sein. Zusätzlich zu einer Implementierung als Netzliste oder in synthetisierbarer Form können NoCs auch in physischen Deskriptionen niedrigerer Ebenen (lower level) ausgeführt sein. Analoge IP-Blockelemente wie beispielsweise SERDES, PLL, DAC, ADC und so weiter können in einem Transistor-Layout-Format wie beispielsweise GDSII verteilt sein. Digitale Elemente von IP-Blöcken werden oftmals auch in Layout-Formaten angeboten. Es ist darüber hinaus bekannt, dass IP-Blöcke sowie andere gemäß der Erfindung implementierte Logikschaltungen in Form von Computerdatendateien beispielsweise als Logikdefinitions-Programmcode verteilt sein können, die auf verschiedenen Detailebenen die Funktionalität und/oder das Layout der Schaltungsanordnungen, die solche Logik implementieren, definieren. Auf diese Weise und obgleich die Erfindung bisher im Kontext von Schaltungsanordnungen, die in voll funktionierenden integrierten Schaltungseinheiten, solche Einheiten verwendenden Datenverarbeitungssystemen und anderen materiellen physischen Hardware-Schaltungen implementiert sind, beschrieben wurde und im weiteren Verlauf auch in dieser Form beschrieben wird, ist den Fachleuten unter Nutzung des Vorteils der vorliegenden Offenbarung bekannt, dass die Erfindung auch in einem Programmprodukt implementiert sein kann und dass die Erfindung ungeachtet des bestimmten Typs von computerlesbarem Speichermedium, das zum Verteilen des Programmproduktes verwendet wird, gleichermaßen Anwendung findet. Beispiele von computerlesbaren Speichermedien sind unter anderem, ohne auf diese beschränkt zu sein, physische Aufzeichnungsmedien wie beispielsweise flüchtige und nichtflüchtige Speichereinheiten, Floppy-Disks, Festplattenlaufwerke, CD-ROMS, und DVDs (unter anderem).
  • Jeder IP-Block 104 in dem Beispiel von 2 ist über einen Speicherkommunikations-Controller 106 auf einen Router eingerichtet. Bei jedem Speicherkommunikations-Controller handelt es sich um einen Verbund aus einer synchronen und asynchronen Logikschaltung, die so eingerichtet die sind, dass sie eine Datenübertragung zwischen einem IP-Block und einem Speicher gewährleisten. Zu Beispielen eines solchen Datenübertragung zwischen IP-Blöcken und Speicher gehören Lade- und Speicheranweisungen für Speicher. Die Speicherkommunikations-Controller 106 werden im weiteren Verlauf in Bezug auf 3 ausführlicher beschrieben. Jeder IP-Block 104 ist des Weiteren über einen Netzwerkschnittstellen-Controller 104 auf einen Router 110 eingerichtet, der die Datenübertragung zwischen den IP-Blöcken 104 über den Router 110 steuert. Zu Beispielen einer Datenübertragung zwischen IP-Blöcken gehören Mitteilungen transportierende Daten und Anweisungen zum Verarbeiten der Daten zwischen IP-Blöcken in Anwendungen mit Parallel- und Pipelineverarbeitung. Die Netzwerkschnittstellen-Controller 108 werden in Bezug auf 3 ebenfalls ausführlicher beschrieben.
  • Die Router 110 und die entsprechenden Links 118 dazwischen implementieren die Netzwerkoperationen des NoC. Bei den Links 118 kann es sich um Paketstrukturen handeln, die auf physischen parallelen leitungsgestützten Bussen implementiert sind, die alle Router verbinden. Das heißt, jeder Link kann auf einem leitungsgestützten Bus implementiert sein, der breit genug ist, um gleichzeitig ein ganzes Daten-Switching-Paket einschließlich aller Kopfzeileninformationen (header information) und Nutzdaten (payload data) aufzunehmen. Umfasst eine Paketstruktur beispielsweise 64 Byte und beinhaltet eine Kopfzeile von acht Byte sowie Nutzdaten von 56 Byte, dann ist der zu einer jeden Verbindung entgegensetzte (subtending each link) leitungsgestützte Bus 64 Byte breit, 512 Leitungen. Darüber hinaus kann jede Verbindung bidirektional sein, so dass, wenn die Verbindungspaketstruktur 64 Byte hat, der leitungsgestützte Bus tatsächlich 1024 Leitungen zwischen jedem Router und jedem seiner Nachbarn in dem Netzwerk enthält. In solch einer Implementierung könnte eine Mitteilung mehr als ein Paket aufweisen, jedes Paket würde jedoch genau auf die Breite des Drahtbusses passen. Alternativ dazu kann ein Link auf einem leitungsgestützten implementiert sein, der gerade breit genug ist, um einen Abschnitt des Paketes aufzunehmen, so dass ein Paket in mehrere Beats z. B. so unterteilt würde, dass, wenn eine Verbindung mit 16 Byte in der Breite oder 128 Leitungen implementiert ist, ein 64-Byte-Paket in vier Beats unterteilt werden könnte. Es ist bekannt, dass ausgehend von praktischen physischen Grenzen und den gewünschten Leistungseigenschaften verschiedene Implementierungen unterschiedliche Busbreiten verwenden können. Wird die Verbindung zwischen dem Router und jedem Abschnitt des leitungsgestützten Busses als Anschluss (port) bezeichnet, weist jeder Router fünf Anschlüsse auf, einen für jede von vier Richtungen der Datenübertragung auf dem Netzwerk und einen fünften Anschluss zum Einrichten des Routers auf einen bestimmten IP-Block über einen Speicherkommunikations-Controller und einen Netzwerkschnittstellen-Controller.
  • Jeder Speicherkommunikations-Controller 106 steuert die Datenübertragung zwischen einem IP-Block und einem Speicher. Der Speicher kann einen außerhalb des Chips vorhandenen (Off-Chip-)Haupt-Arbeitsspeicher 112, einen direkt über einen Speicherkommunikations-Controller 106 mit einem IP-Block verbundenen Speicher 114, ein als IP-Block aktivierter auf dem Chip vorhandener (On-Chip-)Speicher 116 und On-Chip-Cachespeicher aufweisen. In dem NOC 102 kann einer der On-Chip-Speicher 114 oder 116 beispielsweise als On-Chip-Cachespeicher implementiert sein. All diese Speicherformen können auf demselben Adressenplatz, denselben physischen Adressen oder virtuellen Adressen angeordnet sein, dies trifft sogar für einen direkt an einen IP-Block angehängten Speicher zu. Speicheradressierte Mitteilungen können dementsprechend für IP-Blöcke vollständig bidirektional sein, da solche Speicher direkt von einem beliebigen IP-Block an einem beliebigen Ort auf dem Netzwerk adressiert werden können. Der Speicher 116 auf einem IP-Block kann von diesem IP-Block oder von einem beliebigen anderen IP-Block in dem NoC adressiert werden. Der Speicher 114, der direkt an einen Speicherkommunikations-Controller angeschlossen ist, kann von dem IP-Block adressiert werden, der durch diesen Speicherkommunikations-Controller auf das Netzwerk eingerichtet ist – und er kann des Weiteren von jedem beliebigen anderen IP-Block an einem beliebigen Ort in dem NoC adressiert werden.
  • Das NoC 102 weist zwei Speicherverwaltungseinheiten (memory management units, ,MMUs') 120, 122 auf, die zwei alternative Speicherarchitekturen für NoCs gemäß Ausführungsformen der vorliegenden Erfindung veranschaulichen. Die MMU 120 ist innerhalb eines IP-Blockes implementiert, wodurch ein Prozessor innerhalb des IP-Blockes in einem virtuellen Speicher arbeiten kann, währenddessen die gesamte verbleibende Architektur des NoC auf einem physischen Speicheradressenplatz arbeiten kann. Die MMU 122 ist außerhalb des Chips (off-chip) implementiert und über einen Datenübertragungs-Anschluss 124 mit dem NoC verbunden. Der Anschluss 124 die Pins und andere Verbindungen, die zum Leiten von Signalen zwischen dem NoC und der MMU erforderlich sind, sowie ausreichend Intelligenz zum Umwandeln von Mitteilungspaketen im NoC-Paketformat in ein Busformat, das von der externen MMU 122 benötigt wird. Externer Ort der MMU bedeutet, dass alle Prozessoren in sämtlichen IP-Blöcken des NoC auf virtuellen Speicheradressenplätzen arbeiten können, wobei alle Umwandlungen in physische Adressen des Off-Chip-Speichers von der Off-Chip-MMU 122 bearbeitet werden.
  • Zusätzlich zu den beiden Speicherarchitekturen, die unter Verwendung der MMUs 120, 122 veranschaulicht werden, veranschaulicht der Datenübertragungs-Anschluss 126 eine dritte in NoCs nützliche Speicherarchitektur, die in Ausführungsformen der vorliegenden Erfindung verwendet werden kann. Der Anschluss 126 stellt eine direkte Verbindung zwischen einem IP-Block 104 des NoC 102 und dem Off-Chip-Speicher 112 her. Ohne MMU in dem Verarbeitungs-Thread bietet diese Architektur Nutzung eines physischen Adressenplatzes durch sämtliche IP-Blöcke des NoC. Durch gemeinsames bidirektionales Nutzen des Adressenplatzes können alle IP-Blöcke des NoC über speicheradressierte Mitteilungen auf Speicher auf dem Adressenplatz zugreifen, einschließlich Lade- und Speichervorgängen, die über den direkt mit dem Anschluss 126 verbundenen IP-Block angeleitet werden.
  • Der Anschluss 126 weist Pins und andere Verbindungen, die zum Leiten von Signalen zwischen dem NoC und dem Off-Chip-Speicher 112 erforderlich sind, sowie ausreichend Intelligenz auf, um Mitteilungspakete im NoC-Paketformat in das von dem Off-Chip-Speicher 112 benötigte Busformat umzuwandeln.
  • In dem Beispiel von 2 wird einer der IP-Blöcke einem Host-Schnittstellenprozessor 129 zugeordnet. Ein Host-Schnittstellenprozessor 128 liefert eine Schnittstelle zwischen einem NoC und einem Host-Computer 10, in dem das NoC installiert werden kann, sowie des Weiteren Datenverarbeitungsleistungen für die anderen IP-Blöcke auf dem NoC, darunter beispielsweise Empfangen und Zuteilen der NoC-Datenverarbeitungsanforderungen von dem Host-Computer zwischen den IP-Blöcken. Ein NoC kann beispielsweise einen Videografikadapter 26 oder einen Coprozessor 28 auf einem größeren Computer 10 implementieren, wie dies vorstehend in Bezug auf 1 beschrieben wurde. In dem Beispiel von 1 ist der Host-Schnittstellenprozessor 128 über einen Datenübertragungs-Anschluss 130 mit dem größeren Host-Computer verbunden. Der Anschluss 130 weist die Pins sowie weitere Verbindungen auf, die zum Leiten von Signalen zwischen dem NoC und der MMU erforderlich sind, sowie ausreichende Intelligenz zum Umwandeln von Mitteilungspaketen im NoC-Paketformat in das Busformat, das von dem Host-Computer benötigt wird. In dem Beispiel des NoC-Coprozessors in dem Computer von 1 würde solch ein Anschluss eine Datenübertragungs-Formatübersetzung zwischen der Link-Struktur des NoC-Coprozessors 28 und dem für den Front-Side-Bus 36 zwischen dem NoC-Coprozessors 28 und dem Bus-Adapter 18 benötigten Protokoll bereitstellen.
  • 3 veranschaulicht als Nächstes ein funktionales Blockschaltbild, das die innerhalb eines IP-Blockes implementierten Komponenten, den Speicherkommunikations-Controller 106, den Netzwerkschnittstellen-Controller 108 und den Router 110 in dem NoC, allesamt in 132 dargestellt, ausführlicher veranschaulicht. IP-Block 104 weist einen Computerprozessor 134 und E/A-Funktionen 136 auf. In diesem Beispiel wird der Computerspeicher von einem Segment eines Arbeitsspeichers (,RAM') 138 in dem IP-Block 104 dargestellt. Wie vorstehend in Bezug auf 2 beschrieben kann der Speicher Segmente eines physischen Adressenplatzes einnehmen, dessen Inhalte auf jedem IP-Block adressierbar und von jedem beliebigen IP-Block in dem NoC zugänglich sind. Die Prozessoren 134, E/A-Funktionen 136 und der Speicher 138 implementieren in jedem Block im Prinzip die IP-Blöcke als allgemein programmierbare Mikrocomputer. Wie dies vorstehend beschrieben wurde, stellen jedoch im Umfang der vorliegenden Erfindung IP-Blöcke im Allgemeinen wiederverwendbare Einheiten aus synchroner und asynchroner Logik dar, die als Bausteine zur Datenverarbeitung innerhalb eines NoC verwendet werden. Dementsprechend stellt die Implementierung von IP-Blöcken als allgemein programmierbare Mikrocomputer keine Beschränkung der vorliegenden Erfindung dar, obgleich dies eine im Sinne einer Erklärung übliche und nützliche Ausführungsform ist.
  • In dem NoC 102 von 3 weist jeder Speicherkommunikations-Controller 106 eine Vielzahl von Speicher-Datenübertragungs-Ausführungsmaschinen 140 auf. Jede Speicher-Datenübertragungs-Ausführungsmaschine 140 ist zum Ausführen von Speicher-Datenübertragungs-Anweisungen von einem IP-Block 104, einschließlich eines bidirektionalen Speicher-Datenübertragungs-Anweisungsflusses 141, 142 zwischen dem Netzwerk und dem IP-Block 104, in der Lage. Die von dem Speicherkommunikations-Controller ausgeführten Speicher-Datenübertragungs-Anweisungen können nicht nur von dem auf einen Router über einen bestimmten Speicherkommunikations-Controller eingerichteten IP-Block stammen, sondern auch von einem jedem beliebigen IP-Block 104 eines beliebigen Ortes in dem NoC 102. Das heißt, jeder beliebige IP-Block in dem NoC kann eine Speicher-Datenübertragungs-Anweisung erzeugen und diese Speicher-Datenübertragungs-Anweisung über die Router des NoC an einen anderen Speicherdatenübertragungs-Controller senden, der zu einem anderen IP-Block zur Ausführung dieser Speicherkommunikations-Anweisung gehört. Zu solchen Speicher-Datenübertragungs-Anweisungen können beispielsweise Anweisungen zum Übersetzen von Adressumsetzpuffer-Steueranweisungen, Cachespeicher-Steueranweisungen, Anweisungen zum Sperren sowie Lade- und Speicheranweisungen für Speicher gehören.
  • Jede Speicher-Datenübertragungs-Ausführungsmaschine 140 ist zum Ausführen einer vollständigen Speicher-Datenübertragungs-Anweisung separat und parallel zu anderen Speicher-Datenübertragungs-Ausführungsmaschinen in der Lage. Die Speicher-Datenübertragungs-Ausführungsmaschinen 140 implementieren einen skalierbaren Speicher-Transaktionsprozessor, der für einen gleichzeitigen Durchsatz von Speicherdatenübertragungs-Anweisungen optimiert ist. Der Speicherkommunikations-Controller 106 unterstützt die mehreren Speicher-Datenübertragungs-Ausführungsmaschinen 140, von denen alle zeitgleich zur gleichzeitigen Ausführung von mehreren Speicher-Datenübertragungs-Anweisungen laufen. Von dem Speicherkommunikations-Controller 106 wird eine neue Speicherdatenübertragungs-Anweisung einer Speicher-Datenübertragungs-Ausführungsmaschinen 140 zugewiesen, und Speicher-Datenübertragungs-Ausführungsmaschinen 140 können mehrere Antwortereignisse gleichzeitig annehmen. In diesem Beispiel sind sämtliche der Speicher-Datenübertragungs-Ausführungsmaschinen 140 identisch. Dementsprechend wird Skalieren der Anzahl von Speicher-Datenübertragungs-Anweisungen, die gleichzeitig von einem Speicherkommunikations-Controller 106 bearbeitet werden können, durch Skalieren der Anzahl von Speicher-Datenübertragungs-Ausführungsmaschinen 140 implementiert.
  • In dem NoC von 3 ist jeder Netzwerkschnittstellen-Controller 108 dazu in der Lage, Datenübertragungsanweisungen von einem Befehlsformat in ein Netzwerkpaketformat zur Übertragung zwischen den IP-Blöcken 104 über Router 110 umzuwandeln. Die Datenübertragungsanweisungen können von dem IP-Block 104 oder dem Speicherkommunikations-Controller 106 im Befehlsformat formuliert und dem Netzwerkschnittstellen-Controller 108 im Befehlsformat bereitgestellt werden. Bei dem Befehlsformat kann es sich um ein natives Format handeln, das den Architektur-Registerdateien von IP-Block 104 und dem Speicherkommunikations-Controller 106 entspricht. Bei dem Netzwerkpaketformat handelt es sich normalerweise um das für die Übertragung über die Router 110 des Netzwerkes erforderliche Format. Jede solche Mitteilung ist aus einer oder mehreren Netzwerkpaketen gebildet. Zu Beispielen solcher Datenübertragungsanweisungen, die in dem Netzwerkschnittstellen-Controller vom Befehlsformat in das Paketformat umgewandelt werden, gehören Speicher- und Ladeanweisungen für Speicher zwischen IP-Blöcken und Speicher. Zu solchen Datenübertragungsanweisungen können auch Datenübertragungsanweisungen gehören, die Mitteilungen zwischen IP-Blöcken senden, die Daten und Anweisungen zur Verarbeitung von Daten zwischen IP-Blöcken in Parallel- und Pipeline-Anwendungen transportieren.
  • In dem NoC 102 von 3 ist jeder IP-Block in der Lage, auf Speicheradressen beruhende Datenübertragung zu und vom Speicher über die Speicherkommunikations-Controller der IP-Blöcke und anschließend über seine Netzwerkschnittstellen-Controller an das Netzwerk zu senden. Bei einer auf Speicheradressen beruhenden Datenübertragung handelt es sich um eine Speicherzugriffsanweisung wie beispielsweise eine Lade- oder eine Speicheranweisung für einen Speicher, die von einer Speicher-Datenübertragungs-Ausführungsmaschine eines Speicherkommunikations-Controllers eines IP-Blockes ausgeführt wird. Solch eine auf Speicheradressen beruhende Datenübertragung hat ihren Ursprung normalerweise in einem IP-Block, ist im Befehlsformat formuliert und wird zur Ausführung an einen Speicherkommunikations-Controller weitergegeben.
  • Viele auf Speicheradressen beruhende Datenübertragungen werden im Zuge von Mitteilungsverkehr ausgeführt, da sich jeder beliebige Speicher, auf den zugegriffen werden muss, an jedem beliebigen Ort auf dem physischen Speicheradressenplatz, auf dem Chip oder außerhalb des Chips befinden kann, direkt an einen beliebigen Speicherkommunikations-Controller in dem NoC angeschlossen oder schließlich mit direktem Zugriff darauf über einen beliebigen IP-Block des NoC ungeachtet dessen sein kann, von welchem IP-Block irgendeine bestimmte auf Speicheradressen beruhende Datenübertragung stammte. Auf diese Weise werden in dem NoC 102 alle auf Speicheradressen beruhenden Datenübertragungen, die im Mitteilungsverkehr ausgeführt werden, von dem Speicherkommunikations-Controller an einen zugehörigen Netzwerkschnittstellen-Controller zum Umwandeln von einem Befehlsformat in ein Paketformat und zum Übertragen über das Netzwerk in einer Mitteilung weitergeleitet. Beim Umwandeln in das Paketformat identifiziert der Netzwerkschnittstellen-Controller des Weiteren eine Netzwerkadresse für das Paket in Abhängigkeit von der Speicheradresse oder den Adressen, auf die durch eine auf Speicheradressen beruhende Datenübertragung zugegriffen werden muss. Auf Speicheradressen beruhende Mitteilungen werden mit Speicheradressen adressiert. Jede Speicheradresse wird von dem Netzwerkschnittstellen-Controller auf einer Netzwerkadresse abgebildet, normalerweise den Ort im Netzwerk eines Speicherkommunikations-Controllers, der für einen Bereich der physischen Speicheradressen zuständig ist. Der Ort im Netzwerk eines Speicherkommunikations-Controllers 106 ist natürlich auch der Netzwerkort des zu diesem Speicherkommunikations-Controller gehörenden Routers 110, des Netzwerkschnittstellen-Controllers 108 und des IP-Blockes 104. Die Anweisungs-Umwandlungslogik 150 innerhalb eines jedes Netzwerkschnittstellen-Controllers ist zum Umwandeln von Speicheradressen in Netzwerkadressen zum Zwecke des Sendens von auf Speicheradressen beruhender Datenübertragung über Router eines NoC in der Lage.
  • Bei Empfang von Mitteilungsverkehr von Routern 110 des Netzwerkes prüft jeder Netzwerkschnittstellen-Controller 108 jedes Paket im Hinblick auf Speicheranweisungen. Jedes Paket, das eine Speicheranweisung enthält, wird an den zu dem empfangenden Netzwerkschnittstellen-Controller gehörenden Speicherkommunikations-Controller 106 weitergeleitet, der die Speicheranweisung ausführt, bevor die verbleibende Nutzlast (payload) des Paketes zur weiteren Verarbeitung an den IP-Block gesendet wird. Auf diese Weise werden Speicherinhalte stets zum Unterstützen von Datenverarbeitung durch einen IP-Block vorbereitet, bevor der IP-Block die Ausführung von Anweisungen von einer Mitteilung beginnt, die von einem bestimmten Speicherinhalt abhängt.
  • In dem NoC 102 von 3 ist jeder IP-Block 104 in der Lage, seinen Speicherkommunikations-Controller 106 zu umgehen und zwischen IP-Blöcken übertragene netzwerkadressierte Datenübertragungen 146 über den Netzwerkschnittstellen-Controller 108 des IP-Blockes direkt an das Netzwerk zu senden. Bei netzwerkadressierten Datenübertragungen handelt es sich um Mitteilungen, die von einer Netzwerkadresse an einen anderen IP-Block geleitet werden. Solche Mitteilungen übertragen Arbeitsdaten in Pipeline-Anwendungen, mehrere Daten für eine einzelne Programmverarbeitung zwischen IP-Blöcken in einer SIMD-Anwendung und so weiter, wie den Fachleuten bekannt ist. Solche Mitteilungen unterscheiden sich von auf Speicheradressen beruhenden Datenübertragungen darin, dass sie von Beginn an von dem Ursprungs-IP-Block netzwerkadressiert werden, der die Netzwerkadresse kennt, an die die Mitteilung über die Router des NoC geleitet werden soll. Solche netzwerkadressierten Datenübertragungen werden im Befehlsformat vom IP-Block über E/A-Funktionen 136 direkt an den Netzwerkschnittstellen-Controller des IP-Blockes gesendet, anschließend von dem Netzwerkschnittstellen-Controller in Paketformat umgewandelt und über Router des NoC an einen anderen IP-Block gesendet. Solche netzwerkadressierten Datenübertragungen 146 sind bidirektional und können zu und von jedem IP-Block des NoC in Abhängigkeit von ihrer Verwendung in einer beliebigen bestimmten Anwendung weitergeleitet werden. Jeder Netzwerkschnittstellen-Controller ist jedoch sowohl zum Senden als auch Empfangen solcher Datenübertragungen an und von einem zugehörigen Router in der Lage, und jeder Netzwerkschnittstellen-Controller ist sowohl zum Senden als auch Empfangen solcher Datenübertragungen direkt an und von einem zugehörigen IP-Block sowie zum Umgehen eines zugehörigen Speicherkommunikations-Controller 106 dabei in der Lage.
  • Jeder Netzwerkschnittstellen-Controller 108 in dem Beispiel von 3 ist des Weiteren zum Implementieren virtueller Kanäle auf dem Netzwerk in der Lage, wodurch Netzwerkpakete nach Typ charakterisiert werden. Jeder Netzwerkschnittstellen-Controller 108 weist eine virtuelle Kanalimplementierungs-Logik 148 auf, die jede Datenübertragungsanweisung nach Typ charakterisiert und den Typ von Anweisung in ein Feld des Netzwerkpaketformats einträgt, bevor die Anweisung in Paketformat an einen Router 110 zur Übertragung auf dem NoC weitergegeben wird. Zu Beispielen von Datenübertragungsanweisungstypen gehören zwischen IP-Blöcken gesendete auf Netzwerkadressen beruhende Mitteilungen, Anforderungsmitteilungen, Antworten auf Anforderungsmitteilungen, an Cachespeicher geleitete ungültige Mitteilungen; Mitteilungen zum Laden und Speichern für Speicher; und Antworten auf Mitteilungen zum Laden in Speicher usw.
  • Jeder Router 110 in dem Beispiel von 3 weist eine Routing-Logik 152, eine virtuelle Kanalsteuerungs-Logik 154 und virtuelle Kanalpuffer 156 auf. Die Routing-Logik ist normalerweise als Netzwerk aus synchroner und asynchroner Logik implementiert, das einen Datenübertragungs-Protokollstapel zur Datenübertragung in dem von den Routern 110, Links 118 und Busleitungen zwischen den Routen gebildeten Netzwerk implementiert. Die Routing-Logik 152 weist die Funktionalität auf, die Leser und Fachleute möglicherweise in wenigstens einigen Ausführungsformen mit Off-Chip-Netzwerken mit Routing-Tabellen erwarten würden, die jedoch für eine Verwendung in einem NoC als zu langsam und umständlich erachtet werden. Als ein Netzwerk aus synchroner und asynchroner Logik implementierte Routing-Logik kann so konfiguriert sein, dass Routing-Entscheidungen mit der Schnelligkeit eines einzigen Taktzyklus getroffen werden. Die Routing-Logik in diesem Beispiel leitet Pakete durch Auswählen eines Anschlusses zum Weiterleiten eines jeden Paketes, das in einem Router empfangen wurde. Jedes Paket enthält eine Netzwerkadresse, an die das Paket geleitet werden soll.
  • Bei der vorstehenden Beschreibung von auf Speicheradressen Datenübertragungen wurde jede Speicheradresse so beschrieben, dass sie von den Netzwerkschnittstellen-Controllern auf einer Netzwerkadresse, einem Netzwerkort eines Speicherkommunikations-Controllers, abgebildet wird. Der Netzwerkort eines Speicherkommunikations-Controllers 106 ist natürlich auch der Netzwerkort des zu diesem Speicherkommunikations-Controller gehörenden Router 110, des Netzwerkschnittstellen-Controller 108 und des IP-Blockes 104. Bei zwischen IP-Blöcken gesendeten oder auf Netzwerkadressen beruhenden Datenübertragungen ist es dementsprechend auch normal für eine Datenverarbeitung auf Anwendungsebene, Netzwerkadressen als den Ort eines IP-Blockes innerhalb des Netzwerkes zu erachten, das von den Routern, Links und Busleitungen des NoC gebildet wird. 2 veranschaulicht, dass eine Struktur eines solchen Netzwerkes ein Geflecht (mesh) aus Zeilen und Spalten ist, in denen jede Netzwerkadresse implementiert sein kann, beispielsweise als ein eindeutiges Identifizierungselement für jeden Satz aus zugehörigem Router, IP-Block, Speicherkommunikations-Controller und Netzwerkschnittstellen-Controller des Geflechtes oder x-y-Koordinaten eines solchen Satzes in dem Geflecht.
  • In dem NoC 102 von 3 implementiert jeder Router 110 zwei oder mehr virtuelle Datenübertragungskanäle, wobei jeder virtuelle Datenübertragungskanal durch einen Datenübertragungstyp charakterisiert ist. Zu Datenübertragungsanweisungstypen und dementsprechend virtuellen Kanaltypen gehören die vorstehend erwähnten: zwischen IP-Blöcken gesendete auf Netzwerkadressen beruhende Mitteilungen, Anforderungsmitteilungen, Antworten auf Anforderungsmitteilungen, an Cachespeicher geleitete ungültige Mitteilungen; Mitteilungen zum Laden und Speichern für Speicher; und Antworten auf Mitteilungen zum Laden in Speicher und so weiter. Als Unterstützung von virtuellen Kanälen weist jeder Router 110 in dem Beispiel von 3 des Weiteren eine virtuelle Kanalsteuerungs-Logik 154 und virtuelle Kanalpuffer 156 auf. Die virtuelle Kanalsteuerungs-Logik 154 prüft jedes empfangene Paket auf seinen zugewiesenen Datenübertragungstyp und platziert jedes Paket in einen abgehenden virtuellen Kanalpuffer für diesen Datenübertragungstyp zum Übertragen über einen Anschluss oder einen benachbarten Router auf dem NoC.
  • Jeder virtuelle Kanalpuffer 156 hat einen begrenzten Speicherplatz. Werden viele Pakete in einem kurzen Zeitraum empfangen, kann ein virtueller Kanalpuffer erschöpfend gefüllt sein, so dass keine weiteren Pakete in den Puffer gelegt werden können. In anderen Protokollen würden Pakete, die auf einem virtuellen Kanal ankommen, dessen Puffer voll ist, verworfen werden. In diesem Beispiel ist jedoch jeder virtuelle Kanalpuffer 156 mit Steuersignalen der Busleitungen aktiviert, um umliegende Router über die virtuelle Kanalsteuerungs-Logik zu einem Aussetzen der Übertragung in einem virtuellen Kanal zu veranlassen, das heißt, die Übertragung von Paketen eines bestimmten Datenübertragungstyp auszusetzen. Wird ein virtueller Kanal auf diese Weise ausgesetzt, bleiben alle anderen virtuellen Kanäle davon unbeeinträchtigt und können weiter bei voller Auslastung arbeiten. Die Steuersignale werden über jeden Router die gesamte Strecke zurück zu jedem zum Router gehörenden Netzwerkschnittstellen-Controller 108 übertragen. Jeder Netzwerkschnittstellen-Controller ist so konfiguriert, dass er bei Empfang eines solchen Signals von seinem zugehörigen Speicherkommunikations-Controller 106 oder von seinem zugehörigen IP-Block 104 die Annahme von Datenübertragungsanweisungen für den ausgesetzten virtuellen Kanal verweigern kann. Auf diese Weise beeinträchtigt die Aussetzung eines virtuellen Kanals all die Hardware, die den virtuellen Kanal implementiert, die ganze Strecke zurück bis zu dem Ursprungs-IP-Blöcken.
  • Eine Auswirkung ausgesetzter Paketübertragungen in einem virtuellen Kanal besteht darin, dass keine Pakete jemals verworfen werden. Tritt bei einem ein Router eine Situation auf, in der ein Paket in einem etwas unzuverlässigen Protokoll wie beispielsweise in dem Internet Protocol möglicherweise verworfen wird, können die Router in dem Beispiel von 3 durch ihre virtuellen Kanalpuffer 156 und ihre virtuelle Kanalsteuerungs-Logik 154 alle Übertragungen von Paketen in einem virtuellen Kanal so lange aussetzen, bis wieder Pufferspeicherplatz verfügbar ist, womit die Notwendigkeit, Pakete zu verwerfen, entfällt. Das NoC von 3 kann dementsprechend zuverlässige Netzwerkdatenübertragungsprotokolle mit einer äußerst dünnen Hardwareschicht implementieren.
  • Das Beispiel von 3 kann auch so konfiguriert sein, dass eine Cachespeicher-Kohärenz sowohl zwischen On-Chip- als auch Off-Chip-Cachespeichern aufrechterhalten wird. Jeder NoC kann mehrere Cachespeicher unterstützen, von denen jeder gegen denselben zugrundeliegenden Speicheradressenplatz arbeitet. So können Cachespeicher beispielsweise von IP-Blöcken, von Speicherkommunikations-Controllern oder von Cachespeicher-Controllern, die sich außerhalb des NoC befinden, gesteuert werden. Jeder der On-Chip-Speicher 114, 116 in dem Beispiel von 2 kann auch als On-Chip-Cachespeicher implementiert sein, und innerhalb des Umfangs der vorliegenden Erfindung kann auch der Cachespeicher außerhalb des Chips (off-chip) implementiert sein.
  • Jeder in 3 dargestellte Router 110 weist fünf Anschlüsse auf, vier Anschlüsse über Busleitungen 118 mit anderen Routern 158A–D-verbunden und einen fünften Anschluss 160, der jeden Router über einen Netzwerkschnittstellen-Controller 108 und einen Speicherkommunikations-Controller 106 mit seinem zugehörigen IP-Block 104 verbindet. Wie den Veranschaulichungen in den 2 und 3 entnommen werden kann, bilden die Router 110 und die Links 118 des NoC 102 ein „Mesh”-Netzwerk mit vertikalen und horizontalen Links, die vertikale und horizontale Anschlüsse in jedem Router verbinden. In der Veranschaulichung von 3 werden beispielsweise die Anschlüsse 158A, 158C und 160 als vertikale Anschlüsse und die Anschlüsse 158B und 158D als horizontale Anschlüsse bezeichnet.
  • Als Nächstes veranschaulicht 4 auf andere Weise eine beispielhafte Ausführungsform eines IP-Blockes 104 gemäß der Erfindung, der als ein Verarbeitungselement implementiert ist, das in eine Anweisungseinheit (IU) 162, eine Ausführungseinheit (XU) 164 und eine Hilfsausführungseinheit (AXU) 166 unterteilt ist. In der veranschaulichten Implementierung weist die IU 162 eine Vielzahl von Anweisungs-Puffern 168 auf, die Anweisungen von einem L1-Anweisungs-Cachespeicher (iCACHE) 170 empfangen. Jeder Anweisungs-Puffer 168 ist einer Vielzahl von beispielsweise vier symmetrischen Multithread-Hardware-Threads (SMT) zugeordnet. Eine „Effective-to-Real Translation”-Einheit (iERAT) 172 ist mit dem iCACHE 170 verbunden und wird zum Übersetzen von Anweisungs-Abrufanforderungen von einer Vielzahl von Thread-Abruf-Sequencern 174 in reale Adressen zum Abruf von Anweisungen von Speichern niedrigerer Ordnung verwendet. Jeder Thread-Abrufs-Sequencer 174 ist einem bestimmten Hardware-Thread zugeordnet und wird verwendet um sicherzustellen, dass von dem zugehörigen Thread auszuführende Anweisungen zum Zuteilen zu der geeigneten Ausführungseinheit in den iCACHE abgerufen werden. Wie dies in 4 ebenfalls dargestellt ist, können in den Anweisungs-Puffer 168 abgerufene Anweisungen auch von der Sprungvorhersage-Logik 176 überwacht werden, womit Hinweise auf jeden Thread-Abrufs-Sequencer 174 zum Minimieren von Fehlzugriffen auf Anweisungs-Cachespeicher bereitgestellt werden, die von Sprüngen beim Ausführen von Threads resultieren.
  • Die IU 162 weist des Weiteren einen Abhängigkeits/Ausgabe-Logikblock 178 auf, der jedem Hardware-Thread eigens zugeordnet und so konfiguriert ist, dass er Abhängigkeiten löst und die Ausgabe von Anweisungen von dem Anweisungs-Puffer an die XU 164 steuert. Darüber hinaus wird in der veranschaulichten Ausführungsform eine separate Abhängigkeits/Ausgabe-Logik 180 in der AXU 166 bereitgestellt, wodurch separate Anweisungen gleichzeitig von verschiedenen Threads an die XU 164 und die AXU 166 ausgegeben werden können. In einer alternativen Ausführungsform kann eine Logik 180 in der IU 162 angeordnet oder ganz weggelassen werden, so dass die Logik 178 Anweisungen an die AXU 166 ausgibt.
  • Die XU 164 ist als Festkomma-Ausführungseinheit implementiert, aufweisend einen Satz von Allgemeinregistern (General Purpose Registers (GPRs)) 182, die mit der Festkomma-Logik 184, einer Sprung-Logik 186 und einer Lade/Speicher-Logik 188 verbunden ist. Die Lade/Speicherlogik 188 ist mit einem L1-Daten-Cachespeicher (dCACHE) 190, mit einer von der dERAT-Logik 192 bereitgestellten „effective to real translation” verbunden. Die XU 164 kann so konfiguriert sein, dass sie praktisch jeden beliebigen Logiksatz implementieren kann, beispielsweise die Gesamtheit oder einen Abschnitt eines 32b- oder 64b-PowerPC-Anweisungssatzes.
  • Die AXU 166 arbeitet als Hilfsausführungseinheit und weist eine eigens zugeordnete Abhängigkeits/Ausgabe-Logik 180 zusammen mit einem oder mehreren Ausführungsblöcken 194 auf. Die AXU 166 kann eine beliebige Anzahl von Ausführungsblöcken aufweisen und praktisch jeden Typ von Ausführungseinheit implementieren, zum Beispiel eine Gleitkomma-Einheit oder eine oder mehrere spezialisierte Ausführungseinheiten wie beispielsweise Verschlüsselungseinheiten, Coprozessoren, Vektorverarbeitungseinheiten, Grafikverarbeitungseinheiten, XML-Verarbeitungseinheiten usw.. In der veranschaulichten Ausführungsform weist die AXU 166 eine Hochgeschwindigkeits-Hilfsschnittstelle zur XU 164 z. B. zur Unterstützung direkter Verschiebungen zwischen dem eingerichteten Zustand der AXU und dem eingerichteten Zustand der XU auf.
  • Die Datenübertragung mit dem IP-Block 104 kann auf die vorstehend im Zusammenhang mit 2 beschriebene Weise über den Netzwerkschnittstellen-Controller 108 gesteuert werden, der mit dem NoC 102 verbunden ist. Eine auf Adressen beruhende Datenübertragung, z. B. zum Zugriff auf den L2-Cachespeicher, kann zusammen mit auf Mitteilungen beruhenden Datenübertragungen bereitgestellt werden. So kann beispielsweise jeder IP-Block 104 einen eigens zugeordneten Posteingang und/oder Postausgang aufweisen, um eine zwischen Knoten stattfindende Datenübertragung zwischen IP-Blöcken zu bearbeiten.
  • Ausführungsformen der vorliegenden Erfindung können innerhalb der vorstehend im Zusammenhang mit den 1 bis 4 beschriebenen Hardware- und Software-Umgebung implementiert werden. Den Fachleuten wird jedoch unter Nutzung des Vorteils der vorliegenden Offenlegung ersichtlich sein, dass die Erfindung in einer Vielzahl von unterschiedlichen Umgebungen implementiert sein kann und dass auch andere Modifizierungen an der vorstehenden Hardware- und Software-Umgebung vorgenommen werden können, ohne vom Umfang der Erfindung abzuweichen. Als Solches ist die Erfindung nicht auf die bestimmte hierin offenbarte Hardware- und Software-Umgebung begrenzt.
  • Virtualisierungs-Support zur differenzierten Steuerung einer Sprungvorhersage-Logik
  • Es ist wichtig, Sprungvorhersagelogik-Daten aufzubewahren und/oder sicherzustellen, weil Daten wie beispielsweise Daten der Sprung-Historie-Tabelle genaue Sprungvorhersage-Ergebnisse liefern können, so dass Ausführungsformen gemäß der Erfindung Guest-Modus- und/oder Benutzermodus-Mechanismen zum Aktivieren und Deaktivieren von Sprungvorhersage-Logikoperation, die zusammen mit Hypervisormodus-Mechanismen arbeiten, bereitstellen können.
  • Viele Mikroarchitekturen von Mikroprozessoren weisen Hardware-Sprungvorhersage-Algorithmen auf, die ganz oder teilweise von einer oder mehreren Sprung-Historie-Tabellen implementiert sind. Richtige Vorhersagen von Sprungergebnissen („taken” oder „not taken”) können die Gesamtleistung der CPU erheblich steigern, insbesondere in einem, „Out-of-Order”-Mikroprozessor. Dementsprechend ist es wichtig sicherzustellen, dass der Inhalt der Sprung-Historie-Tabelle sowie andere Sprungvorhersage-Daten genau und repräsentativ für zukünftige Code-Ströme sind.
  • Ausführungsformen gemäß der Erfindung erweitern jegliche Mechanismen für Hypervisor-Codes zum Steuern der Funktion der Sprungvorhersage-Logik, z. B. durch Hypervisoren zugängliche Steuerregister, die beispielsweise eine Sprungvorhersage-Logik wie zum Beispiel Sprung-Historie-Tabellen global aktivieren und deaktivieren. Insbesondere ist es möglich, dass Guest-Modus-Mechanismen für ein von einem Hypervisor gehostetes Guest-Betriebssystem und optional dazu Benutzermodus-Anwendungen und -Prozesse die Sprungvorhersage-Logik steuern, da diese zu den eigenen Code-Strömen des Guest-Betriebssystems gehören, und ein Hypervisor dabei eine globale Sprungvorhersage-Logikoperation einrichten kann.
  • In den nachstehend beschriebenen Ausführungsformen können mehrere Funktionen unterstützt werden, unter anderem beispielsweise Benutzermodus- und/oder Guest-Modus-Anweisungen zum Aktivieren/Deaktivieren von Sprungvorhersage-Logikaktualisierungen, z. B. Aktualisierungen von Sprung-Historie-Tabellen; Hypervisor-Modus- und/oder Guest-Modus-Anweisungen zum Aktivieren/Deaktivieren von Aktualisierungen einer Sprungvorhersage-Logik, z. B. Aktualisierungen von Sprung-Historie-Tabellen, auf der Grundlage von einem Prozess-Identifizierungselement; Aktivierung/Deaktivierung durch einen Hypervisor von Guest-Modus- und/oder Benutzer-Modus-Anweisungen zum Beschränken des Guest-Betriebssystems und/oder der Benutzeranwendungen im Steuern der Sprung-Historie-Tabellen in Umständen, unter denen solch eine Steuerung aufgeschoben werden sollte; und neben anderen Leistungsmerkmalen Zurücksetzen von Benutzer-Modus-Steuerungen über Hypervisor-Modus.
  • Es ist gleichermaßen wichtig, Sprungvorhersagelogik-Daten aufzubewahren und/oder sicherzustellen, weil Daten wie beispielsweise Daten der Sprung-Historie-Tabelle genaue Sprungvorhersage-Ergebnisse liefern können, und es ist in einigen Ausführungsformen auch wünschenswert, einen differenzierteren Mechanismus zum Speichern und Wiederherstellen des Zustandes der Sprungvorhersage-Logik zu gewährleisten.
  • Normalerweise handelt es sich bei der Sprungvorhersage-Logik, z. B. einer Sprung-Historie-Tabelle, um eine von allen Hardware-Threads und Software-Prozessen gemeinsam genutzte Ressource, die auf diesen Hardware-Threads innerhalb eines gegebenen Verarbeitungskerns ausgeführt werden. Dies kann dann zu einem Problem führen, wenn die Papierkörbe für Zustände der Sprung-Historie-Tabelle als Software-Prozesse unterschiedliche Code-Sätze ausführen. Herkömmliche Hardware-Implementierungen nutzen Hashing-Algorithmen, verschiedene Größen von Sprung-Historie-Tabellen und andere Techniken zum Verringern der Auswirkungen des gemeinsamen Nutzens zwischen Prozessen; dennoch erhöhen viele dieser Techniken unerwünscht die Größe und Komplexität der Sprungvorhersage-Logik.
  • Im Gegensatz dazu können Ausführungsformen gemäß der Erfindung eine differenzierte Steuerung des Speicherns und Wiederherstellens von Zuständen der Sprungvorhersage-Logik bereitstellen, wodurch die Vorbereitungszeit für die Logik zum Erfassen von Historie-Daten verringert werden kann, und die Sprungvorhersage-Genauigkeit für die verschiedenen in dem System ausgeführten Software-Typen somit verbessert wird. Es ist somit möglich, dass die Software durch Umschalten des Kontexts mit einer vorbereiteten („warmed up”) Sprung-Historie-Tabelle (BHT) ausgeführt werden kann, die spezifisch für diesen Prozess ist. Wenn darüber hinaus Zustandsdaten nicht verworfen, sondern gespeichert und für viele Prozesse gesammelt werden, ist es möglich, die Größe und Komplexität von Sprungvorhersage-Logik zu verringern.
  • Wie dies im weiteren Verlauf ausführlicher beschrieben wird, stellen Ausführungsformen gemäß der Erfindung Anweisungen bereit, beispielsweise Speichern und Wiederherstellen von Zustandsdaten der Sprung-Historie-Tabelle, darunter Hypervisor-Modus-Anweisungen zum Speichern/Wiederherstellen des Zustands der Sprungvorhersage-Logik auf/von dem Speicher oder anderen Speichermedien; Guest-Modus- und/oder Benutzermodus-Anweisungen zum Speichern/Wiederherstellen von Zuständen der Sprungvorhersage-Logik auf/von dem Speicher; Aktivieren/Deaktivieren über einen Hypervisor-Modus von Guest-Modus- und/oder Benutzermodus-Anweisungen zum Speichern/Wiederherstellen; und Zurücksetzen von Zuständen der Sprungvorhersage-Logik über den Hypervisor-Modus.
  • In Bezug auf 5 wird in dieser Figur eine beispielhafte Hardware- und Software-Umgebung für ein Datenverarbeitungssystem 200 veranschaulicht, in dem Virtualisierungs-Support für eine differenzierte Steuerung einer Sprungvorhersage-Logik gemäß der Erfindung implementiert werden kann. Im Hinblick auf die Hardware 202 weist das Datenverarbeitungssystem 200 eine Vielzahl von Prozessoren oder Verarbeitungseinheiten 204 auf, wobei jede einen oder mehrere Hardware-Threads aufweist, die von der Sprungvorhersage-Logik 208 unterstützt werden und ein oder mehrere Spezialregister (SPRs, special purpose registers) 210, einen Speicher 214 und eine E/A-Ebene 214 aufweist, die das Datenverarbeitungssystem 200 mit verschiedenen Hardware-Ressourcen z. B. externen Netzwerken, Speichereinheiten und Netzwerken usw. verbindet.
  • In dieser beispielhaften Ausführungsform werden sowohl selektives Aktivieren der Sprungvorhersage-Logik als auch Speichern/Wiederherstellen von Zuständen der Sprungvorhersage-Logik unterstützt. In dieser Form können ,wie dies auch im weiteren Verlauf beschrieben wird, ein oder mehrere Steuerregister, die als SPRs implementiert sind, zum Steuern von sowohl dem Aktivierungszustand der Sprungvorhersage-Logik als auch den zu dem Zustand der Sprungvorhersage-Logik gehörigen Speicher-/Wiederherstelloperationen, die zu dem Zustand der Sprungvorhersage-Logik gehören, verwendet werden. Des Weiteren können gespeicherte Zustandsdaten 216 in dem Speicher 212 gespeichert und im Zusammenhang mit Wiederherstelloperationen abgerufen werden. Es ist jedoch ersichtlich, dass einige Datenverarbeitungssysteme gemäß der Erfindung möglicherweise nur selektives Aktivieren der Sprungvorhersage-Logik unterstützen, während andere möglicherweise nur Speichern/Wiederherstellen von Zuständen der Sprungvorhersage-Logik unterstützen, dementsprechend ist die hierin offenbarte Implementierung nicht die ausschließliche Möglichkeit zum Implementieren der Erfindung.
  • Es ist offensichtlich, dass die Verteilung von Hardware-Threads, Sprungvorhersage-Logik und Prozessoren/Verarbeitungseinheiten in verschiedenen Ausführungsformen variieren kann. So können die Prozessoren 204 beispielsweise als Verarbeitungskerne in einem oder mehreren Multi-Core-Prozessorchips implementiert sein, und jeder Prozessor 204 kann eine beliebige Anzahl von Hardware-Threads aufweisen. Des Weiteren kann die Sprungvorhersage-Logik von mehreren Threads gemeinsam genutzt oder für verschiedene Threads repliziert werden. Darüber hinaus kann die Sprungvorhersage-Logik zu einer spezifischen Ausführungseinheit in einem Prozessor oder zu dem Prozessor als Ganzes gehören. In einer Ausführungsform können die Prozessoren 204 beispielsweise als IP-Blöcke implementiert sein, die in einer NoC-Anordnung miteinander verbunden sind, wie dies vorstehend im Zusammenhang mit den 1 bis 4 offenbart wurde. Dementsprechend wird ersichtlich, dass die Erfindung in praktisch jeder beliebigen Hardware-Umgebung verwendet werden kann, in der Sprungvorhersage-Logik in einem Prozessor oder einem Verarbeitungskern verwendet wird und die Erfindung demzufolge nicht auf die bestimmte hierin offenbarte Hardware-Umgebung begrenzt ist.
  • Im Hinblick auf die Software implementiert das Datenverarbeitungssystem eine virtualisierte Umgebung, in der ein Hypervisor 218, oftmals auch als Partitions-Manager oder virtueller Maschinenmanager bezeichnet, ein oder mehrere Guest-Betriebssysteme 220 hostet und eine Schnittstelle zwischen den Guest-Betriebssystemen 220 und der Hardware 202 so bereitstellt, dass die Guest-Betriebssysteme 220 einem Abschnitt der Hardware-Ressourcen (z. B. Hardware-Threads, Verarbeitungskernen, Prozessoren, Speichern, E/A-Funktionen usw.) in dem Datenverarbeitungssystem zugewiesen werden und so, dass die Guest-Betriebssysteme 220 zum Großteil auf gleiche Weise arbeiten, wie sie das in einer nicht virtualisierten Umgebung tun würden. Jedes Guest-Betriebssystem 220 hostet eine oder mehrere Benutzeranwendungen oder -programme 222, die normalerweise in unabhängigen Prozessen arbeiten, um Konflikte zwischen unterschiedlichen Anwendungen zu minimieren.
  • Ausführbare Anweisungen, die zu dem Hypervisor 218, Guest-Betriebssystemen 220 und Benutzeranwendungen 222 gehören, werden jeweils als Hypervisor-Modus-, Guest-Modus und Benutzermodus-Anweisungen bezeichnet, und jeder Prozessor 204 unterstützt wünschenswerterweise diese unterschiedlichen Anweisungsmodi, um die Aktivitäten einer jeden Softwareebene selektiv zu begrenzen und ihre relativen Prioritäten zu steuern. Insbesondere wird dem Hypervisor 218 der höchste Prioritätsmodus gewährt, wobei den Guest-Betriebssystemen 220 und Benutzeranwendungen 222 abnehmende Prioritäten gewährt werden.
  • Zum Implementieren einer selektiven Aktivierung von Sprungvorhersage-Logik unterstützt das Datenverarbeitungssystem 200 sowohl eine Hypervisor-Modus- als auch eine Guest-Modus-Steuerung der Sprungvorhersage-Logik, so dass die Guest-Modus-Steuerungen verwendet werden können, um jegliche Hypervisor-Modus-Steuerungen zu überschreiben. Darüber hinaus können in einigen Ausführungsformen Benutzermodus-Steuerungen zum Überschreiben von beliebigen Guest-Modus- und/oder Hypervisor-Modus-Steuerungen verwendet werden. In einigen Ausführungsformen können solche Steuerungen auf alle Guest-Betriebssysteme und/oder Benutzeranwendungen angewendet werden so dass, wann immer ein Prozessor oder ein Verarbeitungskern irgendwelche Guest-Modus-/Benutzermodus-Anweisungen ausführt, die Guest-Modus-/Benutzermodus-Steuerungen zum Steuern der Sprungvorhersage-Logik verwendet werden, jedoch die Hypervisor-Modus-Steuerungen für Hypervisor-Modus-Anweisungen verwendet werden. Alternativ dazu können Guest-Modus- und/oder Benutzermodus-Steuerungen an spezielle Guest-Betriebssysteme und/oder Benutzeranwendungen gebunden sein, so dass beispielsweise jedem Guest-Betriebssystem und/oder jeder Benutzeranwendung gestattet wird, die Sprungvorhersage-Logik separat von anderen Guest-Betriebssystemen und/oder Benutzeranwendungen zu steuern.
  • Darüber hinaus kann es wünschenswert sein, dass ein Hypervisor- und/oder Guest-Betriebssystem die Steuerungen irgendeiner höheren Softwareebene „sperren” kann, so dass die Fähigkeit eines Guest-Betriebssystems oder einer Benutzeranwendung zum Steuern der Sprungvorhersage-Logik deaktiviert werden kann, entweder innerhalb des gesamten Systems oder beschränkt auf ein bestimmtes Guest-Betriebssystem und/oder bestimmte Benutzeranwendungen.
  • In den veranschaulichten Ausführungsformen wird die Steuerung über das selektive Aktivieren von Sprungvorhersage-Logik über die Steuerung eines Aktivierungszustandes der Sprungvorhersage-Logik implementiert. Wenn der Aktivierungszustand anzeigt, dass die Sprungvorhersage-Logik aktiviert ist, ist die Sprungvorhersage-Logik aktiv und arbeitet auf normale Weise, wenn hingegen der Aktivierungszustand anzeigt, dass die Sprungvorhersage-Logik deaktiviert ist, ist die Sprungvorhersage-Logik im Wesentlichen „abgeschaltet”, so dass die Sprungvorhersage-Logik keinen Versuch unternimmt, das Ergebnis der Sprunganweisungen vorherzusagen und normalerweise keine Historie-Daten auf der Grundlage der überwachten Ausführung einer oder mehrerer Anweisungsströme erfasst, die von einem Prozessor oder Verarbeitungskern ausgeführt werden. So kann beispielsweise die Sprungvorhersage-Logik, die eine Sprung-Historie-Tabelle aufweist, so konfiguriert sein, dass das Speichern in Cachespeichern neuer Einträge in der Sprung-Historie-Tabelle oder das Aktualisieren bestehender Einträge in der Tabelle unterbrochen wird.
  • Der Aktivierungszustand der Sprungvorhersage-Logik kann beispielsweise unter Verwendung eines oder mehrerer auf Hardware beruhenden Steuerregister/s gesteuert werden, auf die durch die Sprungvorhersage-Logik zugegriffen wird, um zu ermitteln, ob die Sprungvorhersage-Logik aktuell aktiv ist. Beispielsweise veranschaulicht 6 ein beispielhaftes Aktivierungsmodus-Steuerregister 230, das ein Hypervisor-Aktivierungsfeld 232, ein Guest-Aktivierungsfeld 234 und ein Benutzer-Aktivierungsfeld 236 aufweist, die jeweils kontrollieren, ob die Sprungvorhersage-Logik aktiv ist, wenn die Hypervisor-Modus-, Guest-Modus- und Benutzermodus-Anweisungen ausgeführt werden. Alle drei Felder 232 bis 236 sind von dem Hypervisor beschreibbar, wohingegen die Felder 234 und 236 von einem Guest-Betriebssystem beschreibbar und Feld 236 von einer Benutzeranwendung beschreibbar sind.
  • Darüber hinaus werden zwei Sperrfelder, ein Guest-Sperrfeld 238 und ein Benutzer-Sperrfeld 240, zum Deaktivieren der Fähigkeit eines Guest-Betriebssystems (für das Feld 238) oder einer Benutzeranwendung (für das Feld 240) zum Schreiben in das entsprechende Feld 234, 236 und dementsprechend zum Steuern der Sprungvorhersage-Logik verwendet. Normalerweise sind die Sperrfelder 238 und 240 von einem Hypervisor beschreibbar, und das Sperrfeld 240 ist von einem Guest-Betriebssystem beschreibbar, obgleich beide Sperrfelder von allen Ebenen lesbar sind, so dass beispielsweise ein Guest-Betriebssystem oder eine Benutzeranwendung überprüfen kann, ob Rechte zur Steuerung der Sprungvorhersage-Logik gewährt wurden, bevor ein Versuch zur Änderung des Aktivierungszustandes der Logik unternommen wurde.
  • In einigen Anwendungen ist es vielleicht wünschenswert, die Gesamtheit oder ein Teil des Zustandes des Steuerregisters 230 im Zusammenhang mit Kontextumschaltungen zu speichern und wiederherzustellen, so dass beispielsweise die Aktivierungszustände, die von den Guest-Betriebssystemen und/oder Benutzeranwendungen eingestellt wurden, nur dann verwendet werden, wenn Anweisungen für diese Guest-Betriebssysteme und/oder Benutzeranwendungen ausgeführt werden, wodurch die Möglichkeit unterstützt wird, jedes Guest-Betriebssystem und/oder jede Benutzeranwendung verfügbar zu haben.
  • Alternativ dazu kann es wie in 7 dargestellt wünschenswert sein, eine Datenstruktur wie eine prozessspezifische Aktivierungszustands-Tabelle 250 zu verwenden, die eine Vielzahl von Einträgen 252 aufweist, die einen Prozess-Kennzeichner 254 an Benutzer-Aktivierungs- und Sperrfelder 256, 258 binden, welche eine prozessspezifische Anpassung der Sprungvorhersage-Logik ermöglichen. Tabelle 250 kann von einem Hypervisor oder einem Guest-Betriebssystem zum Konfigurieren dahingehend verwaltet werden, welche Prozesse und Anwendungen in diesem Prozessen zum Steuern der Sprungvorhersage-Logik in der Lage sind, sowie zum Zulassen oder Beschränken dieser Prozesse von/in dem selektiven Aktivieren und Deaktivieren der Sprungvorhersage-Logik während des Ausführens der jeweiligen Prozesse. Eine ähnliche Datenstruktur kann auch in einigen Ausführungsformen verwendet werden, um eine guestspezifische Steuerung von mehreren Guest-Betriebssystemen bereitzustellen.
  • Darüber hinaus kann, wie vorstehend erwähnt wurde, die Sprungvorhersage-Logik von mehreren Hardware-Threads gemeinsam genutzt werden, die in einem gegebenen Verarbeitungskern ausgeführt werden, und in den in den 6 bis 7 veranschaulichten Ausführungsformen betrifft die Steuerung der Sprungvorhersage-Logik alle Hardware-Threads, die die Sprungvorhersage-Logik in einem gegebenen Verarbeitungskern verwenden. Alternativ dazu kann, wie in 8 veranschaulicht ist, eine threadspezifische Aktivierungszustands-Datenstruktur wie beispielsweise eine Tabelle 260 separate Einträge 262 aufweisen, die zu den unterschiedlichen Threads gehören und separate Hypervisor-, Guest- und Benutzer-Aktivierungsfelder 264, 266, 268 sowie Guest- und Benutzer-Sperrfelder 270, 272 für jeden Hardware-Thread aufweisen, so dass unterschiedliche Aktivierungszustände für unterschiedliche Hardware-Threads eingestellt werden können. Die Sprungvorhersage-Logik kann anschließend so konfiguriert werden, 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 aktuell auf einem gegebenen virtuellen Thread abgebildet wird.
  • Als weitere Alternative können die Aktivierungssteuerungs-Datenstrukturen virtualisiert und in Beziehung zu bestimmten virtuellen Threads gesetzt werden, so dass, wann immer ein bestimmter virtueller Thread von einem gegebenen Hardware-Thread ausgeführt wird, die zu diesem virtuellen Thread gehörenden Aktivierungssteuerungen für diesen virtuellen Thread verwendet werden. So kann beispielsweise ein virtuelles threadspezifisches Steuerregister in ein auf Hardware beruhendes Steuerregister für einen Verarbeitungskern geladen werden, der dem Ausführen eines solchen virtuellen Thread während eines Kontextumschaltens auf diesen virtuellen Thread zugeteilt ist, so dass die Sprungvorhersage-Logik in dem Verarbeitungskern so konfiguriert wird, dass sie in einer von dem virtuellen Thread festgelegten Weise arbeitet.
  • Ungeachtet dessen, wie die Steuerungsdaten des Aktivierungszustandes verwaltet werden, kann die Sprungvorhersage-Logik während des Betriebs eines Datenverarbeitungssystems auf die allgemeine Weise selektiv aktiviert werden, die durch die Sequenz von Operationen 280 von 9 veranschaulicht wird, welche die allgemeine Ausführung eines einzelnen Hardware-Thread in einem Datenverarbeitungssystem veranschaulicht. Es ist ersichtlich, dass andere in dem Datenverarbeitungssystem vorhandene Hardware-Threads auf ähnliche Weise ausgeführt werden können.
  • Auf der Hypervisor-Ebene wird Kontextumschalten periodisch zwischen dem Hypervisor und einem oder mehreren Guest-Betriebssystemen durchgeführt, wie dies in den Blöcken 282 bis 294 veranschaulicht wird. Genauer gesagt, aktiviert oder deaktiviert Block 282 die Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für das Guest-Betriebssystem, das kurz vor dem Ausführen durch den Thread steht. Es ist ersichtlich, dass dieser Aktivierungszustand von dem Guest-Betriebssystem oder von dem Hypervisor bestimmt werden kann, entweder weil das Guest-Betriebssystem vom Einstellen des Aktivierungszustandes gesperrt ist oder weil die Benutzeranwendung einen von dem Hypervisor oder dem Guest-Betriebssystem eingestellten Standardzustand nicht überschrieben hat.
  • Wurde die Sprungvorhersage-Logik selektiv aktiviert oder deaktiviert, wird das Guest-Betriebssystem über einen gewissen Zeitraum betrieben beziehungsweise ausgeführt (Block 284), so dass die Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für das aktuell ausgeführte Guest-Betriebssystem aktiviert oder deaktiviert wird. Die Ausführung dauert entweder bis zu einer präventiven Unterbrechung an, oder, wie dies in Block 286 dargestellt ist, bis das Guest-Betriebssystem sein zugeteiltes Zeitintervall abgeschlossen hat, womit die Steuerung auf Block 288 zum Aktivieren oder Deaktivieren der Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für den Hypervisor übergeht. Anschließend wird der Hypervisor für einen gewissen Zeitraum (Block 290) betrieben beziehungsweise ausgeführt, und in Block 292 wird eine Entscheidung dahingehend getroffen, ob zurückgekehrt oder das letzte Guest-Betriebssystem ausgeführt oder in ein anderes Guest-Betriebssystem gewechselt werden soll. Wird die Entscheidung für einen Wechsel in ein anderes Guest-Betriebssystem getroffen, geht die Steuerung in Block 294 zum Durchführen des Wechsels und anschließend zurück in Block 282 zum Ausführen des neuen Guest-Betriebssystems unter Verwendung des Aktivierungszustandes für das neue Guest-Betriebssystem über. Anderenfalls gibt Block 292 die Steuerung zurück an Block 282, um mit dem Ausführen des aktuellen Guest-Betriebssystems unter Verwendung des Aktivierungszustandes für das aktuelle Guest-Betriebssystem fortzufahren.
  • Auf der Ebene des Guest-Betriebssystems werden Kontextumschaltungen periodisch zwischen dem Guest-Betriebssystem und einer oder mehreren Benutzeranwendungen durchgeführt, wie dies in den Blöcken 296 bis 308 veranschaulicht wird. Genauer gesagt, aktiviert oder deaktiviert Block 296 die Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für die Benutzeranwendung, die kurz vor dem Ausführen durch den Thread steht. Es ist ersichtlich, dass dieser Aktivierungszustand von der Benutzeranwendung oder von dem Hypervisor oder Guest-Betriebssystem ermittelt werden kann, entweder weil die Benutzeranwendung vom Einstellen des Aktivierungszustandes gesperrt ist oder weil die Benutzeranwendung einen von dem Hypervisor oder dem Guest-Betriebssystem eingestellten Standardzustand nicht überschrieben hat.
  • Wurde die Sprungvorhersage-Logik selektiv aktiviert oder deaktiviert, wird die Benutzeranwendung über einen gewissen Zeitraum betrieben beziehungsweise ausgeführt (Block 298), so dass die Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für die aktuell ausgeführte Benutzeranwendung aktiviert oder deaktiviert wird. Die Ausführung dauert entweder bis zu einer präventiven Unterbrechung an, oder, wie dies in Block 300 dargestellt ist, bis die Benutzeranwendung ihr zugeteiltes Zeitintervall abgeschlossen hat, womit die Steuerung auf Block 302 zum Aktivieren oder Deaktivieren der Sprungvorhersage-Logik auf der Grundlage des Aktivierungszustandes für das Guest-Betriebssystem übergeht. Anschließend wird das Guest-Betriebssystem für einen gewissen Zeitraum (Block 304) betrieben beziehungsweise ausgeführt, und in Block 306 wird eine Entscheidung dahingehend getroffen, ob zum Ausführen der letzten Benutzeranwendung zurückgekehrt oder in eine andere Benutzeranwendung gewechselt werden soll. Wird die Entscheidung für einen Wechsel in eine andere Benutzeranwendung getroffen, geht die Steuerung in Block 308 zum Durchführen des Wechsels und anschließend zurück in Block 296 zum Ausführen der neuen Benutzeranwendung unter Verwendung des Aktivierungszustandes für die neue Benutzeranwendung über. Anderenfalls gibt Block 306 die Steuerung zurück an Block 296, um mit dem Ausführen der aktuellen Benutzeranwendung unter Verwendung des Aktivierungszustandes für die aktuelle Benutzeranwendung fortzufahren.
  • Wenn ein Anwendungsentwickler erkennt, dass bestimmte Abschnitte einer sich in Entwicklung befindenden Anwendung oder die gesamte Anwendung zu einem Beeinträchtigen der Funktion der Sprungvorhersage-Logik mit nutzlosen Historie-Daten z. B. aufgrund der zufälligen und nicht vorhersagbaren Natur der Verarbeitungsprozesse (workload) tendiert, kann der Entwickler in einer Ausführungsform dementsprechend die Anwendung so konfigurieren, dass sie die Sprungvorhersage-Logik selektiv für die Anwendung oder für irgendwelche problematischen Abschnitte davon deaktiviert und ein Beeinträchtigen der Funktion der Sprungvorhersage-Logik verhindert, was zu einer verbesserten Sprungvorhersage-Logik für die anderen Abschnitte der Anwendung sowie jeglichen anderen Programme führt, die möglicherweise die Sprungvorhersage-Logik verwenden. Auf gleiche Weise können, wenn ein Guest-Betriebssystem bestimmte Anwendungen oder Typen von Anwendungen bemerkt, die nicht gut mit der aktivierten Sprungvorhersage-Logik funktionieren, oder wenn ein Hypervisor bestimmte Anwendungen oder Guest-Betriebssystem bemerkt, die mit der Sprungvorhersage-Logik nicht gut funktionieren, das Guest-Betriebssystem und/oder der Hypervisor die Sprungvorhersage-Logik selektiv deaktivieren, wenn diese inkompatiblen Programme ausgeführt werden.
  • Als Nächstes wird in den veranschaulichten Ausführungsformen Steuerung des Speicherns und Wiederherstellens des Zustandes der Sprungvorhersage-Logik durch Verwendung von Hypervisor-Modus- sowie Guest-Modus und/oder Benutzermodus-Anweisungen implementiert, z. B. über Anweisungen zwischen adressierbaren Registern in der Sprungvorhersage-Logik oder einem oder mehreren von der Sprungvorhersage-Logik bereitgestellten Anschlüssen und einem Speicher oder anderem Puffer, der in Cachespeichern gespeicherte Zustandsdaten speichern kann. So kann in einigen Ausführungsformen beispielsweise Software eine Speicheradresse in einem SPR bereitstellen und anschließend ein Kick-Off-Bit (erstes Bit) schreiben (z. B. ein Bit für Speichern, ein Bit für Wiederherstellen), um eine Mikrocode-Einheit oder einen Hardware-Assist-Sequencer in Bezug auf Speichern/Wiederherstellen der Daten auf/von der bereitgestellten Speicheradresse zu benachrichtigen. In einigen Ausführungsformen können dieselben SPRs, die die Adresse und Kick-Off-Bits halten, durch den vorstehend beschriebenen Hypervisor/Guest/Benutzer-Mechanismus zum Einstellen des Aktivierungszustandes geschützt werden. Darüber hinaus können, wenn kein Hardware-Assist-Sequencer verwendet wird, Software-Anweisungen Speicher- und Wiederherstelloperationen durch Durchlaufen von Schleifen (Looping) zwischen Anweisungen durchführen, die eine Speicheradresse einstellen, ein Kick-Off-Bit schreiben und die Adresse so lange erhöhen, bis alle Daten übertragen worden sind.
  • In einigen Ausführungsformen kann, wie dies z. B. in 10 veranschaulicht wird, ein Speichermodus-Steuerregister 310, aufweisend das Sperrfelder 312, 314 für Guest-Modus- und Benutzermodus-Anweisungen, zum selektiven Aktivieren von Guest-Betriebssystemen und/oder Benutzeranwendungen oder -prozessen zum Speichern und/oder Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik verwendet werden. Wie bei der Funktionalität zum Aktivieren/Deaktivieren kann in einigen Ausführungsformen gemäß der Erfindung das Aktivieren der Funktionalität zum Speichern/Wiederherstellen auf alle Guest-Betriebssystem- und/oder Benutzeranwendungen angewendet werden oder es gilt speziell für ein bestimmtes Guest-Betriebssystem, bestimmte Benutzeranwendungen und/oder einen bestimmten Benutzerprozess.
  • Darüber hinaus kann, wie vorstehend erwähnt wurde, das Implementieren von Speicher- und Wiederherstell-Operationen vorwiegend in Software z. B. über Verschiebeanweisungs-Schleifen (loops of move instructions) implementiert sein, oder alternativ dazu kann sie auf eine zugeordnete Logik in oder auf andere Weise verbunden mit der Sprungvorhersage-Logik zum Beschleunigen der Speicher- und Wiederherstelloperationen zurückgreifen. 11 veranschaulicht zum Beispiel eine beispielhafte Sprung-Historie-Tabelle 320, aufweisend eine Vielzahl von Einträgen 322 und verbunden mit einer Lade- und Speichereinheit 324 für eine Sprung-Historie-Tabelle 324. Die Lade/Speichereinheit 324 kann beispielsweise zum Kopieren einer oder mehrerer Einträge 322 als Zustandsdaten 326 von der Sprung-Historie-Tabelle 320 in einen Speicher 328 sowie zum Wiederherstellen der Sprung-Historie-Tabelle 320 durch Kopieren von Einträgen in Zustandsdaten 326 zurück in die Sprung-Historie-Tabelle 320 verwendet werden.
  • In dem Speicher 328 können beispielsweise auf der Grundlage von unterschiedlichen Benutzeranwendungen, unterschiedlichen Guest-Betriebssystemen usw. mehrere Kopien von Zustandsdaten 326 verwaltet werden. Bei dem Speicher 328 kann es sich um einen Teil einer Hauptspeicherarchitektur eines Datenverarbeitungssystems oder in einigen Implementierungen um einen zugeordneter Puffer, z. B. einen zugeordneten Puffer in einem Verarbeitungskern, handeln. Die Lade/Speichereinheit 324 kann beispielsweise als Sequencer oder Mikrocode-Einheit implementiert sein, die auf von einem Thread bereitgestellte Eingabedaten reagiert, um eine Übertragung ausgewählter Daten zwischen der Sprung-Historie-Tabelle 320 und dem Speicher 328 zu initiieren.
  • In einigen Implementierungen können die gesamte Sprung-Historie-Tabelle und optional weiterhin andere Zustandsdaten für die Sprungvorhersage-Logik als Zustandsdaten gespeichert/wiederhergestellt werden. In einigen Ausführungsformen kann es jedoch auch wünschenswert sein, lediglich eine Teilmenge der Daten zu speichern/wiederherzustellen, die den Zustand der Sprungvorhersage-Logik darstellen, und z. B. Einträge 322 zu überspringen, die als ungültig markiert sind, oder nur die N am meisten benutzten oder zuletzt benutzten Einträge zu speichern. Darüber hinaus kann es in einigen Ausführungsformen wünschenswert sein, die Zustandsdaten in einem Speicher 328 zu komprimieren, um die Menge an Speicherplatz, der zum Verwalten der Zustandsdaten erforderlich ist, zu verringern und anschließend die komprimierten Daten zu dekomprimieren, wenn diese zurück in der Sprungvorhersage-Logik wiederhergestellt werden, wie durch die Komprimierungs/Dekomprimierungs-Maschine 330 in der Lade/Speichereinheit 324 veranschaulicht wird. Alternativ dazu können andere auf Hardware beruhende Methoden zum Beschleunigen oder anderweitigen Verringern der Auswirkung des Speicherns und Wiederherstellens der Zustandsdaten der Sprungvorhersage-Logik auf die Leistung verwendet werden.
  • Ungeachtet der Tatsache, wie die Zustandsdaten der Sprungvorhersage-Logik gespeichert und wiederhergestellt werden, veranschaulicht 12 eine Sequenz von Operationen 340, die zur allgemeinen Ausführung eines einzelnen Hardware-Threads in einem Datenverarbeitungssystem im Zusammenhang mit Speichern und Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik geeignet sind. Es ist ersichtlich, dass auch andere Hardware-Threads auf ähnliche Weise in einem Datenverarbeitungssystem verwendet werden können.
  • Auf der Hypervisor-Ebene schaltet die Ausführung periodisch zwischen dem Hypervisor und einem oder mehreren Guest-Betriebssystemen um, wie in den Blöcken 342 bis 360 dargestellt ist. Genauer gesagt, stellt Block 342 z. B. in Reaktion auf eine Guest-Modus-Anweisung in dem Guest-Betriebssystem gespeicherte Zustandsdaten der Sprungvorhersage-Logik für das Guest-Betriebssystem wieder her. Wurde der Zustand der Sprungvorhersage-Logik wiederhergestellt, wird das Guest-Betriebssystem über einen Zeitraum betrieben beziehungsweise ausgeführt (Block 346), so dass die Sprungvorhersage-Logik die wiederhergestellten Daten solange verwendet, wie das Guest-Betriebssystem ausgeführt wird. Die Ausführung dauert so lange an, bis entweder eine präventive Unterbrechung auftritt, oder, wie dies in Block 348 dargestellt ist, bis das Guest-Betriebssystem sein zugeteiltes Zeitintervall abgeschlossen hat, womit die Steuerung auf Block 350 zum Speichern des Zustands der Sprungvorhersage-Logik, z. B. in Reaktion auf eine Guest-Modus-Anweisung in dem Guest-Betriebssystem übergeht. Als Nächstes stellt Block 352, z. B. in Reaktion auf eine Hypervisor-Modus-Anweisung in dem Hypervisor den gespeicherten Zustand der Sprungvorhersage-Logik für den Hypervisor wieder her. Anschließend wird der Hypervisor über einen gewissen Zeitraum betrieben beziehungsweise ausgeführt (Block 354), und anschließend speichert Block 356 den Zustand der Sprungvorhersage-Logik, z. B. in Reaktion auf eine Hypervisor-Modus-Anweisung in dem Hypervisor. Als Nächstes wird in Block 358 eine Entscheidung dahingehend getroffen, ob zum Ausführen des Guest-Betriebssystems zurückgekehrt oder in ein anderes Guest-Betriebssystem gewechselt werden soll. Wird eine Entscheidung für den Wechsel in ein anderes Guest-Betriebssystem getroffen, geht die Steuerung auf Block 360 zum Durchführen des Wechsels und anschließend zurück zu Block 342 zum Wiederherstellen des Zustandes der Sprungvorhersage-Logik für das Guest-Betriebssystem über. Anderenfalls gibt Block 358 die Steuerung an Block 342 zum Wiederherstellen des Zustands der Sprungvorhersage-Logik für das Guest-Betriebssystem zurück.
  • Auf der Ebene des Guest-Betriebssystems werden Kontextumschaltungen periodisch zwischen dem Guest-Betriebssystem und einer oder mehreren Benutzeranwendungen durchgeführt, wie dies in den Blöcken 362 bis 380 veranschaulicht wird. Genauer gesagt, stellt Block 362 z. B. in Reaktion auf eine Benutzermodus-Anweisung in der Benutzeranwendung gespeicherte Zustandsdaten der Sprungvorhersage-Logik für die Benutzeranwendung wieder her. Wurde der Zustand der Sprungvorhersage-Logik wiederhergestellt, wird die Benutzeranwendung über einen gewissen Zeitraum betrieben beziehungsweise ausgeführt (Block 364), so dass die Sprungvorhersage-Logik den wiederhergestellten Zustand verwendet, während die Benutzeranwendung ausgeführt wird. Die Ausführung dauert entweder bis zu einer präventiven Unterbrechung an, oder, wie dies in Block 368 dargestellt ist, bis die Benutzeranwendung ihr zugeteiltes Zeitintervall abgeschlossen hat, womit die Steuerung auf Block 370 zum Speichern des Zustands der Sprungvorhersage-Logik z. B. in Reaktion auf eine Benutzermodus-Anweisung in der Benutzeranwendung übergeht. Als Nächstes stellt Block 372 z. B. in Reaktion auf eine Guest-Modus-Anweisung in dem Guest-Betriebssystem den gespeicherten Zustand der Sprungvorhersage-Logik für das Guest-Betriebssystem wieder her. Anschließend wird das Guest-Betriebssystem für einen gewissen Zeitraum betrieben beziehungsweise ausgeführt (Block 374), und anschließend speichert Block 376 den Zustand der Sprungvorhersage-Logik, z. B. in Reaktion auf eine Guest-Modus-Anweisung in dem Guest-Betriebssystem. Als Nächstes wird in Block 378 eine Entscheidung dahingehend getroffen, ob zur Ausführung der letzten Benutzeranwendung zurückgekehrt oder in eine andere Benutzeranwendung gewechselt werden soll. Wird die Entscheidung für einen Wechsel in eine andere Benutzeranwendung getroffen, geht die Steuerung in Block 380 zum Durchführen des Wechsels und anschließend zurück zu Block 362 zum Wiederherstellen des Zustandes der Sprungvorhersage-Logik für die Benutzeranwendung über. Anderenfalls gibt Block 378 die Steuerung zurück an Block 362 zum Wiederherstellen des Zustandes der Sprungvorhersage-Logik für die Benutzeranwendung.
  • Es ist ersichtlich, dass die Anweisungen zum Speichern und/oder Wiederherstellen der Zustandsdaten der Sprungvorhersage-Logik innerhalb von Kontextumschaltungen implementiert werden können, die zum Speichern oder Wiederherstellen anderer Zustandsdaten ausgeführt werden, die zu einem gegebenen, durch einen Hardware-Thread ausgeführten Kontext gehören. Es ist des Weiteren ersichtlich, dass der Hypervisor, ausgewählte Guest-Betriebssysteme und/oder ausgewählte Benutzeranwendungen möglicherweise keinen Bedarf am Speichern oder Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik haben, so dass diese ausgewählten Einheiten die Ausführung irgendwelcher Anweisungen während des Kontextumschaltens entweder zum Speichern oder Wiederherstellen von Daten der Sprungvorhersage-Logik für solche Einheiten weglassen können.
  • Die 13 bis 14 veranschaulichen auf ausführlichere Weise die Operationen, die im Zusammenhang mit Speichern und Wiederherstellen der Sprungvorhersage-Zustandstabelle, z. B. Einträgen der Sprung-Historie-Tabelle erfolgen. 13 veranschaulicht beispielsweise eine Routine zum Speichern in der Sprung-Historie-Tabelle 390, die von einem Programm, z. B. einem Hypervisor, einem Guest-Betriebssystem und/oder einer Benutzeranwendung zum Speichern von Zustandsdaten der Sprungvorhersage-Logik ausgeführt wird. Block 392 ermittelt beispielsweise zuerst, ob dem Programm ein Speichern des Zustandes der Sprungvorhersage-Logik gestattet ist, z. B. durch Prüfen eines zugehörigen Sperrfeldes für das Programm. In einigen Fällen, z. B. für einen Hypervisor, kann das Programm immer zum Speichern des Zustandes der Sprungvorhersage-Logik berechtigt sein, also kann Block 392 weggelassen werden. Wird durch Block 392 keine Erlaubnis erteilt, wird die Routine 390 beendet. Anderenfalls übergibt Block 392 die Steuerung an Block 394 zum Speichern des Zustandes der Sprungvorhersage-Logik, womit die Routine 390 abgeschlossen ist.
  • Auf ähnliche Weise veranschaulicht 14 eine Routine zum Wiederherstellen einer Sprung-Historie-Tabelle 400, die von einem Programm, z. B. einem Hypervisor, einem Guest-Betriebssystem und/oder einer Benutzeranwendung zum Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik ausgeführt wird. Block 402 ermittelt beispielsweise zunächst, ob das Programm den Zustand der Sprungvorhersage-Logik wiederherstellen darf, z. B. durch Prüfen eines zugehörigen Sperrfeldes für das Programm. In einigen Fällen, z. B. für einen Hypervisor, kann das Programm immer zum Wiederherstellen des Zustandes der Sprungvorhersage-Logik berechtigt sein, also kann Block 402 weggelassen werden. Wird durch Block 402 keine Erlaubnis erteilt, wird die Routine 390 beendet. Anderenfalls gibt Block 402 die Steuerung an Block 404 zum Zurücksetzen des Zustandes der Sprungvorhersage-Logik z. B. durch Löschen aller alten Einträge der Sprung-Historie-Tabelle und anschließend an Block 406 zum Wiederherstellen des Zustandes der Sprungvorhersage-Logik weiter. Anschließend ist Routine 400 abgeschlossen.
  • Dementsprechend ermöglichen Ausführungsformen gemäß der Erfindung eine differenzierte Steuerung der Sprungvorhersage-Logik durch selektives Aktivieren/Deaktivieren und/oder selektives Speichern und Wiederherstellen von Zustandsdaten der Sprungvorhersage-Logik. Es besteht die Annahme, dass in vielen Ausführungsformen die Bereitstellung einer differenzierteren Steuerung die Sprungvorhersage-Logik für unterschiedliche Typen von Programmen und Verarbeitungsprozessen verbessern und so in einigen Fällen die Verwendung einer kleineren und weniger komplexen Sprungvorhersage-Logik ermöglichen kann, wodurch Kosten gespart werden und die Größe des von der Sprungvorhersage-Logik auf einem Prozessorchip eingenommenem Speicherplatzes verringert wird.
  • An den offenbarten Ausführungsformen können verschiedene Modifizierungen vorgenommen werden, ohne vom Geist und Umfang der Erfindung abzuweichen. In diesem Sinne wird die Erfindung durch die hieran angehängten Ansprüche definiert.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Nicht-Patentliteratur
    • IEEE 802.3 [0043]

Claims (15)

  1. Verfahren zum Steuern einer Sprungvorhersage-Logik in einem Datenverarbeitungssystem, wobei das Verfahren aufweist: Speichern eines ersten Zustandes der Sprungvorhersage-Logik in dem Verarbeitungskern in Reaktion auf eine erste, Hypervisor-Modus-Anweisung, die von dem Verarbeitungskern für einen in dem Datenverarbeitungssystem befindlichen Hypervisor ausgeführt wird; Wiederherstellen des ersten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine zweite, Hypervisor-Modus-Anweisung, die von dem Verarbeitungskern für den Hypervisor ausgeführt wird; Speichern eines zweiten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine dritte Anweisung, die von dem Verarbeitungskern für ein von dem Hypervisor gehostetes Programm ausgeführt wird; und Wiederherstellen des zweiten Zustandes der Sprungvorhersage-Logik in Reaktion auf eine vierte Anweisung, die von dem Verarbeitungskern ausgeführt und von dem Hypervisor gehostet wird.
  2. Verfahren nach Anspruch 1, wobei die Sprungvorhersage-Logik so konfiguriert ist, dass sie Sprungvorhersage-Daten in einer Sprungvorhersage-Tabelle zwischenspeichert, wobei Speichern des ersten Zustandes der Sprungvorhersage-Logik Speichern wenigstens eines Eintrages in der Sprungvorhersage-Tabelle aufweist und wobei das Wiederherstellen des ersten Zustandes der Sprungvorhersage-Logik ein Speichern wenigstens eines Eintrages in der Sprungvorhersage-Tabelle aufweist.
  3. Verfahren nach Anspruch 2, wobei das Speichern des ersten Zustandes Speichern von lediglich einer Teilmenge der Einträge in der Sprungvorhersage-Tabelle auf der Grundlage einer Verwendungshäufigkeit aufweist.
  4. Verfahren nach Anspruch 2, wobei das Speichern des ersten Zustandes ein Speichern von lediglich gültigen Einträgen in der Sprungvorhersage-Tabelle aufweist.
  5. Verfahren nach Anspruch 1, wobei das Speichern des ersten Zustandes ein Komprimieren von zu dem ersten Zustand gehörenden Daten und ein Speichern der komprimierten Daten in einem Speicher aufweist, und wobei das Wiederherstellen des ersten Zustandes ein Dekomprimieren der komprimierten Daten in dem Speicher aufweist.
  6. Verfahren nach Anspruch 1, wobei das Speichern des ersten Zustandes ein Veranlassen einer Hardware-Logik in dem Verarbeitungskern zum Speichern des ersten Zustandes aufweist, wobei optional die Hardware-Logik eine Mikrocode-Logik aufweist.
  7. Verfahren nach Anspruch 1, wobei das Speichern des ersten Zustandes der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten weg von dem Hypervisor durchgeführt wird, und wobei das Wiederherstellen des ersten Zustandes der Sprungvorhersage im Zusammenhang mit einem Kontextumschalten hin zu dem Hypervisor durchgeführt wird.
  8. Verfahren nach Anspruch 1, wobei das Speichern des zweiten Zustandes der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten weg von dem Programm durchgeführt wird, und wobei das Wiederherstellen des zweiten Zustandes der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten hin zu dem Programm durchgeführt wird.
  9. Verfahren nach Anspruch 1, wobei das Programm ein von dem Hypervisor gehostetes Guest-Betriebssystem aufweist, wobei es sich bei den dritten und vierten Anweisungen um Guest-Modus-Anweisungen handelt.
  10. Verfahren nach Anspruch 1, wobei das Programm einen von dem Hypervisor gehosteten Benutzerprozess aufweist, wobei es sich bei den dritten und vierten Anweisungen um Benutzermodus-Anweisungen handelt und/oder wobei der Benutzerprozess von einem Guest-Betriebssystem gehostet wird, das von dem Hypervisor gehostet wird, und/oder das Verfahren des Weiteren ein Zurücksetzen eines Zustandes der Sprungvorhersage-Logik in Reaktion auf eine fünfte Hypervisor-Modus-Anweisung aufweist, die von dem Verarbeitungskern für den Hypervisor durchgeführt wird, und/oder das Verfahren des Weiteren, mit dem Hypervisor, ein selektives Deaktivieren des Programms im Hinblick auf ein Speichern oder ein Wiederherstellen eines Zustandes der Sprungvorhersage-Logik aufweist.
  11. Schaltungsanordnung, aufweisend: einen Verarbeitungskern; und eine in dem Verarbeitungskern angeordnete Sprungvorhersage-Logik; wobei der Verarbeitungskern so konfiguriert ist, dass er einen ersten Zustand der Sprungvorhersage-Logik in Reaktion eine erste, Hypervisor-Modus-Anweisung speichert, die von dem Verarbeitungskern für einen in dem Datenverarbeitungssystem befindlichen Hypervisor ausgeführt wird, den ersten Zustand der Sprungvorhersage-Logik in Reaktion auf eine zweite, Hypervisor-Modus-Anweisung wiederherstellt, die von dem Verarbeitungskern für den Hypervisor ausgeführt wird, einen zweiten Zustand der Sprungvorhersage-Logik in Reaktion auf eine dritte Anweisung speichert, die von dem Verarbeitungskern für ein von dem Hypervisor gehostetes Programm ausgeführt wird, und den zweiten Zustand der Sprungvorhersage-Logik in Reaktion auf eine vierte Anweisung wiederherstellt, die von dem Verarbeitungskern ausgeführt und von dem Hypervisor gehostet wird.
  12. Schaltungsanordnung nach Anspruch 11, wobei die Sprungvorhersage-Logik so konfiguriert ist, dass sie Sprungvorhersage-Daten in einer Sprungvorhersage-Tabelle speichert, wobei der Verarbeitungskern so konfiguriert ist, dass er den ersten Zustand der Sprungvorhersage-Logik durch Speichern wenigstens eines Eintrages in der Sprungvorhersage-Tabelle speichert, und wobei der Verarbeitungskern so konfiguriert ist, dass er den ersten Zustand der Sprungvorhersage-Logik durch Speichern des wenigstens einen Eintrages in der Sprungvorhersage-Tabelle wiederherstellt, und/oder wobei der Verarbeitungskern so konfiguriert ist, dass er den ersten Zustand der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten weg von dem Hypervisor speichert und den ersten Zustand der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten hin zu dem Hypervisor wiederherstellt und/oder wobei der Verarbeitungskern so konfiguriert ist, dass er den zweiten Zustand der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten weg von dem Programm speichert und den zweiten Zustand der Sprungvorhersage-Logik im Zusammenhang mit einem Kontextumschalten hin zu dem Programm wiederherstellt und/oder wobei das Programm ein von dem Hypervisor gehostetes Guest-Betriebssystem aufweist, wobei es sich bei den dritten und vierten Anweisungen um Guest-Modus-Anweisungen handelt, und/oder wobei der Verarbeitungskern so konfiguriert ist, dass er einen Zustand der Sprungvorhersage-Logik in Reaktion auf eine fünfte, Hypervisor-Modus-Anweisung zurücksetzt, die von dem Verarbeitungskern für den Hypervisor ausgeführt wird, und/oder wobei der Verarbeitungskern so konfiguriert ist, dass er in Reaktion auf den Hypervisor das Programm selektiv im Hinblick auf ein Speichern oder ein Wiederherstellen eines Zustandes der Sprungvorhersage-Logik deaktiviert.
  13. Schaltungsanordnung nach Anspruch 11, wobei das Programm einen von dem Hypervisor gehosteten Benutzerprozess aufweist, wobei es sich bei den dritten und vierten Anweisungen um Benutzermodus-Anweisungen handelt, und wobei optional der Benutzerprozess von einem Guest-Betriebssystem gehostet wird, das von dem Hypervisor gehostet wird.
  14. Datenverarbeitungssystem, aufweisend die Schaltungsanordnung nach Anspruch 11.
  15. Programmprodukt, aufweisend: ein computerlesbares Medium; und einen auf dem computerlesbaren Medium gespeicherten Programmcode, wobei der Programmcode aufweist: eine erste Hypervisor-Modus-Anweisung, die so konfiguriert ist, dass sie von einem Verarbeitungskern zum Speichern eines ersten Zustandes einer Sprungvorhersage-Logik in dem Verarbeitungskern ausgeführt wird, eine zweite Hypervisor-Modus-Anweisung, die so konfiguriert ist, dass sie von dem Verarbeitungskern zum Wiederherstellen des ersten Zustandes der Sprungvorhersage-Logik ausgeführt wird, eine dritte Anweisung für ein von dem Hypervisor gehostetes Programm und die so konfiguriert ist, dass sie von dem Verarbeitungskern zum Speichern eines zweiten Zustandes der Sprungvorhersage-Logik ausgeführt wird, und eine vierte Anweisung für das von dem Hypervisor gehostete Programm und die so konfiguriert ist, dass sie von dem Verarbeitungskern zum Wiederherstellen des zweiten Zustandes der Sprungvorhersage-Logik ausgeführt wird.
DE102013200503A 2012-01-23 2013-01-15 Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik Ceased DE102013200503A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US13/355,884 2012-01-23
US13/355,884 US8935694B2 (en) 2012-01-23 2012-01-23 System and method for selectively saving and restoring state of branch prediction logic through separate hypervisor-mode and guest-mode and/or user-mode instructions

Publications (1)

Publication Number Publication Date
DE102013200503A1 true DE102013200503A1 (de) 2013-07-25

Family

ID=47748196

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102013200503A Ceased DE102013200503A1 (de) 2012-01-23 2013-01-15 Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik

Country Status (4)

Country Link
US (1) US8935694B2 (de)
CN (1) CN103218209B (de)
DE (1) DE102013200503A1 (de)
GB (1) GB2500456B (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201300608D0 (en) * 2013-01-14 2013-02-27 Imagination Tech Ltd Indirect branch prediction
US9520180B1 (en) 2014-03-11 2016-12-13 Hypres, Inc. System and method for cryogenic hybrid technology computing and memory
US10261826B2 (en) 2014-06-02 2019-04-16 International Business Machines Corporation Suppressing branch prediction updates upon repeated execution of an aborted transaction until forward progress is made
US10235172B2 (en) * 2014-06-02 2019-03-19 International Business Machines Corporation Branch predictor performing distinct non-transaction branch prediction functions and transaction branch prediction functions
US10289414B2 (en) 2014-06-02 2019-05-14 International Business Machines Corporation Suppressing branch prediction on a repeated execution of an aborted transaction
US10503538B2 (en) 2014-06-02 2019-12-10 International Business Machines Corporation Delaying branch prediction updates specified by a suspend branch prediction instruction until after a transaction is completed
US9742630B2 (en) * 2014-09-22 2017-08-22 Netspeed Systems Configurable router for a network on chip (NoC)
US10348563B2 (en) 2015-02-18 2019-07-09 Netspeed Systems, Inc. System-on-chip (SoC) optimization through transformation and generation of a network-on-chip (NoC) topology
US10063569B2 (en) * 2015-03-24 2018-08-28 Intel Corporation Custom protection against side channel attacks
US10218580B2 (en) 2015-06-18 2019-02-26 Netspeed Systems Generating physically aware network-on-chip design from a physical system-on-chip specification
CN105005737A (zh) * 2015-07-31 2015-10-28 天津大学 一种面向分支预测攻击的微体系结构级安全防护方法
US10423418B2 (en) * 2015-11-30 2019-09-24 International Business Machines Corporation Method for maintaining a branch prediction history table
US10013270B2 (en) 2015-12-03 2018-07-03 International Business Machines Corporation Application-level initiation of processor parameter adjustment
US10452124B2 (en) 2016-09-12 2019-10-22 Netspeed Systems, Inc. Systems and methods for facilitating low power on a network-on-chip
US10489296B2 (en) 2016-09-22 2019-11-26 International Business Machines Corporation Quality of cache management in a computer
US20180159786A1 (en) 2016-12-02 2018-06-07 Netspeed Systems, Inc. Interface virtualization and fast path for network on chip
US10063496B2 (en) 2017-01-10 2018-08-28 Netspeed Systems Inc. Buffer sizing of a NoC through machine learning
US10469337B2 (en) 2017-02-01 2019-11-05 Netspeed Systems, Inc. Cost management against requirements for the generation of a NoC
US11144457B2 (en) 2018-02-22 2021-10-12 Netspeed Systems, Inc. Enhanced page locality in network-on-chip (NoC) architectures
US10983910B2 (en) 2018-02-22 2021-04-20 Netspeed Systems, Inc. Bandwidth weighting mechanism based network-on-chip (NoC) configuration
US10547514B2 (en) 2018-02-22 2020-01-28 Netspeed Systems, Inc. Automatic crossbar generation and router connections for network-on-chip (NOC) topology generation
US11023377B2 (en) 2018-02-23 2021-06-01 Netspeed Systems, Inc. Application mapping on hardened network-on-chip (NoC) of field-programmable gate array (FPGA)
US11176302B2 (en) 2018-02-23 2021-11-16 Netspeed Systems, Inc. System on chip (SoC) builder
US10705848B2 (en) * 2018-05-24 2020-07-07 Arm Limited TAGE branch predictor with perceptron predictor as fallback predictor
GB2574042B (en) * 2018-05-24 2020-09-09 Advanced Risc Mach Ltd Branch Prediction Cache
US11256644B2 (en) * 2018-09-05 2022-02-22 Fungible, Inc. Dynamically changing configuration of data processing unit when connected to storage device or computing device
US10740140B2 (en) 2018-11-16 2020-08-11 International Business Machines Corporation Flush-recovery bandwidth in a processor
US11301254B2 (en) * 2019-07-25 2022-04-12 International Business Machines Corporation Instruction streaming using state migration
US11061681B2 (en) * 2019-07-25 2021-07-13 International Business Machines Corporation Instruction streaming using copy select vector
US20220100519A1 (en) * 2020-09-25 2022-03-31 Advanced Micro Devices, Inc. Processor with multiple fetch and decode pipelines
CN113722016A (zh) * 2021-09-10 2021-11-30 拉卡拉支付股份有限公司 应用程序配置方法、装置、设备、存储介质及程序产品

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4679141A (en) 1985-04-29 1987-07-07 International Business Machines Corporation Pageable branch history table
EP0218335A3 (de) 1985-08-30 1989-03-08 Advanced Micro Devices, Inc. Steuerspeicher eines elektronischen Rechners
US5228131A (en) 1988-02-24 1993-07-13 Mitsubishi Denki Kabushiki Kaisha Data processor with selectively enabled and disabled branch prediction operation
US5606715A (en) 1995-06-26 1997-02-25 Motorola Inc. Flexible reset configuration of a data processing system and method therefor
US5949995A (en) 1996-08-02 1999-09-07 Freeman; Jackie Andrew Programmable branch prediction system and method for inserting prediction operation which is independent of execution of program code
DE69727773T2 (de) 1996-12-10 2004-12-30 Texas Instruments Inc., Dallas Verbesserte Verzweigungsvorhersage in einem Pipelinemikroprozessor
US6108775A (en) 1996-12-30 2000-08-22 Texas Instruments Incorporated Dynamically loadable pattern history tables in a multi-task microprocessor
US6108776A (en) 1998-04-30 2000-08-22 International Business Machines Corporation Globally or selectively disabling branch history table operations during sensitive portion of millicode routine in millimode supporting computer
US6223280B1 (en) 1998-07-16 2001-04-24 Advanced Micro Devices, Inc. Method and circuit for preloading prediction circuits in microprocessors
US6574712B1 (en) 1999-11-08 2003-06-03 International Business Machines Corporation Software prefetch system and method for predetermining amount of streamed data
US6877089B2 (en) 2000-12-27 2005-04-05 International Business Machines Corporation Branch prediction apparatus and process for restoring replaced branch history for use in future branch predictions for an executing program
US7493478B2 (en) 2002-12-05 2009-02-17 International Business Machines Corporation Enhanced processor virtualization mechanism via saving and restoring soft processor/system states
WO2004068337A1 (ja) 2003-01-30 2004-08-12 Fujitsu Limited 情報処理装置
CN1755660B (zh) * 2004-09-28 2010-09-29 惠普开发有限公司 冗余处理器中的诊断存储器转储方法
US7308571B2 (en) 2004-10-06 2007-12-11 Intel Corporation Overriding processor configuration settings
US20080114971A1 (en) 2006-11-14 2008-05-15 Fontenot Nathan D Branch history table for debug
US7650785B1 (en) * 2006-11-17 2010-01-26 Vibro-Meter, Inc. Scan lock and track fluid characterization and level sensor apparatus and method
US8171328B2 (en) * 2008-12-31 2012-05-01 Intel Corporation State history storage for synchronizing redundant processors

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE 802.3

Also Published As

Publication number Publication date
US8935694B2 (en) 2015-01-13
GB2500456A (en) 2013-09-25
GB201300405D0 (en) 2013-02-20
US20130191825A1 (en) 2013-07-25
GB2500456B (en) 2014-03-19
CN103218209B (zh) 2016-03-02
CN103218209A (zh) 2013-07-24

Similar Documents

Publication Publication Date Title
DE102013200503A1 (de) Virtualisierungs-Support zum Speichern und Wiederherstellen von Zuständen einer Sprungvorhersage-Logik
DE112013000654T5 (de) Verzweigungsvorhersagelogik
DE112013002069T5 (de) Hohes Leistungsverbindungskohärenz-Protokoll
DE102019104394A1 (de) Befehlssatzarchitektur zum ermöglichen von energieeffizientem rechnen für exascalearchitekturen
DE102013200161A1 (de) Datenverschlüsselung/-Komprimierung auf der Grundlage einer Speicheradressübersetzung
DE112013000381T5 (de) Datenverschlüsselung auf der Grundlage einer Speicheradressumsetzung
DE102010035603A1 (de) Bereitstellen von Hardwareunterstützung für gemeinsam benutzten virtuellen Speicher zwischen physischem Lokal- und Fernspeicher
DE112018004384B4 (de) Schützen von arbeitsspeicherinternen konfigurationsstatusregistern
DE112016007566T5 (de) Systeme, Verfahren und Vorrichtungen zur heterogenen Berechnung
DE112012005058T5 (de) Variablenübertragungsnetzwerk mit geringer Latenzzeit für feingranulierte Parallelität virtueller Threads zwischen mehreren Hardware-Threads
DE112007001171T5 (de) Verfahren für virtualisierten Transaktionsspeicher bei globalem Überlauf
DE102012224265A1 (de) Gemeinsame Nutzung dicht benachbarter Daten-Cachespeicher
DE102015002383A1 (de) Verfahren und Vorrichtung zum Implementieren einer dynamischen Out-of-order-Prozessorpipeline
DE102014003690A1 (de) Prozessoren, Verfahren und Systeme zur Befehlsemulation
DE112012005700T5 (de) Externe Hilfsausführungseinheiten-Schnittstelle zur ausserhalb des Chips angeordneten Hilfsausführungseinheit
DE202019005682U1 (de) Hardwaregestützte Paging-Mechanismen
DE112005000706T5 (de) Verfahren und System zum Bereitstellen von Multi-Threading auf Nutzerebene
DE102018006797A1 (de) Kohärente Speichereinrichtungen über PCIe
DE112012000303T5 (de) Dynamische binäre Optimierung
DE102014003705A1 (de) Prozessoren, Verfahren und Systeme zur Befehlsemulation
DE112018004364B4 (de) Vereinfachung einer verarbeitung in einer datenverarbeitungsumgebung durch gruppierung eines konfigurationsstatusregisters auf grundlage von funktionaler affinität
DE112016007516T5 (de) Vorrichtungen und verfahren für eine prozessorarchitektur
DE112006002582T5 (de) Bewirken einer Zusatzspeicherung in einem User-Levelspeicher
DE112018004388T5 (de) Globale speicher- und ladeoperationen von konfigurationsstatusregistern
DE112017001700T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen zum Abruf von Daten auf der angegebenen Cache-Ebene mit garantiertem Abschluss

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

Representative=s name: DILG HAEUSLER SCHINDELMANN PATENTANWALTSGESELL, DE

R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

Representative=s name: LIFETECH IP SPIES DANNER & PARTNER PATENTANWAE, DE

R016 Response to examination communication
R082 Change of representative

Representative=s name: LIFETECH IP SPIES & BEHRNDT PATENTANWAELTE PAR, DE

R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final