-
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.