DE19983632B4

DE19983632B4 - Emulation eines Befehlssatzes bei einem Befehlssatzarchitekturübergang

Info

Publication number: DE19983632B4
Application number: DE19983632T
Authority: DE
Inventors: Carole Saratoga Dulong; John H. Saratoga Crawford
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1998-10-12
Filing date: 1999-10-06
Publication date: 2007-02-22
Anticipated expiration: 2019-10-07
Also published as: WO2000022524A1; GB2357876A; KR100401799B1; GB2357876B; AU1104000A; DE19983632T1; WO2000022524A9; CN1328666A; KR20010080104A; US6163764A; GB0107747D0; CN1126034C

Abstract

Verfahren zum Emulieren der Ausführung eines Befehls einer erster Befehlssatzarchitektur auf einem Prozessor, der eine von der ersten Befehlssatzarchitektur abweichende, zweite Befehlssatzarchitektur aufweist, wobei sich die Befehlssatzarchitekturen darin unterscheiden, daß für die Operanden des Befehls verschiedene Datenformate in Prozessorregistern verwendet werden, wobei:
der Befehlscode des Befehls und wenigstens ein Operand in einem ersten Datenformat, das der ersten Befehlssatzarchitektur entspricht, von dem Prozessor empfangen werden,
der wenigstens eine Operand aus dem ersten Datenformat in ein abweichendes, zweites Datenformat, das der zweiten Befehlssatzarchitektur entspricht, konvertiert und in wenigstens einem Register des Prozessors gespeichert wird,
der Befehl von dem Prozessor ausgeführt wird, indem die von dem Befehlscode codierte Operation an dem wenigstens einen Operanden in dem zweiten Datenformat ausgeführt wird, wobei ein Ergebnis in dem zweiten Datenformat erzeugt und in einem Prozessorregister gespeichert wird, und
das Ergebnis aus dem zweiten Datenformat in das erste Datenformat konvertiert wird.

Description

Die Erfindung betrifft ein Verfahren zum Emulieren der Ausführung eines Befehls einer ersten Befehlssatzarchitektur auf einem Prozessor, der eine von der ersten Befehlssatzarchitektur abweichende, zweite Befehlssatzarchitektur aufweist, wobei sich die Befehlssatzarchitekturen darin unterscheiden, daß für die Operanden des Befehls verschiedene Datenformate in Prozessorregistern verwendet werden.
Wenn ein Prozessor derart verbessert wird, daß er erweiterte Fähigkeiten aufweist, ist es wichtig, die Softwarekompatibilität mit den bei dem vorhergehenden Modell entwickelten Anwendungen aufrechtzuerhalten. Ein spezielles Problem ist die Darstellung von Daten für logische und/oder arithmetische Operationen.
Beispielsweise weist das Gleitkomma(FP)-Zahlenformat Datenformate einfacher Genauigkeit (SP; Single Precision) und doppelter Genauigkeit (DP; Double Precision) auf. Während das SP-Format typischerweise durch eine 32-Bit-Darstellung dargestellt wird, kann das DP-Format zwei verschiedene Arten der Darstellung aufweisen: ein reguläres 64-Bit-Format und ein erweitertes 82-Bit-Format. Ein regulärer Prozessor verwendet typischerweise das reguläre 64-Bit-FPDP-Format für sowohl in seinen Registern als auch im Speicher gespeicherte Operanden. Ein erweiterter Prozessor benutzt typischerweise das erweiterte 82-Bit-FPDP-Format für die in seinen Registern gespeicherten Operanden und das reguläre 64-Bit-FPDP-Format für im Speicher gespeicherte Operanden. Beispielsweise umfassen die Intel-Architektur(IA)-Prozessoren ein 32-Bit-Modell und ein erweitertes 64-Bit-Modell: den IA-32-Prozessor und den IA-64-Prozessor. Der IA-32-Prozessor verwendet das 64-Bit-FPDP-Format sowohl für in den Registern als auch im Speicher gespeicherte Operanden. Der IA-64-Prozessor verwendet das 64-Bit- FPDP-Format für Speicheroperanden und das erweiterte 82-Bit-FPDP-Format für Registeroperanden.
Der Übergang von einem Befehlssatz, der mit einem regulären Datenformat arbeitet, zu einem anderen Befehlssatz, der mit einem erweiterten Datenformat arbeitet, wird als Befehlssatzarchitektur(ISA)-Übergang bezeichnet. Bei einem solchen ISA-Übergang, bei dem ein unter Verwendung eines regulären Betriebsmodus (z. B. 64-Bit-FPDP) geschriebenes Anwendungsprogramm zu einem Prozessor transportiert wird, der einen erweiterten Betriebsmodus (z. B. 82-Bit-FPDP) verwendet, oder umgekehrt, können Operanden-Nicht-Übereinstimmungen auftreten. Derartige Nicht-Übereinstimmungen verursachen eine Leistungsverschlechterung und können in vielen Fällen eine Softwareinkompatibilität verursachen.
Folglich gibt es ein technologisches Erfordernis, ein Verfahren zum Emulieren eines Befehlssatzes für ein Datenformat auf einem Prozessor, der in einem erweiterten Datenformat betrieben wird, zur Verfügung zu stellen.

Aus der "Technical Note HW23 – FPU Operations on Macintosh Quadra Computers", Apple Computer, Inc.; 1. Juni 1989, S. 1–12, ist die Emulation eines Befehls eines MC68881/2 durch die Befehlssatzarchitektur eines 68040 bekannt, wobei für die Operanden eines Befehls verschiedene Datenformate verwendet werden. Ferner beschreiben Robert F. Cmelik und David Keppel in "Shade: A Fast Instruction-Set Simulator for Execution Profiling", Technical Report UWCSE 39-06-06, University of Washington, S. 1–41, 1993, ein Programm mit dem Namen "Shade", bei welchem es sich um einen Befehlssatzsimulator und Trace-Generator handelt. Bei dem Programm werden Teile eines zu testenden Anwendungsprogramms, welches (später) auf einer Zielmaschine laufen soll, d.h. Anwendungsprogrammcodefragmente, in spezielle Codefragmente einer Host-Maschine kompiliert, welche Übersetzungen (Translations) genannt werden. Die Übersetzungen bestehen aus einem Prolog, einem Körper und einem Epilog. Der aus den Anwendungsprogrammcodeabschnitten erzeugte Körper der Übersetzungen enthält Befehlscode zum Simulieren der Anwendungsprogrammbefehle sowie ggf. Befehlscode zum Verfolgen (trace) der Anwendungsprogrammbefehle. Das Programm Shade dient dazu, Befehle der für eine Ziel-Maschine geschriebenen Anwendung derart zu simulieren, daß verschiedene Zustände innerhalb des simulierten Prozessors erfaßt und verfolgt werden können.

Aufgabe der Erfindung ist es, ein Verfahren zu schaffen, daß einen Befehlssatz mit einem ersten Datenformat auf einem Prozessor emulieren kann, der mit einem zweiten, erweiterten Datenformat arbeitet.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte und/oder bevorzugte Weiterbildungen des erfindungsgemäßen Verfahrens sind in den Ansprüchen 2 bis 6 gekennzeichnet.

Die Merkmale und Vorteile der vorliegenden Erfindung werden aus der folgenden detaillierten Beschreibung der vorliegenden Erfindung klar, in welcher:
1 eine Darstellung ist, die ein Computersystem veranschaulicht, in welchem ein Ausführungsbeispiel der Erfindung ausgeführt werden kann.
3 ist eine Darstellung, die eine Formatkonvertierung gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
4 ist eine Darstellung, die einen Modusübergang gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
5 ist eine Darstellung, die eine Kontextumschaltung gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
6 ist eine Darstellung, die eine Zahlenformatkonvertierung gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
7 ist eine Darstellung, die einen Prozeß zum Emulieren logischer Befehle gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
8 ist eine Darstellung, die eine Aufrufoperation gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
9 ist ein Ablaufdiagramm, das einen Prozeß für eine Objektcodeübersetzung (OCT) gemäß einem Ausführungsbeispiel der Erfindung veranschaulicht.
BESCHREIBUNG
Die Erfindung ist ein Verfahren und eine Einrichtung zum Emulieren von Befehlen, die in einer Datenformatdarstellung auf einem Prozessor, der eine andere Datenformatdarstellung aufweist, arbeiten. Diese Technik umfaßt eine Reihe von Ausführungsbeispielen. Verschiedene Schemata zum Konvertieren der Datendarstellungen werden angegeben. Es wird ein Code-Patching mit einem Sprungbefehl zum Springen zum richtigen Code bei Modusübergängen oder Kontextumschaltungen verwendet. Konvertierungsbefehle konvertieren die Datendarstellungen für arithmetische und logische Befehle zwischen ganzen Zahlen und Gleitkommazahlen. Die Erfindung schafft eine Softwarekompatibilität zwischen einer Prozessorarchitektur und einer erweiterten Prozessorarchitektur.
In der folgenden Beschreibung werden aus Gründen der Erläuterung zahlreiche Details angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu erreichen. Für einen Fachmann ist es jedoch klar, daß diese speziellen Details nicht erforderlich sind, um die vorliegende Erfindung auszuführen. An anderen Stellen werden gut bekannte elektrische Strukturen und Schaltungen in Blockdarstellungsform gezeigt, um die Erfindung nicht zu verdecken.
1 ist eine Darstellung, die ein Computersystem veranschaulicht, in welchem ein Ausführungsbeispiel der Erfindung ausgeführt werden kann. Das Computersystem 100 enthält einen Prozessor 110, einen Host-Bus 120, eine Speichersteuereinrichtung 130 und eine Speichereinrichtung 150.
Der Prozessor 110 repräsentiert eine zentrale Verarbeitungseinheit einer beliebigen Architektur, wie beispielsweise eine Architektur eines Computers mit komplexen Befehlssatz (CISC), eines Computers mit reduzierten Befehlssatz (RISC), eines sehr langen Befehlsworts (VLIW) oder eine Hybridarchitektur. Während dieses Ausführungsbeispiel unter Bezugnahme auf ein Einzelprozessorcomputersystem beschrieben wird, könnte die Erfindung auch in einem Mehrprozessorcomputersystem implementiert werden.
Die Speichersteuereinrichtung 140 stellt verschiedene Zugriffsfunktionen auf die Speichereinrichtung 150 zur Verfügung. Die Speichersteuereinrichtung 140 ist mit dem Host-Bus 130 gekoppelt, um es dem Prozessor zu ermöglichen, auf die Speichereinrichtung 150 zuzugreifen. Die Speichereinrichtung 150 repräsentiert einen oder mehrere Mechanismen zum Speichern von Informationen. Beispielsweise kann die Speichereinrichtung 150 nicht-flüchtige oder flüchtige Speicher umfassen. Beispiele dieser Speicher schließen Flash-Speicher, Nur-Lese-Speicher (ROM) oder Speicher mit wahlfreiem Zugriff (RAM) ein.
1 veranschaulicht darüber hinaus, daß in der Speichereinrichtung 150 Programmcode 152 und Daten 154 gespeichert sind. Der Programmcode 152 repräsentiert den erforderlichen Code zum Durchführen einiger und/oder sämtlicher der Techniken bei der vorliegenden Erfindung. Insbesondere umfaßt der Programmcode 152 einen Emulationscode 153. Der Emulationscode 153 emuliert Befehle in einem Datenformat (oder Modus) auf dem Prozessor 110. Die Daten 154 speichern von dem Programmcode 152 verwendete Daten, Graphikdaten und temporäre Daten. Insbesondere enthält der Datenspeicher 154 ein Datensegment 155, welches in einem Format 1, das als Speicherformat oder reguläres Format bezeichnet wird, dargestellte Daten enthält. Selbstverständlich enthält die Speichereinrichtung 150 vorzugsweise zusätzliche (nicht gezeigte) Software, welche für das Verständnis der Erfindung nicht erforderlich ist.
1 veranschaulicht zusätzlich, daß der Prozessor 110 eine Decodiereinheit 112, eine Ausführungseinheit 114, einen Registersatz 116 und einen internen Bus 111 enthält. Selbstverständlich enthält der Prozessor 110 zusätzliche Schaltungen, welche für das Verständnis der Erfindung nicht erforderlich sind. Die Decodiereinheit 112 wird zum Decodieren von durch den Prozessor 110 empfangenen Befehlen in Steuersignale und/oder Mikrocodeeintrittspunkte verwendet. In Erwiderung dieser Steuersignale und/oder Mikrocodeeintrittspunkte führt die Ausführungseinheit 114 die richtigen Operationen durch. Der Registersatz 116 enthält eine Reihe von Registern, die in einem Format 2, das als das Registerformat bezeichnet wird, dargestellte Daten speichern.
Bei einem Ausführungsbeispiel ist der Prozessor 110 ein Intel-Architektur-64(IA-64-)Prozessor. Der IA-64 ist ein 64-Bit-Prozessor, der 64-Bit-Daten verarbeitet. Bei dem IA-64 werden 64-Bit-Gleitkommazahlen doppelter Genauigkeit (FPDP) als 82-Bit-FPDP in dem Registersatz 116 (erweitertes oder Registerformat) dargestellt, aber als 64-Bit-FPDP in dem Speicher 155 (reguläres oder Speicherformat). Ein 32-Bit-Prozessor (z. B. IA-32) stellt 64-Bit-FPDP-Zahlen sowohl in seinen Registern als auch im Speicher als 64-Bit-FPDP dar, was als reguläres Format bezeichnet wird. Um die Softwarekompatibilität aufrechtzuerhalten, wenn für einen 32-Bit-Prozessor (z. B. IA-32) entwickelte Programme auf einen 64-Bit-Prozessor (z. B. IA-64) portiert werden, ist irgendeine Übersetzung oder Konvertierung erforderlich. Die Technik bei der vorliegenden Erfindung kann verwendet werden, um die 32-Bit-Befehle auf dem 64-Bit-Prozessor zu emulieren. In der folgenden Diskussion wird der Prozessor 110 als Plattformprozessor bezeichnet und die Programme oder die Software, die unter Verwendung des 32-Bit-Befehlssatzes geschrieben worden ist, wird als portierende Software oder portierende Programme bezeichnet.
Die Emulation kann auf verschiedene Weise implementiert werden. Ein Weg umfaßt eine geringfügige Hardwaremodifikation auf dem Plattformprozessor. Andere Wege umfassen Konvertierungen der Datenformate durch Einfügen (Patching) von Befehlscode in die Portierungsprogramme.
Das Computerprogramm oder die Computersoftware, die die bei der vorliegenden Erfindung beschriebenen Techniken implementieren, können in einem maschinenlesbaren Medium gespeichert und/oder übermittelt werden. Beispiele derartiger maschinenlesbarer Medien umfassen Halbleiterspeicher, wie beispielsweise Speicher mit wahlfreiem Zugriff (RAM), Nur-Lese-Speicher (ROM), löschbare ROM (EROM), Flash-Speicher, magnetische Medien, Compakt-Disc-Nur-Lese-Speicher (CDROM), Disketten, Festplatten, optische Platten, Signale, Trägerwellen, etc. Das Computerprogramm oder die Codesequenz emuliert den Befehl, welcher an wenigstens einem Operanden in einem ersten Datenformat arbeitet, während der Prozessor in einem zweiten Datenformat betrieben wird. Das Computerprogramm oder die Codesequenz enthält eine Anzahl von Codesegmenten, Unterprogrammen, Subroutinen oder Funktionen zum Durchführen einer Anzahl von Operationen. Beispiele dieser Operationen umfassen die Konvertierung des Operanden aus dem ersten Datenformat in das zweite Datenformat, das Ausführen des Befehls durch den Prozessor in dem zweiten Datenformat, um ein Ergebnis in dem zweiten Datenformat zu erzeugen, das Konvertieren des Ergebnisses aus dem zweiten Datenformat in das erste Datenformat. Zusätzliche Codesegmente werden verwendet, um weitere Funktionen auszuführen, wie es im folgenden detaillierter erörtert wird.
3 ist eine Darstellung, die eine Formatkonvertierung in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht. Das Formatkonvertierungsverfahren konvertiert das 64-Bit-Format in das 82-Bit-Format vor sämtlichen Operationen und das 82-Bit-Format in das 64-Bit-Format nach sämtlichen Operationen. Die Formatkonvertierung umfaßt einen Format-1-Konvertierer 320, einen Format-2-Konvertierer 360 und eine Operation 340.
3 zeigt Operanden 310, 330, 350 und 370. Die Operanden 310 und 370 sind im Format 1 (z. B. 64-Bit) und die Operanden 330 und 350 sind im Format 2 (z. B. 82-Bit). Der Format-1-Konvertierer konvertiert die Operanden 310 aus dem Format 1 in die Operanden 330 in Format 2 vor der Operation. Die Operation 340 wird unter Verwendung des Formats 2 durchgeführt. Nach der Operation werden die Operanden 350 von dem Format-2-Konvertierer 360 zurück in die Operanden 370 in dem Format 1 konvertiert.
4 ist eine Darstellung, die einen Modusübergang in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht. Ein Modusübergang (z. B. ISA(instruction set architecture)-Übergang) tritt auf, wenn eine in einem ersten Modus (z. B. IA32) ablaufende Anwendung eine Anwendung in einem zweiten Modus (z. B. IA64) aufruft.
Ein Modusübergang umfaßt eine Modus1-Anwendung 410, eine Modus1-Domäne 420, eine Modus2-Domäne 430 und eine Modus2-Anwendung 440. Die Modus1-Anwendung 410 ruft zu der Modus2-Anwendung 440 auf. Die Modus2-Anwendung 440 hat keine Kenntnis über das Modus1-Format (z. B. das Registerformat). Die Modus1-Domäne 420 stellt einen Sprung zu dem Modus2 durch einen Sprungbefehl (z. B. JUMPE) zur Verfügung. Die Modus2-Domäne 430 stellt die Modus2-Konvertierung von Parametern zur Verfügung. Dann findet die Operation in der Modus2-Anwendung 440 statt.
Bei einem Modusübergang aus der Modus2-Anwendung 440 in die Modus1-Anwendung 410 stellt ein Verzweigungsbefehl (z. B. BR_IA) einen Ausgang aus der Modus2-Anwendung 440 in die Modus1-Anwendung 410 zur Verfügung.
In der Modus1-Anwendung 410 können die Daten doppelter Genauigkeit in den Registern im Speicher- oder regulären Format dargestellt werden. In der Modus1-Domäne 420 werden sämtliche Register in der Modus1-Anwendung 410 im Speicher gesichert. Die Modus2-Domäne 430 lädt die Parameter aus dem Speicher mit dem der Verwendung entsprechenden Format. In der Modus2-Anwendung 440 werden die Daten doppelter Genauigkeit in das erweiterte Format in den Registern konvertiert. Nach der Operation in der Modus2-Anwendung leitet der Verzweigungsbefehl die Ergebnisparameter im Speicher zu der Modus1-Anwendung 410 weiter.
5 ist eine Darstellung, die eine Kontextumschaltung 500 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht. Die Kontextumschaltung 500 tritt infolge eines Interrupts auf und umfaßt eine Modus1-Anwendung 410 und ein Modus2-Betriebssystem 520. Wie es einem Fachmann bekannt ist, sind weitere Ursachen für die Kontextumschaltung möglich, wie beispielsweise eine Prozeßauslagerung (process swapping), ein Multitasking, etc.
Die Modus1-Anwendung ist eine Anwendung, die im Modus1-Befehlssatz (z. B. IA32) abläuft. Die Modus1-Anwendung 410 umfaßt einen Aufrufcode 512 und einen Rückkehrcode 514. Das Modus2-Betriebssystem (OS) 520 ist ein Betriebssystem, das im Modus2-Befehlssatz (z. B. IA64) abläuft. Das Modus2-OS 520 enthält einen Patch-Code 522, einen Sicherungscode 524, einen Modus2-Code 525, einen Wiederherstellungscode 526 und einen Rückkehrcode 528.
Bei der in 5 veranschaulichten Kontextumschaltung 500 empfängt die Modus1-Anwendung 410 ein Interrupt. Die Register in der Modus1-Anwendung 410 sind in dem Speicherformat und dem erweiterten Format. Der Aufrufcode 512 ruft zu dem Modus2-OS 520 auf. Wenn die Steuerung zu dem Modus2-OS 520 weitergeleitet wird, führt der Patch-Code 522 einen Übergang durch, um aus dem Emulationsmodus in den ursprünglichen Modus zu gehen, indem ein Patching-Befehl, wie beispielsweise ein JUMPE-Befehl ausgeführt wird. Sämtliche Register werden bei dem Patching-Befehl in das Speicherformat konvertiert. Der Sicherungscode 524 sichert sämtliche Modus1-Register als Bits mit einem Bit-Speichere-Befehl. Ein Bit-Speichere-Befehl (z. B. STF.SPILL) speichert den Inhalt der Register ohne Konvertierung. Beispielsweise werden die IA32-FP-Register in dem Speicher als 16-Bytes ohne Konvertierung gespeichert.
Dann fährt der Modus2-Code 525 mit der Ausführung des Modus2-Befehlssatzes (z. B. IA64) fort, um das Interrupt oder weitere Aufgaben in der geeigneten Weise zu bedienen. Nachdem der Modus2-Code 525 seine Ausführung abgeschlossen hat, stellt der Wiederherstellungscode 526 die gesicherten Modus1-Register als Bits mit einem Bit-Rückspeicherungsbefehl wieder her. Ein Bit-Rückspeicherungsbefehl (z. B. LDF.FILL) stellt die durch den Bit-Speichere-Befehl in den Speicher gespeicherten Registerbits in den Registern wieder her. Beispielsweise werden die IA32-FP-Register mit den 16 Bytes aus dem Speicher ohne Konvertierung wiederhergestellt. Dann bewirkt der Rückkehrcode 528 einen ISA-Übergang, um zu der Modus1-Anwendung zurückzukehren, indem ein Verzweigungsbefehl (z. B. BR_IA) ausgeführt wird. Bei Rückkehr zu dem Rückkehrcode 514 in der Modus1-Anwendung 410 werden sämtliche Register in dem Speicherformat wiederhergestellt. Sofern eine Tag-Architektur verwendet wird, werden sämtliche internen Tags in das Speicherformat zurückge setzt. Der Rückkehrcode 514 in der Modus1-Anwendung 410 fährt mit seiner Operation in der Modus1-Umgebung fort.
6 ist eine Darstellung, die eine Zahlenformatkonvertierung in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht. Die Zahlenformatkonvertierung konvertiert ein gepacktes 32-Bit-Ganzzahl(INT)-Element 610 in ein gepacktes 32-Bit-Einfachgenauigkeit(SP)-Element 660 und umgekehrt. Das gepackte 32-Bit-INT-Element 610 wird in das gepackte 32-Bit-SP-Element 660 durch die Konvertierungssequenz 605 konvertiert. Das gepackte 32-Bit-SP-Element 660 wird in das gepackte 32-Bit-INT-Element 610 durch Verwendung ursprünglicher Konvertierungsbefehle, wie beispielsweise dem fpcvt-Befehl, konvertiert.
Die Konvertierungssequenz 605 konvertiert das gepackte 32-Bit-INT-Element 610 in ein ungepacktes 32-Bit-INT-Element 620, indem das Element 610 in zwei separate Teile entpackt wird, wobei jedes Teil ein 32-Bit-INT-Element ist. Dann wird das entpackte 32-Bit-INT-Element 620 in ein ungepacktes 64-Bit-INT-Element 630 konvertiert, indem jedes 32-Bit-INT-Element in ein zugehöriges 64-Bit-INT-Element konvertiert wird. Dann wird das ungepackte 64-Bit-INT-Element 630 in ein ungepacktes 82-Bit-DP-Element 640 konvertiert, indem jedes 64-Bit-INT-Element in ein zugehöriges 82-Bit-DP-Element konvertiert wird. Das ungepackte 82-Bit-DP-Element 640 wird dann in ein gepacktes 82-Bit-DP-Element 650 konvertiert, indem die 82-Bit-DP-Elemente in ein gepacktes Format gepackt oder kombiniert werden. Schließlich wird das gepackte 82-Bit-DP-Element 650 in das 32-Bit-SP-Element 660 konvertiert.
7 ist eine Darstellung, die einen Prozeß 700 zum Emulieren logischer Befehle in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht.
Bei START bestimmt der Prozeß 700, ob der Befehl ein logischer Befehl doppelter Genauigkeit (DP; Double Precision) ist, wie beispielsweise ANDNDP, ANDDPD, ORDP, XORDP (Block 710). Wenn dies nicht der Fall ist, wird der Prozeß 700 beendet. Sofern der Befehl einer der logischen DP-Befehle ist, bestimmt der Prozeß 700 als nächstes, ob die Operanden in dem Speicher format sind (Block 720). Wenn dies nicht der Fall ist, wird der Prozeß 700 beendet. Sofern die Operanden in dem Speicherformat sind, bestimmt der Prozeß 700, ob der Signifikand gleich Null ist (Block 730). Wenn dies nicht der Fall ist, setzt der Prozeß 700 das Exponentenfeld auf 0 × 1003E (Block 750) und fährt damit fort, die logische Operation auszuführen (Block 760). Sofern der Signifikand gleich Null ist, setzt der Prozeß 700 das Exponentenfeld auf 0 × 0 (Block 740) und fährt damit fort, die zugehörige logische Operation, wie beispielsweise FAND, FANDCM, FOR oder FXOR, auszuführen (Block 760).
8 ist eine Darstellung, die eine aufrufende Operation 800 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht. Die aufrufende Operation 800 umfaßt einen Aufrufer 810 und einen Aufgerufenen 820.
Der Aufrufer 810 arbeitet die Anwendung in einem Datenformat ab und ruft den Aufgerufenen 820 auf. Der Aufgerufene 820 arbeitet die Anwendung in einem anderen Datenformat ab. Der Aufrufer kennt die Verwendung seiner Register und sichert folglich nur die Register, welche bewahrt werden müssen, bevor er den Aufgerufenen 820 aufruft. Der Aufgerufene 820 entleert (spill) die Register in Übereinstimmung mit den Tag-Bits, indem er die Register in Form von Bits in dem Speicher speichert. Nach der Operation stellt der Aufgerufene 820 die in dem Speicher gesicherten Registerbits in Speicherformat wieder her. Sofern es eine Nicht-Übereinstimmung des Formats gibt, konvertiert der Aufgerufene 820 zurück, wenn er die Aufruferbefehle ausführt. Bei Rückkehr zu dem Aufrufer 810 vermeidet der Aufrufer unechte (spurious) Datentypkonvertierungen.
9 ist ein Ablaufdiagramm, das einen Prozeß 900 für eine Objektcodeübersetzung (OCT; Object Code Translation) in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung veranschaulicht.
Bei START bestimmt der Prozeß 900, ob der Befehl ein ursprünglicher Befehl des erweiterten oder angereicherten Modus (EM; Enhanced Mode) ist (Block 910). Sofern dies nicht der Fall ist, wird der Prozeß 900 beendet. Sofern der Befehl ein ursprünglicher EM-Befehl ist, bestimmt der Prozeß 900, ob er einer der gepackten DP-Befehle ist (Block 920). Sofern dies nicht der Fall ist, wird der Prozeß 900 beendet. Sofern der Befehl ein gepackter DP-Befehl ist, emuliert der Prozeß 900 den Befehl mit dem entsprechenden ursprünglichen DP-Befehl (Block 930). Der Prozeß 900 fügt einen geeigneten Konvertierungsbefehl ein, um das Speicherformat (z. B. 64-Bit-DP) in das erweiterte DP-Format (z. B. 82-Bit-DP) zu konvertieren. Der Konvertierungsbefehl umfaßt typischerweise eine Speichere- und Lade-Sequenz.
Als nächstes führt der Prozeß 900 die DP-Befehle mit dem erweiterten DP-Format (z. B. 82-Bit-DP) aus (Block 950). Nach der Ausführung fügt der Prozeß 900 einen Konvertierungsbefehl ein, um das erweiterte DP-Format (z. B. 82-Bit) in das Speicherformat (z. B. 64-Bit) zu konvertieren. Wiederum umfaßt der Konvertierungsbefehl typischerweise eine Speichere- und Lade-Sequenz. Der Prozeß 900 wird dann beendet.
Die vorliegende Erfindung schafft eine Technik zum Emulieren eines Befehlssatzes doppelter Genauigkeit auf einem Prozessor, welcher eine Formatdarstellung erweiterter Genauigkeit aufweist. Die Technik umfaßte eine Formatkonvertierung, Kontextumschaltung, Tag-Architektur, Aufrufkonventionen und Konvertierungsbefehle.
Während diese Erfindung unter Bezugnahme auf veranschaulichende Ausführungsbeispiele beschrieben wurde, soll diese Beschreibung nicht in einem einschränkenden Sinne ausgelegt werden. Verschiedene Modifikationen der veranschaulichten Ausführungsbeispiele sowie weitere Ausführungsbeispiele der Erfindung, welche Fachleuten, an welche sich die Erfindung richtet, klar sind, sind als innerhalb des Geistes und Umfangs der Erfindung liegend anzusehen.

Claims

Verfahren zum Emulieren der Ausführung eines Befehls einer erster Befehlssatzarchitektur auf einem Prozessor, der eine von der ersten Befehlssatzarchitektur abweichende, zweite Befehlssatzarchitektur aufweist, wobei sich die Befehlssatzarchitekturen darin unterscheiden, daß für die Operanden des Befehls verschiedene Datenformate in Prozessorregistern verwendet werden, wobei: der Befehlscode des Befehls und wenigstens ein Operand in einem ersten Datenformat, das der ersten Befehlssatzarchitektur entspricht, von dem Prozessor empfangen werden, der wenigstens eine Operand aus dem ersten Datenformat in ein abweichendes, zweites Datenformat, das der zweiten Befehlssatzarchitektur entspricht, konvertiert und in wenigstens einem Register des Prozessors gespeichert wird, der Befehl von dem Prozessor ausgeführt wird, indem die von dem Befehlscode codierte Operation an dem wenigstens einen Operanden in dem zweiten Datenformat ausgeführt wird, wobei ein Ergebnis in dem zweiten Datenformat erzeugt und in einem Prozessorregister gespeichert wird, und das Ergebnis aus dem zweiten Datenformat in das erste Datenformat konvertiert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Konvertieren des Operanden aus dem ersten Datenformat in das zweite Datenformat ein Konvertieren des Operanden aus einem Gleitkommaformat doppelter Genauigkeit (DPFP-Format) umfaßt.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß das DPFP-Format eine 64-Bit-Darstellung hat.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß das Konvertieren des Operanden aus dem ersten Datenformat in das zweite Datenformat ein Konvertieren des Operanden in ein erweitertes Gleitkommaformat doppelter Genauigkeit (EDPFP-Format) umfaßt.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß das EDPFP-Format eine 82-Bit-Darstellung hat.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß das 64-ßit-DPFP-Format im Speicher und das 82-Bit-EDPFP-Format in den Registern eines die zweite Befehlssatzarchitektur aufweisenden Prozessor verwendet wird.