DE10297624T5

DE10297624T5 - Steuerung von Kompatibilitätsgraden von Binärcode-Übersetzungen zwischen Befehlssatzarchitekturen

Info

Publication number: DE10297624T5
Application number: DE10297624T
Authority: DE
Inventors: Roni Rosner; Avi Mendelson
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2002-01-02
Filing date: 2002-12-27
Publication date: 2004-11-25
Also published as: GB2400949A; GB2400949B; WO2003058432A1; CN100357882C; US20030126587A1; AU2002361884A1; GB0414805D0; TWI279715B; TW200403583A; US7251811B2; HK1067205A1; CN1613054A

Abstract

Verfahren, umfassend:
Empfangen eines Binärcodes eines Programmcodes, wobei der Binärcode auf einer ersten Befehlssatzarchitektur basiert; und
Übersetzen des Binärcodes, wobei der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.

Description

Gebiet der Erfindung
Die Erfindung betrifft Computerverarbeitung. Genauer gesagt betrifft die Erfindung die Übersetzung von Binärcodes zwischen unterschiedlichen Befehlssatzarchitekturen oder unterschiedlichen Optimierungsgraden mit derselben Befehlssatzarchitektur.
Hintergrund der Erfindung
Während gegenwärtige Computerprogrammcompiler gestaltet sind, um Binärcodes zu erzeugen, die die neuesten Entwicklungen von gegenwärtigen Befehlssatzarchitekturen (Instruction Set Architectures (ISA)) nutzen, können Binärcodes, die auf der Grundlage einer älteren Befehlssatzarchitektur erzeugt worden sind, nicht diese neuesten Entwicklungen nutzen. Binärcode-Übersetzung stellt ein übliches Verfahren dar, das zum Übersetzen von Binärcodes eines bestimmten Programmcodes/von bestimmten Anwendungen, die auf einer Befehlssatzarchitektur basieren, in Binärcodes eines bestimmten Programmcodes/von bestimmten Anwendungen verwendet wird, die auf einer anderen Befehlssatzarchitektur oder einer anderen Untergruppe derselben Befehlssatzarchitektur basieren. Die andere Befehlssatzarchitektur kann eine andere Architektur oder eine verbesserte Version der älteren Befehlssatzarchitektur sein.
Typischerweise wird erwartet, daß binär übersetzte Programme genau dieselbe Funktionalität liefern, wie sie von dem ursprünglichen binär übersetzten Programm bereitgestellt wurde, das auf der älteren Befehlssatzarchitektur basierte. Mit anderen Worten wird typischerweise erwartet, daß Binärcode-Übersetzungen Programmsemantik, wie sie von der älteren Befehlssatzarchitektur definiert ist, vollständig erhalten, wodurch vollständige Abwärtskompatibilität bereitgestellt wird. Dementsprechend können die Anforderungen an die ältere Befehlssatzarchitektur diejenigen einschließen, die mit normalem Befehlsfluß, Datengenauigkeit, Handhabung von Ausnahmen und anderen Nebeneffekten der Programmausführung verbunden sind, die von dieser älteren Befehlssatzarchitektur definiert sind.
Diese Anforderung an die Semantik beschränkt typischerweise die Leistung der Binärcode-Übersetzung – entweder, indem gewisse Beschränkungen hinsichtlich der übersetzbaren Binärcodes auferlegt werden oder durch Beschränkung des Umfangs, in dem die Binärcode-Übersetzung die Vorteile der neuen Befehlssatzarchitektur nutzen kann. Wenn z. B. die zwei unterschiedlichen Befehlssatzarchitekturen nicht dieselben Gleitkommaformate, Breiten oder Genauigkeiten unterstützen, kann die Binärcode-Übersetzung zwischen diesen Befehlssatzarchitekturen von Gleitkommaoperationen schwierig und/oder ineffizient sein.
Kurzbeschreibung der Zeichnungen
Ausführungsformen der Erfindung können durch Bezugnahme auf die folgende Beschreibung und beigefügten Zeichnungen, die derartige Ausführungsformen darstellen, am besten verstanden werden. Das Nummerierschema für die hierin enthaltenen Figuren ist derart, daß die vordere Ziffer für ein bestimmtes Element in einer Figur mit der Nummer der Figur verbunden ist. Zum Beispiel ist System 100 in 1 auszumachen. Jedoch sind Elementzahlen dieselben für diejenigen Elemente, die dieselben über unterschiedliche Figuren sind.
In den Zeichnungen stellt
1 ein Beispielsystem 100, das Prozessoren 102 und 104 zur Steuerung von Kompatibilitätsgraden von Binärcode-Übersetzungen zwischen Befehlssatzarchitekturen umfaßt, gemäß Ausführungsformen der vorliegenden Erfindung dar;
2 ein detaillierteres Diagramm eines Prozessors und zugehörigen Speichers gemäß Ausführungsformen der vorliegenden Erfindung dar;
3 ein Flussdiagramm zur Übersetzung von Befehlen aus einem Binärcode, der auf einer ersten Befehlssatzarchitektur basiert, in Befehle aus einer zweiten Befehlssatzarchitektur, die mit der ersten Befehlssatzarchitektur teilweise kompatibel ist, gemäß Ausführungsformen der vorliegenden Erfindung dar;
4 Quellcode und den erzeugten Assembler-Code, worin ein Register als Teil des Hardware-Stapelspeichers benutzt wird und nicht benutzt wird, gemäß Ausführungsformen der vorliegenden Erfindung dar.
Ausführliche Beschreibung
In der folgenden Beschreibung werden zu Erläuterungszwecken zahlreiche spezielle Details dargestellt, um für ein umfassendes Verständnis der vorliegenden Erfindung zu sorgen. Es wird jedoch für einen Fachmann auf dem Gebiet ersichtlich sein, daß die vorliegende Erfindung ohne diese speziellen Details realisiert werden kann.
Ausführungsformen der vorliegenden Erfindung ermöglichen eine teilweise kompatible Befehlssatzarchitektur, worin ein Binärcode eines Programmcodes, der für eine erste Befehlssatzarchitektur erzeugt ist, in einen Binärcode übersetzt wird, der bestimmte Eigenschaften einer zweiten Befehlssatzarchitektur nutzt, während er mit der ersten Befehlssatzarchitektur teilweise kompatibel bleibt. In einer Ausführungsform wird der Kompatibilitätsgrad von der Programmumgebung gesteuert, die den Benutzer, den Compiler und das Betriebssystem einschließt, ohne aber darauf beschränkt zu sein. In einer derartigen Ausführungsform wird eine Gruppe von Kompatibilitätsmodi bzw. -parametern (switches) auf der zweiten Befehlssatzarchitektur definiert. Dementsprechend kann die Programmumgebung den gewünschten Kompatibilitätsmodus explizit einstellen. In einer Ausführungsform zur Hardware-Übersetzung kann die Einstellung des Kompatibilitätsmodus durch eine Gruppe von Hardware-Befehlen erfolgen. In einer Ausführungsform zur Software-Übersetzung kann diese Einstellung des Kompatibilitätsmodus durch eine Anzahl von Befehlszeilen-Flags durchgeführt werden, die in Verbindung mit der Initiierung der Ausführung des Binärcodes verwendet werden.
Wie unten ausführlicher beschrieben wird, ermöglichen somit Ausführungsformen der vorliegenden Erfindung eine Verbesserung der Leistung (bezogen auf die zweite Befehlssatzarchitektur) im Tausch gegen eine gewisse Abweichung von der genauen Programmsemantik (bezogen auf die erste Befehlssatzarchitektur).
Zusätzlich können in einer Ausführungsform die unterschiedlichen Befehlssatzarchitekturen, auf denen die (hierin beschriebenen) Binärcodes basieren, irgendeine von einer Anzahl von unterschiedlichen Befehlssatzarchitekturen, einschließlich, aber ohne darauf beschränkt zu sein, der unterschiedlichen Complex-Instruction-Set-Computer (CISC)-Befehlssätze sowie der unterschiedlichen Reduced-Instruction-Set-Computer (RISC)-Befehlssätze, sein. Beispiele für derartige Befehlssatzarchitekturen schließen Intel^®IA-32 und Intel^®IA-64 ein.
1 stellt ein Beispielsystem 100, das Prozessoren 102 und 104 zur Steuerung von Kompatibilitätsgraden von Binärcode-Übersetzungen zwischen Befehlssatzarchitekturen umfaßt, gemäß Ausführungsformen der vorliegenden Erfindung dar. Obwohl im Zusammenhang mit System 100 beschrieben, kann die vorliegende Erfindung in irgendeinem geeigneten Computersystem, das irgendeinen oder mehrere geeignete integrierte Schaltkreise umfaßt, implementiert werden.
Wie in 1 dargestellt, umfaßt das Computersystem 100 den Prozessor 102 und den Prozessor 104. Das Computersystem 100 enthält auch Speicher 132, Prozessorbus 110 und Input/Output Controller Hub (ICH) 140. Die Prozessoren 102 und 104, der Speicher 132 und der ICH 140 sind mit dem Prozessorbus 110 gekoppelt. Die Prozessoren 102 und 104 können jeweils irgendeine geeignete Prozessorarchitektur aufweisen und weisen in einer Ausführungsform eine Intel^®-Architektur auf, die z. B. in der Pentium^®-Familie von Prozessoren verwendet wird, die von Intel^® Corporation of Santa Clara, Kalifornien, erhältlich sind. Das Computersystem 100 kann für andere Ausführungsformen einen, drei oder mehr Prozessoren umfassen, von denen jeder einen Satz von Befehlen ausführen kann, die gemäß Ausführungsformen der vorliegenden Erfindung sind.
Der Speicher 132 speichert Daten und/oder Befehle z. B. für das Computersystem 100 und kann irgendeinen geeigneten Speicher, wie z. B. einen dynamischen Speicher mit wahlfreiem Zugriff (Dynamic Random Access Memory (DRAM)), umfassen. Grafik-Controller 134 steuert die Anzeige von Informationen auf einem geeigneten Anzeigegerät 136, wie z. B. einer Kathodenstrahlröhre (Cathode Ray Tube (CRT)) oder Flüssigkristallanzeige (Liquid Crystal Display (LCD)), die mit dem Grafik-Controller 134 gekoppelt ist.
Der ICH 140 sorgt für eine Schnittstelle für Ein-/Ausgabegeräte oder Peripheriekomponenten für das Computersystem 100. Der ICH 140 kann irgendeinen geeigneten Schnittstellen-Controller umfassen, um für eine geeignete Kommunikationsverbindung mit den Prozessoren 102/104, dem Speicher 132 und/oder irgendeinem geeigneten Gerät oder einer geeigneten Komponente, die mit dem ICH 140 in Verbindung steht, zu sorgen. Der ICH 140 sorgt in einer Ausführungsform für geeignete Buszuteilung und Pufferung für jede Schnittstelle.
In einer Ausführungsform liefert der ICH 140 eine Schnittstelle zu einem oder mehreren geeigneten Integrated Drive Electronics (IDE)-Laufwerke(n) 142, wie z. B. Festplattenlaufwerk (Hard Disk Drive (HDD)) oder Compact Disc Read Only Memory (CD ROM)-Laufwerk zum Speichern von z. B. Daten und/oder Befehlen und einem oder mehreren geeigneten Universal Serial Bus (USB)-Geräten über einen oder mehrere USB-Ports 144. Der ICH 140 sorgt in einer Ausführungsform auch für eine Schnittstelle zu einer Tastatur 151, einer Maus 152, einem oder mehreren geeigneten Geräten wie z. B. einem Drucker, über einen oder mehrere parallele Ports 153, einem oder mehreren geeigneten Geräten über einen oder mehrere serielle Ports 154 und einem Diskettenlaufwerk 155.
Zusätzlich enthält das Computersystem 100 eine Übersetzungseinheit 180. In einer Ausführungsform kann die Übersetzungseinheit 180 ein Prozeß oder eine Task sein, der/die sich im Hauptspeicher 132 und/oder Prozessoren 102 und 104 befinden kann und in den Prozessoren 102 und 104 ausgeführt werden kann. Jedoch sind Ausführungsformen der vorliegenden Erfindung nicht so beschränkt, da die Übersetzungseinheit 180 unterschiedliche Arten von Hardware (wie z. B. digitale Logik) sein kann, die die darin beschriebene Verarbeitung (die unten detaillierter beschrieben ist) durchführt.
Entsprechend enthält das Computersystem 100 ein maschinenlesbares Medium, auf dem ein Satz von Befehlen (d. h. Software) gespeichert ist, die irgendeine oder alle der hierin beschriebenen Methodologien verkörpern. Z .B. kann sich Software vollständig oder zumindest teilweise im Speicher 132 und/oder in den Prozessoren 102/104 befinden. Für die Zwecke dieser Beschreibung soll der Begriff „maschinenlesbares Medium" jede Einrichtung enthalten, die Informationen in einer von einer Maschine (z. B. einem Computer) lesbaren Form liefert (d. h. speichert und/oder überträgt). Z. B. enthält ein maschinenlesbares Medium Nur-Lese-Speicher (Read Only Memory (ROM)); Speicher mit wahlfreiem Zugriff (Random Access Memory (RAM)); Magnetplattenspeichermedien; optische Speichermedien; Flashmemory-Geräte; elektrische, optische, akustische und andere Formen von ausgebreiteten Signalen (z. B. Trägerwellen, Infrarotsignale, digitale Signale, etc.); etc.
2 stellt ein detaillierteres Diagramm eines Prozessors gemäß Ausführungsformen der vorliegenden Erfindung dar. Insbesondere stellt 2 ein detaillierteres Diagramm eines der Prozesoren 102/104 (nachfolgend "Prozessor 102") dar. Wie gezeigt, ist eine Speicherschnittstelleneinheit 270 mit Cache-Puffern 256, Register-Datei 250, (die Universal- Register 252 und Spezialzweck-Register 254 enthält) und Befehlspuffer 202 gekoppelt, so daß die Speicherschnittstelleneinheit 270 Makrobefehle und zugehörige Operanden abrufen und diese Daten im Befehlspuffer 202 und in den Cache-Puffern 256, Universal-Registern 252 und/oder Spezialzweck-Registern 254 speichert. Zusätzlich sind die Cache-Puffer 256 und die Register-Datei 250 mit einem Decoder 204, Funktionseinheiten 212-218 und einer Abschlußlogik (retirement logic) 228 gekoppelt.
Der Decoder 204 ist mit dem Befehlspuffer 202 so gekoppelt, daß der Decoder 204 die Befehle aus dem Befehlspuffer 202 abfragt. Der Decoder 204 kann diese Befehle empfangen und jeden davon decodieren, um den bestimmten Befehl zu ermitteln und auch eine Anzahl von Befehlen in einem internen Befehlssatz zu erzeugen. Z. B. werden in einer Ausführungsform die vom Decoder 204 empfangenen Befehle als Makrobefehle bezeichnet, während die Befehle, die vom Decoder 204 erzeugt werden, als Mikrobefehle (oder Mikrooperationen) bezeichnet werden. Der Decoder 204 ist auch mit einem Befehlseinteiler 208 gekoppelt, so daß der Befehlseinteiler 208 diese Mikrooperationen zur planmäßigen Ausführung durch Funktionseinheiten 212–218 empfangen kann.
Der Befehlseinteiler 208 ist mit einer Abfertigungslogik (dispatch logic) 226 gekoppelt, so daß der Befehlseinteiler 208 die von den Funktionseinheiten 212–218 auszuführenden Befehle sendet. Die Abfertigungslogik 226 ist mit Funktionseinheiten 212–218 gekoppelt, so daß die Abfertigungslogik 226 die Befehle zu den Funktionseinheiten 212–218 zur Ausführung sendet. Die Funktionseinheiten 212–218 können eine von einer Anzahl von unterschiedlichen Ausführungseinheiten sein, die eine arithmetische Integer-Logikeinheit (integer Arithmectic Logic Unit (ALU)), eine Gleitkommaeinheit, Speicherlade/Speichereinheit, etc. enthalten, ohne aber darauf beschränkt zu sein. Die Funktionseinheiten 212–218 sind auch mit der Abschlußlogik 228 gekoppelt, so daß die Funktionseinheiten 212–218 die Befehle ausführen und die Ergebnisse an die Abschlußlogik 228 senden. Die Abschlußlogik 228 kann diese Ergebnisse zum Speicher senden, der sich intern oder extern vom Prozessor 102 befinden kann, wie z. B. Register in der Register-Datei 250 oder den Cache-Puffern 256, oder Speicher 132 (extern vom Prozessor 102).
Die Operationen des Computersystems 100 werden nun detaillierter in Verbindung mit dem Flußdiagramm von 3 beschrieben werden. Insbesondere stellt 3 ein Flußdiagramm zur Übersetzung von Befehlen aus einem Binärcode, der auf einer ersten Befehlssatzarchitektur basiert, in Befehle von einer zweiten Befehlssatzarchitektur, die mit der ersten Befehlssatzarchitektur teilweise kompatibel ist, gemäß Ausführungsformen der vorliegenden Erfindung dar.
Das Flußdiagramm 300 von 3 ist als Teil des Decodier-Ausführ-Ablaufs des Computersystems 100 beschrieben. Ausführungsformen der vorliegenden Erfindung sind jedoch nicht so beschränkt. Z. B. könnten in einer anderen Ausführungsform die in dem Flußdiagramm 300 dargestellten Übersetzungsoperationen unabhängig vom Decodier-Ausführ-Ablauf des Computersystems 100 durchgeführt werden. In einer derartigen Ausführungsform könnten die übersetzten Befehle in einem speziellen Puffer (entweder intern oder extern bzgl. des Prozessors 102), wie z. B. einem Trace Cache (in 1 nicht gezeigt), gespeichert werden. Dementsprechend könnten derartige übersetzte Befehle aus diesem speziellen Puffer abgerufen und im Prozessor 102 ausgeführt werden. Somit ist in einer derartigen Ausführungsform der Kompatibilitätsgrad optional, so daß der Prozessor 102 die übersetzten Befehle in Abhängigkeit von seinem derzeitigen Wissen bzw. von seinen Ressourcen ausführen kann oder nicht. Z. B. können die übersetzten Befehle in einer ersten Umgebung (, in der die übersetzten Befehle vollständig verwertet werden) ausgeführt werden, während sie in einer zweiten Umgebung (, worin die Ausführung der übersetzten Befehle die Leistungswirkung nicht erhöht) nicht ausgeführt werden. Außerdem ist in einer Ausführungsform eine Untergruppe der übersetzten Befehle in die Ausführung des Binärcodes aufgenommen. Z. B. kann ein bestimmter Befehl eine Anzahl von Malen übersetzten werden. Jedoch ist in einer Ausführungsform die Anzahl von Malen, die dieser übersetzte Befehl in die Ausführung des Binärcodes aufgenommen wird, geringer als die Gesamtanzahl von Malen, die der Befehl übersetzt wird.
Bei Prozeßblock 302 wird ein erster Binärcode eines Programmcodes, der auf einer ersten Befehlssatzarchitektur basiert, empfangen. In einer Ausführungsform empfängt die Übersetzungseinheit 180 diesen ersten Binärcode eines Programmcodes, der auf einer ersten Befehlssatzarchitektur basiert. In einer Ausführungsform empfängt der Decoder 204 diesen ersten Binärcode eines Programmcodes, der auf einer ersten Befehlssatzarchitektur basiert. In einer Ausführungsform können sowohl die Übersetzungseinheit 180 als auch der Decoder 204 diesen Binärcode eines Programmcodes empfangen, der auf der ersten Befehlssatzarchitektur basiert.
In einer Ausführungsform wird die Übersetzungseinheit 180 verwendet, um eine Software-Übersetzung dieses ersten Binärcodes, der auf einer ersten Befehlssatzarchitekur basiert, in einen zweiten oder anderen Binärcode zu übersetzen, der auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert. In einer Ausführungsform wird der Decoder 204 benutzt, um eine Hardware-Übersetzung dieses ersten Binärcodes, der auf einer ersten Befehlssatzarchitektur basiert, in einen zweiten oder anderen Binärcode durchzuführen, der auf einer Kombination der ersten Befehlssatzarchitektur und der zweiten Befehlssatzarchitektur basiert. Wie unten detaillierter beschrieben wird, kann in einer Ausführungsform die Software-Übersetzung eines Binärcodes durch die Übersetzungseinheit 180 in Verbindung mit der Hardware-Übersetzung eines selben Binärcodes durch den Decoder 204 verwendet werden. In einer anderen Ausführungsform erfolgt die Software-Übersetzung eines Binärcodes durch die Übersetzungseinheit 180 ohne die Hardware-Übersetzung desselben Binärcodes durch den Decoder 204 und umgekehrt.
Bei Prozeßblock 304 werden Befehlssatzarchitekturausführungs-Flags überprüft, um mögliche Übersetzungen des ersten Binärcodes zu ermitteln. In einer Ausführungsform überprüft die Übersetzungseinheit 180 Befehlssatzarchitekturausführungs-Flags, um mögliche Übersetzungen des ersten Binärcodes zu ermitteln. In einer Ausführungsform überprüft der Decoder 204 Befehlssatzarchitekturausführungs-Flags, um mögliche Übersetzungen des ersten Binärcodes zu ermitteln. Obwohl die Übersetzungseinheit 180 mögliche Übersetzungen des ersten Binärcodes durch unterschiedliche Techniken ermitteln kann, ermittelt in einer Ausführungsform die Übersetzungseinheit 180 diese mögliche Übersetzung des ersten Binärcodes durch Überprüfung von Befehlszeilen-Flags, die in Verbindung mit dem Befehl, mit der Ausführung dieses ersten Binärcodes (, der diese Übersetzung enthalten kann) angenommen werden. Wenn z. B. der Name des ersten Binärcodes "binary.exe" wäre, könnte der Befehl, der Befehlszeilen-Flags zum Beginnen der Ausführung enthält, lauten: "binary.exe-f64-s-o", wobei die Befehlszeilen-Flags (1) – f64, (2) -s und (3) -o sind. Diese Befehlszeilen-Flags könnten unterschiedliche Übersetzungen dieses ersten Binärcodes anzeigen.
Zur Unterstützung der Darstellung könnte die Übersetzungseinheit 180 das „-s" als eine Übersetzung einer Anzahl von Einzelbefehlen (basierend auf einer Befehlssatzarchitektur, die keine Datenverarbeitung mit singulären Befehls- und parallelem Datenstrang (Same Instruction Multiple Data (SIMD)-Operationen unterstützt) in einen oder mehrere SIMD-Befehle in der zweiten oder anderen Befehlssatzarchitektur, die derartige Operationen unterstützt, anzeigend interpretieren. Wie unten detaillierter beschrieben werden wird, dienen die hierin beschriebenen unterschiedlichen Befehlssatzarchitekturausführungs-Flags als Beispiel und nicht als Beschränkung, da andere Befehle und Operationen innerhalb des ersten Binärcodes, der auf der ersten Befehlssatzarchitektur basiert, in andere Befehle und Operationen übersetzt werden können, die auf einer zweiten oder anderen Befehlssatzarchitektur basieren. Außerdem könnte in einer weiteren Ausführungsform (anstelle der und/oder in Verbindung mit der Prüfung von Befehlszeilen-Flags) die Übersetzungseinheit 180 diese mögliche Übersetzung des ersten Binärcodes durch Überprüfen von zahlreichen Speicherorten, wie z. B. einem Register in der Register-Datei 250 (in 2 gezeigt) ermitteln, um mögliche unterschiedliche Übersetzungen zu überprüfen.
Zum Prozeßblock 304 des Flußdigramms 300 in 3 zurückkehrend, kann der Decoder 204 auch Befehlssatzarchitekturausführungs-Flags überprüfen, um mögliche Übersetzung des ersten Binärcodes zu ermitteln. In einer Ausführungsform kann der Decoder 204 Befehlssatzarchitekturausführungs-Flags durch Abfragen eines Registers, wie z. B. eines von Spezialzweckregistern 254 in der Register-Datei 250 (in 2 dargestellt), überprüfen. In einer derartigen Ausführungsform ist ein bestimmtes Bit mit einem bestimmten Übersetzungstyp verbunden. Z. B. ist das Bit Null mit einer Modifikation der Genauigkeit von Gleitkommaoperanden verbunden (z. B. von einem 80-Bit-Format für eine Intel^®IA-32-Befehlssatzarchitektur zu einem 64-Bit-Format für eine Intel^®IA-64-Befehlssatzarchitektur ausgehend). Dementsprechend könnte ein auf weniger genauen Operanden basierendes anderes Ergebnis erzeugt werden, wobei die Ausführungsleistung größer ist, da Prozessoren Befehle, die auf dieser zweiten oder anderen Befehlssatzarchitektur basieren, typischerweise schneller im Vergleich zu Befehlen, die auf der ersten Befehlssatzarchitektur basieren, ausführen.
In einer Ausführungsform werden diese in einem Register im Prozessor 102 gespeicherten Befehlssatzarchitekturausführungs-Flags durch Architekturbefehle gesetzt, die bestimmte Flags ins Register setzen und ändern. In einer derartigen Ausführungsform können diese Befehle vom Betriebssystem vor Ausführung des Binärcodes verwendet werden.
Am Prozeßentscheidungsblock 304 des Flußdiagramms 300 wird eine Entscheidung hinsichtlich der Frage getroffen, ob Software-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. In einer Ausführungsform bestimmt die Übersetzungseinheit 180, ob Software-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. Wie oben beschrieben, kann die Übersetzungseinheit 180 durch eine von einer Anzahl von unterschiedlichen Arten ermitteln, ob Software-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. Die Anzahl von unterschiedlichen Arten schließt Überprüfen von Befehlszeilen-Flags bei der Initiierung der Ausführung des ersten Binärcodes und Überprüfen von verschiedenen Speicherorten, wie z. B. einem Register, ein, aber ohne darauf beschränkt zu sein.
Am Prozeßblock 308 wird mindestens ein Befehl vom ersten Binärcode in mindestens einen Befehl, der auf der zweiten Befehlssatzarchitektur basiert, unter Verwendung von Software-Übersetzung bei Ermittlung, daß Software-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist, übersetzt. In einer Ausführungsform führt die Übersetzungseinheit 180 diese Übersetzung durch. Wie oben beschrieben, könnte z. B. die Übersetzungseinheit 180 eine Anzahl von Einzelbefehlen (basierend auf einer Befehlssatzarchitektur, die keine SIMD-Operationen unterstützt) in einen oder mehrere SIMD-Befehle in der zweiten oder anderen Befehlssatzarchitektur, die derartige Operationen unterstützt, übersetzen. Zur Unterstützung der Darstellung könnte die Übersetzungseinheit 180 den Binärcode durchlaufen und ermitteln, daß dieser Binärcode vier verschiedene Befehle zur Addition enthält, so daß vier unterschiedliche Sätze von Operanden vorliegen. Dementsprechend könnte die Übersetzungseinheit 180 diese vier unterschiedlichen Befehle in diesem Binärcode in einen einzigen Befehl zur Addition übersetzen, worin die zwei Sätze von vier Operanden (jeweils 32 Bits) in zwei 128-Bit-SIMD-Register im Prozessor 120 zur Ausführung platziert sind.
In einer Ausführungsform für diese SIMD-Übersetzung basieren die Einzelbefehle auf einer ersten Befehlssatzarchitektur, während die SIMD-Befehle auf einer zweiten Befehlssatzarchitektur basieren. In einer Ausführungsform für diese SIMD-Übersetzung basieren die Einzelbefehle auf einer ersten Befehlssatzarchitektur, während die SIMD-Befehle auch auf der ersten Befehlssatzarchitektur basieren. Dementsprechend ermöglicht die SIMD-Übersetzung eine Verbesserung der Befehle für dieselbe Befehlssatzarchitektur.
Eine derartige Übersetzung könnte zu einer geringeren Genauigkeit bzgl. der Operanden führen; jedoch könnte die durch diese Übersetzung ermöglichte Leistungszunahme den Genauigkeitsaspekt in Abhängigkeit von der Art der Anwendung und/oder der Ausführungsumgebung, in der die Anwendung ausgeführt wird, ausgleichen. Somit kann die Programmumgebung, wie z. B. der Nutzer, vorschreiben, welche Übersetzungsarten auftreten können, während der Genauigkeitsverlust im Verhältnis zur Erhöhung der Leistung berücksichtigt wird. Z. B. können einige Grafikanwendungen, die nur einen Teil der vollen Gleitkommagenauigkeit verwenden, eine kleine Ungenauigkeit in den Gleitkommaoperationen tolerieren. Im Gegensatz dazu würden Anwendungen zur Vorhersage des Wetters, die die gesamte Gleitkommagenauigkeit in deren Gleitkommaoperationen verwenden, keine kleine Ungenauigkeit tolerieren, da eine derartige Ungenauigkeit andere und möglicherweise ungenaue Ergebnisse erzeugen könnte.
Außerdem kann dieselbe Anwendung derartige Modifikationen der Genauigkeit der Operanden in Abhängigkeit von der Ausführungsumgebung unterschiedlich tolerieren. Z. B. könnte eine Anwendung derartige Modifikationen der Genauigkeit für einen ersten Satz von Eingabedaten tolerieren, während dieselbe Anwendung derartige Modifikationen der Genauigkeit für einen anderen Satz von Eingabedaten nicht tolerieren könnte. Wenn, zur Unterstützung der Darstellung, der Satz von Eingabedaten vor Ausführung derartiger Daten durch die Anwendung validiert worden ist, muß die Anwendung keine Ausnahmen von der Genauigkeit behandeln. Wenn umgekehrt der Satz von Eingabedaten als besonders betrachtet wird und/oder nicht validiert worden ist, kann die Anwendung fordern, daß die Handhabung von Ausnahmen durchgeführt wird, die genaue und vollständige Daten für die Ausnahmen liefert. Somit könnte die Programmumgebung derartigen Unterschieden im Satz mit Eingabedaten Rechnung tragen und die Übersetzung im ersten Szenario ermöglichen und die Übersetzung im zweiten Szenario ausschließen.
Ein weiteres Beispiel für Software-Übersetzung durch die Übersetzungseinheit 180 enthält Optimierungen bezogen auf den Programm-Stapelspeicher. Insbesondere kann eine bestimmte Befehlssatzarchitektur, wie z. B. Intel^®IA32-Befehlssatzarchtektur, einen Hardware-Stapelspeicher mit Push- and Pop-Operationen enthalten, worin Daten, die in eine Prozedur eines Programms geleitet werden, auf dem Stapelspeicher durch eine Push-Operation platziert und aus dem Stapelspeicher durch eine Pop-Operation nach Beendigung der Prozedur entfernt werden. Außerdem können derartige Befehlssatzarchitekturen einen direkten Zugriff auf den Stapelzeiger (, der typischerweise in einem von Spezialzweck-Registern 254 gespeichert ist) ermöglichen. Da diese Befehlssatzarchitektur einen expliziten Zugang zum Stapelzeiger ermöglicht, können somit Binärcodes von Anwendungen unkonventionelle Zugriffe auf diesen Hardware-Stapelspeicher vornehmen.
Nehmen wir z. B. an, daß das Programm in eine Prozedur eintritt und einen Wert "V" an einem gewissen Ort "L" im Stapelspeicher, unter Verwendung eines bestimmten konstanten Versatzes vom Stapelzeiger, speichert. Das Programm kehrt dann aus der Prozedur zurück. In gewissen Befehlssatzarchitekturen wird jedoch der Wert "V" nicht explizit aus dem Stapelspeicher gelöscht. Außerdem stellen derartige Befehlssatzarchitekturen sicher, daß das Programm weiterhin auf den Wert "V" aus dem Stapelspeicher basierend auf dem Ort "L" unter Bezugnahme auf den Stapelzeiger (unter der Annahme, daß der Ort von anderen Teilen des Programms nicht überschrieben worden ist) zugreifen kann. Umgekehrt kann eine andere Befehlssatzarchitektur einen Modus enthalten, in dem der Hardware-Stapelspeicher abstraktere Semantik aufweist und die Inhalte des freigegebenem Stapelspeichers flüchtig sind. Insbesondere kann diese andere Befehlssatzarchitektur nicht sicherstellen, daß der Wert "V" unverändert am Ort "L" unter Bezugnahme auf den Stapelzeiger im Nachgang zum Abschluß der Prozedur gespeichert ist.
Dementsprechend kann in einer Ausführungsform die Übersetzungseinheit 180 den ersten Binärcode in einen anderen Binärcode übersetzen, wobei mindestens eine der Prozeduren in den Programmcode eingebunden ist, der die Prozedur aufrief. Wenn z. B. die Hauptprozedur "main()" einen Aufruf einer Prozedur "first_procedure(x, y)" enthielte, wobei fünf Codezeilen in "first_procedure(x, y)" enthalten sind, kann die Übersetzungseinheit 180 den Binärcode derart modifizieren, daß der Prozeduraufruf beseitigt wird und die fünf Codezeilen direkt in "main()" enthalten sind. Dementsprechend werden in Parameter x und y nicht auf dem Stapelspeicher platziert. Da jedoch dieser andere Binärcode auf der zweiten Befehlssatzarchitektur basiert, wird der Programmcode, was dem Rückverweis des Stapelzeigers im Anschluß an eine Rückkehr von einem Programmaufruf für einen Parameter im Programmaufruf anbelangt, keinen derartigen Rückverweis enthalten. Wie unten detaillierter beschrieben wird, kann die Hardware-Übersetzung durch den Decoder 204, da der Binärcode auf einer Befehlssatzarchitektur basiert, die sicherstellt, daß auf den Wert "V" nicht vom Ort "L" unter Bezugnahme auf den Stapelzeiger im Anschluß an den Abschluß der Prozedur gegriffen wird, auch in Verbindung mit und/oder ohne diese Software-Übersetzung durchgeführt werden.
Unter Bezugnahme auf das Flussdiagramm 300 von 3 wird bei Prozeßblock 310 unabhängig davon, ob Software-Übersetzung beim Prozeßblock 308 durchgeführt wird, in einer Ausführungsform eine Entscheidung hinsichtlich dessen getroffen, ob eine Hardware-Übersetzung zur Durchführung einer Übersetzung des ersten Binärcodes notwendig ist. In einer Ausführungsform bestimmt der Decoder 204, ob eine Hardware-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. Wie oben beschrieben, kann der Decoder 204 über einen von einer Anzahl von unterschiedlichen Wegen bestimmen, ob eine Hardware-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. Die Anzahl von unterschiedlichen Wegen schließt Abrufen eines Registers, wie z. B. eines der Spezialzweck- Register 254 in der Register-Datei 250 (wie in 2 dargestellt) ein, ohne aber darauf beschränkt zu sein.
Bei Prozeßblock 312 wird mindestens ein Befehl vom ersten Binärcode in mindestens einen Befehl, der auf einer zweiten Befehlssatzarchitektur basiert, bei Festlegung übersetzt, daß eine Hardware-Übersetzung zum Übersetzen des ersten Binärcodes notwendig ist. In einer Ausführungsform übersetzt der Decoder 204 mindestens einen Befehl vom ersten Binärcode in mindestens einen Befehl, der auf einer zweiten Befehlssatzarchitektur basiert. Insbesondere kann in einer Ausführungsform der Decoder eine Anzahl von unterschiedlichen Übersetzungen durchführen, die auf unterschiedliche Eigenschaften der zweiten Befehlssatzarchitektur bezogen sind.
Zur Unterstützung der Darstellung nehmen wir an, daß der Prozessor 102 Befehle ausführen kann, die auf sowohl Intel^®IA-32- als auch Intel^®IA-64-Befehlssatzarchitekturen basieren, und daß ein erster Binärcode auf der Grundlage des Intel^®IA-32 erzeugt worden ist, so daß die Gleitkommaoperanden eine Breite von 80 Bits aufweisen. Zusätzlich kann vor oder in Verbindung mit der Ausführung eines bestimmten Binärcodes eines der Spezial-Register 254 eingestellt werden, um anzuzeigen, daß Gleitkommaoperanden, die gegenwärtig 80-Bit-Operanden sind, die auf der Intel^®IA-32-Befehlssatzarchitektur basieren, in 64-Bit-Operanden, die auf der Intel^®IA-64-Befehlssatzarchitektur basieren, umzuwandeln sind. Somit übersetzt der Decoder 204 bei Abfrage dieses speziellen Registers Gleitkommabefehle, die auf der Intel^®IA-32-Befehlssatzarchitektur basieren, in einen anderen Satz von Gleitkommabefehlen, die auf der Intel^®IA-64-Befehlssatzarchitektur basieren.
Zum Beispiel beim Empfang eines Gleitkommamultiplikationsbefehls erzeugt der Decoder 204 die Mikrooperationen für die Intel^®IA-64-Befehlssatzarchitektur (anstelle der Mikrooperationen für die Intel^®IA-32-Befehlssatzarchitektur), wodurch die zugehörige Gleitkommaeinheit (unter den Funktionseinheiten 212–218) zum Modifizieren der 80-Bit-Operanden in 64-Bit-Operanden und zum Ausführen des Gleitkommamultiplikationsbefehls als der zugehörige Befehl für die Intel^®IA-64-Befehlssatzarchitektur angewiesen wird. Somit wird die Genauigkeit der Gleitkommaoperanden vermindert werden; jedoch können die auf der neuen Befehlssatzarchitektur basierenden Gleitkommabefehle die Leistung bei der Ausführung der Anwendung erhöhen.
Ein weiteres Beispiel für Hardware-Übersetzung durch den Decoder 204 enthält auf den Programm-Stapelspeicher bezogene Optimierungen. Wie oben beschrieben, kann insbesondere eine bestimmte Befehlssatzarchitektur, wie z. B. die Intel^®IA-32-Befehlssatzarchitektur, einen Hardware-Stapelspeicher mit Push- und Pop-Operationen enthalten, worin in eine Prozedur eines Programms geleitete Daten auf dem Stapelspeicher durch eine Push-Operation plaziert und vom Stapelspeicher durch eine Pop-Operation nach Abschluß der Prozedur entfernt werden. Außerdem können derartige Befehlssatzarchitekturen einen direkten Zugriff auf den Stapelzeiger (der typischerweise in einem der Spezialzweck-Register 254 gespeichert ist) ermöglichen. Da diese Befehlssatzarchitektur einen expliziten Zugriff auf den Stapelzeiger ermöglicht, können somit Binärcodes bzw. Anwendungen unkonventionelle Zugriffe auf diesen Hardware-Stapelspeicher vornehmen.
Zum Beispiel tritt das Programm in eine Prozedur und speichert es einen Wert "V" an irgendeinem Ort "L" im Stapelspeicher unter Verwendung irgendeines konstanten Versatzes vom Stapelzeiger. Danach kehrt das Programm aus der Prozedur zurück. In bestimmten Befehlssatzarchitekturen wird jedoch der Wert "V" nicht explizit aus dem Stapelspeicher gelöscht. Ferner stellen derartige Befehlssatzarchitekturen sicher, daß das Programm weiterhin auf den Wert "V" aus dem Stapelspeicher basierend auf dem Ort "L" unter Bezugnahme auf den Stapelzeiger zugreifen kann (unter der Annahme, daß dieser Ort nicht von anderen Teilen des Programms überschrieben worden ist). Umgekehrt kann eine andere Befehlssatzarchitektur einen Modus enthalten, in dem der Hardware-Stapelspeicher abstraktere Semantik aufweist und die Inhalte des freigegebenen Stapelspeichers flüchtig sind. Insbesondere kann diese andere Befehlssatzarchitektur nicht sicherstellen, daß der Wert "V" weiterhin am Ort "L" unter Bezugnahme auf den Stapelzeiger im Anschluß an den Abschluß der Prozedur gespeichert ist.
Somit kann in einer Ausführungsform eines der Spezialzweck-Register 254 als Teil des Hardware-Stapelspeichers zusätzlich zum Stapelspeicher im Speicher, wie z. B. Speicher 132 extern vom Prozessor 102 benutzt werden. Dementsprechend reduziert dies die Anzahl von Lade- und Speicheroperationen durch mit dem Hardware-Stapelspeicher verbundene Funktionseinheiten 212–218. Insbesondere stellt 4 Quellcode und den erzeugten Assembler-Code, wobei ein Register als Teil des Hardware-Speicherstapels genutzt wird und nicht benutzt wird, gemäß Ausführungsformen der vorliegenden Erfindung dar. Wie gezeigt, enthält 4 Quellcode 402, Assembler-Code 404 und Assembler-Code 406. Der Assembler-Code 404 enthält Teile der für den Quellcode 402 erzeugten Assembler-Code-Befehle, wenn ein Register im Prozessor 102 nicht als Teil des Hardware-Speicherstapels benutzt wird. Der Assembler-Code 406 enthält Teile der für den Quellcode 402 erzeugten Assembler-Code-Befehle, wenn ein Register im Prozessor 102 als Teil des Hardware-Stapelspeichers benutzt wird.
Der Quellcode 402 enthält eine Prozedur mit Parametern "x" und "y", worin ein Befehl in der Prozedur eine Variable "z" gleich der Addition von "x" und "y" setzt. Der Assembler-Code 404 enthält eine Lade-Operation zum Speichern des Werts von "x" in Register "r1 "; eine Lade-Operation zum Speichern des Werts von "y" in Register "r2"; und eine Addier-Operation von Register "r1" und Register "r2". Wie dargestellt, sind zwei verschiedene Lade-Operationen notwendig, um die Werte von "x" und "y" (, die auf dem Stapelspeicher im externen Speicher gespeichert sind) in Register im Prozessor 102 zu bringen. Im Gegensatz dazu enthält der Assembler-Code 406 (, worin ein Spezial-Register im Prozessor 102 als Teil des Hardware-Stapelspeichers benutzt wird) eine einzige Lade-Operation, der sich eine Addier-Operation anschließt. Insbesondere enthält der Assembler-Code 406 eine Lade-Operation zum Speichern des Werts von "y" in Register "r2" und eine Addier-Operation von Spezial-Register "sr1" und Register "r2" (, worin Spezial-Register "sr1" Teil des Hardware-Stapelspeichers ist).
Wie gezeigt, kann mindestens ein Spezialzweck-Register in den Spezialzweck-Registern 254 als Teil des Programm-Stapelspeichers benutzt werden, wenn die Programmumgebung, wie z. B. der Benutzer, andeutet, daß Zugriffe auf Variablen auf dem Programm-Stapelspeicher nicht im Anschluß an die Pop-Operationen für diese Variablen durchgeführt werden (selbst wenn die erste Befehlssatzarchitektur, auf der der erste Binärcode erzeugt wurde, derartige Zugriffe ermöglicht). Dementsprechend kann der Decoder 204 die zugehörigen Mikrooperationen für den Assembler-Code 406 (anstelle der zugehörigen Mikrooperationen für den Assembler-Code 404) erzeugen, wenn ein besonderes Befehlssatzarchitekturausführungs-Flag gesetzt ist, das anzeigt, daß das Programm oder die Anwendung, das/die ausgeführt wird, nicht versuchen wird, auf Datenparameter auf dem Stapelspeicher im Anschluß an den Abschluß der Prozedur mit diesen Datenparametern zuzugreifen.
Ein weiteres Beispiel für Hardware-Übersetzung durch Komponenten des Prozessors 102 betrifft einen Zugriff auf den Speicher in der falschen Reihenfolge. Insbesondere kann ein Programm, das auf einer ersten Befehlssatzarchitektur basiert, einen Zugriff auf einen Speicher (sowohl im als auch außerhalb des Prozessors 102) in der richtigen Reihenfolge garantieren. Somit müssen Speicherzugriffe während der Ausführung dieses Binärcodes serialisiert werden, um die Kompatibilität des Binärcodes mit der ersten Befehlssatzarchitektur zu garantieren. Diese Serialisierung kann die Ausführungsleistung des Binärcodes reduzieren. Wenn z. B. ein erster Befehl eine Lade-Operation von einer noch nicht bekannten Adresse abschließen muß, während ein zweiter Befehl (der nach dem ersten Befehl in der seriellen Ausführung des Binärcodes auszuführen ist) auch eine Speicher-Operation bzgl. einer Adresse abschließen muß, die bereits bekannt ist, muß der erste Befehl unverändert vor Abschluß des zweiten Befehls abgeschlossen werden, selbst wenn die Speicher-Operation des zweiten Befehls während des Wartens auf die für die Lade-Operation des ersten Befehls notwendige Adresse abgeschlossen worden sein könnte. Eine derartige Serialisierung ist entscheidend, um die korrekte Ausführung von Mehrprozess- oder Mehrprozessor-Systemen zu garantieren.
Im Gegensatz dazu kann eine zweite Befehlssatzarchitektur Zugriffe auf einen Speicher in falscher Reihenfolge sowie Wege ermöglichen, um derartige Zugriffe zu ordnen, nachdem die Zugriffe abgeschlossen worden sind. Wenn die Programmumgebung, wie z. B. der Benutzer, sicherstellen kann, daß der Binärcode, der auf der ersten Befehlssatzarchitektur basiert, keine Serialisierung der Befehlsausführung erfordert, kann dementsprechend die Programm umgebung das zugehörige Befehlssatzarchitekturaufführungs-Flag setzen, um Zugriffe auf den Speicher in falscher Reihenfolge zu ermöglichen, wodurch mögliche Erhöhungen der Leistungswirkung des Binärcodes gestattet werden. Wenn z. B. der Binärcode ein Programm mit einem einzigen Thread ohne Synchronisierung mit anderen gleichzeitigen Prozessen oder Geräten ist, kann der Binärcode dann in einem Modus, der Zugriffe auf den Speicher in falscher Reihenfolge ermöglicht, sicher ausgeführt werden.
Somit kann in einer Ausführungsform bei Festlegung, daß Zugriffe auf den Speicher in falscher Reihenfolge möglich sind (für einen Binärcode, der auf einer Befehlssatzarchitektur basiert, die nicht für derartige Zugriffe sorgt) der Decoder 204 die Speicherschnittstelleneinheit 72 anweisen, Zugriffe auf den Speicher für diesen Binärcode in falscher Reihenfolge bezüglich der Reihenfolge der Befehle im Binärcode zu planen.
In einer Ausführungsform betrifft ein Beispiel für Hardware-Übersetzung durch Komponenten des Computersystems 100 einen selbstmodifizierenden Code. Insbesondere enthält der selbstmodifizierende Code einen Code, der auf Speicherorte schreibt, wo sich der Code selbst befindet. Eine Anzahl von Befehlssatzarchitekturen gestattet die Ausführung eines derartigen Codes. Doch ist ein derartiger Code ineffizient und senkt er die Leistung bei der Ausführung des Codes. Insbesondere müssen Speichercontroller und/oder andere Komponenten die Orte verfolgen, wo der Speicher beschrieben wird, um festzulegen, ob der Code selbst modifizierend ist. Mit anderen Worten legen diese Speichercontroller und/oder anderen Komponenten fest, ob, für jedes Schreiben in den Speicher, der Ort im Speicher, der von dem Code beschrieben wird, den Code selbst enthält.
Im Gegensatz dazu kann eine zweite Befehlssatzarchitektur in einem Modus arbeiten, in dem ein selbstmodifizierender Code nicht zulässig ist. Wenn die Programmumgebung, wie z. B. der Benutzer, sicherstellen kann, daß der Binärcode, der auf der ersten Befehlssatzarchitektur basiert, keinen selbstmodifizierenden Code enthält, kann dementsprechend die Programmumgebung das zugehörige Befehlssatzarchitekturausführungs-Flag setzen, um die Überprüfung auszuschalten, ob ein bestimmter Programmcode selbstmodifizierend ist.
Somit kann in einer Ausführungsform bei Festlegung, daß der Programmcode, auf dem der Binärcode basiert, nicht selbstmodifizierend ist, der Decoder 204 die zu dem Speicher, der den Binärcode speichert, gehörigen Speichercontroller anweisen, nicht zu überprüfen, ob der bestimmte Programmcode selbstmodifizierend ist. Jedes Mal, wenn eine Speicherschreib-Operation durchgeführt wird, würden dementsprechend genannte Speichercontroller nicht überprüfen, um zu sehen, ob der Ort, an dem in den Speicher geschrieben wird, sich innerhalb der Orte befindet, worin sich der Programmcode befindet, wodurch die Geschwindigkeit der Ausführung des Binärcodes erhöht wird.
In einer Ausführungsform betrifft die Hardware-Übersetzung durch Komponenten des Computersystems 100 die Speichersegmentierung. Insbesondere wird die Speichersegmentierung zur Erweiterung des zugänglichen Adressraumes eines Programmcodes verwendet. Z. B. kann eine bestimmte Architektur Beschränkungen hinsichtlich der Größe der Breiten der Register aufgewiesen haben, wodurch die Größe des Adressraumes begrenzt wird. Dementsprechend kann ein bestimmter Programmcode/Binärcode auf Daten zugreifen, die über eine Anzahl von unterschiedlichen Segmenten im Speicher gespeichert werden. In einer Ausführungsform wird ein Wert, der in einem der Spezialzweck-Register 254 gespeichert wird, als ein Offset zur Konvertierung vom virtuellen zum physikalischen Adressraum benutzt. In einer Ausführungsform wird dieser Wert zur virtuellen Adresse addiert, um die physikalische Adresse zu erzeugen. Wenn der Binärcode auf Daten über eine Anzahl von Segmenten im Speicher zugreift, wird somit dieser Wert während der Programmausführung aktualisiert, wenn das Segment, aus dem auf Daten zugegriffen wird, geändert wird. Im Gegensatz dazu definieren neuere Architekturen größere Registerbreiten, wie z. B. 32 Bit oder 64 Bit, wodurch Betriebssystemen ermöglicht wird, auf derartigen Architekturen auszuführen, um Programme mit einem ausreichend größeren virtuellen Adressraum, ohne auf Segmentierung angewiesen zu sein, anzubieten.
In einer Ausführungsform basiert der erste Binärcode auf einer ersten Befehlssatzarchitektur, worin die Daten, auf die vom ersten Binärcode zugegriffen wird, in einer Anzahl von Segmenten im Speicher gespeichert werden. Zusätzlich enthält in einer Ausführungsform eine zweite Befehlssatzarchitektur einen virtuellen Adressraum, der größer als der virtuelle Adressraum für die erste Befehlssatzarchitektur ist. Wenn die Programmumgebung, wie z. B. der Benutzer, sicherstellen kann, daß die Daten, auf die vom ersten Binärcode, der auf der ersten Befehlssatzarchitektur basiert, zugegriffen wird, in einem einzigen Segment im Speicher basierend auf der zweiten Befehlssatzarchitektur gespeichert werden können, kann die Programmumgebung das zugehörige Ausführungs-Flag setzen, um Speichersegmentierung auszulassen, wodurch Segmentierung während der Übersetzung von Speicheradressen von virtuell nach physikalisch umgangen wird.
In einer Ausführungsform werden die größeren Breiten von Registern in der Register-Datei 250 verwendet, um den größeren virtuellen Adressraum zu ermöglichen. Zum Beispiel kann die erste Befehlssatzarchitektur 16 Bits von Registern verwenden, die eine Breite von 32 Bits aufweisen und in der Register-Datei 250 gespeichert sind, während die zweite Befehlssatzarchitektur die vollen 32 Bits derartiger Register verwenden kann. In einer Ausführungsform erzeugt der Decoder 204 keine Mikrooperationen zum Aktualisieren dieses Offset-Werts für virtuellen zum physikalischen Adressraum, der in einem der Spezialzweck-Register 250 gespeichert ist, da dieser Wert über den Verlauf der Ausführung des Binärcodes konstant bleibt, (da die Daten, auf die vom Binärcode zugegriffen wird, sich in einem einzigen Segment im Speicher befinden). Dementsprechend wird die Ausführung des Binärcodes erhöht, wenn Speichersegmentierung auf der Grundlage der zweiten Befehlssatzarchitektur ausgelassen wird.
Außerdem wird in einer Ausführungsform ein Binärcode, der auf einer ersten Befehlssatzarchitektur basiert, so erzeugt, daß die Größe der Daten, auf die vom Binärcode zugegriffen wird, in einem einzigen Segment im Speicher gespeichert werden können. Dementsprechend müssen die Breiten der in den Universal-Registern 252 gespeicherten Werte nicht erhöht werden. Nach einer Ausführungsform kann die Programmumgebung ein Befehlssatzarchitekturausführungs-Flag setzen, worin der Binärcode nicht auf der zweiten Befehlsarchitektur bezogen auf die größere Breite in den Registern basiert. In einer derartigen Ausführungsform erzeugt der Decoder 204 keine Mikrooperationen zum Aktualisieren dieses Offset-Werts für virtuellen zu physikalischen Adressraum, der in einem der Spezial-Register 254 gespeichert ist. Insbesondere muß dieser Wert nicht aktualisiert werden, da die Daten, auf die vom Binärcode zugegriffen wird, in einem einzigen Segment im Speicher gespeichert sind.
Zum Flussdiagramm 300 von 3 zurückkehrend, werden bei Prozeßblock 314 die Befehle (, die, wie oben beschrieben, modifiziert worden sein können) ausgeführt. In einer Ausführungsform führen die Funktionseinheiten 212–218 die Befehle aus. Die hierin beschriebenen Software- und Hardware-Übersetzungen dienen als Beispiele und nicht als Beschränkungen, da Ausführungsformen der vorliegenden Erfindung andere Übersetzungen (sowohl Software – als auch Hardware -) eines ersten Binärcodes, der auf einer ersten Befehlssatzarchitektur basiert, in einen zweiten Binärcode enthalten können, der auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert. Während eine bestimmte Übersetzung unter Bezugnahme auf Software oder Hardware beschrieben worden ist, sind ferner Ausführungsformen der vorliegenden Erfindung nicht so beschränkt. Während eine bestimmte Übersetzung in Beziehung mit einer Software-Übersetzung beschrieben worden ist, kann in einer anderen Ausführungsform z. B. eine Übersetzung in Hardware und/oder eine Kombination der Hardware und Software durchgeführt werden.
Außerdem sind auf Software-Übersetzung bezogene Ausführungsformen der vorliegenden Erfindung in Beziehung mit Übersetzungen eines vollständigen Binärcodes beschrieben worden. Jedoch sind Ausführungsformen der vorliegenden Erfindung nicht so beschränkt. In einer Ausführungsform kann ein Programmiermodell komplexere Wechselwirkungen zwischen Binärebenen-Objekten enthalten. Nehmen wir z. B. an, daß eine gemeinsam benutzte Bibliothek von Binärcodes basierend auf einer ersten Befehlssatzarchitektur kompiliert wird und ein Hauptbinärcode, der Binärcodes in der gemeinsam benutzten Bibliothek verwendet/miteinander verbindet, auf einer Kombination der ersten und zweiten Befehlssatzarchitekturen, wie hierin beschrieben, basiert. In einer Ausführungsform kann der Hauptbinärcode in Abhängigkeit von der erforderlichen Funktionalität, Programmumgebung, etc. zwischen den verschiedenen Funktionen der zwei verschiedenen Befehlssatzarchitekturen wechseln. Zum Beispiel können die Binärcodes in der Bibliothek den Kompatibilitätsgrad zwischen der ersten und zweiten Befehlsarchitektur in Abhängigkeit davon, welcher Binärcode in der Bibliothek aufgerufen wird, vom globalen Programmzustand des Hauptbinärcodes etc., dynamisch einstellen.
Obwohl die vorliegende Erfindung unter Bezugnahme auf spezielle beispielhafte Ausführungsformen beschrieben worden ist, wird ersichtlich sein, daß zahlreiche Modifikationen und Änderungen an diesen Ausführungsformen vorgenommen werden können, ohne aus dem breiteren Geist und Schutzbereich der Erfindung zu gelangen. Dementsprechend sollen die Beschreibung und die Zeichnungen in einem erläuternden statt einem einschränkenden Sinne betrachtet werden.
Zusammenfassung
In einer Ausführungsform enthält ein Verfahren Empfangen eines Binärcodes eines Programmcodes. Der Binärcode basiert auf einer ersten Befehlssatzarchitektur. Das Verfahren enthält auch Übersetzen des Binärcodes, wobei der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.

Claims

Verfahren, umfassend: Empfangen eines Binärcodes eines Programmcodes, wobei der Binärcode auf einer ersten Befehlssatzarchitektur basiert; und Übersetzen des Binärcodes, wobei der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.
Verfahren nach Anspruch 1, umfassend Überprüfen von Befehlssatzarchitekturausführungs-Flags, wobei die Befehlssatzarchitekturausführungs-Flags mindestens eine Übersetzung eines Teils des Binärcodes anzeigen.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die Befehlssatzarchitekturausführungs-Flags von einer Programmumgebung des Binärcodes gesetzt werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß ein Register in einem den Binärcode übersetzenden Prozessor zum Speichern der Befehlssatzarchitekturausführungs-Flags dient.
Verfahren nach Anspruch 2, das Ausführen des übersetzten Binärcodes umfaßt.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das Übersetzen und Ausführen auf einem Befehl basieren, wobei die Befehlssatzarchitekturausführungs-Flags auf einer Anzahl von Befehlszeilen-Flags basieren, die mit dem Befehl verbunden sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur Gleitkommabefehle umfaßt und das zweite Befehlssatzarchitektur Gleitkommabefehle umfaßt, wobei das Übersetzen des Binärcodes Übersetzen der Gleitkommabefehle der ersten Befehlssatzarchitektur in Gleitkommabefehle der zweiten Befehlssatzarchitektur umfaßt.
Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß das Übersetzen des Binärcodes Speichern eines Teils eines Hardware-Stapelspeichers in einem Register eines den Binärcode übersetzenden Prozessors umfaßt.
Verfahren, umfassend: Empfangen eines Binärcodes von einem Programmcode, wobei der Binärcode auf einer ersten Befehlssatzarchitektur basiert; und Ausführen des Binärcodes, wobei das Ausführen Übersetzen eines Befehls des Binärcodes, der auf der ersten Befehlssatzarchitektur basiert, in mindestens einen Befehl umfaßt, der auf einer zweiten Befehlssatzarchitektur basiert.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur Zugriffe auf Speicher in richtiger Reihenfolge enthält und die zweite Befehlssatzarchitektur Zugriffe auf Speicher in falscher Reihenfolge enthält, wobei das Übersetzen des Binärcodes Zugriffe auf den Speicher von einem den Binärcode ausführenden Prozessor in falscher Reihenfolge enthält.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur ermöglicht, daß der Binärcode sich selbst modifiziert, und die zweite Befehlssatzarchitektur nicht ermöglicht, daß sich der Binärcode selbst modifiziert, wobei das Übersetzen des Binärcodes einen Befehl an Controller der Speicher, die den Binärcode speichern, zur Durchführung von Schreiboperationen unabhängig von Überprüfungen, ob die Schreiboperationen einen Ort modifizieren, wo der Binärcode gespeichert wird, enthält.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß die zweite Befehlssatzarchitektur einen Adressraum aufweist, der größer als die erste Befehlssatzarchitektur ist, wobei das Übersetzen des Binärcodes die Verwendung des Adressraums der zweiten Befehlssatzarchitektur umfaßt.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, daß die Daten, auf die vom Binärcode zugegriffen wird, in einem einzigen Segment im Speicher gespeichert werden, und daß ein Offset-Wert zum Übersetzen einer virtuellen Adresse in eine physikalische Adresse für die Daten während der Ausführung des Binärcodes nicht modifiziert wird.
System, umfassend: einen Speicher zum Aufnehmen eines Binärcodes eines Programmcodes, der auf einer ersten Befehlssatzarchitektur basiert; und einen mit dem Speicher gekoppelten Prozessor, wobei der Prozessor zum Ausführen des Binärcodes dient, wobei Ausführen des Binärcodes Übersetzen des Binärcodes umfaßt und der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.
System nach Anspruch 14, dadurch gekennzeichnet, daß der Prozessor ein Register zum Speichern von Befehlssatzarchitekturausführungs-Flags umfaßt, wobei die Befehlssatzarchitekturausführungs-Flags mindestens eine Übersetzung eines Teils des Binärcodes anzeigen.
System nach Anspruch 15, dadurch gekennzeichnet, daß die Befehlssatzarchitekturausführungs-Flags von einer Programmumgebung des Binärcodes gesetzt werden.
System nach Anspruch 14, dadurch gekennzeichnet, daß die zweite Befehlssatzarchitektur einen Adressraum aufweist, der größer als die erste Befehlssatzarchitektur ist, wobei das Übersetzen des Binärcodes die Verwendung des Adressraums der zweiten Befehlssatzarchitektur umfaßt.
System nach Anspruch 17, dadurch gekennzeichnet, daß der Binärcode in einem einzigen Segment im Speicher gespeichert wird, und daß ein Offset-Wert zum Übersetzen einer virtuellen Adresse in eine physikalische Adresse während der Ausführung des Binärcodes nicht modifiziert wird.
Vorrichtung, umfassend: einen Decoder zum Empfangen eines Binärcodes, der auf einer ersten Befehlssatzarchitektur basiert; und eine Anzahl von Registern, wobei mindestens eines der Anzahl von Registern zum Speichern von Befehlssatzarchitekturausführungs-Flags dient, ferner die Befehlssatzarchitekturausführungs-Flags zum Anzeigen einer Übersetzung eines Binärcodes dienen und der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.
Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur Gleitkommabefehle umfaßt und daß die zweite Befehlssatzarchitektur Gleitkommabefehle umfaßt, wobei das Übersetzen des Binärcodes Übersetzen der Gleitkommabefehle der ersten Befehlssatzarchitektur in Gleitkommabefehle der zweiten Befehlssatzarchitektur umfaßt.
Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, daß das Übersetzen des Binärcodes Speichern eines Teils eines Hardware-Stapelspeichers in einem Register in der Anzahl von Registern umfaßt.
Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, daß die Vorrichtung mit Speichern zum Speichern des Binärcodes gekoppelt ist, wobei die erste Befehlssatzarchitektur ermöglicht, daß sich der Binärcode selbst modifiziert, und die zweite Befehlssatzarchitektur nicht ermöglicht, daß sich der Binärcode selbst modifiziert, ferner das Übersetzen des Binärcodes einen Befehl an Controller der Speicher zur Durchführung von Schreiboperationen unabhängig von Überprüfungen, ob die Schreiboperationen einen Ort modifizieren, wo der Binärcode gespeichert wird, enthält.
Vorrichtung nach Anspruch 19, dadurch gekennzeichnet, daß die zweite Befehlssatzarchitektur einen Adressraum aufweist, der größer als die erste Befehlssatzarchitektur ist, wobei das Übersetzen des Binärcodes Verwendung des Adressraums der zweiten Befehlssatzarchitektur umfaßt.
Vorrichtung nach Anspruch 23, dadurch gekennzeichnet, daß die Daten, auf die vom Binärcode zugegriffen wird, in einem einzigen Segment im mit der Vorrichtung gekoppelten Speicher gespeichert werden, und daß ein Offset-Wert zum Übersetzen einer virtuellen Adresse in eine physikalische Adresse für die Daten während der Ausführung des Binärcodes nicht modifiziert wird.
Maschinenlesbares Medium, das Befehle liefert, die bei Ausführung von einer Maschine, die Maschine Operationen durchführen lassen, umfassend: Empfangen eines Binärcodes eines Programmcodes, wobei der Binärcode auf einer ersten Befehlssatzarchitektur basiert; Übersetzen des Binärcodes, wobei der übersetzte Binärcode auf einer Kombination der ersten Befehlssatzarchitektur und einer zweiten Befehlssatzarchitektur basiert.
Maschinenlesbares Medium nach Anspruch 25, umfassend die Ausführung des übersetzten Binärcodes.
Maschinenlesbares Medium nach Anspruch 26, dadurch gekennzeichnet, daß das Übersetzen und Ausführen auf einem Befehl basieren, wobei die Befehlssatzarchitekturausführungs-Flags auf einer Anzahl von Befehlszeilen-Flags basieren, die mit dem Befehl verbunden sind.
Maschinenlesbares Medium nach Anspruch 25, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur Gleitkommabefehle umfaßt und daß die zweite Befehlssatzarchitektur Gleitkommabefehle umfaßt, wobei das Übersetzen des Binärcodes Übersetzen der Gleitkommbefehle der ersten Befehlssatzarchitektur in Gleitkommabefehle der zweiten Befehlssatzarchitektur umfaßt.
Maschinenlesbares Medium nach Anspruch 25, dadurch gekennzeichnet, daß die erste Befehlssatzarchitektur ermöglicht, daß sich der Binärcode selbst modifiziert, und die zweite Befehlssatzarchitektur nicht ermöglicht, daß sich der Binärcode selbst modifiziert, wobei das Übersetzen des Binärcodes einen Befehl an Controller von Speichern, die den Binärcode speichern, zum Durchführen von Schreiboperationen unabhängig von der Überprüfung, ob die Schreiboperationen einen Ort modifizieren, wo der Binärcode gespeichert wird, enthält.