DE102015002383A1

DE102015002383A1 - Verfahren und Vorrichtung zum Implementieren einer dynamischen Out-of-order-Prozessorpipeline

Info

Publication number: DE102015002383A1
Application number: DE102015002383.7A
Authority: DE
Inventors: Denis M. Khartikov; Naveen Neelakantam; Polychronis Xekalakis; John H. Kelm
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2014-03-28
Filing date: 2015-02-25
Publication date: 2015-10-01
Also published as: JP6043374B2; KR20150112774A; US20170300334A1; TW201602906A; JP2015191660A; TWI599949B; GB2524619A; CN104951281B; KR101754462B1; GB2524619B; US20150277916A1; CN104951281A; US9612840B2; JP2017027636A; GB201500942D0; US10338927B2

Abstract

Hardware/Software-Co-Entwurf für eine optimierte dynamische Out-of-order-Pipeline mit Very Long Instruction Words (VLIW-Pipeline). Zum Beispiel umfasst eine Ausführungsform einer Vorrichtung Folgendes: eine Befehlsabrufeinheit zum Abrufen von Very Long Instruction Words (VLIWs) in ihrer Programmreihenfolge aus dem Speicher, wobei jedes der VLIWs mehrere Reduced-Instruction-Set-Computing-Befehlssilben (RISC-Befehlssilben) umfasst, die in den VLIWs in einer Reihenfolge gruppiert sind, die Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben beseitigt; eine Decodiereinheit zum Decodieren der VLIWs in ihrer Programmreihenfolge und zum parallelen Ausgeben der Silben jedes decodierten VLIW; und eine Out-of-order-Ausführungsmaschine zum vorzugsweise parallelen Ausführen der Silben mit anderen Silben, wobei wenigstens einige der Silben in einer anderen Reihenfolge als der Reihenfolge, in der sie von der Decodiereinheit empfangen werden, ausgeführt werden sollen, wobei die Out-of-order-Ausführungsmaschine eine oder mehrere Verarbeitungsstufen aufweist, die, wenn sie Operationen ausführen, nicht auf Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben prüfen.

Description

HINTERGRUND
Gebiet der Erfindung
Diese Erfindung bezieht sich allgemein auf das Gebiet der Computerprozessoren. Insbesondere bezieht sich die Erfindung auf eine Vorrichtung und auf ein Verfahren zum Implementieren einer dynamischen Out-of-order-Prozessorpipeline.
Beschreibung des verwandten Gebiets
Viele Mainstream-Prozessoren beruhen aktuell auf dynamischen Out-of-order-Mikroarchitekturen, die mehr oder weniger dieselben Prinzipien höherer Ebene der Out-of-order-Pipeline-Implementierung gemeinsam nutzen. Mit jeder Generation der reinen Hardware-Out-of-order-Entwürfe werden die Verbesserung der Leistungsfähigkeit dieser Prozessoren, des Wirkungsgrads, der Flächendichte und der Hardwareskalierbarkeit zunehmend schwieriger.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Ein besseres Verständnis der vorliegenden Erfindung kann aus der folgenden ausführlichen Beschreibung in Verbindung mit den folgenden Zeichnungen erhalten werden, in denen:
1A ein Blockschaltplan ist, der sowohl eine beispielhafte In-order-Pipeline als auch eine beispielhafte Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Pipeline in Übereinstimmung mit Ausführungsformen der Erfindung darstellt;
1B ein Blockschaltplan ist, der sowohl eine beispielhafte Ausführungsform eines In-order-Architektur-Kerns als auch eines beispielhaften Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Architektur-Kerns, der in einen Prozessor in Übereinstimmung mit Ausführungsformen der Erfindung aufgenommen werden soll, darstellt;
2 ein Blockschaltplan eines Einkernprozessors und eines Mehrkernprozessors mit integriertem Speichercontroller und integrierter Graphik in Übereinstimmung mit Ausführungsformen der Erfindung ist;
3 einen Blockschaltplan eines Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung darstellt;
4 einen Blockschaltplan eines zweiten Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung darstellt;
5 einen Blockschaltplan eines dritten Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung darstellt;
6 einen Blockschaltplan eines Einchipsystems (SoC) in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung darstellt;
7 einen Blockschaltplan darstellt, der die Verwendung eines Softwarebefehlsumsetzers zum Umsetzen binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz in Übereinstimmung mit Ausführungsformen der Erfindung gegenüberstellt;
8 eine Ausführungsform eines Befehlsformats darstellt, das für Very-Large-Instruction-Word-Silben (VLIW-Silben) verwendet wird;
9 eine Ausführungsform eines Very Long Instruction Word (VLIW) darstellt, das mehrere Silben umfasst;
10A–B eine herkömmliche Out-of-order-Pipeline (OOO-Pipeline) und eine OOO-Pipeline in Übereinstimmung mit einer Ausführungsform der Erfindung darstellen;
11A–B Abhängigkeiten zwischen mehreren herkömmlichen Mikrobefehlen (μops), die in Binärcode angrenzen, und mehreren Silben darstellen;
12A–B eine Registerumbenennung in einem herkömmlichen Prozessor und eine Registerumbenennung, die in einer Ausführungsform der Erfindung genutzt wird, darstellen;
13A–B eine Registerumbenennung, eine Planerlogik und eine Abbruchlogik in einem herkömmlichen OOO-Prozessor in Übereinstimmung mit einer Ausführungsform der Erfindung darstellen;
14A eine herkömmliche Pipeline darstellt, die zwischen Umbenennungs/Zuweisungs-, Planungs- und Absendestufe mehrere Kreuzschienenschalter enthält;
14B eine Pipeline in Übereinstimmung mit einer Ausführungsform der Erfindung darstellt, die eine Umbenennungs/Zuweisungs-Stufe, eine Planungsstufe und eine Absendestufe enthält;
15 eine Ausführungsform einer Prozessorpipeline nach einer Decodierungsstufe darstellt; und
16 eine Ausführungsform einer Umordnung einer Sequenz von Befehlen auf der Grundlage von Befehlsabhängigkeiten darstellt.
AUSFÜHRLICHE BESCHREIBUNG
In der folgenden Beschreibung sind zur Erläuterung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der Ausführungsformen der hier beschriebenen Erfindung zu erzeugen. Allerdings ist für den Fachmann auf dem Gebiet offensichtlich, dass die Ausführungsformen der Erfindung ohne einige dieser spezifischen Einzelheiten verwirklicht werden können. In anderen Fällen sind gut bekannte Strukturen und Vorrichtungen in Blockschaltplanform gezeigt, um eine Verdeckung der zugrundeliegenden Prinzipien der Ausführungsformen der Erfindung zu vermeiden.
BEISPIELHAFTE PROZESSORARCHITEKTUREN UND DATENTYPEN
1A ist ein Blockschaltplan, der sowohl eine beispielhafte In-order-Pipeline als auch eine beispielhafte Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Pipeline in Übereinstimmung mit Ausführungsformen der Erfindung darstellt. 1B ist ein Blockschaltplan, der sowohl eine beispielhafte Ausführungsform eines In-order-Architektur-Kerns als auch eines beispielhaften Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Architektur-Kerns, der in einen Prozessor in Übereinstimmung mit Ausführungsformen der Erfindung aufgenommen werden soll, darstellt. Die Kästen in durchgezogenen Linien in 1A–B veranschaulichen die In-order-Pipeline und den In-order-Kern, während die optionale Hinzufügung der Kästen in Strichlinien die Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Pipeline und den Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Kern veranschaulicht. Ausgehend davon, dass der In-order-Aspekt eine Teilmenge des Out-of-order-Aspekts ist, wird der Out-of-order-Aspekt beschrieben.
In 1A enthält eine Prozessorpipeline 100 eine Abrufstufe 102, eine Längendecodierungsstufe 104, eine Decodierungsstufe 106, eine Zuordnungsstufe 108, eine Umbenennungsstufe 110, eine Planungsstufe (auch als eine Absende- oder Ausgabestufe bekannt) 112, eine Registerlese/Speicherlese-Stufe 114, eine Ausführungsstufe 116, eine Zurückschreib/Speicherschreib-Stufe 118, eine Ausnahmebehandlungsstufe 122 und eine Festschreibstufe 124.
1B zeigt einen Prozessorkern 190, der eine Frontend-Einheit 130 enthält, die mit einer Ausführungsmaschineneinheit 150 gekoppelt ist, wobei beide mit einer Speichereinheit 170 gekoppelt sind. Der Kern 190 kann ein Reduced-Instruction-Set-Computing-Kern (RISC-Kern), ein Complex-Instruction-Set-Computing-Kern (CISC-Kern), ein Very-Long-Instruction-Word-Kern (VLIW-Kern) oder ein Hybridkerntyp oder ein alternativer Kerntyp sein. Als eine abermals andere Option kann der Kern 190 ein Spezialkern wie etwa z. B. ein Netz- oder Kommunikationskern, eine Kompressionsmaschine, ein Coprozessorkern, ein Mehrzweck-Computergraphikverarbeitungseinheits-Kern (GPGPU-Kern), ein Graphikkern oder dergleichen sein.
Die Frontend-Einheit 130 enthält eine Verzweigungsvorhersageeinheit 132, die mit einer Befehls-Cache-Einheit 134 gekoppelt ist, die mit einem Befehls-Translation-Lookaside-Puffer (TLB) 136 gekoppelt ist, der mit einer Befehlsabrufeinheit 138 gekoppelt ist, die mit einer Decodiereinheit 140 gekoppelt ist. Die Decodiereinheit 140 (oder der Decodierer) kann Befehle decodieren und als eine Ausgabe eine oder mehrere Mikrooperationen, Mikrocodeeinsprungpunkte, Mikrobefehle, andere Befehle oder andere Steuersignale, die aus den ursprünglichen Befehlen decodiert werden oder die diese auf andere Weise widerspiegeln oder von ihnen hergeleitet sind, erzeugen. Die Decodiereinheit 140 kann unter Verwendung vieler verschiedener Mechanismen implementiert werden. Beispiele geeigneter Mechanismen enthalten Nachschlagetabellen, Hardwareimplementierungen, programmierbare Logikanordnungen (PLAs), Mikrocode-Nur-Lese-Speicher (ROMs) usw., sind darauf aber nicht beschränkt. In einer Ausführungsform enthält der Kern 190 einen Mikrocode-ROM oder ein anderes Medium, der bzw. das Mikrocode für bestimmte Makrobefehle (z. B. in der Decodiereinheit 140 oder auf andere Weise innerhalb der Frontend-Einheit 130) speichert. Die Decodiereinheit 140 ist mit einer Umbenennungs/Zuweisungs-Einheit 152 in der Ausführungsmaschineneinheit 150 gekoppelt.
Die Ausführungsmaschineneinheit 150 enthält die Umbenennungs/Zuweisungs-Einheit 152, die mit einer Ausscheideeinheit 154 und mit einem Satz einer oder mehrerer Planereinheiten 156 gekoppelt ist. Die eine oder die mehreren Planereinheiten 156 repräsentieren irgendeine Anzahl unterschiedlicher Planer einschließlich Reservierungsstationen, eines zentralen Befehlsfensters usw. Die eine oder die mehreren Planereinheiten 156 sind mit der bzw. mit den physikalischen Registerdateieinheiten 158 gekoppelt. Jede der einen oder mehreren physikalischen Registerdateieinheiten 158 repräsentiert eine oder mehrere physikalische Registerdateien, von denen verschiedene einen oder mehrere verschiedene Datentypen wie etwa skalar-ganzzahlig, skalar-Gleitkomma, gepackt-ganzzahlig, gepackt-Gleitkomma, Vektorganzzahlig, Vektor-Gleitkomma, Status (z. B. einen Befehlszeiger, der die Adresse des nächsten auszuführenden Befehls ist) usw. speichern. In einer Ausführungsform umfasst die physikalische Registerdateieinheit 158 eine Vektorregistereinheit, eine Schreibmaskenregistereinheit und eine Skalarregistereinheit. Diese Registereinheiten können Architekturvektorregister, Vektormaskenregister und Mehrzweckregister bereitstellen. Die eine oder die mehreren Registerdateieinheiten 158 sind mit der Ausscheideeinheit 154 überlappt, um verschiedene Arten darzustellen, in denen die Registerumbenennung und die Out-of-order-Ausführung (z. B. unter Verwendung eines oder mehrerer Umordnungspuffer und einer oder mehrerer Ausscheideregisterdateien; unter Verwendung einer oder mehrerer Zukunftsdateien, eines oder mehrerer Historienpuffer und einer oder mehrerer Ausscheideregisterdateien; unter Verwendung von Registerkarten und eines Pools von Registern; usw.) implementiert werden können. Die Ausscheideeinheit 154 und die eine oder die mehreren physikalischen Registerdateieinheiten 158 sind mit dem einen oder den mehreren Ausführungsclustern 160 gekoppelt. Der eine oder die mehreren Ausführungscluster 160 enthalten einen Satz einer oder mehrerer Ausführungseinheiten 162 und einen Satz einer oder mehrerer Speicherzugriffseinheiten 164. Die Ausführungseinheiten 162 können verschiedene Operationen (z. B. Stellenversetzungsoperationen, Addition, Subtraktion, Multiplikation) und diese an verschiedenen Datentypen (z. B. skalar-Gleitkomma, gepackt-ganzzahlig, gepackt-Gleitkomma, Vektor-ganzzahlig, Vektor-Gleitkomma) ausführen. Obwohl einige Ausführungsformen eine Anzahl von Ausführungseinheiten enthalten können, die für spezifische Funktionen oder Sätze von Funktionen vorgesehen sind, können andere Ausführungsformen nur eine Ausführungseinheit oder mehrere Ausführungseinheiten, die alle sämtliche Funktionen ausführen, enthalten. Da bestimmte Ausführungsformen für bestimmte Typen von Daten/Operationen getrennte Pipelines erzeugen (z. B. eine Skalar-ganzzahlig-Pipeline, eine Skalar-Gleitkomma/Gepackt-ganzzahlig/Gepackt-Gleitkomma/Vektor-ganzzahlig/Vektor-Gleitkomma-Pipeline und/oder eine Speicherzugriffspipeline, die jeweils ihre eigene Planreinheit, ihre eigenen eine oder mehreren physikalischen Registerdateieinheiten und/oder ihren eigenen einen oder mehrere Ausführungscluster besitzen – und da im Fall einer getrennten Speicherzugriffspipeline bestimmte Ausführungsformen implementiert werden, in denen nur der Ausführungscluster dieser Pipeline eine oder mehrere Speicherzugriffseinheiten 164 besitzt), sind die eine oder die mehreren Planereinheiten 156, physikalischen Registerdateieinheiten 158 und Ausführungscluster 160 in der Weise gezeigt, dass sie möglicherweise mehrere sind. Außerdem ist zu verstehen, dass dort, wo getrennte Pipelines verwendet werden, eine oder mehrere dieser Pipelines Out-of-order-Ausgabe/Ausführungs- und der Rest In-Order- sein können.
Der Satz von Speicherzugriffseinheiten 164 ist mit der Speichereinheit 170 gekoppelt, die eine Daten-TLB-Einheit 172 enthält, die mit einer Daten-Cache-Einheit 174 gekoppelt ist, die mit einer Cache-Einheit 176 der 2. Ebene (L2-Cache-Einheit) gekoppelt ist. In einer beispielhaften Ausführungsform können die Speicherzugriffseinheiten 164 eine Ladeeinheit, eine Speicheradresseneinheit und eine Speicherdateneinheit enthalten, von denen jede mit der Daten-TLB-Einheit 172 in der Speichereinheit 170 gekoppelt ist. Ferner ist die Befehls-Cache-Einheit 134 mit einer Cache-Einheit 176 der 2. Ebene (L2-Cache-Einheit) in der Speichereinheit 170 gekoppelt. Die L2-Cache-Einheit 176 ist mit einer oder mit mehreren weiteren Cache-Ebenen und schließlich mit einem Hauptspeicher gekoppelt.
Beispielsweise kann die beispielhafte Registerumbenennungs-Out-of-order-Ausgabe/Ausführungs-Kern-Architektur die Pipeline 100 Folgendes implementieren: 1) Der Befehlsabruf 138 führt die Abruf- und Längendecodierungsstufe 102 und 104 aus; 2) die Decodiereinheit 140 führt die Decodierungsstufe 106 aus; 3) die Umbenennungs/Zuweisungs-Einheit 152 führt die Zuweisungsstufe 108 und die Umbenennungsstufe 110 aus; 4) die eine oder die mehreren Planereinheiten 156 führen die Planungsstufe 112 aus; 5) die eine oder die mehreren physikalischen Registerdateieinheiten 158 und die Speichereinheit 170 führen die Registerlese/Speicherlese-Stufe 114 aus; der Ausführungscluster 160 führt die Ausführungsstufe 116 aus; 6) die Speichereinheit 170 und die eine oder die mehreren physikalischen Registerdateieinheiten 158 führen die Zurückschreib/Speicherschreib-Stufe 118 aus; 7) verschiedene Einheiten können an der Ausnahmebehandlungsstufe 122 beteiligt sein; und 8) die Ausscheideeinheit 154 und die eine oder die mehreren physikalischen Registerdateieinheiten 158 führen die Festschreibstufe 124 aus.
Der Kern 190 kann einen oder mehrere Befehlssätze (z. B. den ×86-Befehlssatz (mit einigen Erweiterungen, die bei neueren Versionen hinzugefügt worden sind); den MIPS-Befehlssatz der MIPS Technologies aus Sunnyvale, CA; den ARM-Befehlssatz (mit optionalen zusätzlichen Erweiterungen wie etwa NEON) der ARM Holdings aus Sunnyvale, CA) einschließlich des einen oder der mehreren hier beschriebenen Befehle unterstützen. In einer Ausführungsform enthält der Kern 190 eine Logik zum Unterstützen einer Befehlssatzerweiterung für gepackte Daten (z. B. AVX1, AVX2 und/oder eine Form des im Folgenden beschriebenen generischen vektorfreundlichen Befehlsformats (U = 0 und/oder U = 1)) und ermöglicht er dadurch, dass die von vielen Multimediaanwendungen verwendeten Operationen unter Verwendung gepackter Daten ausgeführt werden.
Es ist zu verstehen, dass der Kern Multithreading (die Ausführung zweier oder mehrerer paralleler Sätze von Operationen oder Threads) unterstützen kann und dass er dies auf eine Vielzahl von Arten einschließlich Zeitschlitz-Multithreading, gleichzeitigem Multithreading (wobei ein einzelner physikalischer Kern einen Logikkern für jeden der Threads bereitstellt, den der physikalische Kern gleichzeitig im Multithreading ausführt) oder einer Kombination davon (z. B. Zeitschlitz-Abrufen und Zeitschlitz-Decodieren und gleichzeitiges Multithreading danach wie etwa in der Intel^®-Hyperthreading-Technologie) tun kann.
Obwohl die Registerumbenennung im Kontext der Out-of-order-Ausführung beschrieben ist, ist zu verstehen, dass die Registerumbenennung in einer In-order-Architektur verwendet werden kann. Obwohl die dargestellte Ausführungsform des Prozessors ebenfalls getrennte Befehls- und Daten-Cache-Einheiten 134/174 und eine gemeinsam genutzte L2-Cache-Einheit 176 enthält, können alternative Ausführungsformen einen einzelnen internen Cache sowohl für Anwendungen als auch für Daten wie etwa z. B. einen internen Cache der 1. Ebene (L1-Cache) oder mehrere Ebenen eines internen Caches aufweisen. In einigen Ausführungsformen kann das System eine Kombination eines internen Caches und eines externen Caches, der extern gegenüber dem Kern und/oder dem Prozessor ist, enthalten. Alternativ kann der gesamte Cache gegenüber dem Kern und/oder dem Prozessor extern sein.
2 ist ein Blockschaltplan eines Prozessors 200, der mehr als einen Kern aufweisen kann, einen integrierten Speichercontroller aufweisen kann und eine integrierte Graphik aufweisen kann, in Übereinstimmung mit Ausführungsformen der Erfindung. Die Kästen in durchgezogenen Linien in 2 veranschaulichen einen Prozessor 200 mit einem einzelnen Kern 202A, einem Systemagenten 210 und einem Satz einer oder mehrerer Buscontrollereinheiten 216, während die optionale Hinzufügung der Kästen in Strichlinien einen alternativen Prozessor 200 mit mehreren Kernen 202A–N, einem Satz einer oder mehrerer integrierter Speichercontrollereinheiten 214 in der Systemagenteneinheit 210 und einer Speziallogik 208 darstellt.
Somit können verschiedene Implementierungen des Prozessors 200 Folgendes enthalten: 1) eine CPU mit der Speziallogik 208, die eine integrierte Graphik und/oder eine wissenschaftliche (Durchsatz-)Logik ist (die einen oder mehrere Kerne enthalten kann) und mit den Kernen 202A–N, die einer oder mehrere Mehrzweckkerne (z. B. Mehrzweck-In-order-Kerne, Mehrzweck-Out-of-order-Kerne, eine Kombination der zwei) sind; 2) einen Coprozessor mit den Kernen 202A–N, die eine große Anzahl von Spezialkernen sind, die primär für Graphik und/oder für Wissenschaft (Durchsatz) bestimmt sind; und 3) einen Coprozessor mit den Kernen 202A–N, die eine große Anzahl von Mehrzweck-In-order-Kernen sind. Somit kann der Prozessor 200 ein Mehrzweckprozessor, ein Coprozessor oder ein Spezialprozessor wie etwa z. B. ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Graphikprozessor, eine GPGPU (Mehrzweck-Graphikverarbeitungseinheit), ein Coprozessor mit vielen integrierten Kernen (MIC-Coprozessor) mit hohem Durchsatz (der 30 oder mehr Kerne enthält), ein eingebetteter Prozessor oder dergleichen sein. Der Prozessor kann in einem oder in mehreren Chips implementiert sein. Der Prozessor 200 kann unter Verwendung einer Anzahl von Prozesstechnologien wie etwa z. B. BiCMOS, CMOS oder NMOS ein Teil eines oder mehrerer Substrate und/oder auf ihnen implementiert sein.
Die Speicherhierarchie enthält eine oder mehrere Cache-Ebenen innerhalb der Kerne, einen Satz oder eine oder mehrere gemeinsam genutzte Cache-Einheiten 206 und externen Speicher (nicht gezeigt), der mit dem Satz integrierter Speichercontrollereinheiten 214 gekoppelt ist. Der Satz gemeinsam genutzter Cache-Einheiten 206 kann einen oder mehrere Caches mittlerer Ebene wie etwa einen Cache der 2. Ebene (L2-Cache), einen Cache der 3. Ebene (L3-Cache, einen Cache der 4. Ebene (L4-Cache) oder Caches anderer Ebenen, einen Cache der letzten Ebene (LLC-Cache) und/oder Kombinationen davon enthalten. Obwohl in einer Ausführungsform eine ringgestützte Verdrahtungseinheit 212 die integrierte Graphiklogik 208, den Satz gemeinsam genutzter Cache-Einheiten 206 und die Systemagenteneinheit 210/die eine oder die mehreren integrierten Speichercontrollereinheiten 214 verbindet, können alternative Ausführungsformen irgendeine Anzahl gut bekannter Techniken zum Verbinden solcher Einheiten verwenden. In einer Ausführungsform wird die Kohärenz zwischen einer oder mehreren Cache-Einheiten 206 und Kernen 202A–N aufrechterhalten.
In einigen Ausführungsformen sind einer oder mehrere der Kerne 202A–N Multithreadingfähig. Der Systemagent 210 enthält jene Komponenten, die die Kerne 202A–N koordinieren und betreiben. Die Systemagenteneinheit 210 kann z. B. eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann Logik und Komponenten, die notwendig sind, um den Leistungszustand der Kerne 202A–N und der integrierten Graphiklogik 208 zu regeln, sein oder enthalten. Die Anzeigeeinheit dient zum Ansteuern einer oder mehrerer extern verbundener Anzeigen.
Die Kerne 202A–N können hinsichtlich des Architekturbefehlssatzes homogen oder heterogen sein; d. h., zwei oder mehr der Kerne 202A–N können zur Ausführung desselben Befehlssatzes fähig sein, während andere zur Ausführung nur einer Teilmenge dieses Befehlssatzes oder eines anderen Befehlssatzes fähig sein können. In einer Ausführungsform sind die Kerne 202A–N heterogen und enthalten sie sowohl die ”kleinen” Kerne als auch die ”großen” Kerne, die im Folgenden beschrieben sind.
Die 3–6 sind Blockschaltpläne beispielhafter Computerarchitekturen. Andere Systementwürfe und Systemkonfigurationen, die auf den Gebieten der Laptops, der Desktops, der Hand-PCs, der Personal Digital Assistants, der technischen Workstations, der Server, der Netzvorrichtungen, der Netz-Hubs, der Switches, der eingebetteten Prozessoren, der digitalen Signalprozessoren (DSPs), der Graphikvorrichtungen, der Videospielvorrichtungen, der Set-Top-Boxen, der Mikrocontroller, der Mobiltelephone, der tragbaren Medienspieler, der Handvorrichtungen und verschiedener anderer elektronischer Vorrichtungen bekannt sind, sind ebenfalls geeignet. Allgemein sind eine breite Vielfalt von Systemen oder elektronischen Vorrichtungen, die einen Prozessor und/oder eine andere Ausführungslogik, wie sie hier offenbart sind, enthalten können, allgemein geeignet.
Nun anhand von 3 ist ein Blockschaltplan eines Systems 300 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Das System 300 kann einen oder mehrere Prozessoren 310, 315 enthalten, die mit einem Controller-Hub 320 gekoppelt sind. In einer Ausführungsform enthält der Controller-Hub 320 einen Graphikspeichercontroller-Hub (GMCH) 390 und einen Eingabe/Ausgabe-Hub (IOH) 350 (die sich auf getrennten Chips befinden können); enthält der GMCH 390 Speicher und Graphikcontroller, mit denen der Speicher 340 und ein Coprozessor 345 gekoppelt sind; koppelt der IOH 350 die Eingabe/Ausgabe-Vorrichtungen (E/A-Vorrichtungen) 360 mit dem GMCH 390. Alternativ sind der Speichercontroller und/oder der Graphikcontroller innerhalb des Prozessors (wie hier beschrieben) integriert, wobei der Speicher 340 und der Coprozessor 345 mit dem Prozessor 310 und mit dem Controller-Hub 320 in einem einzelnen Chip mit dem IOH 350 direkt gekoppelt sind.
Das optionale Wesen zusätzlicher Prozessoren 315 ist in 3 mit Strichlinien bezeichnet. Jeder Prozessor 310, 315 kann einen oder mehrere der hier beschriebenen Verarbeitungskerne enthalten und kann dieselbe Version des Prozessors 200 sein.
Der Speicher 340 kann z. B. dynamischer Schreib-Lese-Speicher (DRAM), Phasenwechselspeicher (PCM) oder eine Kombination der zwei sein. Für wenigstens eine Ausführungsform kommuniziert der Controller-Hub 320 mit dem einen oder mit den mehreren Prozessoren 310, 315 über einen Mehr-Abzweig-Bus wie etwa einen Frontside-Bus (FSB), über eine Punkt-zu-Punkt-Schnittstelle wie etwa QuickPath Interconnect (QPI) oder über eine ähnliche Verbindung 395.
In einer Ausführungsform ist der Coprozessor 345 ein Mehrzweckprozessor wie etwa z. B. ein MIC-Prozessor mit hohem Durchsatz, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Graphikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen. In einer Ausführungsform kann der Controller-Hub 320 einen integrierten Graphikbeschleuniger enthalten.
Hinsichtlich eines Spektrums von Gütemetriken kann es zwischen den physikalischen Betriebsmitteln 310, 315 eine Vielzahl von Unterschieden einschließlich Architektureigenschaften, Mikroarchitektureigenschaften, thermischer Eigenschaften, Leistungsverbrauchseigenschaften und dergleichen geben.
In einer Ausführungsform führt der Prozessor 310 Befehle aus, die Datenverarbeitungsoperationen eines allgemeinen Typs steuern. In die Befehle können Coprozessorbefehle eingebettet sein. Der Prozessor 310 erkennt diese Coprozessorbefehle als einen Typ, der durch den angeschlossenen Coprozessor 345 ausgeführt werden sollte. Dementsprechend gibt der Prozessor 310 diese Coprozessorbefehle (oder Steuersignale, die Coprozessorbefehle repräsentieren) auf einem Coprozessorbus oder auf einer anderen Verdrahtung an den Coprozessor 345 aus. Der eine oder die mehreren Coprozessoren 345 nehmen die empfangenen Coprozessorbefehle an und führen sie aus.
Nun in 4 ist ein Blockschaltplan eines ersten spezielleren beispielhaften Systems 400 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 4 gezeigt ist, ist das Multiprozessorsystem 400 ein Punkt-zu-Punkt-Verdrahtungssystem und enthält es einen ersten Prozessor 470 und einen zweiten Prozessor 480, die über eine Punkt-zu-Punkt-Verdrahtung 450 gekoppelt sind. Jeder der Prozessoren 470 und 480 kann eine selbe Version des Prozessors 200 sein. In einer Ausführungsform der Erfindung sind die Prozessoren 470 und 480 die Prozessoren 310 bzw. 315, während der Coprozessor 438 der Coprozessor 345 ist. In einer anderen Ausführungsform sind die Prozessoren 470 bzw. 480 der Prozessor 310 bzw. der Coprozessor 345.
Die Prozessoren 470 und 480 sind in der Weise gezeigt, dass sie integrierte Speichercontrollereinheiten (IMC-Einheiten) 472 bzw. 482 enthalten. Außerdem enthält der Prozessor 470 als Teil seiner Buscontrollereinheiten Punkt-zu-Punkt-Schnittstellen (P-P-Schnittstellen) 476 und 478; ähnlich enthält der zweite Prozessor 480 P-P-Schnittstellen 486 und 488. Die Prozessoren 470, 480 können unter Verwendung der P-P-Schnittstellenschaltungen 478, 488 über eine Punkt-zu-Punkt-Schnittstelle (P-P-Schnittstelle) 450 Informationen austauschen. Wie in 4 gezeigt ist, koppeln IMCs 472 und 482 die Prozessoren mit jeweiligen Speichern, d. h. mit einem Speicher 432 und mit einem Speicher 434, die Abschnitte des Hauptspeichers sein können, der lokal an die jeweiligen Prozessoren angeschlossen ist.
Die Prozessoren 470, 480 können über einzelne P-P-Schnittstellen 452, 454 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 476, 494, 486, 498 mit einem Chipsatz 490 Informationen austauschen. Der Chipsatz 490 kann über eine Hochleistungsschnittstelle 439 optional Informationen mit dem Coprozessor 438 austauschen. In einer Ausführungsform ist der Coprozessor 438 ein Spezialprozessor wie etwa z. B. ein MIC-Prozessor mit hohem Durchsatz, ein Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, ein Graphikprozessor, eine GPGPU, ein eingebetteter Prozessor oder dergleichen.
Ein gemeinsam genutzter Cache (nicht gezeigt) kann in einem der Prozessoren oder außerhalb beider Prozessoren enthalten sein, aber dennoch mit den Prozessoren über eine P-P-Verdrahtung verbunden sein, so dass die lokalen Cache-Informationen eines oder beider Prozessoren in dem gemeinsam genutzten Cache gespeichert werden können, falls ein Prozessor in eine Betriebsart mit niedrigem Leistungsverbrauch versetzt wird.
Der Chipsatz 490 kann über eine Schnittstelle 496 mit einem ersten Bus 416 gekoppelt sein. In einer Ausführungsform kann der erste Bus 416 ein Peripheral-Component-Interconnect-Bus (PCI-Bus) oder ein Bus wie etwa ein PCI-Express-Bus oder ein anderer E/A-Verdrahtungsbus der dritten Generation sein, obwohl der Schutzumfang der vorliegenden Erfindung darauf nicht beschränkt ist.
Wie in 4 gezeigt ist, können mit dem ersten Bus 416 zusammen mit einer Busbrücke 418, die den ersten Bus 416 mit einem zweiten Bus 420 koppelt, verschiedene E/A-Vorrichtungen 414 gekoppelt sein. In einer Ausführungsform sind einer oder mehrere zusätzliche Prozessoren 415 wie etwa Coprozessoren, MIC-Prozessoren mit hohem Durchsatz, GPGPUs, Beschleuniger (wie etwa z. B. Graphikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP-Einheiten)), frei programmierbare logische Anordnungen oder irgendein anderer Prozessor mit dem ersten Bus 416 gekoppelt. In einer Ausführungsform kann der zweite Bus 420 ein Bus mit niedriger Anschlussstiftanzahl (LPC) sein. In einer Ausführungsform können verschiedene Vorrichtungen einschließlich z. B. einer Tastatur und/oder einer Maus 422, Kommunikationsvorrichtungen 427 und einer Ablageeinheit 428 wie etwa eines Plattenlaufwerks oder einer anderen Massenablagevorrichtung, die Befehle/Code und Daten 430 enthalten kann, mit einem zweiten Bus 420 gekoppelt sein. Ferner kann mit dem zweiten Bus 420 eine Audio-E/A 424 gekoppelt sein. Es wird angemerkt, dass andere Architekturen möglich sind. Zum Beispiel kann ein System anstelle der Punkt-zu-Punkt-Architektur aus 4 einen Mehr-Abzweig-Bus oder eine andere solche Architektur implementieren.
Nun in 5 ist ein Blockschaltplan eines zweiten spezielleren beispielhaften Systems 500 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in 4 und 5 tragen gleiche Bezugszeichen und bestimmte Aspekte aus 4 sind aus 5 weggelassen worden, um die Verdeckung anderer Aspekte aus 5 zu vermeiden.
5 veranschaulicht, dass die Prozessoren 470, 480 einen integrierten Speicher und eine E/A-Steuerlogik (”CL”) 472 bzw. 482 enthalten können. Somit enthalten die CL 472, 482 integrierte Speichercontrollereinheiten und enthalten sie eine E/A-Steuerlogik. 5 stellt dar, dass nicht nur die Speicher 432, 434 mit der CL 472, 482 gekoppelt sind, sondern dass auch die E/A-Vorrichtungen 514 mit der Steuerlogik 472, 482 gekoppelt sind. Mit dem Chipsatz 490 sind Legacy-E/A-Vorrichtungen 515 gekoppelt.
Nun in 6 ist ein Blockschaltplan eines SoC 600 in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 2 tragen gleiche Bezugszeichen. Außerdem sind Kästen in Strichlinien optionale Merkmale in fortgeschritteneren SoCs. In 6 sind eine oder mehrere Verdrahtungseinheiten 602 mit Folgendem gekoppelt: einem Anwendungsprozessor 610, der einen Satz eines oder mehrerer Kerne 202A–N und eine oder mehrere gemeinsam genutzte Cache-Einheiten 206 enthält; einer Systemagenteneinheit 210; einer oder mehreren Buscontrollereinheiten 216; einer oder mehreren integrierten Speichercontrollereinheiten 214; einem Satz oder einem oder mehreren Coprozessoren 620, die eine integrierte Graphiklogik, einen Bildprozessor, einen Audioprozessor und einen Videoprozessor enthalten können; einer statischen Schreib-Lese-Speichereinheit (SRAM-Einheit) 630; einer Einheit 632 für direkten Speicherzugriff (DMA); und einer Anzeigeeinheit 640 zum Koppeln mit einer oder mit mehreren externen Anzeigen. In einer Ausführungsform enthalten der eine oder die mehreren Coprozessoren 620 einen Spezialprozessor wie etwa z. B. einen Netz- oder Kommunikationsprozessor, eine Kompressionsmaschine, eine GPGPU, einen MIC-Prozessor mit hohem Durchsatz, einen eingebetteten Prozessor oder dergleichen.
Ausführungsformen der hier offenbarten Mechanismen können in Hardware, in Software, in Firmware oder in einer Kombination solcher Implementierungsherangehensweisen implementiert werden. Ausführungsformen der Erfindung können als Computerprogramme oder als Programmcode implementiert werden, die in programmierbaren Systemen ausgeführt werden, die wenigstens einen Prozessor, ein Ablagesystem (einschließlich flüchtiger und nichtflüchtiger Speicher- und/oder Ablageelemente), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
Programmcode wie etwa der in 4 dargestellte Code 430 kann angewendet werden, um Befehle einzugeben, um die hier beschriebenen Funktionen auszuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können auf bekannte Weise an eine oder mehrere Ausgabevorrichtungen angelegt werden. Für diese Anmeldung enthält ein Verarbeitungssystem irgendein System, das einen Prozessor aufweist, wie etwa z. B.: einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor.
Der Programmcode kann in einer höheren prozeduralen oder objektorientierten Programmiersprache zum Kommunizieren mit einem Verarbeitungssystem implementiert werden. Auf Wunsch kann der Programmcode ebenfalls in Assembler- oder Maschinensprache implementiert werden. Tatsächlich sind die hier beschriebenen Mechanismen in Bezug auf den Schutzumfang nicht auf irgendeine bestimmte Programmiersprache beschränkt. Auf jeden Fall kann die Sprache eine kompilierte oder interpretierte Sprache sein.
Einer oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentative Befehle implementiert werden, die in einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie durch eine Maschine gelesen wird, veranlasst, dass die Maschine Logik herstellt, um die hier beschriebenen Techniken auszuführen. Solche Darstellungen, die als ”IP-Kerne” bekannt sind, können in einem konkreten, maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, um sie in die Fertigungsmaschinen zu laden, die die Logik oder den Prozessor tatsächlich herstellen.
Solche maschinenlesbaren Ablagemedien können ohne Beschränkung nichtflüchtige, konkrete Anordnungen von Artikeln, die durch eine Maschine oder Vorrichtung hergestellt oder gebildet sind, einschließlich Ablagemedien wie etwa Festplatten, irgendeinem anderen Typ von Platten einschließlich Disketten, optischer Platten, Compact-Disc-Nur-Lese-Speicher (CD-ROMs), Compact-Disc-Rewritables (CD-RWs) und magnetooptischer Platten, Halbleitervorrichtungen wie etwa Nur-Lese-Speicher (ROMs), Schreib-Lese-Speicher (RAMs) wie etwa dynamische Schreib-Lese-Speicher (DRAMs), statische Schreib-Lese-Speicher (SRAMs), löschbare programmierbare Nur-Lese-Speicher (EPROMs), Flash-Speicher, elektrisch löschbare programmierbare Nur-Lese-Speicher (EEPROMs), Phasenwechselspeicher (PCM), magnetischer oder optischer Karten oder irgendeines anderen Medientyps, der zum Speichern elektronischer Befehle geeignet ist, enthalten.
Dementsprechend enthalten Ausführungsformen der Erfindung ebenfalls nichtflüchtige konkrete maschinenlesbare Medien, die Befehle enthalten oder die Entwurfsdaten wie etwa eine Hardware Description Language (HDL), die die hier beschriebenen Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale definiert, enthalten. Solche Ausführungsformen können auch als Programmprodukte bezeichnet werden.
In einigen Fällen kann ein Befehlsumsetzer verwendet werden, um einen Befehl von einem Quellbefehlssatz in einen Zielbefehlssatz umzusetzen. Zum Beispiel kann ein Befehlsumsetzer einen Befehl (z. B. unter Verwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischen Kompilierung) übersetzen, morphen, emulieren oder auf andere Weise in einen oder mehrere andere Befehle umsetzen, damit sie durch den Kern verarbeitet werden. Der Befehlsumsetzer kann in Software, in Hardware, in Firmware oder in einer Kombination davon implementiert werden. Der Befehlsumsetzer kann sich auf einem Prozessor, außerhalb eines Prozessors oder teilweise auf einem und teilweise außerhalb eines Prozessors befinden.
7 ist ein Blockschaltplan, der die Verwendung eines Softwarebefehlsumsetzers zum Umsetzen binärer Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz in Übereinstimmung mit Ausführungsformen der Erfindung gegenüberstellt. In der dargestellten Ausführungsform ist der Befehlsumsetzer ein Softwarebefehlsumsetzer, obwohl der Befehlsumsetzer alternativ in Software, in Firmware, in Hardware oder in verschiedenen Kombinationen davon implementiert werden kann. 7 zeigt, dass ein Programm in einer höheren Sprache 702 unter Verwendung eines ×86-Compilers 704 kompiliert werden kann, um ×86-Binärcode 706 zu erzeugen, der durch einen Prozessor mit wenigstens einem ×86-Befehlssatzkern 716 systemspezifisch ausgeführt werden kann. Der Prozessor mit wenigstens einem ×86-Befehlssatzkern 716 repräsentiert irgendeinen Prozessor, der im Wesentlichen dieselben Funktionen wie ein Intel-Prozessor mit wenigstens einem ×86-Befehlssatzkern ausführen kann, indem er Folgendes kompatibel ausführt oder auf andere Weise verarbeitet: (1) einen wesentlichen Teil des Befehlssatzes des Intel-×86-Befehlssatzkerns oder (2) Objektcodeversionen von Anwendungen oder anderer Software, die darauf gerichtet ist, auf einem Intel-Prozessor mit wenigstens einem ×86-Befehlssatzkern ausgeführt zu werden, um im Wesentlichen dasselbe Ergebnis wie ein Intel-Prozessor mit wenigstens einem ×86-Befehlssatzkern zu erzielen. Der ×86-Compiler 704 repräsentiert einen Compiler, der dafür betreibbar ist, ×86-Binärcode 706 (z. B. Objektcode) zu erzeugen, der mit oder ohne zusätzliche Bindeverarbeitung auf dem Prozessor mit wenigstens einem ×86-Befehlssatzkern 716 ausgeführt werden kann. Ähnlich zeigt 7, dass das Programm in der höheren Sprache 702 unter Verwendung eines Compilers 708 des alternativen Befehlssatzes kompiliert werden kann, um Binärcode 710 des alternativen Befehlssatzes zu erzeugen, der durch einen Prozessor ohne wenigstens einen ×86-Befehlssatzkern 714 (z. B. einen Prozessor mit Kernen, die den MIPS-Befehlssatz der MIPS Technologies of Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz der ARM Holdings of Sunnyvale, CA, ausführen) systemspezifisch ausgeführt werden kann.
Der Befehlsumsetzer 712 wird verwendet, um den ×86-Binärcode 706 in Binärcode 711 eines alternativen Befehlssatzes umzusetzen, der durch den Prozessor ohne einen ×86-Befehlssatzkern 714 systemspezifisch ausgeführt werden kann. Dieser umgesetzte Code kann derselbe wie der Binärcode 710 des alternativen Befehlssatzes, der sich aus dem Compiler 708 des alternativen Befehlssatzes ergibt, oder ein anderer sein; allerdings erreicht der umgesetzte Code denselben allgemeinen Betrieb und kann er aus Befehlen aus dem alternativen Befehlssatz aufgebaut sein. Somit repräsentiert der Befehlsumsetzer 712 Software, Firmware, Hardware oder eine Kombination davon, die durch Emulation, Simulation oder irgendeinen anderen Prozess ermöglichen, dass ein Prozessor oder eine andere elektronische Vorrichtung, die keinen ×86-Befehlssatz-Prozessor oder ×86-Befehlssatz-Kern besitzt, den ×86-Binärcode 706 ausführt.
VORRICHTUNG UND VERFAHREN ZUM IMPLEMENTIEREN EINER DYNAMISCHEN OUT-OF-ORDER-PROZESSORPIPELINE
Eine Ausführungsform der Erfindung enthält eine optimierte Implementierung einer dynamischen Out-of-order-Pipeline, die die Beschränkungen vorhandener Out-of-order- und In-order-VLIW-Prozessor-Implementierungen auf verschiedene Arten behandelt. Die Hardwareverbesserungen werden mit Hilfe speziell definierter (z. B. privater) Befehlssatzarchitekturmerkmale (ISA-Merkmale) und eines co-entworfenen Softwareoptimierers, der ein Optimierungscompiler 708 oder ein binärer Übersetzer (z. B. Umsetzer 712) für die ISA sein kann, erzielt (siehe 7). Bezeichnenderweise behält und verbessert die neu optimierte Hardwarepipeline alle Grundprinzipien der dynamischen Out-of-order-Ausführung in Hardware. Ein zusätzliches wertvolles Merkmal, das die Ausführungsformen der Erfindung ermöglichen, ist die erheblich verbesserte Hardwareskalierbarkeit für Out-of-order-Prozessorentwürfe mit breiterer Ausgabe.
Einige im Folgenden dargelegte Ausführungsformen sind auf der Grundlage der Beobachtung entworfen, dass eine herkömmliche Out-of-order-Pipeline, die irgendeine herkömmliche ISA (z. B. wie etwa die Intel^®-Architektur (IA)) unterstützt, die richtige superskalare Ausführung jeder gültigen Codesequenz in der ISA durch Hardware sicherstellen muss. Falls dagegen eine Out-of-order-Mikroarchitektur für eine neue Reduced-Instruction-Set-Computer-artige (RISC-artige) ISA entworfen wird, die ähnlich einigen der Beschränkungen in Very-Long-Instruction-Word-ISAs (VLIW-ISAs) bestimmte Beschränkungen an die für die Hardwareausführung zulässigen Codesequenzen definiert, kann die Implementierung der Out-of-order-Pipeline Hardware auf eine Anzahl von Arten wesentlich optimiert werden.
Besondere Optimierungen sind in dieser Patentanmeldung als ein Paket eng verwandter ISA-abhängiger oder ISA-Ableitungs-Erfindungen beschrieben. Die neue ISA kann entweder privat oder öffentlich sein. Optional wird die Dynamic-Binary-Translation-Technologie (dBT-Technologie) verwendet, um von vorhandenen Binärcodes (z. B. IA) in die neue private ISA zu übersetzen und die vollständige Binärkompatibilität mit vorhandener Software zu ermöglichen. In 7 kann die dBT-Technologie z. B. durch einen Befehlsumsetzer 712 zum Umsetzen von ×86-Binärcode 706 in systemspezifischen Binärcode, der für die Ausführung auf der hier beschriebenen Prozessorarchitektur ausgelegt ist, implementiert sein. Alternativ kann ein Optimierungscompiler für die neue öffentliche ISA wie etwa der Compiler 708 in 7 verwendet werden, um ausführbare Binärdateien 710 zu erzeugen.
Bezeichnenderweise ändern die neuen Hardwareoptimierungen in einer Ausführungsform nicht die Grundprinzipien der Out-of-order-Pipeline, sondern nur ihre Implementierung. Somit widerspiegelt die optimierte Pipeline den herkömmlichen konzeptionellen Ablauf von Befehlen: superskalaren In-order-Abruf und superskalare In-order-Zuweisung von Befehlen, eine dynamische Datenflussplanungsmaschine (Out-of-order) und superskalare In-order-Ausscheidung von Befehlen. Dies beides stellt die Hardwarerealisierbarkeit sicher und hilft, die hohen Leistungserwartungen über einen weiten Bereich von Mehrzwecksoftwareanwendungen zu erfüllen.
Die beschriebenen Ausführungsformen der Erfindung ermöglichen eine erhebliche Anzahl von Hardwareoptimierungen – Vereinfachungen, Verringerungen und Verbesserungen – in der superskalaren Out-of-order-Pipeline-Implementierung. Durch diese Ausführungsformen werden die folgenden Merkmale implementiert:
drastische Frontend-Hardwareoptimierungen ähnlich jenen im Frontend eines In-order-Prozessors;
Vereinfachung und Verringerung der Größe von Out-of-order-Maschinen-Zuweisungs-, Planeraufbau- und Ausscheideeinheiten auslassseitig der Out-of-order-Pipeline;
Beseitigung mehrerer kritischer Abhängigkeiten zwischen den Stufen in der Zuweisungspipeline und Verringerung einiger Pipelinestufen, was das Segment der Out-of-order-Pipeline paralleler macht;
Latenzzeitverringerung für mehrere kritische Pipelinestufen, was einen breiteren Bereich der dynamischen Betriebsfrequenz/Betriebsspannung für einen Out-of-order-Prozessor ermöglicht;
einen partitionierten Entwurf vieler Hardwarestrukturen entlang der Pipeline sowie Verringerung ihrer Lese/Schreib-Ports über das hinaus, was in herkömmlichen Out-of-order-Prozessoren durchführbar oder praktisch ist;
Beseitigung großer Kreuzschienenstrukturen (Multiplexierungsstrukturen) in mehreren Stufen der Out-of-order-Pipeline und hochparallele, lose partitionierte Organisation in Teilen des Datenwegs und der Steuerbusse; und
verbesserte Nutzung teurer Out-of-order-Hardwarestrukturen (z. B. Reservierungsstationen, Puffer usw.) mit einer gegebenen Größe im Vergleich zu den herkömmlichen Out-of-order-Entwürfen.
In einer Ausführungsform wird die obenerwähnte verbesserte Nutzung im Rest der Out-of-order-Pipeline durch Ausnutzung der In-order-Organisationskomplexität der Wirkungen des Out-of-order-Befehlsabrufs, der Zuweisung zum Backend und der Ausscheidung in Bezug auf die ursprüngliche Programmreihenfolge in der Hardware ermöglicht. Alle Merkmale ermöglichen wiederum eine bessere Hardwareskalierbarkeit für Out-of-order-Prozessorentwürfe mit breiter Ausgabe.
(0) Einleitung
Das herkömmliche Paradigma zum Definieren der Architektur eines in Hardware/Software co-entworfenen Prozessors nimmt an, dass Co-Entwurfs-Verfahren mit einem Softwarecodeoptimierer durch speziell definierte ISA-Merkmale angewendet werden, um in Hardware ein Konzept einer neuen Befehlsebenenparallelität (ILP-Konzept) zu ermöglichen, das sich von den aktuellen Mainstream-Out-of-order-Pipelines in Bezug auf die Prinzipien der Organisation und/oder der ILP-Ausnutzung drastisch unterscheiden muss. Allerdings ist keiner der früheren Versuche im Vergleich zu herkömmlichen reinen Hardware-Out-of-order-Pipelines in Bezug auf die Leistungsfähigkeit und/oder Effizienz konkurrenzfähig.
Die Ausführungsformen der Erfindung beruhen auf einem neuen Paradigma für den Hardware/Software-Co-Entwurf, der stattdessen auf die Implementierung einer Out-of-order-Pipeline gerichtet ist. Die Optimierungen in der Hardwarepipelineimplementierung enthalten:
ISA-optimierte Out-of-order-Pipeline mit VLIW-Frontend und Ausscheide/Festschreib-Einheiten
ISA-optimierte Hardwareregisterumbenennung
ISA-optimierte Planereinstelllogik und Planereinstellungspipeline
ISA-optimierte Befehlsabbruch-Einstelllogik und Befehlsabbruch-Einstellungspipeline
kombinierte Planereinstelllogik und Abbrucheinstelllogik
kombinierte Planeraufwecklogik und Abbruchlogik
verzögerte Hardwareregisterumbenennung
nicht spekulative frühe Absendung von Befehlen
vollständig partitionierte Organisation einer optimierten Out-of-order-Pipeline
partitionierte Befehlszuweisungseinheit
Verringerung der Zuweisungsports (Schreibports) in einer optimierten Out-of-order-Pipeline
Out-of-order-Zuweisung einer Out-of-order-Maschine in optimierter Pipeline
VLIW-Codeplanung mit verbesserter Hardware für optimierte Out-of-order-Pipeline
ISA-optimierte Befehlsausscheideeinheit
ISA-optimierte geclusterte Organisation der Out-of-order-Pipeline.
Die meisten der Out-of-order-Pipeline-Optimierungen beruhen direkt auf neuen, speziell definierten ISA-Merkmalen. Die neue ISA kann entweder privat oder öffentlich sein. Wie erwähnt wurde, kann die dBT-Technologie verwendet werden, um von vorhandenen Binärcodes (z. B. IA-Binärcodes) in die neue private ISA zu übersetzen und um die vollständige Binärkompatibilität mit vorhandener Software zu ermöglichen. Alternativ ist ein Optimierungscompiler für die neue öffentliche ISA erforderlich, um ausführbare Binärdateien zu erzeugen.
Ohne Verlust der Allgemeinheit nehmen die im Folgenden beschriebenen Ausführungsformen die Verwendung der dBT-Technologie mit der optimierten Out-of-order-Pipeline an. Die Ausführungsformen der Erfindung erlegen der dBT-Implementierung keine speziellen Anforderungen auf und die spezifischen Einzelheiten des dBT-Betriebs sind im Folgenden nicht diskutiert, um eine Verdeckung der zugrundelegenden Prinzipien der Erfindung zu vermeiden.
(1) Spezielle ISA-Anforderungen für die optimierte Out-of-order-Pipeline
Wie in 8 dargestellt ist, ist die private ISA für die optimierte Out-of-order-Pipeline in einer Ausführungsform ein Befehlsformat 800 fester Länge im RISC-Stil. Insbesondere kann eine Lade-Speicher-ISA genutzt werden, in der jeder Befehl fester Länge ein 3-Adressen-Register-Opcode/Operanden-Format 801 (z. B. dst, src1, src2) und explizite Befehlstypinformationen 802 (z. B. Speicher, ALU, Steuerung) enthält. Außerdem enthält jeder Befehl ein Stoppbit 803, das, wenn es gesetzt ist, explizit die Grenzen von in der privaten ISA verwendeten Very Long Instruction Words (VLIWs) kennzeichnet.
Ein Merkmal der privaten ISA ist, dass sie einen Satz von Befehlsgruppierungsbeschränkungen definiert, die Folgendes enthalten können:
einzelne RISC-Befehle (wie etwa der in 8 gezeigte) müssen zu einer In-order-Sequenz von Gruppen kombiniert werden, die üblicherweise Very Long Instruction Words (VLIWs) genannt werden, für die ein Beispiel in 9 gezeigt ist. Insbesondere veranschaulicht 9 mehrere einzelne Befehle 901–907, die in einem einzelnen VLIW-Format gruppiert sind. Somit umfasst der private ISA-Binärcode in einer Ausführungsform eine In-order-Sequenz von VLIWs. Die einzelnen RISC-Befehle in einem VLIW werden gelegentlich als ”Silben” bezeichnet.
VLIWs können eine variable Anzahl von Silben bis zu einem durch die Architektur definierten Maximalwert enthalten. Somit ist die Länge jedes VLIW, aber mit einer Granularität der RISC-Silben fester Länge in sich, variabel. Ein Einstellwert eines Stoppbits 803, das in jeder Silbe vorhanden ist, codiert explizit Kennzeichnungen der Grenzen der VLIWs und wird von der Hardwarepipeline zum Identifizieren getrennter VLIWs verwendet. Für die Anzahl der Symbole eines bestimmten Typs innerhalb jedes VLIW kann eine Grenze (z. B. nicht mehr als ein Steuerbefehl pro VLIW) spezifiziert werden.
In einer Ausführungsform haben Silben innerhalb eines VLIW keine Registeroperandenabhängigkeiten mit wahrem Datenfluss (Lesen-nach-Schreiben (”R-A-W”)) oder mit falschem Ausgabedatenfluss (Schreiben-nach-Schreiben (”W-A-W”)) voneinander. Innerhalb eines VLIW können falsche Datenfluss-Gegenabhängigkeiten (z. B. Schreiben-nach-Lesen (”W-A-R”)) zulässig sein (siehe z. B. 11A–B und der dazugehörende Text darunter). Diese Beschränkungen bedeuten effizient, dass es außer für Speicheroperationen keine Programmordnungsbeziehungen zwischen Silben in einem VLIW gibt.
In einer Ausführungsform folgen VLIWs der Programmreihenfolge. Das heißt, eine Silbe in einem gegebenen VLIW kann von einer Silbe in einem anderen vorhergehenden VLIW, das in der Programmreihenfolge der VLIWs älter ist (d. h. früher abgerufen wurde), irgendeine Datenflussabhängigkeit (R-A-W, W-A-R oder W-A-W) besitzen.
In einigen Ausführungsformen der privaten ISA kann die relative Position einer Silbe in einem VLIW den Typ der Silbe definieren. Zum Beispiel können Befehle eines gegebenen Typs in einem VLIW in Bezug auf Befehle desselben Typs und in Bezug auf Befehle der anderen Typen streng geordnet sein. Außerdem kann die Position eines Symbols einen bestimmten Befehlsabsendeport (d. h. einen Hardware-Pipelineabschnitt) in der superskalaren Pipeline (z. B. ALU0, ALU1 usw.), zu der die Silbe durch Hardware gelenkt werden muss, definieren. Zum Beispiel ist der Befehl 901 in 9 eine Additionsoperation, die auf der Grundlage ihrer Position zur alu0 gelenkt werden kann. In einigen Ausführungsformen können Steuerbefehle (z. B. wie etwa eine in 9 gezeigte Verzweigung BRC) nur bestimmte zulässige relative Positionen in dem VLIW-Code belegen.
In 9 ist ein bestimmtes VLIW gezeigt, das bis zu 7 Silben enthält. Es ist gezeigt, dass es eine Steuersilbe 907, (bis zu) zwei Gleitkommavektorsilben 905–906, (bis zu) zwei Speichersilben (Lade-, Speichersilbe) 903–904 und (bis zu) zwei Ganzzahl-ALU-Silben 901–902 aufweist. Ein gesetztes Stoppbit 803 in der Steuersilbe (BRC-Silbe) kennzeichnet die Grenze der VLIW-Instanz.
(2) ISA-optimierte Out-of-order-Pipeline mit VLIW-Frontend und Ausscheide/Festschreib-Einheiten
Im Folgenden werden die in der Ausführungsform genutzten Hardwareoptimierungen mit einer herkömmlichen Out-of-order-Pipeline-Implementierung verglichen. In 10A–B ist eine Struktur auf höherer Ebene der optimierten Out-of-order-Pipeline mit der herkömmlichen Out-of-order-Pipeline nebeneinander dargestellt. Ein Unterschied zwischen den zwei Pipelines ist, dass die optimierte Pipeline anstelle der superskalaren In-order-Frontend-Einheiten 1001 bzw. der superskalaren In-order-Ausscheideeinheiten 1003 in der herkömmlichen Pipeline die In-order-VLIW-Frontend-Einheiten 1011 und die Ausscheide/Festschreib-Einheiten 1013 verwendet. In einer Ausführungsform arbeiten die Einheiten der optimierten Out-of-order-Pipeline in einem VLIW pro Taktzyklus.
Wieder anhand von 1B können die Frontend-Einheiten 1001 und 1011 die in der Frontend-Einheit 130 gezeigten Komponenten enthalten; können die Datenflussmaschinen 1002 und 1012 Komponenten von der Ausführungsmaschineneinheit 150 (z. B. in einer Ausführungsform mit Ausnahme von 154) und von der Speichereinheit 170 enthalten; und können die Ausscheideeinheiten 1003 und 1013 Komponenten von der Ausscheideeinheit 154 enthalten.
In einer Ausführungsform weist die optimierte Pipeline die Out-of-order-Silben von nicht mehr als einem VLIW pro Taktzyklus zu. Anders als bei der dynamisch erzeugten Zuweisungs-”Zeile” von μops in der herkömmlichen Pipeline kann ein VLIW mit einer Garantie, dass ISA-Beschränkungen während der Gruppierung der RISC-Befehlssilben in dem VLIW angewendet werden, durch den dBT-Optimierer statistisch im Voraus definiert werden und explizit für die Hardware bereitgestellt werden.
Nach der Zuweisung zu der dynamischen Datenfluss-Out-of-order-Maschine 1012 in der optimierten Pipeline wird ein VLIW in seine getrennten Silben zerlegt, so dass sie die Maschine auf ähnliche (aber nicht gleiche) Weise unabhängig planen kann, wie die Datenflussmaschine 1002 getrennte μops in der herkömmlichen Out-of-order-Pipeline plant.
(3) Grundorganisation der Out-of-order-Maschinen-Zuweisung in der optimierten Pipeline
11A veranschaulicht ein Beispiel einer superskalaren Zuweisungs-”Zeile” von Mikrooperationen (”μops”) in einem herkömmlichen Out-of-order-Prozessor nebeneinander mit einer entsprechenden Entität in der optimierten Out-of-order-Pipeline, dem VLIW, in 11B.
Eine superskalare Zuweisungszeile von μops kann zwischen den μops, die sich aus einer Umsetzung einer gültigen Makrobefehlssequenz (ISA-Sequenz) in dem Prozessor-Frontend in Mikrocode ergeben, nahezu irgendeine der Registerabhängigkeiten R-A-W (als punktierter Pfeil 1101 gezeigt, der die Ausgabe von μop0 mit der Eingabe von μop1 verbindet), W-A-R (als der Strichlinienpfeil 1102 gezeigt, der die Ausgabe der μop2 mit der Eingabe der μop1 verbindet) und W-A-W (als Strichpunktpfeil 1103 gezeigt, der μop0 verlässt und bei der Ausgabe von μop3 ankommt) enthalten. Somit muss die herkömmliche Out-of-order-Pipeline in jeder Zuweisungszeile der μops auf alle möglichen Intra-Zeilen-Abhängigkeiten (oder ”Inline”-Abhängigkeiten) prüfen und sie richtig behandeln. Außerdem muss die herkömmliche Zuweisungshardware die ursprünglichen Programmordnungsrelationen zwischen den μops in einer Zeile verfolgen und richtig durchsetzen. Die Anforderungen verkomplizieren die Implementierung der Zuweisungshardware in einer herkömmlichen Out-of-order-Pipeline wesentlich und behindern die Hardwareskalierbarkeit für breitere Out-of-order-Prozessorentwürfe stark.
Im Gegensatz dazu muss eine entsprechende Zuweisungsentität in der optimierten Out-of-order-Pipeline unter Verwendung einer VLIW-Implementierung, wie in 11B gezeigt ist, die früher beschriebenen Beschränkungen einer privaten ISA an zulässige Abhängigkeiten zwischen den Silbenbefehlen in einem VLIW befolgen. Die Beschränkungen sind typisch für herkömmliche VLIW-ISAs und verbieten wahre Datenflussabhängigkeiten (R-A-W-Abhängigkeiten) und falsche Ausgabeabhängigkeiten (W-A-W-Abhängigkeiten) zwischen Silben in einem VLIW. Wie durch den Strichlinienpfeil 1112 angegeben ist, der den Ausgang von I2 mit dem Eingang von I1 in 11B verbindet, sind falsche Gegenabhängigkeiten (W-A-R) zwischen Silben zulässig. Die privaten ISA-Definitionen bedeuten außerdem, dass es bis auf Speicherbefehle keine Programmordnungsrelationen zwischen verschiedenen Silben in einem VLIW gibt. Somit können die Silben von einem einzelnen VLIW durch die Out-of-order-Pipeline-Hardware in irgendeiner Reihenfolge in Bezug zueinander und ohne irgendwelche Komplikationen für die Richtigkeit ihrer Out-of-order-Verarbeitung verarbeitet werden. Es liegt in der Verantwortung der dBT-Software, den ursprünglichen Binärcode in eine vollständige semantische Entsprechung und in gültigen privaten ISA-Code, der alle Beschränkungen der optimierten Out-of-order-Pipeline befolgt, zu übersetzen.
(4) ISA-optimierte Hardwareregisterumbenennung
Wie in 12B dargestellt ist, stützt sich die hier beschriebene optimierte Pipeline ähnlich einer herkömmlichen Out-of-order-Pipeline auf eine Hardware-Registerumbenennungseinheit 1213 zum Abbilden der privaten logischen ISA-Operanden für logische Register auf eine größere Anzahl physikalischer Register, die in der Mikroarchitektur verfügbar sind. Ein Zweck der Registerumbenennung ist es, falsche W-A-R- und W-A-W-Registerabhängigkeiten zu beseitigen und somit das Niveau der ausnutzbaren Parallelität in dem ausgeführten Code zu erhöhen.
Die 12A–B bieten einen Vergleich der Registerumbenennung in einer herkömmlichen Pipeline (12A) und in einer optimierten Out-of-order-Pipeline (12B). Wie dargestellt ist, ist in der herkömmlichen Pipeline eine erhebliche Menge zusätzlicher Schaltungsanordnung einschließlich der Operandenvergleichs-Schaltungsanordnung 1201 und der Operandenüberschreib-Schaltungsanordnung 1202 (die üblicherweise als ein großer Multiplexer implementiert wird) erforderlich, um Abhängigkeiten aufzulösen. Im Gegensatz zu 12A sind in der in 12B gezeigten optimierten Pipeline nur die Registerumbenennungstabellen 1213 erforderlich. Die Vereinfachungen und Verbesserungen beruhen auf der Tatsache, dass es keine R-A-W- und W-A-W-Abhängigkeiten zwischen Silben in einem VLIW gibt. Somit braucht die Umbenennungseinheit nicht auf die Abhängigkeiten zu prüfen und sie durchzusetzen (da sie nicht existieren). Die Vereinfachung beseitigt die Komparatoren 1201 für Operanden logischer Register und die entsprechenden Inline-Multiplexer 1202 für Operanden physikalischer Register in der Lesephase der Registerumbenennung. Diese letztere Hardwareverringerung ist besonders erheblich, da die Multiplexer 1202 große drahtdominierte Bereiche belegen und die Gesamtlatenzzeit der Registerumbenennungsstufe erhöhen. Außerdem sind die beseitigten Multiplexer in Prozessorentwürfen mit breiterer Ausgabe der am schlechtesten skalierbare Teil der Umbenennungseinheit.
In einer Ausführungsform werden die falschen W-A-R-Gegenabhängigkeiten, die in einem VLIW zulässig sind, ähnlich der herkömmlichen Out-of-order-Pipeline in der optimierten Pipeline dadurch beseitigt, dass die Registerumbenennungs-Schreibphase in Bezug auf die Registerumbenennungs-Lesephase um einen halben Taktzyklus verzögert wird.
Die Hardwareimplementierung der Registerumbenennungs-Schreibphase in der optimierten Out-of-order-Pipeline wird durch eine garantierte Abwesenheit falscher W-A-W-Ausgabeabhängigkeiten zwischen Silben in einem Zuweisungs-VLIW vereinfacht, so dass die Registerumbenennungshardware nicht auf die Abhängigkeiten zu prüfen braucht und sie vor der Aktualisierung der Registerumbenennungstabellen 1213 richtig behandeln kann.
(5) ISA-optimierte Planereinstelllogik und Planereinstellungspipeline
Die nächste Verbesserung, die die optimierte Out-of-order-Pipeline in ihrem Zuweisungssegment ermöglicht, bezieht sich auf die Einstelllogik des Datenflussplaners. Die 13A–B bieten einen Vergleich der Zuweisungs- und der Einstelllogik in einer herkömmlichen Pipeline (13A) und in einer optimierten Out-of-order-Pipeline (13B). Insbesondere veranschaulicht 13A eine serielle Anordnung einer Registerumbenennungslogik 1301, einer Planereinstelllogik 1302 und einer Planerlogik 1303 sowie einer Abbrucheinstelllogik 1304 und einer Abbruchlogik 1305. 13B veranschaulicht eine verbesserte parallele Anordnung für die Registerumbenennungslogik 1311, für die Planereinstelllogik 1312 und für die Abbrucheinstelllogik 1314 sowie für die Planerlogik 1313 und für die Abbruchlogik 1315.
Wie oben erwähnt wurde, beseitigt irgendeine Out-of-order-Pipeline falsche W-A-R und W-A-W aus dem Zuweisungscode, um ihre ausnutzbare Parallelität zu erhöhen, und betrachtet sie nur wahre Datenflussabhängigkeiten (R-A-W). Allerdings zwingen die Komplexität und die Zeitkritikalität des Detektierens und Beseitigens falscher Abhängigkeiten innerhalb der Zuweisungszeile von μops in einer herkömmlichen Out-of-order-Pipeline sie, die Planereinstelllogik 1302 in Bezug auf die Registerumbenennungslogik 1301 zu serialisieren. Die Registerumbenennungslogik 1301 beseitigt die falschen Abhängigkeiten und die Planereinstelllogik 1302 verwendet ihre Ergebnisse, um nur die wahren R-A-W-Datenflussabhängigkeiten zu betrachten (Einstellung). Allerdings erhöht diese Vereinfachung die Länge der Zuweisungspipeline und verzögert sie den frühesten Zeitpunkt, zu dem ein Zuweisungsbefehl abgesendet werden kann.
Im Gegensatz dazu braucht die in 13B gezeigte Ausführungsform der optimierten Out-of-order-Pipeline keine Intra-VLIW-Register-Abhängigkeiten zu behandeln, so dass die Planereinstelllogik 1312 die Planungseinstellung parallel zu der durch die Registerumbenennungslogik 1311 ausgeführten Registerumbenennung ausführt. Die Implementierung verringert die Gesamtlänge der Zuweisungspipeline (beseitigt Stufen) und ermöglicht das frühere Absenden von Befehlen, was die Leistungsfähigkeit nach einer Wiederherstellung von einer Verzweigungsfehlvorhersage und nachdem der Befehls-Cache einen Fehltreffer erzielt verbessert. Außerdem verbessert die kürzere Zuweisungspipeline die Nutzung der Betriebsmittel der Out-of-order-Maschine, was die minimale Betriebsmittel-Durchlauflatenzzeit verringert.
In einer Ausführungsform der optimierten Zuweisungspipeline verwendet die Planereinstelllogik 1312 als Eingabeinformationen (die z. B. durch Operanden logischer Register indiziert sind) anstelle größerer physikalischer Registerkennungen logische ISA-Registerkennungen der Operanden einer Silbe. Außerdem braucht die Planereinstelllogik 1312 nicht einmal die wahren R-A-W-Datenflussabhängigkeiten zwischen Silben in einem zuweisenden VLIW zu prüfen. Diese Merkmale ermöglichen, dass der typische inhaltsadressierbare Speicher (CAM), der in der Planereinstellung verwendet wird, durch eine einfachere und kleinere tabellenbasierte Planereinstelllogik 1312 ersetzt wird. In einer Ausführungsform bildet jede Einstelltabelle jeden Planereintrag mit dem neuesten Erzeugerbefehl in der Zuweisungsreihenfolge für ein logisches Register auf ein entsprechendes logisches Register ab; falls der neueste Erzeugerbefehl für ein logisches Register bereits ausgeführt wird, berichtet die Einstelltabelle das Register als eines ohne Abhängigkeiten von irgendeinem Befehl bei dem Planer. Die verbesserte Planereinstelllogik 1312 muss weiterhin falsche W-A-R-Gegenabhängigkeiten zwischen Zuweisungssilben behandeln, was dadurch implementiert werden kann, dass die Planereinstelllogik-Schreibphase in Bezug auf die Planereinstelllogik-Lesephase um einen halben Taktzyklus verzögert wird. Wie bei der Registerumbenennung (12B) braucht die Planereinstelllogik 1312 außerdem keine falschen W-A-W-Ausgabeabhängigkeiten während der Schreibphase zu behandeln, da solche falschen Ausgabeabhängigkeiten in der beschriebenen privaten ISA beschränkt sind.
(6) ISA-optimierte Befehlsabbruch-Einstelllogik und Befehlsabbruch-Einstellungspipeline
Viele aktuelle Out-of-order-Pipelines implementieren die spekulative Absendung eines Befehls in Abhängigkeit von Ladeoperationen unter der Annahme, dass der Ladevorgang in dem Daten-Cache einen Treffer erzielt, was der statisch häufigste Fall für die Ausführung des Ladevorgangs ist. Diese Optimierung ermöglicht, dass die Verbraucheroperationen geladene Daten früher empfangen, als wenn sie nicht spekulativ abgesendet würden. In einem seltenen Fall, wenn ein Ladevorgang in dem Daten-Cache einen Fehltreffer erzielt, müssen alle spekulativ abgesendeten abhängigen Operationen in der Out-of-order-Pipeline selektiv abgebrochen werden. Die Operationen werden später durch die Out-of-order-Maschine nicht spekulativ erneut abgesendet (erneut abgespielt), wenn der Ladevorgang, der einen Fehltreffer erzielt hat, Daten von anderen Ebenen der Speicherhierarchie des Prozessors liefert.
Die spekulative Absendung von Ladeverbrauchern wird durch die Befehlsabbruchlogik 1305 ermöglicht, die Abhängigkeiten von μops, die der Out-of-order-Maschine bei Ladevorgängen zugewiesen werden, einschließlich ihrer indirekten Abhängigkeiten über andere Nicht-Ladevorgangs-μops in dem Planer verfolgt. Die Abhängigkeitsinformationen werden verwendet, um betroffene abgesendete Befehle wahlweise abzubrechen, falls ein Ladevorgang in dem Daten-Cache einen Fehltreffer erzielt. Ähnlich der Datenflussplanereinstellung führt die herkömmliche Out-of-order-Pipeline die Abbruchlogikeinstellung 1304 nach der Registerumbenennung 1301 aus und verwendet sie sowohl die umbenannten Registerinformationen von 1301 als auch die Datenflussplaner-Einstellinformationen von 1302 und frühere Abbrucheinstellinformationen von 1305, um die Funktion der Abbrucheinstelllogik 1304 zu vereinfachen. Wegen der Notwendigkeit, die indirekten Abhängigkeiten von Ladevorgängen über die Zuweisungszeile der μops zu bestimmen und zu verfolgen, was serialisierte Zugriffe auf mehrere Hardwarestrukturen und die komplexe Vereinigung von Zwischen-Einstellinformationen enthält, ist die Einstellfunktion weiterhin kompliziert.
Ganz ähnlich der Verbesserung der Planereinstelllogik 1312 verbessert die optimierte Out-of-order-Pipeline die Abbruchlogikeinstellung 1314, die parallel zu der Registerumbenennung 1311 und mit der Planereinstellung 1312 implementiert wird, und dies auf eine tabellenbasierte, durch Operanden logischer Register indizierte Weise (d. h., wie oben für 1312 diskutiert wurde, CAM-frei). Die Verbesserung beruht ähnlich auf der garantierten Abwesenheit von R-A-W- und W-A-W-Abhängigkeiten zwischen Silben in einem zuweisenden VLIW.
Die abbruchspezifische Identifizierung und Verfolgung indirekter Abhängigkeiten von Ladebefehlen wird durch die Abwesenheit von R-A-W- und von W-A-W-Abhängigkeiten in einem VLIW in der optimierten Pipeline ebenfalls stark vereinfacht, so dass die Gesamtkomplexität und Gesamtlatenzzeit der Einstellung der Abbruchlogik 1314 gleich jener für die Planereinstelllogik 1312 wird. W-A-R-Abhängigkeiten werden durch Verzögern der Schreibphase der Abbruchlogikeinstellung 1314 um einen halben Taktzyklus in Bezug auf ihre Lesephase ähnlich behandelt. In einer Ausführungsform kann die Schreibphase der Abbruchlogikeinstellung 1314 die Ergebnisse der Lesephase der Abbruchlogikeinstellung 1314 als eine der Eingaben verwenden.
(7) Kombinierte Planereinstell- und Abbrucheinstelllogik
Die Gesamtoptimierungen der Abbrucheinstelllogik 1314 ermöglichen, dass sie in der optimierten Out-of-order-Pipeline mit der Planereinstelllogik 1312 in einer einzelnen Tabelle kombiniert wird, die durch Kennungen logischer Register der Operanden einer Silbe adressierbar (indiziert) ist. Zusätzlich beruht das Kombinieren auf der allgemeinen Tatsache, dass alle indirekten Datenflussabhängigkeiten immer vor direkten Datenflussabhängigkeiten, wie sie auf die indirekten Abhängigkeiten von Ladevorgängen, die in den Befehlsabbruchinformationen enthalten sind, angewendet werden, aufgelöst werden.
(8) Kombinierte Planeraufweck- und Abbruchlogik
Außerdem können die Befehlsabbruchinformationen anstatt in einer getrennten Hardwarestruktur wie bei herkömmlichen Out-of-order-Pipelines nun zusammen mit den Informationen über die wahre Datenflussabhängigkeit (R-A-W-Abhängigkeitsinformationen) für die Befehle in einer Aufwecklogik des Datenflussplaners 1313 gehalten werden. Außerdem beruht die Optimierung auf der allgemeinen Tatsache, dass alle indirekten Datenflussabhängigkeiten immer vor direkten Datenflussabhängigkeiten, wie sie auf die indirekten Abhängigkeiten von in den Befehlsabbruchinformationen enthaltenen Ladevorgängen angewendet werden, aufgelöst werden.
All dies bedeutet, dass die optimierte Out-of-order-Pipeline die Notwendigkeit einer getrennten Befehlsabbrucheinstell- und Befehlsverfolgungslogikhardware, die einen wesentlichen Leistungs- und Flächenbedarf in einer herkömmlichen Out-of-order-Maschine besitzt, vollständig beseitigt, während sie weiterhin vollständig in der Lage ist, die selektiven Befehlsabbruchfunktionen auszuführen.
(9) Verzögerte Hardwareregisterumbenennung
Eine weitere Optimierung der Zuweisungspipelineimplementierung beruht auf der Tatsache, dass die oben beschriebenen Verbesserungen des Planers 1312–1313 und der Abbrucheinstelllogik 1314 die Kritikalität der Registerumbenennungsstufe in der Out-of-order-Pipeline beseitigen.
Zur Referenz erfordern herkömmliche Out-of-order-Pipelines, dass die Registerumbenennung 1301 so früh wie möglich abgeschlossen wird. Dies ist erforderlich, da die nachfolgenden Funktionen der Planereinstellung 1302 und der Abbruchlogikeinstellung 1304 von den Informationen von der Umbenennungsstufe abhängen.
In der neuen, optimierten Out-of-order-Pipeline kann die Registerumbenennungsphase 1311 verzögert werden, bis die Informationen über die umbenannten Register erstmals benötigt werden, d. h., bis bevor erstmals ein Befehl von dem Datenflussplaner in der Pipeline abgesendet werden kann. Die verzögerte Registerumbenennung 1311 ermöglicht im Vergleich zu der herkömmlichen Pipeline die spätere Zuweisung freier physikalischer Zielregister, so dass eine minimale Durchlauflatenzzeit physikalischer Register verkürzt wird und eine physikalische Registerdatei mit einer gegebenen Größe besser genutzt wird. Die Beseitigung der Kritikalität der Registerumbenennung kann ebenfalls verwendet werden, um die physikalische Auslegung der Out-of-order-Maschine zu optimieren, da die Anforderungen für die Anordnung von Registerumbenennungstabellen in Bezug auf die anderen Hardwarestrukturen in der Zuweisungspipeline nun gelockert werden können.
(10) Nichtspekulative frühe Absendung von Befehlen
Aktuelle Out-of-order-Prozessoren können die frühe Absendung von Zuweisungsbefehlen implementieren, die parallel zu der Planereinstell- und mit der Befehlsplanungsphase ihrer Pipelines ausgeführt wird. Die frühe Absendung von Befehlen verbessert die Prozessorleistungsfähigkeit, da viele Zuweisungsbefehle, insbesondere nach einer Wiederherstellung von einer Verzweigungsfehlvorhersage oder nach einem Befehls-Cache-Fehltreffer, tatsächlich gelesen werden, um zu ihrer Zuweisungszeit abgesendet zu werden. Allerdings sind die Informationen in Bezug auf die Befehlsbereitschaft zu dieser frühen Stufe in der herkömmlichen Pipeline nicht verfügbar. Im Ergebnis führt die Pipeline das frühe Absenden spekulativ aus, indem sie annimmt, dass irgendein Zuweisungsbefehl zu seiner Zuweisungszeit bereit sein kann.
Später in der herkömmlichen Pipeline prüft der Prozessor, um zu bestimmen, ob der spekulativ abgesendete Befehl tatsächlich gelesen wird, wobei er den Befehl abbricht, wenn das nicht der Fall ist. Der Abbruch falsch spekulierter früh abgesendeter Befehle erfordert eine spezielle Hardwareunterstützung und bringt einen zusätzlichen Leistungsorganisationsaufwand mit sich.
Die oben beschriebenen Optimierungen der Planereinstelllogik 1312 und der Zuweisungspipeline machen die Befehlsbereitschaftsinformationen leicht früh genug verfügbar, so dass die optimierte Out-of-order-Pipeline die nicht spekulative frühe Absendung nur der bereiten Befehle ausführen kann und somit den Leistungsorganisationsaufwand der Abbrüche sowie die zugeordnete Abbruchhardware beseitigen kann.
(11) Vollständig partitionierte Organisation einer optimierten Out-of-order-Pipeline
Eine weitere wesentliche Verbesserung der optimierten Hardwareimplementierung der Out-of-order-Pipeline beruht auf der Ausnutzung einer ISA-definierten streng relativen Reihenfolge zwischen Befehlen (Silben) verschiedener Typen in einem VLIW (z. B. wie etwa ALU, Speicher, Steuerung, usw.) sowie auf der definierten Abwesenheit spezifischer Programmordnungsrelationen zwischen Silben in einem VLIW außer für Speicheroperationen.
Außerdem definiert eine Ausführungsform der privaten ISA die streng relative Ordnung von Befehlen desselben Typs innerhalb eines VLIW. Das heißt, falls in einem VLIW mehrere Befehle desselben Typs (z. B. zwei ALU-Befehle) vorhanden sind, definiert eine Ausführungsform der ISA die spezifischen Absendeports, zu denen jeder der Befehle durch Hardware gelenkt werden muss.
Für mehrere Speicherbefehle in einem VLIW definiert eine Ausführungsform der ISA ihre relative Programmordnung von Speicherzugriffen in Abhängigkeit von dem Speicherabsendeport, zu dem sie gelenkt werden müssen. Zum Beispiel enthält eine VLIW-Silbe, die dem Speicherabsendeport 0 (MEM0) zugeordnet ist, in einer Ausführungsform immer einen Speicherbefehl, der in der Programmreihenfolge relativ zu einer VLIW-Silbe, die dem Speicherabsendeport 1 (MEM1) zugeordnet ist, älter ist.
Eine Ausführungsform der privaten ISA ermöglicht eine vollständig partitionierte Implementierung der optimierten Out-of-order-Pipeline, wie sie in 14B gezeigt ist. Jede Pipelinepartition oder jeder Hardwarepipelineabschnitt ist einem bestimmten Hardwareabsendeport, z. B. ALU0, ALU1, MEM0, MEM1, CONTROL usw. zugeordnet. Die Pipelinepartitionen fungieren entweder unabhängig oder lose miteinander gekoppelt, das den Prozessorhardwareentwurf, die Prozessorhardwarevalidierung und die Prozessorhardwarefertigung wesentlich vereinfacht. Außerdem ermöglichen die Partitionen einfache, rationalisierte und stärker parallele physikalische Auslegungen für die Out-of-order-Maschinen-Implementierung.
In einer Ausführungsform wird ein codiertes VLIW im Speicher in kompakter Form dargestellt, wie sie in der privaten ISA definiert ist. Das heißt, ein VLIW kann nicht alle möglichen Silbentypen enthalten oder es kann nicht so viele Silben desselben Typs geben, wie es Hardwareabsendeports für den Befehlstyp gibt; allerdings belegen diese fehlenden Silben keinen Platz im Befehlsspeicher. In einer Ausführungsform erweitert die Frontend-Pipeline 1101 ein kompaktifiziertes VLIW und ordnet sie alle seine aktuellen Silben (Befehle) in entsprechenden Pipelinepartitionen an. Von diesem Punkt in der optimierten Out-of-order-Pipeline werden die Befehle nur durch Pipelinepartitionen verarbeitet, zu denen sie in Übereinstimmung mit den privaten ISA-Definitionen gelenkt wurden.
In einer Ausführungsform ermöglicht diese Pipelinepartitionierung in der optimierten Pipeline im Vergleich zu der Herkömmlichen die Beseitigung großer Multiplexer und Kreuzschienenschalter. Dies geschieht, da die relative Ordnung der Befehle, die in der privaten ISA für ein VLIW definiert ist, genau an die relative Topologie der Hardwarestrukturen und ihrer Lese-/Schreibports in der Out-of-order-Prozessor-Anordnung angepasst ist, so dass über die gesamte Pipeline keine zusätzliche Multiplexierung oder Lenkung von Befehlen oder ihrer Steuerfelder zu bestimmten Hardewarestrukturen erforderlich ist.
In den 14A–B ist ein Vergleich einer herkömmlichen und einer optimierten Out-of-order-Pipeline von der Stufe des Lesens bis zu der Stufe des Ausführens der Warteschlange decodierter Befehle gezeigt. Insbesondere veranschaulicht 14A eine Sequenz von μops 0–3, die über einen ersten Kreuzschienenschalter 1401 zu der Umbenennungs/Zuweisungs-Stufe 1404 geschaltet werden. Ein zweiter Kreuzschienenschalter 1402 koppelt μops von der Umbenennungs/Zuweisungs-Stufe 1404 zu der Planungsstufe 1405, die eine monolithische Reservierungsstation (RS) enthält. Ein dritter Kreuzschienenschalter 1403 innerhalb der Absendestufe koppelt die Planungsstufe 1405 mit den physikalischen Registerdateien 1406, um die Operanden der abgesendeten μops zu lesen, und mit den Ausführungsports 1407, an die die μops abgesendet werden.
Im Gegensatz dazu sind in 14B mehrere Kreuzschienenschalter und Multiplexer beseitigt. Insbesondere ist der Kreuzschienenschalter 1401 bei der Registerumbenennungsstufe 1404 beseitigt, der Operandenfelder logischer Register von Befehlen, die in ihrer Programmreihenfolge angeordnet sind, zu spezifischen Typen von Registerumbenennungstabellen (oder RAT) und zu spezifischen Lese- oder Schreibports in den Tabellen lenkt. Da die Ordnung der Silben in dem VLIW direkt an die RAT-Hardwaretopologie angepasst ist, wird diese Kreuzschiene in der optimierten Pipeline redundant. Somit werden die Befehle 0–3 in 14B direkt in die Umbenennungs/Zuweisungs-Stufe 1414 eingespeist. In einigen Ausführungsformen können in der privaten ISA bei Bedarf im Vergleich zu den herkömmlichen ISAs für Out-of-order-Prozessoren weniger Ordnungsbeschränkungen definiert werden, so dass die Kreuzschiene nicht vollständig beseitigt wird, aber ihre Komplexität, Leistung, Latenzzeit und Fläche wesentlich verringert werden.
Außerdem ist in 14B die Kreuzschiene 1402 bei der Planerzuweisungsstufe beseitigt, die in ihrer Programmreihenfolge angeordnete Befehle zu spezifischen Partitionen (oder logischen Abschnitten) des Datenflussplaners 1405 (oder der Reservierungsstationen, RS) lenkt. Da die Ordnung der Silben in einem VLIW direkt an die Hardwaretopologie der Partitionen 1415 des Datenflussplaners in 14B angepasst ist, wird diese Kreuzschiene 1402 in der optimierten Pipeline redundant. In einigen Ausführungsformen können in der privaten ISA bei Bedarf im Vergleich zu den herkömmlichen ISAs für Out-of-order-Prozessoren weniger Ordnungsbeschränkungen definiert werden, so dass die Kreuzschiene nicht vollständig beseitigt wird, aber ihre Komplexität, Leistung, Latenzzeit und Fläche wesentlich verringert werden.
Außerdem ist die Kreuzschiene 1403 bei der Befehlsabsendestufe beseitigt, die abgesendete Befehle von ihren Orten (Partitionen) in dem Datenflussplaner (RS) 1405 zu spezifischen physikalischen Registerdateien 1406 und zu ihren spezifischen Leseports sowie zu spezifischen Befehlsausführungsports 1407 lenkt. Da die relative Anordnung von Partitionen des Datenflussplaners 1415 genau an die Hardwaretopologie der Registerdateien 1416 und ihrer Leseports sowie an die Befehlsausführungsports 1417 angepasst ist, wird die Kreuzschiene in der optimierten Pipeline redundant.
Einige der aktuellen herkömmlichen Out-of-order-Prozessorpipelines implementieren ebenfalls eine partitionierte Organisation des Datenflussplaners (RS); allerdings ermöglicht ihnen dieses Merkmal nur, die spätere Kreuzschiene 1406 bei der Befehlsabsendestufe, nicht aber irgendwelche anderen Kreuzschienen, zu beseitigen. Außerdem müssen die herkömmlichen Out-of-order-Pipelines mit partitioniertem RS zusätzliche Hardwareeinheiten implementieren, die Zuweisungsbefehle zu richtigen Partitionen lenken und sicherstellen, dass die Nutzung verschiedener Befehlsausführungsports, die jeder der Partitionen zugeordnet sind, ausgeglichen ist. In einer Ausführungsform erfordert die optimierte Out-of-order-Pipeline nicht die zusätzlichen Partitionslastausgleichs-Hardwareeinheiten und stützt sie sich auf Codeoptimierersoftware, um den Ausführungsport-Lastausgleich in dem Binärcode, den sie erzeugt, auszuführen. Die letzteren Lastausgleichsinformationen werden implizit über die Silbenordnungsdefinitionen eines VLIW in einer zuvor erwähnten privaten ISA zu der optimierten Hardwarepipeline übermittelt.
Die beseitigten Multiplexer und Kreuzschienenschalter führen zu einer wesentlichen Verringerung der Latenzzeit (d. h. ermöglichen eine höhere Taktfrequenz), Leistung und Fläche in der optimierten Out-of-order-Pipeline. Da die Multiplexer und Schalter drahtdominierte Hardwarestrukturen sind und Drähte in den feineren Prozessen verhältnismäßig schlechter als Siliciumvorrichtungen verkleinert worden sind, wird die positive Wirkung bei künftigen feineren Siliciumherstellungsprozessen noch bedeutsamer.
Da die Fläche und die Latenzzeit der Hardwarestrukturen vom Kreuzschienenschalterstil bei einer linearen Erhöhung der Anzahl ihrer Eingänge/Ausgabe schlecht (etwa quadratisch) skalieren, ermöglicht die Beseitigung der Kreuzschiene für breitere Prozessorentwürfe eine bessere Skalierbarkeit der Hardwareimplementierung der optimierten Out-of-order-Pipeline. Es ist wichtig anzumerken, dass die optimierte Out-of-order-Pipeline weiterhin Multiplexer in der Frontend-Pipeline nutzen kann, um decodierte Befehle von einem erweiterten VLIW zu richtigen Pipelinepartitionen zu leiten. Außerdem kann sie weiter Multiplexer für die Umgehung von Operanden bei der Absende-, bei der Ausführungs- und bei der Rückschreibstufe der Pipeline (siehe 15) verwenden. In den verbleibenden Stufen wird die optimierte Out-of-order-Pipeline frei von Multiplexern und Kreuzschienenschaltern.
15 veranschaulicht eine Ausführungsform einer optimierten Out-of-order-Maschine mit einer Breite von 4 mit einem n-Eintrags-Datenflussplaner, die mehrere 4×-partitionierte Pipelinestufen enthält. Insbesondere enthält die dargestellte Ausführungsform eine 4×-partitionierte decodierte Befehlswarteschlange 1501 zum Speichern von 4 decodierten Befehlen (z. B. der Silben von einem VLIW); eine 4×-partitionierte Zuweisungseinheit 1502 zum Zuweisen von Befehlen zu Prozessorbetriebsmitteln; eine 4×-partitionierte n-Eintrags-Planeraufwecklogik und Reservierungsstation 1503 mit einem 4×-partitionierten Satz einer (n/4):1-Befehlsauswahllogik 1504; einen Satz physikalischer Registerdateien 1505, einer Operandenumgehungslogik 1506; und mehrere Funktionseinheiten 1505. In einer Ausführungsform gibt es für alle der vier Partitionen der Planeraufwecklogik und Reservierungsstationen 1503 insgesamt n Eingänge zum Speichern von n Befehlen, die auf die Ausführung warten, wobei jede der Partitionen n/4 der n Befehle speichert. Beispielhaft speichert jede der Partitionen 1503 für einen Wert von n = 32 (in 8 Einträgen) 32/4 oder 8 Befehle, wobei jede der Auswahllogikpartitionen 1504 aus einer 8-Eintrags-Aufwecklogikpartition 1503, die ihr in der Pipeline zugeordnet ist, einen von bis zu 8 bereiten Befehlen auswählen kann.
In einer Ausführungsform kann jede Partition der Planeraufwecklogik 1503 zum Speichern nur eines bestimmten Typs von Befehlen konfiguriert sein, um das Lenken dieser Befehle zu den Ausführungseinheiten 1507 zu vereinfachen. Zum Beispiel können die Partitionen Nr. 2 und Nr. 3 in 15 ALU-Befehle speichern und können die Partitionen Nr. 0 und Nr. 1 Speicherbefehle speichern (da diese Befehle leicht von den Partitionen zu ihren jeweiligen Ausführungseinheiten gelenkt werden).
Die Zuweisungslogik 1502 enthält zu jeder der 4 Partitionen in der Planeraufwecklogik nur einen Schreibport. Außerdem enthält die 4×-partitionierte Auswahllogik 1504 zu jeder der Partitionen 1503 einen Leseport und kann sie (z. B. in einer Ausführungsform unter Verwendung eines Satzes von vier 8:1-Multiplexern) vier Befehle pro Zyklus – einen von jeder der Partitionen 1503 – auswählen. Somit verringert die 4×-Partitionierung der Pipeline drastisch die zum Implementieren der Planeraufwecklogik 1503 und der Auswahllogik 1504 erforderliche Siliciumfläche, da jede Partition in der Planeraufwecklogik 1503 nur einen einzelnen Leseport und einen einzelnen Schreibport erfordert. Das heißt, jede Partition der Auswahllogik 1504 braucht nur in der Lage zu sein, (im Gegensatz zu n Befehlen, die sich in einer nicht partitionierten Implementierung mit einer Gesamtauswahlkomplexität von n:4 ergeben würden) von jeder der vier Partitionen einen von n/4 Befehlen mit einer Gesamtauswahlkomplexität von 4× ((n/4):1) auszuwählen. In einer Ausführungsform beobachtet die Auswahllogik 1504 alle möglichen Befehle, die ausgeführt werden können (d. h. deren Operanden bereit sind), wobei sie auf der Grundlage von Variablen wie etwa des Zuweisungsalters der Befehle und der Verfügbarkeit von Befehlsabsendeschlitzen für die zugeordnete Ausführungseinheit von jeder Partition einen Befehl zum Absenden auswählt.
In der besonderen in 15 dargestellten Ausführungsform gibt es zwei Speicherausführungskanäle (z. B. für Lade- und/oder Speicheradressenbefehle, die in die physikalische Registerdatei 1505, in die Operandenwertumgehungseinheit 1506 und in die Speicheradressen-Erzeugungseinheiten MEM0 und MEM1 1507 eingegeben werden) und zwei ALU-Kanäle.
Neben anderen Latenzzeit-, Leistungs- und Flächenvorteilen sichert die Planerpartitionierung für Prozessorentwürfe mit breiterer Ausgabe eine bessere Hardwareskalierbarkeit. Obwohl die Art der Planerskalierbarkeit nicht einzigartig für die optimierte Out-of-order-Pipeline ist und in einigen herkömmlichen Pipelines zu finden ist, wird sie in der optimierten Pipeline durch die Fähigkeiten, in der privaten ISA längere VLIW-Formate zu definieren und die längeren VLIWs durch dBT-Optimierersoftware mit Befehlen zu füllen, wesentlich erleichtert.
(12) Partitionierte Befehlszuweisungseinheit
Eine weitere Hardwareimplementierungsverbesserung, die sich aus der vollständig partitionierten Organisation der optimierten Out-of-order-Pipeline ergibt, bezieht sich auf die Implementierung der Befehlszuweisungseinheit 1502. Die Befehlszuweisungseinheit 1502 arbeitet während Zuweisungsstufen der Out-of-order-Pipeline und ist ebenfalls partitioniert, so dass jede ihrer Partitionen genau für eine Partition der optimierten Pipeline dient und ihr pro Taktzyklus nicht mehr als einen Befehl nur des Partitionstyps (z. B. ALU oder Speicher usw.) zuweist. Die partitionierte Zuweisungseinheit 1502 besitzt eine verringerte Hardwarekomplexität und Gesamtfläche zuzüglich einer viel besseren Skalierbarkeit für breitere Out-of-order-Prozessorentwürfe.
(13) Verringerung der Zuweisungsports (Schreibports) in der optimierten Out-of-order-Pipeline
In einer Ausführungsform kann die private ISA die maximale Anzahl an Befehlen eines spezifischen in einem VLIW zulässigen Typs beschränken. Die Beschränkungen können zur zusätzlichen Verringerung und Vereinfachung der Zuweisungshardwareeinheiten (wie oben diskutiert) und einiger verwandter Hardwarestrukturen in der optimierten Out-of-order-Pipeline verwendet werden.
Falls ein VLIW z. B., wie in 9 gezeigt ist, nicht mehr als zwei Speicheroperanden (zwei Ladevorgänge oder einen Ladevorgang und einen Speichervorgang oder zwei Speichervorgänge) enthalten kann, können solche kritischen und großen Strukturen in dem Speicherordnungspuffer (MOB) in 174 (siehe 1B) wie der Ladepuffer (LB) und der Speicherpuffer (SB) im Vergleich zu den MOBs in ähnlichen herkömmlichen Out-of-order-Pipelines eine verringerte Anzahl von Zuweisungsports (Schreibports) besitzen. Die herkömmlichen Pipelines müssen in Hardware die höchstmögliche Zuweisungsrate von Befehlen desselben Typs bereitstellen, da diese Rate nicht durch aktuelle herkömmliche ISAs (z. B. IA) beschränkt ist. Zum Beispiel müssen vorhandene Architekturen in der Lage sein, dem LB bis zu vier Ladevorgänge gleichzeitig zuzuweisen (in ihn zu schreiben). Die verringerte Anzahl von Schreibports zu MOB-Strukturen in der hier beschriebenen optimierten Pipeline führt zu einer erheblichen Flächen- und Leistungsverringerung.
(14) Out-of-order-Zuweisung der Out-of-order-Maschine in der optimierten Pipeline
In einer Ausführungsform wird eine bessere Nutzung der Hardwarebetriebsmittel in der optimierten Out-of-order-Pipeline im Ergebnis der Out-of-order-Zuweisung der Out-of-order-Maschine erzielt. Die Wirkung der Out-of-order-Zuweisung ergibt sich natürlich aus der Anforderung für den dBT-Optimierer, die privaten ISA-Beschränkungen an das Anordnen von Silben in VLIWs zu befolgen. Genauer kann es zwischen Silben in einem VLIW keine wahren Datenflussabhängigkeiten (R-A-W-Abhängigkeiten) und/oder falschen Ausgabeabhängigkeiten (W-A-W-Abhängigkeiten) geben. Der dBT-Optimierer erfüllt die Beschränkungen durch richtiges Umordnen z. B. von IA-Eingangsbefehlen, nachdem sie in die privaten RISC-Silben übersetzt worden sind, aber bevor sie in VLIWs gruppiert werden. Im Ergebnis der Umordnung des statischen Codes werden Verbraucherbefehle (abhängige Befehle) in nachfolgenden VLIW(s) in Bezug auf ihre Erzeugerbefehle angeordnet; außerdem werden die Verbraucherbefehle in der optimierten Out-of-order-Pipeline der Out-of-order-Maschine in Bezug auf die Zeit der Zuweisung ihrer Erzeuger erst in einem der nächsten Taktzyklen zugewiesen.
9 veranschaulicht eine beispielhafte Sequenz von Befehlen (z. B. übersetzten Silben) und zeigt die vorteilhaften Wirkungen der Out-of-order-Codevorausplanung (z. B. durch den dBT-Optimierer). Insbesondere wird für eine gegebene Hardwarekapazität ein Out-of-order-Befehls-”Fenster” 1600 genutzt. Silben werden auf der Grundlage ihrer Abhängigkeiten in das und aus dem Fenster verschoben. Zum Beispiel ist gezeigt, dass mehrere abhängige Befehle 1602 vor das Fenster (d. h. für eine spätere Ausführungszeit) verschoben werden, und ist gezeigt, dass andere, unabhängige Befehle 1601 in das Fenster (für eine frühere Ausführungszeit) verschoben werden.
Da ein abhängiger Befehl (frühestens) erst in dem nächsten Taktzyklus abgesendet werden kann, nachdem der letzte seiner Erzeugerbefehle abgesendet worden ist, hat die verzögerte (Out-of-order-)Zuweisung von Verbraucherbefehlen eine positive Wirkung auf die Nutzung der Einträge des Datenflussplaners und anderer Hardwarepufferbetriebsmittel in der optimierten Out-of-order-Pipeline. Irgendeine frühere Zuweisung würde die Hardwarebetriebsmittel nur verschwenden.
Im Gegensatz dazu muss eine herkömmliche Out-of-order-Pipeline sowohl erzeugende als auch verbrauchende Befehle routinemäßig in demselben Taktzyklus zuweisen, so dass die für die Verbraucherbefehle zugewiesenen Hardwarebetriebsmittel für wenigstens einen Taktzyklus verschwendet werden. Dies geschieht, da ihre Frontend-Einheit 1001 μops in dem aus dem decodierten Befehlsstrom (z. B. IA-Strom) erzeugten Mikrocode nicht umordnen kann; während der Mikrocode für den Befehlsstrom natürlich Verbraucherbefehle besitzt, die an ihre Erzeugerbefehle angrenzend sind. Zum Beispiel sind μop-Kombinationen aus Ladevorgang + ALU in dem Mikrocode typisch für Programmcodes und werden sie einer Out-of-order-Maschine häufig in demselben Taktzyklus zugewiesen. Somit kann der Verbraucher-ALU-Befehl die Hardwarebetriebsmittel in der herkömmlichen Pipeline in Abhängigkeit von der Latenzzeit der erzeugenden Ladeoperation für wenigstens 3–4 Taktzyklen verschwenden.
Im Ergebnis der Unterschiede der relativen Zuweisung der Erzeuger- und Verbraucherbefehle beobachtet ein Hardwaredatenflussplaner mit einer gegebenen Größe in der optimierten Out-of-order-Pipeline im Mittel mehr bereite Befehle als ein ähnlicher Planer in einer herkömmlichen Pipeline. Somit werden die Einträge des Planers in der optimierten Pipeline besser genutzt, so dass entweder die Größe des Planers ohne Leistungsnachteil verringert werden kann oder ein Planer mit einer gegebenen Größe für einen größeren/breiteren Out-of-order-Prozessor dienen kann, ohne seine Leistungsfähigkeit zu beschränken, d. h., die Wirkung der Out-of-order-Zuweisung verbessert die Hardwareskalierbarkeit der optimierten Out-of-order-Pipeline.
Es ist wichtig anzumerken, dass die optimierte Out-of-order-Pipeline die Out-of-order-Zuweisung ohne irgendwelche zusätzliche Hardware als Nebenprodukt der Codevorausplanung in VLIWs, die durch den dBT-Softwareoptimierer ausgeführt wird, um die privaten ISA-Beschränkungen zu befolgen, ermöglicht.
Ähnlich ruft die optimierte Out-of-order-Pipeline effektiv Befehle in ihrer ursprünglichen Programmreihenfolge, z. B. in einer IA-Eingabeanwendung, ab, decodiert sie sie und scheidet sie sie sogar aus. Dennoch führen die Frontend-, die Zuweisungs- und die Ausscheideeinheit in der optimierten Out-of-order-Pipeline weiterhin ihre einfachen In-order-Funktionen aus. Die Hardwaregröße und Hardwarekomplexität der Einheiten sind wesentlich geringer oder wenigstens dieselben wie in der herkömmlichen Out-of-order-Pipeline, die ähnliche positive Wirkungen des Out-of-order-Abrufs und der Out-of-order-Zuweisung ohne merkliche Erhöhung der Frontend-Hardware und ihrer Komplexität wie Multithread-Abruf in dem Frontend, Befehlsvorausplanung/Befehlsumordnungs-Einheit in dem Frontend usw. nicht ausnutzen kann.
(15) VLIW-Codeplan mit verbesserter Hardware für optimierte Out-of-order-Pipeline
Bei Betrachtung der Code-(Voraus-)Planung in VLIWs, die durch den dBT-Softwareoptimierer für die optimierte Out-of-order-Pipeline ausgeführt wird, ist es wichtig, auf mehrere Hauptverbesserungen in dem resultierenden VLIW-Codeplan in Bezug auf einen ähnlichen VLIW-Codeplan für herkömmliche In-order-VLIW-Pipeline-Prozessoren hinzuweisen. In der herkömmlichen In-order-VLIW-Pipeline ist jedes VLIW eine Elementareinheit des Abrufens, des Decodierens, der Zuweisung (oder der Übertragung zu der Backend-Pipeline), des Absendens und der Ausscheidung/Festschreibung. Das heißt, entsprechende Stufen der In-order-Pipeline wirken auf ein gesamtes VLIW, d. h. auf alle seine Silben, gleichzeitig.
Im Gegensatz dazu dient ein VLIW in der optimierten Out-of-order-Pipeline als eine Elementareinheit zum Abrufen, zum Decodieren, zur Zuweisung und zur Ausscheidung/Festschreibung, aber nicht zum Absenden. Während der Backend-Zuweisungs-Stufe wird ein VLIW in einzelne Silben (RISC-Befehle) zu ihrer unabhängigen dynamischen Planung und Absendung, potentiell Out-of-order, durch den Hardware-Datenflussplaner, geteilt. Wie im Folgenden erläutert wird, ermöglicht die Anwesenheit des Hardwaredatenflussplaners in der optimierten Out-of-order-Pipeline einen verbesserten VLIW-Codeplan für sie.
Der Softwarecodeoptimierer für eine herkömmliche In-order-VLIW-Pipeline ist für die Erzeugung einer genauen (und superskalaren, d. h. parallelen) Absendesequenz von Befehlen verantwortlich. Die Absendesequenz wird durch die In-order-Pipeline genau befolgt. Somit müssen abhängige Befehle ihren erzeugenden Befehlen in dem herkömmlichen VLIW-Plan wenigstens um so weit wie die genaue Latenzzeit der erzeugenden Befehle folgen. Für die Einzykluserzeuger können die Verbraucher in dem nächsten VLIW in einem Plan angeordnet werden. Dagegen muss für Verbraucher von Mehrzyklusladevorgängen die volle Latenzzeit (in Anzahlen von VLIWs, da die maximale Absenderate in der In-order-Pipeline ein VLIW pro Taktzyklus ist) übersprungen werden, bevor die Verbraucher in dem VLIW-Code angeordnet werden können.
Für die Planung von Codes mit inhärent hoher Parallelität auf der Befehlsebene und statistisch vorhersagbarem Steuerablauf wie für die meisten inneren Schleifen mit hoher Anzahl von Auslösungen stellt dies kein großes Problem dar, da alle leeren Silben in VLIWs zwischen Mehrzykluserzeugern und ihren Verbrauchern durch den Softwareoptimierer mit anderen unabhängigen Befehlen leicht gefüllt werden können.
Allerdings muss der herkömmliche VLIW-Softwareoptimierer für die Planung von Codes mit niedriger inhärenter Parallelität und mit vielen bedingten Verzweigungen viele No-Op-Befehle in den Codeplan injizieren, nur um zu sicherzustellen, dass die Hardwarepipeline richtige Latenzzeiten zwischen allen Mehrzykluserzeugern und ihren Verbrauchern in dem Codeplan sieht. Die No-Op-Befehle führen zu Blasen in der In-order-Hardware-Pipeline und veranlassen eine Unter-Zuweisung (d. h. eine Unter-Nutzung) von Hardwarebetriebsmitteln in herkömmlichen VLIW-Prozessoren wie jenen in der Itanium^®-Prozessorfamilie (IPF).
Eine Ausführungsform der optimierten Out-of-order-Pipeline enthält Hardwaremechanismen, die die in einem herkömmlichen VLIW-Codeplan zu findenden Ineffizienzen milder. Genauer stützt sich der dBT-Optimierer für Codes mit niedriger Parallelität auf die Fähigkeit der Out-of-order-Maschine, an die lange Latenzzeit von Befehlen vollständig in Hardware dynamisch anzupassen, und nimmt er an, dass alle Befehle eine Latenzzeit eins (eine Latenzzeit von einem Taktzyklus) besitzen, anstatt die tatsächlichen Befehlslatenzzeiten in dem verbesserten VLIW-Codeplan, den er erzeugt, durchzusetzen. Die Annahme der Latenzzeit eins macht den Plan im Vergleich zu dem herkömmlichen VLIW-Plan viel dichter (kompakter) und frei von No-Op-Befehlen, was die Backend-Zuweisungsrate erhöht, aber weiterhin die optimierte Out-of-order-Pipeline mit ausreichenden Informationen (über richtige Abhängigkeiten zwischen den Befehlen bereitstellt.
Für Codes mit höherer Parallelität berücksichtigt eine Ausführungsform des dBT-Softwareoptimierers für die optimierte Out-of-order-Pipeline sowohl die tatsächlichen Latenzzeiten der Befehle, primär der Ladebefehle, und den relativen Grad der Kritikalität bestimmter Befehle in einem übersetzten Codegebiet für ihre schnellere Ausführung. Im Ergebnis erhält der verbesserte VLIW-Codeplan für die Codes mit hoher Parallelität die meisten der Merkmale eines herkömmlichen VLIW-Codeplans: Die Erzeuger- und Verbraucherbefehle werden in dem Plan getrennt, um die Latenzzeit des Erzeugers wenigstens teilweise zu berücksichtigen, und kritischere Befehle werden der Out-of-order-Maschine über ihre frühere Anordnung in dem VLIW-Codeplan vor weniger kritischen Befehlen zugewiesen. Das heißt, an die Mehrzyklusbefehl-Latenzzeiten in Codes mit hoher Parallelität wird (teilweise) über den VLIW-Codeplan anstatt vollständig durch die Hardware der Out-of-order-Maschine angepasst. Dennoch ist der verbesserte VLIW-Codeplan dicht (kompakt) und frei von No-Op-Befehlen. Die Ausführung des Codeplans durch die optimierte Out-of-order-Pipeline führt zu einer besseren Leistungsfähigkeit für Codes mit hoher Parallelität auf der Befehlsebene (ILP) und ermöglicht im Vergleich zu einer herkömmlichen Out-of-order-Pipeline, wie zuvor erwähnt wurde, außerdem die bessere Ausnutzung der Out-of-order-Hardwarebetriebsmittel.
In einer Ausführungsform wird der verbesserte VLIW-Codeplan für die optimierte Out-of-order-Pipeline opportunistisch erzeugt: Der Codeplan muss die Abhängigkeiten zwischen Befehlen richtig widerspiegeln (abhängige Befehle werden in getrennten VLIWs angeordnet), kann aber den minimalen Latenzzeiten der erzeugenden Befehle in der Anordnung ihrer verbrauchenden Befehle nicht genau folgen. Diese Verbesserung ermöglicht im Vergleich zu herkömmlichen In-order-Hardwarepipelines, die sich (z. B. wie in den IPF-Prozessoren) auf ähnliche VLIW-ISA-Eigenschaften stützen, in der optimierten Out-of-order-Pipeline eine viel bessere Codeplandichte und viel bessere Befehlszuweisungsraten.
Außerdem verringert der verbesserte VLIW-Codeplan für die optimierte Out-of-order-Pipeline die Überzuweisung der Hardwarebetriebsmittel der Out-of-order-Maschine, die in einer herkömmlichen Out-of-order-Pipeline typisch ist, indem er die Erzeuger- und die Verbraucherbefehle nicht in demselben VLIW anordnet und somit verhindert, dass sie der Out-of-order-Maschine in demselben Taktzyklus zugewiesen werden.
(16) ISA-optimierte Befehlsausscheideeinheit
In einer Ausführungsform scheidet die in dem Ausscheide/Festschreib-Gebiet 1013 der optimierten Out-of-order-Pipeline gelegene Ausscheideeinheit Befehle streng mit der VLIW-Granularität, bis zu einem VLIW pro Taktzyklus (durch den dBT-Optimierer statisch im Voraus definiert), aus. Im Gegensatz dazu muss eine herkömmliche Out-of-order-Pipeline eine superskalare Gruppe (”Zeile”) von μops dynamisch zur Ausscheidung in Hardware auswählen und mögliche anhängige Unterbrechungen und/oder die Ausführung während der Auswahl sowie die Grenzen zwischen den ursprünglichen Makrobefehlen (ISA) in dem Ausscheidestrom von ”Zeilen” von μops berücksichtigen.
In einer Ausführungsform ist die Hardwareimplementierung des Ausscheidepipelinesegments in 1013 wegen der in der privaten ISA definierten Beschränkungen von Silben in einem VLIW, die der dBT-Softwareoptimierer befolgt, wenn er Code erzeugt, ähnlich dem Zuweisungspipelinesegment 1502 optimiert. Genauer gibt es in einer Ausführungsform keine falschen Ausgabeabhängigkeiten (W-A-W) zwischen Silben in einem VLIW und keine Programmordnung in einem VLIW (mit Ausnahme von Speicheroperationen), so dass die Ausscheideeinheitshardware anders als in ähnlichen Einheiten in herkömmlichen Out-of-order-Pipelines keine Prüfungen auf Abhängigkeiten auszuführen braucht und die Ordnung während der Ausscheidung ignorieren kann. Die beseitigte Abhängigkeits- und Ordnungsprüflogik ist in der herkömmlichen Ausscheideeinheit für die Out-of-order-Prozessorentwürfe mit breiter Ausgabe üblicherweise die am schlechtesten skalierbare Hardware. Da in einer Ausführungsform nur ein VLIW pro Taktzyklus ausgeschieden wird, brauchen die Ausführungsdetektions- und Programmzähler-Aktualisierungsmechanismen in der optimierten Ausscheidungspipeline außerdem nicht für die superskalare (d. h. parallele) Ausscheidung wiederholt zu sein, wie es üblicherweise für die superskalare Ausscheidung von μops in einer herkömmlichen Out-of-order-Pipeline erfolgt, um Grenzen zwischen Makrobefehlen (ISA) bei den ”Zeilen” auf der μops-Ebene sorgfältig zu behandeln.
Alle diese Merkmale ermöglichen eine vereinfachte und lose gekoppelt partitionierte Hardwareimplementierung der ISA-optimierten Ausscheideeinheit mit sehr hohem Spitzendurchsatz.
Zur Vollständigkeit ist es wichtig anzumerken, dass der Umordnungspuffer (ROB) in der optimierten Out-of-order-Pipeline ebenfalls in einer vollständig oder teilweise partitionierten Weise implementiert werden kann, um eine verbesserte Integration mit den optimierten partitionierten Zuweisungs- und Ausscheideeinheiten zu ermöglichen und um für Out-of-order-Prozessorentwürfe mit breiterer Ausgabe eine höhere Hardwareskalierbarkeit zu unterstützen.
Diese Optimierungen der Ausscheideeinheit beinhalten, dass der genau konstruierte Register- und Speicherzustand in der optimierten Out-of-order-Pipeline mit der Genauigkeit jedes VLIW (z. B. an Grenzen zwischen benachbarten VLIWs, statisch erzeugt durch die dBT-Optimierersoftware) unterstützt wird. In einer Ausführungsform wird der genaue Zustand zum Behandeln von Hardwareunterbrechungen, Ausführungsausnahmen, Fehlern usw. verwendet.
Eine Ausführungsform der optimierten Out-of-order-Pipeline unterstützt explizit die private ISA-Definition für den konstruierten Register- und Speicherzustand. Es liegt in der Verantwortung der dBT-Software, dass sie eine zuverlässige Abbildung dieses genauen privaten ISA-Zustands auf den entsprechenden genauen ursprünglichen Binärcodezustand (z. B. IA-Zustand) herstellt und in der Lage ist, den nachfolgenden richtigen Register- und Speicherzustand, wenn er für die Ausführung einer Softwareanwendung angefordert wird und wie es durch die ISA des ursprünglichen Binärcodes (z. B. IA) beinhaltet ist, zu rekonstruieren.
(17) ISA-optimierte geclusterte Organisation der Out-of-order-Pipeline
Eine Ausführungsform der optimierten Out-of-order-Pipeline ermöglicht über private ISA-Merkmale und über eine dBT-Optimierersoftwareunterstützung die effiziente Implementierung geclusterter Out-of-order-Mikroarchitekturen. Geclusterte Mikroarchitekturen teilen ansonsten monolithische und große Hardwarestrukturen und Hardwarebetriebsmittel in kleinere Teile (die Cluster), so dass ihre physikalische Implementierung einfacher wird und die Hardwareskalierbarkeit verbessert wird, da jeder der Teile eine niedrigere Latenzzeit besitzt und mit einer höheren Taktfrequenz als entsprechende monolithische Hardwarestrukturen ausgeführt werden kann.
Die typische Anwendung einer geclusterten Mikroarchitektur ist ein Prozessorentwurf mit breiter Ausgabe, der die physikalische Registerdatei und/oder das Operandenumgehungsnetz in zwei oder mehr kleinere Cluster teilt, z. B. ein Out-of-order-Prozessor mit einer Breite von 8, der als zwei monolithische Ausführungscluster mit einer Breite von 4 implementiert wird und mit einer Taktfrequenz eines Prozessors mit einer Breite von 4 ausgeführt wird. Da die Latenzzeiten für Datenzugriffe und Datenübertragungen zwischen getrennten Clustern größer als jene innerhalb von Clustern oder für kleinere monolithische Out-of-order-Mikroarchitekturen werden, besitzt diese geclusterte Hardwareimplementierung allerdings eine inhärente Zusatzleistungsbelastung.
Die zusätzlichen Latenzzeiten der Kommunikation zwischen Clustern werden üblicherweise in der Gesamtausführungszeit offenbart, wenn eine kritische Datenabhängigkeit in dem Ausführungscode über Cluster geplant wird und diese somit die Kommunikationslatenzzeit zwischen Clustern enthält, die die Leistungsfähigkeit in Bezug auf eine hypothetische (aber nicht notwendig durchführbare) große monolithische Out-of-order-Mikroarchitektur mit ähnlicher Logikgröße und/oder ähnlicher Kapazität der Hardwarestrukturen verschlechtert.
Somit hängt die Effizienz einer geclusterten Out-of-order-Mikroarchitektur davon ab, wie gut die Offenbarung der Latenzzeit zwischen Clustern über Lenkung der Zuweisung von Befehlen zu richtigen Clustern gemildert wird, um die Rate, mit der der effektive kritische Weg der Ausführung die Clustergrenzen schneidet – die Hauptursache der Leistungsverschlechterung –, zu minimieren.
Die Implementierung optimaler Befehlslenkungsmechanismen in geclusterten Mikroarchitekturen wird umfassend als eine herausfordernde Aufgabe angesehen. Naive Befehlslenkungstechniken verursachen in Bezug auf eine monolithische Out-of-order-Pipeline-Basislinie mit derselben Ausgabebreite eine große (z. B. 20%–30%) Leistungsverschlechterung, was die Hardwareeffizienz eines geclusterten Out-of-order-Prozessors mit breiter Ausgabe schwächt.
Anspruchsvollere Befehlslenkungsheuristiken erfordern nicht nur zusätzliche Hardware, um die Analyse des kritischen Wegs des abgerufenen Codes und die Erzeugung richtiger Lenkungsentscheidungen auszuführen, sondern sind auch sehr beschränkt in Bezug auf den Umfang der Analyse, da die Lenkungsentscheidung vor der Befehlszuweisung zu dem Out-of-order-Backend in der Frontend-Pipeline erfolgen muss, wenn die Hardware keine ausreichenden und/oder zuverlässigen Kontextinformationen über Zuweisungsbefehle, um die optimalen Lenkungsentscheidungen zu treffen, besitzt. Wegen der inhärenten Schwierigkeiten ist keine praktisch korrekte geclusterte Implementierung herkömmlicher Out-of-order-Pipelines entwickelt worden.
Im Gegensatz dazu analysiert der dBT-Softwareoptimierer die Eigenschaften des kritischen Wegs des Codes in einer Ausführungsform der optimierten Out-of-order-Pipeline zu seiner Übersetzungszeit als Teil des regulären Codeplanungsprozesses. Natürlich verfügt der dBT-Optimierer über ausreichend Kontextinformationen und berücksichtigt er die Kritikalität von Befehlsabhängigkeiten in den großen Codegebieten, was es ermöglicht, Lenkungsentscheidungen für die optimierte Out-of-order-Pipeline statisch (zur Codeübersetzungszeit) ausreichend optimal zu treffen, um sie während der Codeausführung zu befolgen.
Die dBT-fähigen Techniken für die Befehlslenkung in der optimierten geclusterten Out-of-order-Pipeline überbrücken wesentlich (bis auf 1%–3%) die Effizienz- und Leistungsfähigkeitslücke zwischen geclusterten und monolithischen Out-of-order-Mikroarchitektur-Organisationen, was die Hardwareskalierbarkeit für sehr breite High-End-Out-of-order-Prozessorentwürfe drastisch verbessert, was sie aus der Sicht kommerzieller Produkte möglich macht.
In einer Ausführungsform werden die Informationen, die die Befehlslenkung zu Clustern angeben, an die optimierte Out-of-order-Pipeline explizit über in der privaten ISA definierte Lenkungssteuermerkmale geliefert, die als ein integraler Bestandteil der Gesamtordnungsbeschränkungen für Silben in einem durch die ISA definierten VLIW implementiert sein können. Dies kann z. B. unter Verwendung einer statischen Abbildung bestimmter Silbenpositionen in einem VLIW auf spezifische Hardwarecluster, ähnlich wie die Positionen auf spezifische Ausführungseinheitsports in der wie zuvor beschriebenen optimierten Out-of-order-Pipeline abgebildet werden können, oder über einen 1-Bit-Clusterlenkungshinweis in einer Silbencodierung für die Zwei-Cluster-Mikroarchitekturorganisation (zum Codieren der Lenkungshinweise für eine größere Anzahl von Clustern werden mehr Bits benötigt), ausgeführt werden.
(18) Verschiedene Bemerkungen über die optimierte Out-of-order-Pipeline
Die Ausführungsformen der optimierten Out-of-order-Pipeline ermöglichen effiziente Implementierungen vieler bekannter oder ”klassischer” dBT-Optimierungen vorhandener Binärcodes (z. B. IA). Beispiele solcher Optimierungen enthalten die spekulative schleifeninvariante Codeverschiebung, die spekulative Registerwert-Spill-and-Fill-Codeoptimierung (auch als Registerbeförderung bekannt), spekulative Steuerablaufoptimierungen (die Beseitigung bedingter und/oder indirekter Verzweigungen tendenziell nur für einen Weg, der IF-Umsetzung, der Codebegradigung) usw., sind darauf aber nicht beschränkt. Außerdem können viele reine Hardware-Out-of-order-Pipeline-Optimierungen, die in aktuellen Out-of-order-Prozessoren verfügbar sind, entweder ”so wie sie sind” implementiert werden oder dadurch, dass sie als in einer optimierten Out-of-order-Pipeline co-entworfene Hardware/Software implementiert werden, vereinfacht und verbessert werden. Beispiele solcher Optimierungen enthalten die Verschmelzung von Befehlen, die Beseitigung von Verschiebebefehlen, die Beseitigung von Null-Idiom-Befehlen, die frühe Reklamation physikalischer Register, die spekulative Verriegelungsauslassung usw., sind darauf aber nicht beschränkt.
Ausführungsformen der Erfindung können verschiedene Schritte enthalten, die oben beschrieben worden sind. Die Schritte können in durch eine Maschine ausführbaren Befehlen verkörpert sein, die verwendet werden können, um zu veranlassen, dass ein Mehrzweck- oder Spezialprozessor die Schritte ausführt. Alternativ können diese Schritte durch spezifische Hardwarekomponenten, die fest verdrahtete Logik zum Ausführen der Schritte enthalten, oder durch irgendeine Kombination programmierter Computerkomponenten und kundenangepasster Hardwarekomponenten ausgeführt werden.
Wie oben beschrieben wurde, können sich Befehle auf spezifische Konfigurationen von Hardware wie etwa anwendungsspezifische integrierte Schaltungen (ASICs), die dafür konfiguriert sind, bestimmte Operationen auszuführen, oder die eine vorgegebene Funktionalität aufweisen, oder auf Softwarebefehle, die in einem Speicher gespeichert sind, der in einem nichtflüchtigen computerlesbaren Medium verkörpert ist, beziehen. Somit können die in den Figuren gezeigten Techniken unter Verwendung von Code und Daten implementiert werden, die in einer oder in mehreren elektronischen Vorrichtungen (z. B. in einer Endstelle, in einem Netzelement usw.) gespeichert sind und ausgeführt werden. Solche elektronischen Vorrichtungen speichern und übermitteln (intern und/oder mit anderen elektronischen Vorrichtungen über ein Netz) Code und Daten unter Verwendung computermaschinenlesbarer Medien wie etwa nichtflüchtiger computermaschinenlesbarer Ablagemedien (z. B. Magnetplatten; optischer Platten; Schreib-Lese-Speicher; Nur-Lese-Speicher; Flash-Speichervorrichtungen; Phasenwechselspeicher) und flüchtiger computermaschinenlesbarer Kommunikationsmedien (z. B. elektrischer, optischer, akustischer oder einer anderen Form fortgepflanzter Signale – wie etwa Trägerwellen, Infrarotsignale, Digitalsignale usw.). Außerdem enthalten diese elektronischen Vorrichtungen üblicherweise einen Satz eines oder mehrerer Prozessoren, die mit einer oder mit mehreren anderen Komponenten wie etwa mit einer oder mit mehreren Ablagevorrichtungen (nichtflüchtigen maschinenlesbaren Ablagemedien), Nutzer-Eingabe/Ausgabe-Vorrichtungen (z. B. einer Tastatur, einem Touchscreen und/oder einer Anzeige) und Netzverbindungen gekoppelt sind. Die Kopplung des Satzes von Prozessoren und anderen Komponenten erfolgt üblicherweise über einen oder mehrere Busse und Brücken (auch als Buscontroller bezeichnet). Die Ablagevorrichtung und die Signale, die den Netzverkehr übermitteln, repräsentieren eines oder mehrere maschinenlesbare Ablagemedien bzw. maschinenlesbare Kommunikationsmedien. Somit speichert die Ablagevorrichtung einer gegebenen elektronischen Vorrichtung üblicherweise Code und/oder Daten zur Ausführung in dem Satz eines oder mehrerer Prozessoren dieser elektronischen Vorrichtung. Natürlich können einer oder mehrere Teile einer Ausführungsform der Erfindung unter Verwendung verschiedener Kombinationen aus Software, Firmware und/oder Hardware implementiert werden. Zur Erläuterung wurden überall in dieser ausführlichen Beschreibung zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der vorliegenden Erfindung zu erzeugen. Allerdings ist für den Fachmann auf dem Gebiet offensichtlich, dass die Erfindung ohne diese spezifischen Einzelheiten verwirklicht werden kann. In bestimmten Fällen wurden gut bekannte Strukturen und Funktionen nicht in allen Einzelheiten beschrieben, um eine Verdeckung des Gegenstands der vorliegenden Erfindung zu vermeiden. Dementsprechend sind der Schutzumfang und der Erfindungsgedanke der Erfindung hinsichtlich der folgenden Ansprüche zu beurteilen.

Claims

Beansprucht wird: Vorrichtung, die Folgendes umfasst: eine Befehlsabrufeinheit zum Abrufen von Very Long Instruction Words (VLIWs) in der Programmreihenfolge aus dem Speicher, wobei jedes der VLIWs mehrere Reduced-Instruction-Set-Computing-Befehlssilben (RISC-Befehlssilben) umfasst, die in den VLIWs in einer Reihenfolge gruppiert sind, die Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben beseitigt; eine Decodiereinheit zum Decodieren der VLIWs in der Programmreihenfolge und zum parallelen Ausgeben der Silben jedes decodierten VLIW; und eine Out-of-order-Ausführungsmaschine zum parallelen Ausführen wenigstens einiger der Silben mit anderen Silben, wobei wenigstens einige der Silben in einer anderen Reihenfolge als der Reihenfolge, in der sie von der Decodiereinheit empfangen werden, ausgeführt werden sollen, wobei die Out-of-order-Ausführungsmaschine eine oder mehrere Verarbeitungsstufen aufweist, die, wenn sie Operationen ausführen, nicht auf Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben prüfen.
Vorrichtung nach Anspruch 1, wobei die Out-of-order-Ausführungsmaschine eine Registerumbenennungslogik zum Implementieren einer Lesephase zum Lesen von Operanden logischer Register ohne Verwendung eines Multiplexers und/oder von Komparatoren für Operanden logischer Register enthält.
Vorrichtung nach Anspruch 2, wobei die Out-of-order-Ausführungsmaschine ferner eine Planereinstelllogik zum Bewerten von Abhängigkeiten zwischen Silben vor dem Planen der Silben zur Ausführung durch Funktionseinheiten umfasst, wobei die Planungseinstelllogik parallel zu der Lesephase der Registerumbenennungslogik ausgeführt wird.
Vorrichtung nach Anspruch 3, wobei die Planereinstelllogik ferner jede Silbe parallel zu einer Abbrucheinstelllogik, die von der Out-of-order-Ausführungsmaschine zum Abbrechen der Wirkungen bestimmter abgesendeter Silben verwendet werden kann, bearbeiten soll.
Vorrichtung nach Anspruch 1, die ferner Folgendes umfasst: einen Übersetzer zum Übersetzen von Programmcode von einer höheren Programmiersprache oder von einem öffentlichen Befehlssatzarchitektur-Format (ISA-Format) in ein privates ISA-Format, das die VLIWs und Silben umfasst.
Vorrichtung nach Anspruch 5, wobei der Übersetzer einen Optimierungscompiler oder einen Binärübersetzer einschließlich eines dynamischen Binärübersetzers, darauf aber nicht beschränkt, umfasst.
Vorrichtung nach Anspruch 6, wobei der Übersetzer Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten beim Übersetzen in das private ISA-Format in der Weise auflöst, dass die innerhalb jedes der VLIWs enthaltenen Silben in der richtigen Reihenfolge von dem Speicher abgerufen werden, keine Datenflussabhängigkeiten und falschen Ausgabeabhängigkeiten aufweisen.
Vorrichtung nach Anspruch 7, wobei die Datenflussabhängigkeiten Lesen-nach-Schreiben-Abhängigkeiten (”R-A-W”-Abhängigkeiten) umfassen und die falschen Ausgabeabhängigkeiten Schreiben-nach-Schreiben-Abhängigkeiten (”W-A-W”-Abhängigkeiten) umfassen.
Vorrichtung nach Anspruch 8, wobei der Übersetzer falsche Datenfluss-Gegenabhängigkeiten innerhalb eines VLIW zulässt.
Vorrichtung nach Anspruch 9, wobei die falschen Datenfluss-Gegenabhängigkeiten Schreiben-nach-Lesen-Abhängigkeiten (”W-A-R”-Abhängigkeiten) umfassen.
Vorrichtung nach Anspruch 1, wobei die Silben von mehreren Typen einschließlich irgendeiner Kombination einer oder mehrerer Steuersilben, einer oder mehrerer Gleitkommavektorsilben, einer oder mehrerer Speichersilben und/oder einer oder mehrerer Ganzzahl-ALU-Silben sind, wobei jede Silbe durch einen RISC-Befehl eines entsprechenden Typs repräsentiert sein kann.
Vorrichtung nach Anspruch 11, wobei der Silbentyp durch die zulässige relative Position einer Silbe in einem VLIW definiert ist.
Vorrichtung nach Anspruch 1, wobei die Out-of-order-Ausführungsmaschine eine Absendelogik zum Ausführen der nicht spekulativen frühen Absendung von Silben enthält.
Vorrichtung nach Anspruch 1, wobei die Out-of-order-Ausführungsmaschine einschließlich einer Register-Umbenennungs/Zuweisungs-Einheit mit N Partitionen und einer Planereinheit mit N Partitionen vollständig partitioniert ist.
Vorrichtung nach Anspruch 14, wobei die Partitionen physikalisch zum Behandeln bestimmter Typen von Befehlen angeordnet sind.
Vorrichtung nach Anspruch 15, wobei eine erste Partition in der Planereinheit einem ersten Typ einer Ausführungseinheit zugeordnet ist und eine zweite Partition in der Planereinheit einem zweiten Typ einer Ausführungseinheit zugeordnet ist.
Vorrichtung nach Anspruch 14, wobei die Partitionierung der Umbenennungs/Zuweisungs-Einheit und der Planereinheit die Anzahl der Schreibports in der Out-of-order-Ausführungsmaschine und/oder in dem Speicherordnungspuffer einschließlich seiner Lade- und Speicherpuffer verringert.
Vorrichtung nach Anspruch 5, wobei die öffentliche ISA die Intel-Architektur (IA) umfasst.
Vorrichtung, die Folgendes umfasst: einen Übersetzer zum Übersetzen von Programmcode von einem öffentlichen Befehlssatzarchitektur-Format (ISA-Format) in ein privates ISA-Format, das Very Long Instruction Words (VLIWs) umfasst, wobei jedes der VLIWs mehrere Silben umfasst, die in den VLIWs in einer Reihenfolge gruppiert sind, die Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben beseitigt; und eine Out-of-order-Ausführungsmaschine zum parallelen Ausführen wenigstens einiger der Silben mit anderen Silben, wobei wenigstens einige der Silben in einer anderen Reihenfolge als der Reihenfolge, in der sie von der Out-of-order-Ausführungsmaschine empfangen werden, ausgeführt werden sollen, wobei die Out-of-order-Ausführungsmaschine eine oder mehrere Verarbeitungsstufen umfasst, die beim Behandeln der Silben nicht auf Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben prüfen.
Vorrichtung nach Anspruch 19, wobei wenigstens eine der Stufen eine Registerumbenennungsstufe, die eine Lesephase zum Lesen von Operanden physikalischer Register von Silben ohne Verwendung eines Multiplexers oder von Komparatoren von Operanden logischer Register implementieren soll, umfasst.
Vorrichtung nach Anspruch 20, wobei die Out-of-order-Ausführungsmaschine ferner eine Planereinstelllogik zum Bewerten von Registerdatenflussabhängigkeiten zwischen Silben vor dem Planen der Silben zur Ausführung durch Ausführungseinheiten umfasst, wobei die Planungseinstelllogik parallel zu der Lesephase der Registerumbenennungslogik ausgeführt wird.
Vorrichtung nach Anspruch 21, wobei die Planereinstelleinheit ferner jede Silbe parallel zu der Abbrucheinstelllogik bearbeiten soll, die durch die Out-of-order-Ausführungsmaschine zum Abbrechen der Wirkungen bestimmter abgesendeter Silben verwendbar ist.
Vorrichtung nach Anspruch 19, wobei der Übersetzer einen Optimierungscompiler oder einen Binärübersetzer umfasst.
Vorrichtung nach Anspruch 7, wobei die Datenflussabhängigkeiten Lesen-nach-Schreiben-Abhängigkeiten (”R-A-W”-Abhängigkeiten) umfassen und die falschen Ausgabeabhängigkeiten Schreiben-nach-Schreiben-Abhängigkeiten (”W-A-W”-Abhängigkeiten) umfassen.
Verfahren, das Folgendes umfasst: Übersetzen von Programmcode von einem öffentlichen Befehlssatzarchitektur-Format (ISA-Format) in ein privates ISA-Format, das Very Long Instruction Words (VLIWs) umfasst, wobei jedes der VLIWs mehrere Silben umfasst, die in den VLIWs in einer Reihenfolge gruppiert sind, die Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben beseitigt; und Ausführen wenigstens einiger der Silben durch eine Out-of-order-Ausführungsmaschine parallel zu anderen Silben, wobei wenigstens einige der Silben in einer anderen Reihenfolge als der Reihenfolge, in der sie von der Out-of-order-Ausführungsmaschine empfangen werden, ausgeführt werden sollen, wobei die Out-of-order-Ausführungsmaschine eine oder mehrere Verarbeitungsstufen umfasst, die, wenn sie die Silben behandeln, nicht auf Datenflussabhängigkeiten und falsche Ausgabeabhängigkeiten zwischen den Silben prüfen.