-
Gebiet:
-
In einem Aspekt betrifft Folgendes eine Mikroprozessorarchitektur und in einem spezielleren Aspekt Ansätze zur Codierung von Befehlen in einem Maschinencode, der innerhalb eines Mikroprozessors decodiert werden soll.
-
Stand der Technik:
-
Eine Architektur eines Mikroprozessors betrifft einen Satz von Befehlen, der vom Mikroprozessor ausgeführt werden kann, und wozu diese Befehle den Mikroprozessor veranlassen. Architekturen von Mikroprozessoren können gemäß verschiedenen Merkmalen kategorisiert werden. Ein Hauptmerkmal ist, ob der Befehlssatz als „komplex” oder als von „geringer Komplexität” angesehen wird. Herkömmlicherweise wurden die Begriffe Rechner mit komplexem Befehlssatz (CISC) bzw. Rechner mit reduziertem Befehlssatz (RISC) zur Bezeichnung solcher Architekturen verwendet. Nun weisen manche moderne Prozessorarchitekturen Merkmale auf, die herkömmlicherweise nur bei CISC- oder RISC-Architekturen auftraten. In der Praxis besteht ein Hauptunterschied in der Bedeutung von RISC- und CISC-Architektur darin, ob arithmetische Befehle Speicheroperationen ausführen.
-
Ein RISC-Befehlssatz kann erfordern, dass alle Befehle exakt die gleiche Anzahl an Bits (z. B. 32 Bit) aufweisen. Außerdem kann erforderlich sein, dass diese Bits entsprechend einem begrenzten Satz von Formaten zugeordnet werden. Beispielsweise kann erforderlich sein, dass alle Operationscodes jedes Befehls die gleiche Anzahl an Bits (z. B. 6) aufweisen. Dies impliziert, dass in einer solchen Architektur bis zu 2^6 (64) einzigartige bzw. eindeutige Befehle bereitgestellt werden könnten. In manchen Fällen kann ein Hauptoperationscode einen Befehlstyp spezifizieren, und eine Reihe von Bits kann als Funktionsidentifikator verwendet werden, der zwischen verschiedenen Varianten solch eines Befehls unterscheidet (z. B. können alle Additionsbefehle den gleichen 6-stelligen Hauptoperationscodeidentifikator aufweisen, aber jeder kann einen anderen Typ von Additionsbefehl aufweisen, z. B. ein Addieren, das einen Überlauf ignoriert, und ein Addieren, das bei einem Überlauf abbricht).
-
Verbleibende Bits (neben den „Operationscode”-Bits) können gemäß identifizierenden Quelloperanden, einem Ziel eines Ergebnisses oder Konstanten, die während der Ausführung der durch die „Operationscode”-Bits identifizierte Operation zu verwenden sind, zugeordnet werden. Beispielsweise kann eine arithmetische Operation 6 Bits für einen Operationscode verwenden, weitere 6 Bits für einen Funktionscode (einzeln und gemeinsam, je nach Kontext, die „Operationscode”-Bits), und dann ein Ziel- und zwei Quellregister unter Verwendung von jeweils 5 Bits identifizieren. Obwohl eine RISC-Architektur erfordern kann, dass alle Befehle die gleiche Länge aufweisen und die gleiche Speicherung verwenden (z. B. 32 Bits), erfordert gegebenenfalls nicht jeder Befehl, dass alle Bits belegt sein müssen.
-
KURZFASSUNG
-
KURZE BESCHREIBUNG DER ZEICHNUNG
-
1A und 1B zeigen Blockschaltbilder, die einen beispielhaften Prozessor zeigen, der Aspekte der Offenbarung ausführen kann;
-
2 zeigt eine beispielhafte Befehlscodierung;
-
3 zeigt ein beispielhaftes Blockschaltbild eines Befehlsdecodierers, der Aspekte der Offenbarung ausführen kann;
-
4 zeigt einen beispielhaften Befehlsdecodierer, der Aspekte der Offenbarung implementieren kann;
-
5 zeigt ein Verfahren zur Bestimmung, ob ein bestimmter Befehl gemäß einem literalen oder virtuellen Decodierverfahren zu decodieren ist;
-
6 zeigt ein Verfahren zur Decodierung eines beispielhaften virtuell codierten Befehls;
-
7 zeigt einen beispielhaften Befehlsstrom;
-
8 zeigt eine Interpretation eines Verzweigen-Falls-Gleich-(BEQ-)Befehls;
-
9 zeigt einen beispielhaften Befehlsstrom, der durch literale und virtuelle Decodierung von Befehlen erzeugt wird;
-
10 zeigt Aktionen, die gemacht werden, um einen virtuell codierten BEQ-Befehl zu decodieren und zu verarbeiten;
-
11 zeigt ein alternatives Beispiel für die Implementierung einer Decodierung und Verarbeitung eines virtuell codierten BEQ-Befehls;
-
12 und 13 zeigen Aspekte einer virtuellen Befehlsdecodierung unter Verwendung einer Konstante, die im virtuell codierten Befehl umfasst ist;
-
14 und 15 zeigen Darstellungen, die veranschaulichen, wie eine Verwendung von virtuell codierten Befehlen einen verfügbaren Opcodeidentifikatorraum in einer Befehlssatzarchitektur steigern kann;
-
16 zeigt ein Verfahren zur Kompilierung eines Quellcodes für eine Prozessorarchitektur, die virtualisierte Befehlsdecodierung ausführt;
-
17 zeigt ein Blockschaltbild eines Compilers, der einen Assemblercode, einen Objektcode und einen Code, wie z. B. einen Bytecode, der in einer VM interpretiert oder kompiliert werden kann, erzeugen kann;
-
18 zeigt ein auf Software ausgerichtetes Blockschaltbild einer Maschine, die eine virtuelle Maschine implementiert, die einen Bytecode sowie ausführende Anwendungen in einem nativen Code und einem anderen Code in Ausführungseinheiten ausführen kann; und
-
19 zeigt ein Blockschaltbild eines beispielhaften hardwareorientierten Blockschaltbilds einer Maschine, die Aspekte der Offenbarung implementieren kann.
-
AUSFÜHRLICHE BESCHREIBUNG
-
In der folgenden Offenbarung werden Beispiele verwendet, die sich vorwiegend auf einen RISC-Befehlssatz beziehen, und genauer gesagt auf Aspekte einer MIPS-Prozessorarchitektur. Die Verwendung solcher Beispiele beschränkt jedoch die Anwendbarkeit der Offenbarung auf andere Prozessorarchitekturen und Implementierungen davon nicht.
-
Wie oben eingeführt, weist jeder Befehl, der von einer Prozessorarchitektur unterstützt wird, einen Bitanteil auf, der zur Verfügung steht, um die exakte Operation zu identifizieren, die für einen bestimmten Befehl auszuführen ist. Diese Bitzahl ist aufgrund verschiedener praktischer Überlegungen beschränkt. Eine Überlegung ist die Befehlslänge; ein 32-Bit-Befehl erfordert weniger Speicher als ein 64-Bit-Befehl. Eine Bitzahl, die zur Identifikation von Quell- und Zielregistern erforderlich ist, hängt von einer Anzahl an Architekturregistern ab, die unterstützt werden soll, was sich darauf auswirken kann, wie viele Bits für andere Zwecke verbleiben. Eine Komplexität einer Logik, die zur Decodierung von Befehlen erforderlich ist, kann auch ein Faktor sein; beispielsweise kann sich eine Auswahl, welche Operationscodes welche Befehle identifizieren, auf die Komplexität und Gesamteffizienz einer Decodierlogik auswirken.
-
Neben technischen Überlegungen wird eine Prozessorarchitekturkonstruktion auch durch andere Überlegungen beeinflusst. Eine wichtige Überlegung ist, frühere Generationen einer bestimmten Prozessorarchitektur zu unterstützen. Muss ein Code für eine neue Generation einer vorhandenen Prozessorarchitektur rekompiliert werden, kann das die Akzeptanz durch die Kunden behindern und erfordert mehr unterstützende Infrastruktur als eine Prozessorarchitektur, die Abwärtskompatibilität beibehält. Um Abwärtskompatibilität beizubehalten, sollte die neue Prozessorarchitektur die gleichen Operationen für einen bestimmten Objektcode ausführen wie die vorherige Generation. Dies impliziert, dass die vorhandenen Operationscodes (d. h. die Operationscodes und andere funktionale Switches oder Modifikatoren) in der neuen Prozessorarchitektur unverändert bleiben sollten. Diese Offenbarung beschäftigt sich nicht mit der Möglichkeit, bestimmte Befehle zu emulieren, da Emulation zwar möglich ist, aber keine mit ursprünglicher Ausführung vergleichbare Ausführungsgeschwindigkeit bereitstellt. Da Rechenvorgänge sich im Laufe der Zeit ändern müssen, kann es wünschenswert sein, Befehle hinzuzufügen, um bestimmte Fähigkeiten zu unterstützen; beispielsweise ganzzahlige und Gleitkommabefehle in Rechnerarchitekturen mit Vektorprozessoren (Single Instruction Multiple Data; SIMD). Eine Technik, die ermöglichen könnte, dass mehr Befehle innerhalb einer vorhandenen Befehlssatzarchitektur ausgedrückt werden, während Abwärtskompatibilität erhalten bleibt, ist nützlich. Eine neue Prozessorarchitektur kann auch Aspekte der Offenbarung ausführen.
-
Die Anmelderin hat erkannt, dass manche Befehle Operationen definieren, die ausgenutzt werden können, um Metadaten zu erzeugen, die von einer Decodiereinheit in einem Prozessor verwendet werden können, um einen einzelnen Operationscode in mehrere unterschiedliche Operationen zu decodieren. Ein Merkmal mancher Operationen ist, dass Quelloperanden kommutativ sind, was bedeutet, dass unabhängig von der Reihenfolge, in der zwei oder mehr Quelloperanden präsentiert werden, ein Ergebnis der Operation das gleiche ist. Beispielsweise kann ein Verzweigen-Falls-Gleich-Befehl (BEQ) ein erstes Quellregister und ein zweites Quellregister lesen, und falls Werte in diesen Registern gleich sind, dann wird die Verzweigung ausgeführt; ansonsten wird die Verzweigung nicht ausgeführt. Ein typischer Assembler oder Compiler kann ausgehend von verschiedenen Überlegungen zwei Register auswählen, um die zu vergleichenden Werte zu speichern. Diese Offenbarung präsentiert ein Beispiel, bei dem eine relative Ordnung der Register, die als Quelloperanden verwendet werden, beschränkt ist, um mehrere verschiedene Befehle mit demselben Opcodeidentifikator darzustellen, und einige mögliche Beschränkungen. Um beispielsweise einen Befehl darzustellen, kann erforderlich sein, dass ein zuerst auftretendes Quellregister eine höhere Zahl aufweist als ein als zweites auftretendes Quellregister, z. B. kann ein erstes Quellregister Register 3 sein und ein zweites Quellregister kann Register 5 sein (d. h. dies sind Zahlen oder Bezugszeichen für die Register, nicht die Werte in den Registern). Um einen weiteren Befehl mit demselben Opcodeidentifikator darzustellen, kann es erforderlich sein, dass das zuerst auftretende Register das höhere Register ist (Register 5 im obigen Beispiel). Auf solch eine Weise kann ein zweiter Befehl in einem Opcoderaum dargestellt werden, der vorher nur einen einzigen Befehl darstellen konnte. Somit würde der erste Befehl in einem Beispiel durch binäre Daten ausgedrückt werden, welche die gleichen sind wie binäre Daten für den zweiten Befehl, mit der Ausnahme, dass manche der binären Daten zwischen dem ersten und zweiten Befehl in einer anderen relativen Reihenfolge oder Position angeordnet sind. In diesem Beispiel wären sowohl der erste Befehl als auch der zweite Befehl aus Befehlen ausgewählt, die unabhängig von einer Reihenfolge, in der die Operanden oder andere, für ihre Definition verwendete Daten auftreten, unverändert ausgeführt werden. Manche Implementierungen können auch in der Lage sein, dieses Thema der Operandenreihenfolge mit einem Compiler zu lösen, der die uneinheitlichen Ergebnisse handhabt, die aufgrund einer unterschiedlichen relativen Operandenreihenfolge auftreten würden.
-
1A zeigt eine beispielhafte Darstellung von Funktionselementen eines Prozessors 50, der Aspekte der Offenbarung ausführen kann. Die beispielhaften Elemente des Prozessors 50 werden zuerst einleitend dargelegt und dann, falls erforderlich, genauer erläutert. Dieses Beispiel betrifft einen Prozessor, der zu einer Ausführung in anderer Reihenfolge als der Programmreihenfolge in der Lage ist (engl. out of order execution); offenbarte Aspekte können jedoch auch bei Implementierung mit einem Prozessor mit Ausführung in Programmreihenfolge (engl. in Order) eingesetzt werden. Somit zeigt 1A Funktionselemente einer Mikroarchitektur-Implementierung der Offenbarung, aber andere Implementierungen sind ebenfalls möglich. Ferner können unterschiedliche Prozessorarchitekturen Aspekte der Offenbarung ausführen. Die Namen, die manchen der in 1A dargestellten Funktionselemente gegeben wurden, können sich in vorhandenen Prozessorarchitekturen unterscheiden, aber Durchschnittsfachleute werden anhand dieser Offenbarung verstehen, wie die Offenbarung bei verschiedenen Prozessorarchitekturen zu implementieren ist, einschließlich jener Architekturen, die auf schon vorhandenen Architekturen basieren, oder sogar einer vollkommen neuen Architektur.
-
Der Prozessor 50 umfasst eine Abrufeinheit 52 (engl. fetch unit), die mit einem Befehlscache 54 gekoppelt ist. Der Befehlscache 54 ist mit einer Decodier- und Umbenennungseinheit 56 gekoppelt. Die Decodier- und Umbenennungseinheit 56 ist mit einer Befehlsschlange 58 gekoppelt, und auch mit einem Verzweigungsvorhersager, der einen Befehlsübersetzungspuffer (iTLB) 60 umfasst. Die Befehlsschlange 58 ist mit einem Umordnungspuffer (ROB) 62 gekoppelt, der mit einer Freigabe- bzw. Commit-Einheit 64 gekoppelt ist. Der ROB 62 ist mit (einer) Reservierungsstation(en) 68 und einem Lade/Speicher-Puffer (LSB) 66 gekoppelt. Die Reservierungsstation(en) 68 ist/sind mit (einer) Ausführungspipeline(s) mit anderer Reihenfolge (Out of Order, OO) 70 gekoppelt. Die Ausführungspipeline(s) 70 und der LSB 66 sind jeweils mit einer Registerdatei 72 gekoppelt. Die Registerdatei 72 ist mit (einem) L1-Datencache(s) 74 gekoppelt. Der/die L1-Cache(s) 74 ist/sind mit (einem) L2-Cache(s) 76 gekoppelt. Der Prozessor 50 kann auch Zugang zu weiteren Speicherhierarchieelementen 78 haben. Die Abrufeinheit 52 empfängt Befehle von einem Speicher (z. B. L2-Cache 76, der ein gemeinsamer Cache für Daten und Befehle sein kann). Die Abrufeinheit 52 kann Anweisungen vom Verzweigungsvorhersager 60 darüber empfangen, welche Befehle abgerufen werden sollen.
-
In 1A dargestellte Funktionseinheiten des Prozessors 50 können in verschiedenen Implementierungen unterschiedliche Größen und Anordnungen aufweisen. Beispielsweise kann die Befehlsabrufeinheit 52 gleichzeitig 1, 2, 4, 8 oder mehr Befehle abrufen. Die Decodier- und Umbenennungseinheit 56 kann unterschiedliche Anzahlen von Umbenennungsregistern unterstützen, und die Schlange 58 kann in verschiedenen Implementierungen unterschiedliche Maximalanzahlen von Einträgen unterstützen. Der ROB 62 kann unterschiedliche Größen von Befehlsfenstern unterstützen, während die Reservierungsstation(en) 68 in der Lage sein kann/können, unterschiedliche Anzahlen von Befehlen zu halten, die auf Operanden warten, und auf ähnliche Weise kann der LSB 66 in der Lage sein, unterschiedliche Anzahlen von offenstehenden Lese- und Schreibvorgängen zu unterstützen. Der Befehlscache 54 kann unterschiedliche Cacheersetzungsalgorithmen einsetzen und kann mehrere Algorithmen gleichzeitig für unterschiedliche Teile des Cache 54 einsetzen. Eine Definition der Fähigkeiten unterschiedlicher Mikroarchitekturelemente umfasst verschiedene Abstimmungen, die über den Schutzumfang der vorliegenden Offenbarung hinausgehen.
-
Implementierungen des Prozessors 50 können einzelsträngig sein oder mehrere Stränge unterstützen. Implementierungen können auch Ausführungseinheiten in Form von Rechnerarchitekturen mit Vektorprozessoren (SIMD) umfassen. Ausführungseinheiten können ganzzahlige Operationen, Gleitkommaoperationen oder beides unterstützen. Weitere Funktionseinheiten für unterschiedliche Zwecke können bereitgestellt sein. Beispielsweise können eigenständige Verschlüsselungsengines bereitgestellt werden. 1A dient dazu, einen Kontext für nachfolgende Aspekte der Offenbarung bereitzustellen, und nicht dazu, solche zusätzlichen Funktionselemente auszuschließen.
-
Manche oder alle der Elemente des Prozessors 50 können sich auf einem einzelnen Halbleiterchip befinden. In manchen Fällen können sich Speicherhierarchieelemente 78 auf einem anderen Chip befinden, der unter Verwendung eines Halbleiterprozesses hergestellt wurde, der speziell auf die verwendete Speichertechnologie (z. B. DRAM) ausgerichtet ist. In manchen Fällen kann sich ein Teil des DRAM auf demselben Chip befinden wie die anderen Elemente, und ein weiterer Teil auf einem anderen Chip. Dies ist keine erschöpfende Aufzählung von beispielhaften Konstruktionsmöglichkeiten, die für eine bestimmte Implementierung des Prozessors 50 verwendet werden können.
-
1B zeigt, dass die Registerdatei 72 des Prozessors 50 32 Register umfassen kann. Jedes Register kann durch einen binären Code identifiziert sein, der diesem Register zugeordnet ist. In einem einfachen Beispiel identifiziert 00000b das Register 0, 11111b identifiziert das Register 31 und Register dazwischen sind entsprechend nummeriert. Der Prozessor 50 führt Berechnungen gemäß speziellen Konfigurationsinformationen aus, die von einem Befehlsstrom bereitgestellt werden. Diese Befehle liegen in einem Format vor, das von der Architektur des Prozessors bestimmt wird. Ein Befehl kann ein oder mehrere Quellregister und ein oder mehrere Zielregister für eine bestimmte Operation spezifizieren. Die binären Codes für die Register werden innerhalb der Befehle verwendet, um unterschiedliche Register zu identifizieren. Die Register, die von Befehlen identifiziert werden können, können als „Architekturregister” bezeichnet werden, die einen großen Anteil des, aber nicht notwendigerweise den gesamten, Zustand(s) der Maschine darstellen, der zur Ausführung eines Codes zur Verfügung steht. Implementierungen einer bestimmten Prozessorarchitektur können eine größere Anzahl an physischen Registern unterstützen. Das Vorhandensein einer größeren Anzahl an physischen Registern ermöglicht eine spekulative Ausführung von Befehlen, die sich auf dieselben Architekturregister beziehen. Das Codieren von Befehlen unter Verwendung von Metadaten im Befehl, wie z. B. eine relative Reihenfolge von Quellregistern, wirft ein weiteres Kriterium auf, das ein Compiler während der Erzeugung eines auszuführenden Codes berücksichtigen müsste (d. h. dieser Ansatz zur Codierung von Befehlen stellt eine Beschränkung in Bezug darauf dar, wie Architekturregister in einem bestimmten Befehl benannt werden können). Diese Beschränkung kann dazu führen, dass mehr Befehle dieselben Architekturregister in einem bestimmten Abschnitt des Codes identifizieren. Dieses Kriterium ist jedoch nicht besonders störend, weil falsche Abhängigkeiten durch Registerumbenennung während der Ausführung gelöst werden können.
-
2 zeigt ein Beispiel für einen Befehl, der verwendet werden könnte, um den Prozessor 50 zu konfigurieren. Der Befehl ist ein Verzweigen-Falls-Gleich-Befehl (BEQ). Bei diesem Beispiel werden insgesamt 32 Bits zur Definition des Befehls verwendet. Ein 6-Bit-Identifikatorabschnitt gibt den Hauptopcode an. Der BEQ-Befehl erfordert zwei Quellregister (Ra und Rb). Ra und Rb sind jeweils durch einen 5-Bit-Code identifiziert. Verbleibende 16 Bits der 32 Bits werden einer Konstante (C) zugeordnet, die zur Erzeugung eines Verzweigungsziels verwendet wird, bei dem der Prozessor 50 mit der Ausführung beginnen sollte, falls die Werte in Ra und Rb gleich sind. Der Einfachheit halber ist ein Wert in einem bestimmten Register (z. B. Ra) durch ein vorangestelltes $ bezeichnet (z. B. identifiziert $Ra einen Wert im Register Ra, und so unterscheidet sich der Wert in Register Ra speziell von der Zahl oder dem Identifikator von Register Ra). Register 5 kann beispielsweise den Wert 100 enthalten. Register 5 kann als Operandenquelle in einem Befehl identifiziert sein (z. B. Ra = 5, und falls dies der Fall ist, dann ist $Ra = 100). Andere Befehle können unterschiedliche Formate aufweisen. In manchen Fällen kann ein Befehl eine Kategorie von Operationen unter Verwendung des 6-Bit-Hauptoperationscodeidentifikators spezifizieren und dann ein Funktionscodefeld umfassen, das die jeweils auszuführende Operation spezifiziert. Beispielsweise können alle Additionsoperationen durch den gleichen 6-Bit-Hauptoperationscodeidentifikator identifiziert sein, aber die Funktionscodes variieren. Beispielsweise kann eine Additionsoperation bei einem Überlauf abbrechen, während eine andere Addition dies nicht tut. Dies kann unter Verwendung unterschiedlicher Funktionscodes identifiziert werden. In dieser Offenbarung werden diese unterschiedlichen Felder einzeln und gemeinsam als „Operationscodeidentifikator” (Opcodeidentifikator) bezeichnet, und dieser Begriff bezeichnet daher je nach Kontext den Hauptopcodeidentifikator alleine oder mit einem entsprechenden Funktionscode.
-
8 zeigt ein kanonisches Verhalten eines Prozessors 50 bei Ausführung eines BEQ-Befehls. Bei 240 wird, falls ein in Ra gespeicherter Wert ($Ra) nicht einem in Rb gespeicherten Wert ($Rb) entspricht, die Abzweigung nicht genommen und der Programmzähler (PC) wird zu einem nächsten Befehl erhöht (z. B. durch Erhöhen des PC um 4). Ansonsten wird der PC basierend auf der Konstante C gesetzt, z. B. auf PC + (4·(C + 1)). Durchschnittsfachleute werden erkennen, dass spezielle Prozessoren den PC unterschiedlich setzen können, aber der Punkt ist, dass die Verzweigung genommen oder nicht genommen wird, nur in Abhängigkeit davon, ob $Ra = $Rb ist. Daher ist der BEQ-Befehl ein Befehl, der unabhängig von der Reihenfolge ist, in der die Operanden im Befehl präsentiert werden. Falls beispielsweise Register 5 einen Wert eines Quelloperanden enthält und Register 10 einen Wert des anderen Quelloperanden enthält, dann würde sich der BEQ-Befehl gleich verhalten, egal ob Ra auf 5 oder 10 gesetzt wäre und umgekehrt in Bezug auf Rb. Das Beispiel des BEQ-Befehls ist ein Beispiel für einen Befehl, der Quelloperanden aufweist, die kommutativ sind. Andere Beispiele sind Additions- und Multiplikationsbefehle (z. B. A + B = B + A). Das Beispiel einer logischen Äquivalenz von zwei oder mehr Befehlen aufgrund der Eigenschaft von Operandenkommutativität wird in dieser Offenbarung als Anregungsbeispiel verwendet. Aber auch andere Eigenschaften können zu der Schlussfolgerung führen, dass zwei oder mehr Befehle logisch äquivalent sind. Die folgende Offenbarung kann auf zwei oder mehr Befehle angewandt werden, die als logisch äquivalent bestimmt wurden, entweder im allgemeinen Sinne oder unter speziellen Bedingungen.
-
Die Anmelderin hat erkannt, dass es eine Untergruppe von Operationen gibt, die von einem Prozessor ausgeführt werden und logisch äquivalent sind, aber diese Operationen sind mit unterschiedlichen Befehlen codiert. Die Anmelderin ist daher davon ausgegangen, dass es sich um eine Informationsredundanz handelt, die erforderlich ist, um einen vollen Operationsumfang darzustellen, der von einem bestimmten Befehlssatz unterstützt wird. Damit Befehle in einer typischen Prozessor-ISA voneinander unterschieden werden können, braucht es einen Opcodeidentifikator (oder allgemeiner gesagt einen Teil eines Opcoderaums), der dem Befehl oder den Befehlen zugeordnet werden kann. Falls die Prozessor-ISA neu ist, können allen Befehlen, die unterstützt werden sollen, einfach Opcodeidentifikatoren zugeordnet werden. Manche Prozessorarchitekturfamilien gibt es aber schon seit relativ langer Zeit. Die Prozessor-Befehlssatzarchitektur (ISA) MIPS® wurde beispielsweise 1981 eingeführt, und im Laufe der darauffolgenden Jahre wurde eine Reihe von Änderungen und Zusätzen bei der MIPS-ISA vorgenommen. Eine Möglichkeit, einen Befehl zu einer vorhandenen Prozessor-ISA hinzuzufügen, wäre, einen Opcodeidentifikator für einen vorhandenen Befehl einem neuen Befehl zuzuordnen. Solch ein Ansatz würde jedoch dazu führen, dass für die vorangegangene Version der ISA kompilierte Binaries mit der neuen Version nicht kompatibel wären, da der Prozessor versuchen würde, einen anderen Befehl auszuführen als durch die Binaries bezweckt war. Die Anmelderin möchte diese Art von Inkompatibilitäten verringern oder vermeiden, aber gleichzeitig neue Befehle zu einer vorhandenen ISA hinzufügen. Die Anmelderin möchte außerdem einen größeren Gesamtopcoderaum haben, der durch die gleiche Anzahl an Bits dargestellt wird, und die Anzahl an Bits, die einer Opcodeidentifikation zugeordnet ist, reduzieren, um eine gegebene Anzahl von Operationen unverwechselbar zu identifizieren. Implementierungen der folgenden Offenbarung können eine oder mehrere dieser Fähigkeiten erreichen; es gibt jedoch keine spezielle Anforderung, dass eine Implementierung der Offenbarung diese Ziele erreichen muss oder dass ihre Entwicklung durch solche Ziele motiviert ist. Diese Fähigkeiten sind Beispiele, stellen aber keine erschöpfende Aufzählung der Vorteile dar, die durch die Implementierung der Offenbarung erreicht werden können, und es nicht impliziert, dass ein Gegenstand innerhalb des Schutzumfangs irgendeines Anspruchs einen oder mehrere dieser Vorteile aufweisen muss.
-
3 zeigt Funktionselemente einer beispielhaften Implementierung einer Decodier- und Umbenennungseinheit 56. Eine Quelle von Befehlen 103 stellt eine Reihe von Befehlen (Befehl 105 ist speziell identifiziert) an einen Opcodeidentifikator 107 bereit. Der Opcodeidentifikator 107 ist mit einem Opcodebereichszuordner bzw. Opcodebereichsabbilder (engl. opcode range mapper) 111 und mit einer virtuellen Befehlsdecodierlogik 109 gekoppelt. Der Opcodeidentifikator 107 verwendet Daten vom Opcodebereichszuordner 111, um eine anfängliche Decodierung des Befehls 105 vorzunehmen. In einer Implementierung enthält der Opcodebereichszuordner 111 Zuordnungsdaten, die einen Untersatz von Befehlen identifizieren, die der virtuellen Befehlsdecodierlogik 109 bereitzustellen sind, und andere, die nicht von der virtuellen Befehlsdecodierlogik 109 verarbeitet werden müssen, um im Prozessor 50 verwendet zu werden. Der Opcodeidentifikator 107 und der Opcodebereichszuordner 111 können beispielsweise als Assoziativspeicher(CAM)-Lookup ausgeführt sein. Eine weitere Implementierung eines Opcodeidentifikators 107 kann eine kombinatorische Schaltung sein, welche die zur Decodierung der Opcodeidentifikatoren des Befehlssatzes erforderliche Logik ausführt oder zwischen virtuell codierten Befehlen und literalen Befehlen unterscheidet, falls diese von separaten Schaltungen zu decodieren sind.
-
Ein Multiplexer 113 kann von einem Ausgang eines Opcodeidentifikators 107 gesteuert werden, um aus einer Ausgabe, die von der virtuellen Befehlsdecodierlogik 109 erzeugt wurde, oder dem Befehl 105 auszuwählen. Ein Eingang einer Befehlsschlange 58 ist gekoppelt, um eine Ausgabe des Multiplexers 113 zu empfangen. Die Befehlskette 58 empfängt auch Eingaben von einem Registerumbenenner 115. Der Registerumbenenner 115 erzeugt eine Zuordnung zwischen Architekturregistern und physischen Registern. Die physischen Register, die für einen bestimmten Befehl verwendet werden, werden mit den Architekturregistern korreliert, die in diesem Befehl identifiziert werden; der genaue Ansatz, um solche Korrelationen aufrechtzuerhalten, ist implementierungsspezifisch. Eine Ausgabe der Befehlsschlange 58 kann somit so betrachtet werden, dass sie Informationen enthält, die zur Konfiguration von Ausführungselementen des Prozessors 50 verwendet werden, um den Befehl (z. B. Befehl 105) auszuführen. Im Beispiel aus 1A ist die Befehlsschlange 58 mit dem ROB 62 gekoppelt. Der ROB 62 wird verwendet, um spekulative Ausführungsergebnisse von (einer) Pipeline(s) mit anderer Reihenfolge 70 zu überwachen. Obwohl diese Befehle spekulativ innerhalb eines Spekulationsfensters, das vom ROB 62 unterstützt wird, ausgeführt werden können, kann der ROB 62 eine Beendigung oder Bindung der Ergebnisse in Programmreihenfolge erzwingen.
-
4 zeigt ein Beispiel der virtuellen Befehlsdecodierlogik 109. Im Beispiel aus 4 umfasst die Decodierlogik 109 einen Komparator 119, der einen Quelloperanden Ra 121 und einen Quelloperanden Rb 123 eingibt. Das Beispiel aus 4 ist speziell für den in 2 eingeführten BEQ-Befehl, und die speziellen Eingaben in den Komparator 119 können je nach zu decodierendem Befehl variieren. Eine Ausgabe des Komparators 119 wird einer Opcodeidentifikatorschaltung 129 bereitgestellt. Die Opcodeidentifikatorschaltung 129 weist auch eine Eingabe 125 für einen Opcode vom zu decodierenden Befehl auf (z. B. Befehl 105). In 4 kann die Eingabe 125 so implementiert sein, dass sie genug Bits vom zu decodierenden Befehl umfasst, um den Befehl unverwechselbar einer Operation zuzuordnen, die vom Prozessor ausgeführt wird. Insbesondere können manche virtuell codierte Befehle einen Funktionscode aufweisen. Dieser Funktionscode kann ein „nicht beachten” für die Opcodeidentifikatorschaltung sein, und solch ein Funktionscode kann in diese eingegeben werden oder nicht. Die Opcodeidentifikatorschaltung 129 kann auch eine Eingabe 127 für die Konstante C aufweisen (siehe 2), je nachdem, ob die Konstante C erforderlich ist, um eine für einen gegebenen Befehl auszuführende Operation voll zu bestimmen (natürlich könnte die Konstante C bereitgestellt werden, auch falls es sich um eine Eingabe „nicht beachten” handelt, aber das wäre eine von der Implementierung abhängige Entscheidung). Die Opcodeidentifikatorschaltung 129 gibt Opcodedaten 131 aus, die dann verwendet werden können, um einen Logikteil zur Ausführung einer Operation zu konfigurieren. Der Logikteil kann beispielsweise eine Funktionseinheit sein. Es ist zwar möglich, dass Opcodedaten 131 für einen Mikrocode-Lookup oder eine komplexere Operation verwendet werden, solch ein Mikrocode-Lookup kann aber die Ausführungszeit verlängern, die Anzahl an Pipelinestufen, die für den Befehl erforderlich sind, erhöhen oder eine Variation in die Anzahl von Pipelinestufen einführen, die zur Ausführung unterschiedlicher Befehle erforderlich ist.
-
Beispielhafte Verfahren, die zur Decodierung eines virtuell codierten Befehls ausgeführt werden, sind nachstehend bereitgestellt. 5 zeigt ein beispielhaftes Verfahren, das vom Opcodeidentifikator 107 ausgeführt wird. Bei 152 wird ein zu decodierender Befehl empfangen. Bei 154 wird eine Entscheidung getroffen, ob der Befehl für eine virtuelle Befehlscodierung geeignet ist oder nicht. Falls der Befehl für eine virtuelle Befehlscodierung geeignet ist, dann wird ein virtueller Befehlsdecodierprozess 156 ausgelöst, ansonsten wird eine normale Befehlsdecodierung 158 ausgelöst. Eine normale Befehlsdecodierung 158 kann die Verwendung von nur den binären Elementen umfassen, die im Befehl bereitgestellt sind, und nicht der Metadaten über diese Elemente. Wie hier verwendet, steht Metadaten für Daten über die Elemente eines Befehls, beispielsweise welche Register identifiziert sind, in welcher relativen Reihenfolge Registernummern präsentiert werden oder eine andere Kombination oder Beziehung zwischen oder unter diesen Elementen in einem Befehl, der einer vorbestimmten Interpretationskonvention entspricht. In manchen Implementierungen kann ein Prozessor so gesehen werden, dass er ein Element eines Maschinencodes decodiert, das beispielsweise 32 Bits Daten sein können, die von einer Speicheradresse abgerufen werden, die einer 32-Bit-Grenze zugeordnet sind, und codiert sind, um Elemente eines Befehls darzustellen, der vom Prozessor gemäß einer vordefinierten Spezifikation auszuführen ist.
-
Es ist vorgesehen, dass Implementierungen nur einen Untersatz von Befehlen aufweisen, der virtuell codiert wird. Eine virtuelle Decodierlogik könnte bereitgestellt werden, die alle Befehlsdaten empfängt und ausgelegt ist, literal codierte Befehle durchzuleiten. Somit impliziert die Entscheidung bei 154 nicht, dass der Decodierer 56 eine separate Decodierlogik für literal und virtuell codierte Befehle aufweisen muss. Beispielsweise können eine virtuelle Decodierlogik und eine Logik zur Decodierung regulärer Befehle zusammen implementiert sein, und solch eine Logik kann wiederum mit Logik für andere Funktionen implementiert sein.
-
Ein Beispiel für einen virtuellen Befehlsdecodierprozess ist in 6 dargestellt; dieses Beispiel ist speziell für Befehle, die zwei Quellregister verwenden, wie z. B. der in 2 dargestellte BEQ-Befehl. Die Offenbarung kann jedoch für andere Befehle angepasst oder ausgeweitet werden. Bei 174 empfängt die Decodierlogik Daten für den virtuell zu decodierenden Befehl. Bei 178 wird bestimmt, ob Rb größer als Ra ist; diese Bestimmung ist keine Bestimmung, welche die Werte in diesen Registern beinhaltet, sondern nur die Zahlen der Register selbst. Falls Rb größer ist als Ra, dann wird bei 184 der Befehl in einen ersten virtuellen Opcode decodiert. Falls Rb nicht größer als Ra ist, dann kann bei 180 eine Entscheidung getroffen werden, ob Rb kleiner als Ra ist. Falls dies der Fall ist, dann kann der Befehl in einen zweiten virtuellen Opcode decodiert werden. Falls diese Bedingung nicht zutrifft, kann der Befehl bei 182 unter Verwendung der Konstante C decodiert werden, wie weiter unten erläutert ist. In jedem Fall trifft eine dieser Bedingungen zu, und die resultierende Decodierung des Befehls wird bei 188 auf eine Ausgabe angewandt. Es gilt darauf hinzuweisen, dass der beispielhafte Prozess aus 6 refaktoriert werden kann, während eine logische Äquivalenz erhalten wird, und alle diese Refaktorierungen liegen im Schutzumfang der Offenbarung. Beispielsweise können die Entscheidungen 178 und 180 umgekehrt werden, eine Gleichheitsbestimmung zwischen den Quellregistern kann durchgeführt werden, die Decodierung des Befehls kann für alle Möglichkeiten parallel erfolgen und die Bestimmungen 178 und 180 können verwendet werden, um die resultierenden Decodierungen auszuwählen. Manche Implementierungen benutzen gegebenenfalls keine Konstante C zur Decodierung, und in solchen Implementierungen ist entweder Entscheidung 178 oder 180 unnötig, und die Decodierung in den ersten virtuellen Opcode oder in den zweiten kann basierend auf einem Vergleich erfolgen, ob die Quelle Ra größer oder kleiner ist als die Quelle Rb. Implementierungen können eine Konvention zur Verwendung auswählen (z. B. ob Ra größer ist als Rb oder ob Ra kleiner ist als Rb; diese sind äquivalent dazu, ob Rb kleiner als Ra ist oder Rb größer als Ra ist).
-
Diese speziellen Beispiele können als Offenbarung verstanden werden, dass ein gegebener einzelner Befehl, der Quellregister identifiziert, basierend auf einem relativen Wert der Quellregister in zwei unterschiedliche Befehlen decodiert werden kann, und gegebenenfalls dass, falls diese Register gleich sind, die Decodierung unter Verwendung einer Konstante C durchgeführt werden kann. 7 und 9–12 zeigen ein spezielleres Beispiel für eine virtuelle Befehlsdecodierung innerhalb des Schutzumfangs der Offenbarung. Bezüglich dieser verschiedenen Beispiele für Decodierlogik versteht sich, dass die Beispiele zum leichten Verständnis für Menschen präsentiert sind, dass aber tatsächliche Maschinenstrukturen (z. B. eine umgesetzte synthetisierte Logik), die einen Decodierprozess gemäß der Offenbarung darstellen oder enthalten, sich signifikant von der Erklärung im Text unterscheiden können. Die Offenbarung erläutert Beispiele zur Verwendung von Identifikatoren für Quellregister als Metadaten zur Verwendung bei der Decodierung von Befehlen. Die Identifikatoren können in manchen Implementierungen Sequenzen von Binärziffern mit einer Länge sein, die zur Unterscheidung von Registern voneinander geeignet sind. In einer Implementierung identifizieren Befehle Architekturregister, deren Zahl geringer sein kann als eine Anzahl von physischen Registern. Implementierungen können Metadaten bereitstellen, die bei der Decodierung verwendet werden und Architekturregisteridentifikatoren sein können oder Identifikatoren von physischen Registern sein können (gemäß einer Zuordnung von Architektur- zu physischem Register). Diese Beispiele können für andere Arten von Metadaten generalisiert werden, beispielsweise für Metadaten, die Elemente eines geordneten Satzes identifizieren. Wenn 3 oder mehr Register identifiziert werden, können weitere Befehlscodierungen möglich sein, beispielsweise durch die Verwendung von vordefinierten Reihenfolgensequenzen der drei oder mehr Registeridentifikatoren.
-
7 zeigt einen Strom von Befehlen, wobei PC 225 einen BEQ-Befehl 233 indexiert, der Register 5 und Register 8 in dieser Reihenfolge als Quelloperanden mit einer Konstante A identifiziert. Der Strom von Befehlen umfasst auch einen zweiten BEQ-Befehl 235, der das Register 8 und das Register 5 als Quelloperanden mit einer Konstante B identifiziert. Eine herkömmliche Decodierung vom Befehl 233 und 235 würde beide Befehle zum selben Befehl decodieren (außer es gibt einen potenziellen Unterschied im Wert der Konstante, die das Verzweigungsziel steuert). Mit anderen Worten ist für eine herkömmliche Decodierung die Reihenfolge der Präsentation derselben Quelloperanden irrelevant. Ein Beispiel für solch ein Verhalten ist in 8 dargestellt, das oben beschrieben wurde.
-
9 zeigt einen Befehlsstrom 255, der aus einer virtuellen Decodierung der Befehle 233 und 235 resultiert. Der Befehlsstrom 255 zeigt, dass der zweite Befehl als Verzweigen-Nicht-Gleich-Befehl (BNE) 260 interpretiert wurde, obwohl die Daten des Befehls „literal” einen BEQ-Befehl auslösen. Weiter oben wurde erklärt, dass Befehle, die dem Prozessor 50 bereitgestellt werden, einer bestimmten ISA entsprechen. Eine interne Darstellung der Operation, die tatsächlich vom Prozessor ausgeführt wird, muss jedoch nicht dem bitweisen Format entsprechen, das von der ISA spezifiziert wird. Es gibt beispielsweise nicht notwendigerweise eine Anforderung, dass die interne Darstellung eines Befehls die gleiche Bitzahl umfasst wie die externe Darstellung.
-
Wenn ein gegebener „literaler” Befehl mehrere verschiedene Befehle virtuell codieren kann, dann kann hier eine interne Darstellung eines virtuell codierten Befehls zusätzliche Bits aufweisen. Das Beispiel, dass ein BEQ-Befehl sowohl einen BEQ- als auch einen BNE-Befehl codieren kann, dient der Einfachheit der Erläuterung. Solch eine Codierung kann vorwiegend in einer ISA angewandt werden, die keinen BNE als literal codierten Befehl bereitstellt. Manche Implementierungen können jedoch den gleichen Befehl unterstützen, sowohl als literale Codierung als auch als virtuelle Codierung, als Migrationsstrategie, die sowohl alte Codes mit literaler Codierung als auch neue Codes erlaubt, die erzeugt wurden, um die virtuelle Codierung zu umfassen. Im Laufe der Zeit wird der neue Code zum alten Code, und die alte ISA mit dem literal codierten Befehl kann verworfen werden. In anderen Implementierungen kann derselbe Hauptbefehl mit mehreren Formatoptionen unterstützt werden. Beispielsweise kann ein literal codierter BNE dazu führen, dass die Verzweigung in Bezug auf eine Position genommen wird, die basierend auf der spezifizierten Konstante in Bezug auf eine Basisadresse des auszuführenden Codesegments spezifiziert wird, und der virtuell codierte Befehl kann dazu führen, dass die Verzweigung zu einer Position genommen wird, die von der Konstante in Bezug auf den aktuellen Programmzähler spezifiziert wird. Abweichungen von diesen Beispielen sind möglich (z. B. Verschiebung des Programmzählers um einige Bitzahlen, bevor eine Zieladresse berechnet wird). Eine weitere beispielhafte Kategorie von Befehlen, die bereitgestellt werden können, sind kompakte Verzweigungsbefehle. Ein kompakter Verzweigungsbefehl weist keinen Warteplatz auf. Eine weitere Kategorie umfasst Befehle, die unterschiedliches Verhalten aufweisen können, wenn bestimmte Bedingungen erfasst werden, wie z. B. Überlauf, Unterlauf oder Ausnahmen. Andere mögliche Befehlscodierungen sind nachstehend beschrieben. Beispielsweise können Funktionscodes verschiedene Optionen spezifizieren, wie z. B. eine Verzweigung in Bezug auf einen Programmzähler oder in Bezug auf einen Versatz, Verzweigung bei Überlauf, Verzweigung mit Ausnahme usw.
-
10 und 11 zeigen, wie derselbe literal codierte Befehl verarbeitet werden kann, um zwei unterschiedliche Ausführungsoptionen zu codieren; diese Beispiele zeigen, wie der Prozessor als Ganzes den ihm bereitgestellten literal codierten Befehl behandeln würde. 10 zeigt, dass eine Bestimmung 304, dass Rb größer ist als Ra, dazu führt, dass die Werte in Rb und Ra bei 306 miteinander verglichen werden. Falls die Werte nicht gleich sind, wird die Verzweigung nicht genommen und der PC wird einfach bei 308 erhöht. Falls die Werte gleich sind, wird der PC basierend auf der spezifizierten Konstante bei 312 gesetzt (normales BEQ-Verhalten). 10 zeigt auch, dass gegebenenfalls bestimmt werden kann, ob Rb kleiner als Ra ist, bei 320, und falls dies der Fall ist, wird bei 322 bestimmt, ob die Werte in Rb und Ra nicht gleich sind (oder die Bestimmung 304 kann direkt zu Bestimmung 322 springen anstatt zu 320). Ein Ergebnis der Bestimmung 322 steuert, ob die Verzweigung genommen wird oder nicht. Die Verzweigung wird genommen, falls die Werte in Rb und Ra nicht gleich sind (Sprung zu Aktion 328), und ansonsten nicht (Aktion 325).
-
Eine gleichwertige Implementierung wäre eine Durchführung der Aktion 304 und Codierung eines Ergebnisses dieser Aktion als zusätzliches Zustandsbit, das nach dem Befehl folgt. Dann wird das Ergebnis der Aktion 306 (Vergleich der Werte in den Quellregistern) in Bezug auf das codierte Ergebnis der Bestimmung bei 304 interpretiert. Bei solch einem Ansatz ist die Bestimmung 322 unnötig, da sie das Gegenteil von Aktion 306 ist.
-
11 zeigt eine Implementierung gemäß solch einem Ansatz zur Ausführung des obigen virtuell codierten BEQ/BNE-Beispiels. In 11 werden Ra und Rb bei 330 verglichen. Dieser Vergleich kann während der Befehlsdecodierung erfolgen. Bei 331 wird ein Bit gemäß einem Ergebnis des Vergleichs von Ra und Rb gesetzt (das Bit wird basierend darauf, ob Ra gleich ist wie Rb oder nicht, auf einen Wert gesetzt). Bei 332 wird, falls keine architektonisch sichtbaren Werte für Ra und Rb zur Verfügung stehen, der Befehl von der Ausführung ausgeschlossen (in diesem Beispiel). Bei 333 werden, falls die Werte von Ra und Rb verfügbar werden, diese Werte bei 334 verglichen; ansonsten bleibt der Befehl bei 332 ausgeschlossen. Bei 335 verläuft, falls das Bit auf einen Wert gesetzt wird, der so interpretiert wird, dass er einen BNE-Befehl angibt (dies kann eine Sache von Konvention sein), und falls die Werte von Ra und Rb nicht gleich sind, bei 337 die Verzweigung gemäß der BNE-Befehlsdefinition. Bei 338 verläuft, falls das Bit auf einen Wert gesetzt wird, der so interpretiert wird, dass er einen BEQ-Befehl angibt, und falls die Werte von Ra und Rb gleich sind, bei 336 die Verzweigung gemäß der BEQ-Befehlsdefinition. Ansonsten wird bei 339 der PC erhöht.
-
Das Beispiel aus 11 zeigt, dass der Befehl zur vollständigen Decodierung des Befehls der Decodiereinheit zur Verfügung steht, obwohl die Endwerte von Ra und Rb noch nicht zur Verfügung stehen, und es können Daten erzeugt werden, die definieren, welche Aktionen zu einem späteren Zeitpunkt in der Pipeline des Prozessors gemacht werden sollen. Die in 335 und 336 dargestellten Entscheidungen können refaktoriert werden. Beispielsweise kann der Inhalt der Register verglichen werden und dann kann bestimmt werden, ob ein BNE- oder BEQ-Verhalten indiziert ist, und ein Programmzähler wird demgemäß gesetzt. Dies sind beispielhafte Entscheidungen für Mikroarchitekturimplementierungen, die Durchschnittsfachleute je nach Konstruktionsumständen treffen.
-
12 und 13 zeigen Beispiele für virtuelle Befehlssatzarchitekturen, die auch Befehlssatzinformationen in einem konstanten Wert der literalen Daten für einen gegebenen Befehl codieren, wiederum unter Anwendung eines für einen BNE- oder BEQ-Befehl geeigneten Ansatzes. In 12 wird bei 347 eine Entscheidung getroffen, ob beide Quellregister gleich sind. Bei einem herkömmlichen BNE- oder BEQ-Befehl wird, falls beide Quellregister gleich sind, die Verzweigung niemals genommen oder immer genommen. Unter geeigneten Umständen kann also ein BNE- oder BEQ-Befehl generiert werden, der das gleiche Quellregister in beiden Quelloperanden umfasst. Dieser Umstand kann vom Befehlsdecodierer so interpretiert werden, dass er anzeigt, dass die Konstante zu verwenden ist, um bei 349 zu bestimmen, welche Operation ausgeführt werden soll. Die Konstante ist in diesem Beispiel 16 Bit groß und kann daher viele Informationen codieren. 13 zeigt ein weiteres Beispiel, bei dem solch eine Bestimmung 340 als Hinweis auf eine immer genommene Verzweigung dient, wobei das Verzweigungsziel unter Verwendung des Inhalts des Quellregisters und der Konstante zur Berechnung eines nächsten PC berechnet wird. Das Vorhandensein von zusätzlichen 32 Bits (im Beispiel mit 32-Bit-Registern) ermöglicht das Durchführen einer viel größeren Anzahl von Sprüngen, als wenn nur die 16 Bits des Versatzes verwendet werden können.
-
14 zeigt eine konzeptionelle Darstellung davon, wie Opcodes in einem literalen Opcodeidentifikatorraum 350 positioniert sein können. Gemäß 14 gibt es ungenutzten Opcoderaum zwischen 110011 und 110001 binär (da dieses Beispiel davon ausgeht, dass es keine Hauptopcodes in diesem Raum gibt, müssen die Funktionscodes nicht berücksichtigt werden). In diesem Raum kann ein Satz von virtuellen Opcodes 352 bereitgestellt werden. Das Beispiel aus 14 zeigt, dass ein Paar 355 von virtuellen Opcodes für jeden einzigartigen Opcodeidentifikator zur Verfügung steht. Dies ist der Fall im Beispiel, in dem eine relative Reihenfolge von zwei Quellregisterzahlen berücksichtigt wird, nicht aber beispielsweise ein Wert für eine Konstante. 15 zeigt, dass eine größere Anzahl von virtuellen Opcodes 360 in einem einzelnen literalen Opcodeidentifikator verfügbar ist, wenn auch ein konstanter Wert verwendet wird, der mit einem Befehl bereitgestellt wird, wie in 12. Allgemeiner gesagt kann davon ausgegangen werden, dass Befehle sich auf Elemente aus vorbestimmten Sätzen von Elementen beziehen können, die eine inhärente Reihenfolge besitzen. Durch Anwendung einer Konvention, die den generalisierten Fall beschränkt, wird zusätzlicher Opcodeidentifikatorraum erhalten.
-
Ein Prozessor kann mit einer Decodiereinheit versehen sein, die diese Offenbarungen ausführt. Der Prozessor würde jedoch immer noch unter einer Konfiguration durch einen Code laufen, der von einer externen Quelle (z. B. einem Compiler, einem Assembler oder einem Interpreter) generiert wird. Solch eine Codegenerierung kann das Umwandeln eines Quellcodes in einer höheren Programmiersprache in einen Objektcode (z. B. ein ausführbares Binary oder eine Bibliothek, die dynamisch verbunden werden kann) oder das Produzieren einer Assemblersprachenausgabe umfassen, die editiert und schlussendlich in einen Objektcode umgewandelt werden könnte. Andere Situationen können das Umwandeln eines Quellcodes in ein Zwischencodeformat (z. B. ein „Bytecode”-Format) umfassen, das umgewandelt oder interpretiert werden kann, beispielsweise durch einen Just-In-Time(JIT)-Prozess, wie etwa im Zusammenhang mit einer virtuellen Java®-Maschine. Alle Aspekte dieser Beispiele zur Codegenerierung können in einer Implementierung der Offenbarung eingesetzt werden. Außerdem können diese Beispiele von Durchschnittsfachleuten auf dem Gebiet der Erfindung herangezogen werden, um zu verstehen, wie diese Beispiele unterverschiedenen Umständen anzuwenden sind.
-
16 zeigt ein Beispiel eines Prozesses, mit dem ein Compiler einen maschinenausführbaren Code erzeugen kann, der Merkmale gemäß der Offenbarung aufweist. Bei 402 wird bestimmt, ob ein aktueller Codegenerierungsmodus zur Erstellung von virtualisierten Befehlen dient oder nicht. Falls nicht, dann kann bei 418 ein typischer nichtvirtualisierter Maschinencode für eine gegebene Eingabe (z. B. ein hohes Quellcodemodul oder einen Teil eines Assemblersprachencodes) erzeugt werden. Dient er zur Erstellung von virtualisierten Befehlen, dann wird bei 406 ein Quellcodeelement aus der Eingabe als Kandidat für eine virtualisierte Codierung identifiziert. Bei 408 wird ein Opcode, der einen bestimmten Satz von virtualisierten Opcodes anzeigt, ausgeführt. Solch eine Auswahl kann darauf basieren, welche Operation(en) das Quellcodeelement ausführt. Falls das Quellcodeelement in einer höheren Sprache vorliegt, kann das Element in mehrere Maschinensprachenelemente zerlegt werden, von denen jedes ein Kandidat für eine virtualisierte Befehlscodierung sein könnte. Ein Compiler hat verschiedene Möglichkeiten, wie er einen Objektcode aus einer Quellcodeeingabe erzeugt, und die Bereitstellung von mehr verfügbaren Befehlen durch die Möglichkeit der Verwendung von virtualisierten Opcodes würde diese Optionen vermehren. Compiler können auf verschiedenen Heuristiken und anderen Analyseansätzen basieren, um eine Codesequenz zu bestimmen. Compiler müssen Beschränkungen beachten, die durch die Architektur, für welche der Compiler eine Ausgabe generiert, vorgegeben sind.
-
Bei 410 ist, um einen gegebenen virtualisierten Opcode vollständig zu spezifizieren, eine geeignete relative Reihenfolge von Quellregistern erforderlich (in einem Beispiel). Daher werden bei 410 diese Quellregisterwerte bestimmt. Während einer Ausführung können diese Quellregister in geeignete physische Register umbenannt werden, aber der Compiler sollte immer noch versuchen, falsche Abhängigkeiten zu vermeiden. Bei 412 wird, falls auch eine Konstante zur Codierung eines virtualisierten Opcodes eingesetzt wird, diese Konstante bestimmt. Ansonsten kann die Konstante basierend auf anderen Überlegungen bestimmt werden, wie z. B. der Position eines Verzweigungsziels, in Bezug auf entweder eine Basisadresse oder etwa den PC. Bei 414 kann ein finalisierter Assemblersprachenbefehl ausgegeben werden; in anderen Beispielen kann ein Bytecode oder ein Binärcode ausgegeben werden.
-
17 zeigt ein Diagramm, in dem ein Compiler 430 einen Assembler 434 umfasst. Als Option kann der Compiler 430 einen Assemblercode 432 gemäß der Offenbarung generieren. Dieser Assemblercode könnte ausgegeben werden. Solch ein Assemblercode kann in einer Textdarstellung vorliegen, die Pneumonik für die verschiedenen Befehle sowie für die Operanden und andere Informationen, die für den Befehl verwendet werden, umfasst. Diese Pneumonik kann so gewählt werden, dass die tatsächliche Operation, die für jedes Assemblercodeelement ausgeführt wird, durch die Pneumonik dargestellt ist. Mit anderen Worten würde, obwohl die zugrundeliegenden binären Opcodeidentifikatoren innerhalb eines binären Codes gleich sein können, wenn dieser binäre Code in einer Textassemblersprache dargestellt würde, die gewählte Pneumonik auch basierend auf den anderen Elementen jedes Assemblersprachenelements, etwa der relativen Registerreihenfolge, gewählt, die bestimmen, welche Operation vom Prozessor ausgeführt wird, und nicht einfach eine literale Übersetzung des binären Opcodeidentifikators. 17 zeigt auch, dass der Compiler einen Objektcode und Bytecode ausgeben kann, die auf einer bestimmten Architektur interpretierbar, kompilierbar oder ausführbar sein können. Hier steht „Bytecode” für jede beliebige Form von maschinenlesbarem Zwischenformat, das in vielen Fällen nicht direkt auf eine physische Prozessorarchitektur ausgerichtet ist, sondern auf eine Architektur einer virtuellen Maschine, die schlussendlich eine solche Ausführung durchführt. Eine physische Prozessorarchitektur kann konzipiert sein, um jedes solche maschinenlesbare Zwischenformat auszuführen, und die Bezeichnung „Bytecode” wird eher aufgrund seiner Einfachheit und nicht als Beschränkung verwendet.
-
18 zeigt ein Blockschaltbild einer beispielhaften Maschine 439, in der Aspekte der Offenbarung ausgeführt werden können. Eine Reihe von Anwendungen kann auf der Maschine 439 ausgeführt werden. Diese Anwendungen sind in Bytecode 440 codiert. Anwendungen können auch in nativem Maschinencode dargestellt sein; diese Anwendungen sind durch die Anwendungen 441 dargestellt. In Bytecode codierte Anwendungen werden innerhalb einer virtuellen Maschine 450 ausgeführt. Die virtuelle Maschine 450 kann einen Interpreter und/oder einen Just-In-Time(JIT)-Compiler 452 umfassen. Die virtuelle Maschine 450 kann einen Speicher 454 von kompilierten Bytecodes umfassen, die für die Ausführung von Anwendungen wiederverwendet werden können. Die virtuelle Maschine 450 kann Bibliotheken aus nativen Codebibliotheken 442 verwenden. Diese Bibliotheken sind Objektcodebibliotheken, die für physische Ausführungseinheiten 462 kompiliert sind. Eine Hardwareabstraktionsschicht (HAL) 455 stellt verschiedenen Hardwareelementen abstrahierte Schnittstellen bereit, die gemeinsam als Vorrichtungen 464 bezeichnet werden. Die HAL 455 kann in einem Benutzermodus ausgeführt werden. Eine Maschine 439 führt auch einen Operationssystemkern 455 aus.
-
Die Vorrichtungen 464 können IO-Vorrichtungen und -Sensoren umfassen, die zur Verwendung durch Anwendungen verfügbar zu machen sind. Beispielsweise kann die HAL 455 eine Schnittstelle für ein globales Positionsbestimmungssystem, einen Kompass, ein Gyroskop, einen Beschleunigungsmesser, Temperatursensoren, ein Netz, Nahkommunikationsressourcen, wie z. B. Bluetooth oder Nahfeldkommunikation, ein RFID-Subsystem, eine Kamera usw. bereitstellen.
-
Die Maschine 439 weist einen Satz von Ausführungseinheiten 462 auf, die einen Maschinencode konsumieren, der die Ausführungseinheiten 462 auslegt, damit sie Berechnungen ausführen. Solch ein Maschinencode wird daher ausgeführt, um Anwendungen auszuführen, die ihren Ursprung als Bytecode, als native Codebibliotheken, als Objektcode von Benutzeranwendungen und als Code für den Kern 455 haben. Jede dieser unterschiedlichen Komponenten der Maschine 439 kann unter Verwendung der Offenbarungen zur virtualisierten Befehlscodierung implementiert werden.
-
19 zeigt ein Beispiel für eine Maschine 505, die Ausführungselemente und andere hier offenbarte Aspekte implementiert. 19 zeigt, dass unterschiedliche Implementierungen der Maschine 505 verschiedene Integrationsniveaus aufweisen können. In einem Beispiel kann ein einzelnes Halbleiterelement ein Prozessormodul 558 implementieren, das Kerne 515–517, einen Kohärenzverwalter 520, der eine Schnittstelle mit den Kernen 515–517 mit einem L2-Cache 525 aufweist, eine I/O-Steuereinheit 530 und eine Unterbrechungssteuerung 510 umfasst. Ein Systemspeicher 564 weist eine Schnittstelle mit dem L2-Cache 525 auf. Der Kohärenzverwalter 520 kann eine Speicherverwaltungseinheit umfassen und dient zur Verwaltung von Datenkohärenz zwischen Daten, mit denen die Kerne 515–517 arbeiten. Die Kerne können auch Zugang zu L1-Caches haben, die nicht separat dargestellt sind. In einer weiteren Implementierung ist eine IO-Speicherverwaltungseinheit (IOMMU) 532 bereitgestellt. Die IOMMU 532 kann auf demselben Halbleiterelement bereitgestellt sein wie das Prozessormodul 558, das als Modul 559 bezeichnet wird. Das Modul 559 kann durch eine Zwischenverbindung 580 auch eine Schnittstelle mit IO-Vorrichtungen 575–577 aufweisen. Eine Gruppe aus dem Prozessormodul 558, das im Modul 559 umfasst ist, der Zwischenverbindung 580 und den IO-Vorrichtungen 575–577 kann auf einem oder mehreren Halbleiterelementen ausgebildet sein. In der beispielhaften Maschine 505 aus 19 können die Kerne 515–517 jeweils einen oder mehrere Rechenstränge unterstützen und ihre Architektur kann den Offenbarungen hier entsprechen.
-
Es wurden zwar einige Gegenstände hier in einer Sprache beschrieben, die sich speziell auf Beispiele von Strukturmerkmalen und/oder Verfahrensschritten bezieht, es versteht sich jedoch, dass der in den beiliegenden Ansprüchen definierte Gegenstand nicht unbedingt auf diese beschriebenen Merkmale oder Vorgänge beschränkt ist. Ein gegebenes Strukturmerkmal kann beispielsweise in einem anderen Strukturelement enthalten sein, oder solch ein Merkmal kann zwischen separaten Bauteilen aufgeteilt oder aufgetrennt sein. Auf ähnliche Weise kann ein beispielhafter Abschnitt eines Verfahrens als Nebenprodukt oder gleichzeitig mit der Durchführung eines anderen Vorgangs oder Prozesses erreicht werden, oder er kann in manchen Implementierungen in Form von mehreren separaten Vorgängen ausgeführt werden. In einer Reihenfolge präsentierte Vorgänge können in einer anderen Reihenfolge neu geordnet werden, solange geeignete Abhängigkeiten eingehalten werden. Implementierungen können manche Vorgänge in Bezug zu anderen verzögern. Implementierungen können unterschiedliche Fälle desselben Vorgangs auf derselben Hardware parallel ausführen. Damit sind Implementierungen gemäß dieser Offenbarung nicht auf solche beschränkt, die 1:1 den dargestellten und/oder beschriebenen Beispielen entsprechen.
-
Aspekte von Funktionen und Verfahren, die beschrieben und/oder beansprucht sind, können in Rechnern für spezielle Zwecke oder für allgemeine Zwecke implementiert sein, einschließlich Rechnerhardware, wie nachstehend genauer erläutert ist. Solche Hardware, Firmware und Software kann auch auf einer Videokarte oder auf anderen externen oder internen Computersystem-Peripherieelementen implementiert sein. Verschiedene Funktionalitäten können in individuell zugeschnittenen FPGAs oder ASICs oder anderen konfigurierbaren Prozessoren bereitgestellt werden, und manche Funktionalitäten können in einem Verwaltungs- oder Hostprozessor bereitgestellt werden. Solche Verarbeitungsfunktionalitäten können in Personalcomputern, Desktopcomputern, Laptopcomputern, Nachrichtenprozessoren, Handgeräten, Multiprozessorsystemen, in auf Mikroprozessoren basierender oder programmierbarer Unterhaltungselektronik, Spielkonsolen, Netz-PCs, Minicomputern, Großrechnern, Mobiltelefonen, PDAs, Tablets u. dgl. verwendet werden.
-
Neben Hardwareimplementierungen (z. B. in einem Hauptprozessor („CPU”), Mikroprozessor, einer Mikrosteuerung, einem digitalen Signalprozessor, Prozessorkern, Ein-Chip-System („SOC”) oder einer anderen programmierbaren oder elektronischen Vorrichtung oder gekoppelt mit diesen) können Implementierungen auch in Software implementiert sein (z. B. computerlesbarer Code, Programmcode, Befehle und/oder Daten in beliebiger Form, z. B. als Quell-, Objekt- oder Maschinensprache), die beispielsweise auf einem von einem Rechner nutzbaren (z. B. lesbaren) Medium bereitgestellt sein können, das zur Speicherung der Software ausgelegt ist. Solche Software kann beispielsweise die Funktion, Herstellung, Modellierung, Simulation, Beschreibung und/oder Prüfung der Vorrichtung und der Verfahren, die hier beschrieben sind, ermöglichen. Beispielsweise kann dies durch die Verwendung von allgemeinen Programmiersprachen (z. B. C, C++), GDSII-Datenbanken, Hardwarebeschreibungssprachen (HDL), einschließlich Verilog HDL, VHDL, SystemC Registertransfersprache (RTL) usw., oder anderen verfügbaren Programmen, Datenbanken und/oder Schaltungs- (d. h. schematischen) Erfassungssystemen erreicht werden. Ausführungsformen können auf einem von einem Rechner nutzbaren Medium, einschließlich nichtflüchtiger Speicher, wie z. B. Speicher unter Verwendung von Halbleitern, Magnetscheiben, optischen Scheiben, eisenhaltigen, Resistiv-Speichern usw. bereitgestellt sein.
-
Es versteht sich, dass als spezielle Beispiele Implementierungen von offenbarten Vorrichtungen und Verfahren in einem als geistiges Eigentum geschützten Halbleiterkern implementiert werden können, wie z. B. in einem Mikroprozessorkern oder einem Teil davon, der in einer Hardwarebeschreibungssprache (HDL) ausgeführt ist, was verwendet werden kann, um eine spezielle Implementierung als integrierte Schaltung zu erzeugen. Ein computerlesbares Medium kann solche Beschreibungssprachendaten enthalten oder speichern und somit ein Fabrikat darstellen. Ein nichtflüchtiges maschinenlesbares Medium ist ein Beispiel für computerlesbare Medien. Beispiele für andere Ausführungsformen umfassen computerlesbare Medien, die eine Beschreibung als Registertransfersprache (RTL) speichern, die zur Verwendung in einer speziellen Architektur- oder Mikroarchitekturimplementierung angepasst werden kann. Außerdem können die hier beschriebenen Vorrichtungen und Verfahren als Kombination aus Hardware und Software, die Hardware konfiguriert oder programmiert, ausgeführt sein.
-
In manchen Fällen wurde hier auch Terminologie verwendet, weil sie geeignet schien, um Durchschnittsfachleuten wichtige Punkte auf vernünftige Weise näher zu bringen, aber solche Terminologie ist nicht als implizierte Beschränkung der Implementierungen zu verstehen, die durch die offenbarten Beispiele und andere Aspekte abgedeckt sind.
-
Außerdem wurde in der voranstehenden Offenbarung eine Reihe von Beispielen veranschaulicht und beschrieben. Offensichtlich kann nicht jedes Beispiel jeden Aspekt darstellen, und die Beispiele veranschaulichen keine exklusiven Zusammenstellungen solcher Aspekte. Stattdessen können Aspekte, die in Bezug auf eine Figur oder ein Beispiel veranschaulicht und beschrieben wurden, mit Aspekten kombiniert oder verwendet werden, die in Bezug auf andere Figuren veranschaulicht und beschrieben wurden. Durchschnittsfachleute werden daher anhand dieser Offenbarungen verstehen, dass die voranstehende Offenbarung bezüglich des Umfangs von Ausführungsformen gemäß den Ansprüchen nicht beschränkt ist, und dass der Schutzumfang der Ansprüche die Breite und den Schutzumfang der erfinderischen Ausführungsformen hier definiert. Die Abschnitte Kurzfassung und Zusammenfassung können eine oder mehrere, nicht jedoch alle beispielhaften Ausführungsformen und Aspekte der Erfindung innerhalb des Schutzumfangs der Ansprüche darlegen.
