DE68924543T2

DE68924543T2 - Prozessorsimulation.

Info

Publication number: DE68924543T2
Application number: DE1989624543
Authority: DE
Inventors: Nicolas Arturo Martin De; John Claude O'quin Iii
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1988-02-01
Filing date: 1989-01-05
Publication date: 1996-06-13
Anticipated expiration: 2009-01-06
Also published as: JPH0668724B2; JPH025138A; EP0327198A2; EP0327198B1; DE68924543D1; EP0327198A3

Description

Die Erfindung bezieht sich auf eine Prozessorsimulation, bei der ein für einen spezifischen ersten Prozessor geschriebenes Anwendungsprogramm auf einem zweiten anderen Prozessor mit anderem Befehlssatz ausgeführt werden kann.
Fortschritte in der Computertechnologie haben zu sich ständig ändernden Prozessoren geführt, die hier als Zentraleinheit (CPU) des Prozessorsystems bezeichnet werden. Beispiele für die Entwicklung verschiedener Prozessoren sind der 8088 Prozessor von Intel im IBM PC, der 80286 Prozessor von Intel im IBM PC AT, der 80386 Prozessor im IBM Personal System/2 Modell 80 und der IBM Research/OPD Microprocessor (ROMP), der eine RISC-Architektur (RISC, Computer mit vermindertem Befehlssatz) im IBM RT PC verwendet. Zu anderen Prozessoren gehören unter anderem der 68000 und der 68020 von Motorola.
Die Hardware der verschiedenen Verarbeitungssysteme ändert sich schnell, um sich an die erhöhte Verarbeitungsleistung der neuen Prozessoren anzupassen. Ein Nachteil bei der neuen Hardware ist, daß die für vorherige Prozessoren geschriebene Software nicht bei der neuesten Hardware-Technologie verwendet werden kann. In einigen Fällen, wo die Software auf einem anderen Verarbeitungssystem läuft als dem ursprünglich vorgesehen, ist die Leistung der Anwendung nicht so gut wie beim ursprünglichen System. Als Ergebnis sind Software-Anwendungen, die lange entwickelt wurden, schnell veraltet. Das Veralten der früher geschriebenen Software ist umso tragischer, als die Funktion der Anwendung immer noch wichtig und bei den neuen Hardware-Verarbeitungssystemen gefragt ist.
Daraus ergibt sich, daß nur eine begrenzte Anzahl von "neuer" Software zur Verfügung steht, die speziell für die "neue" Hardware geschrieben ist, wenn diese auf den Markt kommt. Das hängt teilweise mit den langen Entwicklungszyklen von Software-Anwendungsprogrammen zusämmen, und der Geheimhaltung des neuen Hardware-Designs von seiten des Herstellers vor der Vorstellung der Hardware auf dem Markt. Der Software-Hersteller muß bestimmte Tatsachen über die Hardware eines Verarbeitungssystems kennen, bevor ein Software-Anwendungsprogramm für das Verarbeitungssystem geschrieben werden kann.
Im Idealfall hätte der Hersteller von Verarbeitungssystemen gern eine Vielzahl von Software, die für das Verarbeitungssystem geeignet ist, sobald die neue Hardware auf den Markt kommt. Ein Kunde investiert leichter in ein neues Verarbeitungssystem, wenn er weiß, daß zahlreiche Software- Programme bereits zur Verfügung stehen.
Es gab verschiedene Versuche, die große Zahl an Programmen, die zuvor für "ältere" Hardware-Designs geschrieben wurden, zu verwenden. Eine Möglichkeit, um ursprünglich für einen anderen Prozessor geschriebene Anwendungen zu verwenden, besteht darin, einen Coprozessor in das neue Verarbeitungssystem einzubauen. Auf diese Art und Weise können auf dem Verarbeitungssystem Anwendungen für beide Prozessortypen, den neuen und den alten, laufen.
Der IBM RT PC beispielsweise enthielt einen IBM PC AT Coprozessor, um Anwendungen zu nutzen, die ursprünglich für den IBM PC AT geschrieben wurden. Da der Coprozessor jedoch nur in begrenztem Umfang vom Betriebssystem unterstützt wurde, konnte dieser die vom AIX-Betriebssystem bereitgestellten Funktionen nicht voll ausnutzen. Eine der Funktionen des AIX- Betriebssystems ist das Multitasking, das in der gleichzeitig anhängigen Patentschrift EP-A-0 229 336 beschrieben wird.
Der Coprozessor ermöglicht jedoch nur eine Sitzung, da er einen Hardware-Adapter zur Emulation des PC AT enthält. Wenn der Coprozessor mit anderen Worten gestartet wurde, konnten andere Fälle des Coprozessors nicht laufen.
Der Coprozessor ist darüber hinaus auf die Geschwindigkeit des Prozessors des ersten Verarbeitungssystems beschränkt und kann die schnelleren zweiten Verarbeitungssysteme nicht in vollem Ausmaß nutzen.
Eine zweite Möglichkeit besteht darin, den zweiten Prozessor über die Software zu simulieren. Ein Software-Simulator verfügt über einen Mechanismus, mit dem zuvor für einen Prozessor geschriebene Programme auf einem neuen Verarbeitungssystem mit einem anderen Prozessor laufen können. Durch die Simulierung können schnellere zweite Verarbeitungssysteme genutzt werden. Darüber hinaus ist die Verwendung von Multitasking-Fähigkeiten des Betriebssystems möglich, um Mehrfachfälle des ersten Prozessors bereitzustellen.
Unter den Software-Simulatoren auf dem Markt sind Soft PC von Insignia Solutions und der Amiga Transformer von Simile Research Inc. für den Amiga von Commodore (basierend auf dem 68000 von Motorola) zu nennen. Das System wurde in folgendem Artikel beschrieben: "Amiga's Trump Card: IBM PC Emulation", AMIGA WORLD, Vol. 1, No. 2, November/Dezember 1985. Phoenix Technologies stellte ebenfalls einen Simulator zur Simulation des Intel-Prozessors für das Apollo-Gerät vor, das mit einem 68000 Prozessor von Motorola ausgestattet ist.
Jeder CPU-Prozessor verfügt über einen spezifischen Befehlssatz. Wenn ein Software-Anwendungsprogramm für einen spezifischen CPU-Prozessor entwickelt wird, wird dieses in einen Objektcode kompiliert. Der Objektcode läuft auf jeder CPU, die den spezifischen Befehlssatz unterstützt. Ein Simulator nimmt den Objektcode, der für einen spezifischen Befehlssatz geschrieben wurde, und wandelt diesen für einen anderen Prozessor um, der einen ähnlichen oder anderen Befehlssatz hat. Je unterschiedlicher die beiden Prozessoren sind, desto schwieriger ist es, den anderen Prozessor zu simulieren.
Der Intel 80286 Prozessor beispielsweise hat einen sehr umfangreichen Befehlssatz, da er zahlreiche Befehle bereitstellt. Jeder Befehl ist für eine bestimmte Situation maßgeschneidert. Darüber hinaus kann jeder Befehl mehrere Operationen ausführen. Der ROMP-Prozessor im RT PC dagegen verfügt über einen Prozessor mit verringertem Befehlssatz (RISC-Prozessor), der weniger Befehle und weniger Funktionen pro Befehl hat. Da jeder Befehl im Intel 80286 mehrere Tasks ausführen kann, würden für einen ROMP RISC- Prozessor mehr Befehle benötigt, um dieselben Tasks ausführen.
Die Geschwindigkeit eines Prozessors kann durch die Vereinfachung des Befehlssatzes erhöht werden. Obgleich mehr Befehle erforderlich sind, wird keine zusätzliche Zeit für komplizierte Befehle benötigt, während die allgemeineren und einfacheren Tasks ausgeführt werden.
Bei früheren Software-Simulatoren ist eine Subroutine erzeugt worden, die einen Befehlseffekt simulierte. Wenn das zu simulierende Gerät diesen Befehl ausführen mußte, wurde die Subroutine aufgerufen, um den Befehl zu decodieren und auszuführen. Das Problem bei diesem Verfahren ist, daß der zusätzliche Aufwand durch das Decodieren des Befehls immer auftritt, wenn die Subroutine aufgerufen und ausgeführt wird. Das wirkt sich nachträglich auf die Prozessorgeschwindigkeit aus.
Anstatt eine Subroutine aufzurufen, wenn ein Befehl ausgeführt werden mußte, kompilierte eine andere Software-Simulation eine kürzere Folge von Host-Befehlen, um einen Befehl zu simulieren. Der zusätzliche Aufwand von Decodieren und Übersetzen des Befehls tritt nur einmal auf, wenn der Befehl zum ersten Mal aufgerufen wird. Die Übersetzung wird anschließend gespeichert. Ab dann wird die Übersetzung ausgeführt, wenn der Befehl simuliert wird. Dies wird häufig als Simulator zweiter Generation bezeichnet. Ein Simulator erster Generation nimmt jeweils nur einen Befehl, decodiert ihn in Echtzeit und führt ihn aus. Die Decodierung jedes Befehis erfolgt dann, wenn ein Befehl benötigt wird. Ein Simulator zweiter Generation geht durch alle Befehle, übersetzt sie und verwendet dann die Übersetzung anstatt wieder zurückzugehen und erneut zu übersetzen.
Ein Simulator zweiter Generation war der Simulator, der die IBM ROMP CPU im IBM System/370, genannt RSIM, simulierte. Dieser Simulator reserviert eine bestimmte Speichermenge für jeden Befehl (16 Bytes für jedes Halbwort), die als Zellen bezeichnet werden. Die IBM 370-Befehle werden für jede dieser Zelle für jeden RT-Befehl erzeugt. Wenn der erzeugte Code kleiner als die Aufnahmefähigkeit der Zelle ist (was normalerweise der Fall ist), geht es bei der nächsten Grenze der nächsten Zelle weiter. Wenn der erzeugte Code zur Simulierung des Befehls nicht in die Zelle paßt, wird eine Subroutine-Abfrage erzeugt, der zu einem Laufzeitumgebungssatz von Routinen geht, welche die Emulation durchführen und zur Zelle zurückkehren, um die Ausführung zu beenden. Ein weiterer Simulator simuliert den Prozessor des IBM System/370 auf dem IBM RT PC, der in folgendem Artikel beschrieben wird: May, C. "Mimic: A Fast System/370 Simulator", der auf dem Symposium on Interpreters and Interpretive Techniques der Association of Computing Machinery vorgestellt und in SIGPLAN, 1987, Protokoll der ACM, veröffentlicht wurde.
Ein Simulator erster Generation verarbeitet 50 bis 100 Host- Befehle pro simuliertem Befehl. Ein Simulator zweiter Generation verarbeitet durchschnittlich 10 Host-Befehle pro simuliertem Befehl.
Wenn ein Simulator entweder 50 oder 10 Befehle zur Simulation eines Befehls auf einem simulierten Gerät verwendet, muß der zweite Prozessor mit dem Simulator entweder 50 oder 10 mal schneller als das simulierte Gerät sein, um eine vergleichbare Leistung zu erbringen. Aus diesem Grund sollte im Vergleich zur herkömmlichen Technik die Zahl der Simulatorbefehle pro simuliertem oder übersetztem Befehl reduziert werden.
Wenn beispielsweise ein Simulator hergestellt werden könnte, der nur 4 Befehle pro simuliertem Befehl verwendet, und der Simulatorprozessor viermal schneller als der simulierte Geräteprozessor ist, wre der Simulator schneller als das simulierte Gerät. Ein Benutzer würde eine erhöhte Leistung feststellen, wenn anstatt des ursprünglichen Geräts das simulierte Gerät für die Durchführung des Anwendungsprogramms verwendet würde.
Das Problem bei der Simulation eines anderen Prozessors besteht darin, die Zahl der Simulatorbefehle (Host-Befehle) pro simuliertem Befehl zu reduzieren, um die Verarbeitungsgeschwindigkeit des Simulators zu erhöhen.
Gegenstand der Erfindung ist es daher, die durchschnittliche Zahl der Host-Befehle pro simuliertem Gerätebefehl zu reduzieren.
Gemäß vorliegender Erfindung wird ein Verfahren zur Reduzierung der Anzahl von übersetzten Befehlen vorgestellt, die zur Simulation eines ersten Prozessors mit einem ersten Befehlssatz durch einen zweiten Prozessor mit einem zweiten Befehlssatz benötigt werden, wenn eine Anwendung für den ersten Befehlssatz auf dem zweiten Prozessor läuft, wobei das Verfahren bei Laufzeit einen Befehlszeiger eines nächsten Befehls des ersten Prozessors, welcher aus einem dynamischen Steuerbefehl resultiert, in eine Adresse für die Übersetzung des zweiten Prozessors des nächsten Befehls vom ersten Prozessor umwandelt; wobei das Verfahren dadurch gekennzeichnet ist, daß eine Reihe von Schritten miteinander verbunden wird, um die Umwandlung durchzuführen, die folgendes umfaßt: in einem ersten Schritt bei Laufzeit unter Verwendung eines Befehls des zweiten Prozessors einen neuen Befehlszeiger eines nächsten Befehls des ersten Prozessors mit einem vorhergehenden Befehlszeiger eines vorherigen dynamischen Steuerbefehls, welcher für den zweiten Prozessor ubersetzt wurde, zu vergleichen, wobei der Vergleichsschritt eine Adresse für die Übersetzung des zweiten Prozessors für den nächsten Befehl des ersten Prozessors festlegt, wenn der neue Befehlszeiger zur selben Adresse wie der vorherige Befehlszeiger zurückgeht; und die Verzweigung zur Adresse der Übersetzung des zweiten Prozessors des nächsten Befehls, wenn der neue Befehlszeiger mit dem vorherigen Befehlszeiger übereinstimmt; in einem zweiten Schritt unter Verwendung eines Übersetzungsumsetzpuffers mit einer begrenzten Anzahl von Befehlszeigern des ersten Prozessors und entsprechenden Übersetzungsadressen des zweiten Prozessors die Übersetzungsadresse des nächsten Befehls festzulegen, wenn der dynamische Steuerbefehl zur selben Adresse zurückkehrt, zu der mindestens einmal zuvor zurückgekehrt wurde; und in einem dritten Schritt eine verbundene Datenstruktur mit mehr Übersetzungsadressen des zweiten Prozessors als im Umsetzpuffer vorhanden die Übersetzungsadresse des nächsten Befehls festzulegen, wenn der dynamische Steuerbefehl zu einer neuen Adresse zurückkehrt, zu der zuvor noch nicht zurückgekehrt wurde.
Mit diesem Simulator können Anwendungen, die ursprünglich für einen anderen Prozessor geschrieben wurden, mit Hilfe von Software-Emulation ausgeführt werden. Durch diese Simulation mit Software-Unterstützung können die Funktionen des Betriebssystems des Simulatorgeräts genutzt werden. Im bevorzugten Ausführungsbeispiel der Erfindung läuft der Simulator als Anwendung auf dem AIX-Betriebssystem eines RT PC. Der Simulator kann daher die Multitasking-, Multiuser-Fähigkeiten des AIX- Betriebssystems nutzen, um mehrere Anwendungen, die ursprünglich für den PC AT geschrieben wurden, gleichzeitig laufen zu lassen, ohne die Anwendung selbst zu ändern.
Der hier beschriebene Simulator bietet schnellere Verarbeitungsfähigkeiten des simuliuerten Prozessors als vorherige Verfahren von Prozessorsimulationen, indem die Zahl der Host- Befehle pro simuliertem Gerätebefehl verringert wird. Dies wurde durch die Identifizierung von Schlüsselverarbeitungsbereichen erzielt, die mehr Befehle als gewünscht benutzten, und durch die anschließende Ausarbeitung neuer Verfahren, um die Verarbeitungstasks mit weniger Befehlen durchführen zu können.
Um die CPU-Simulation zu verbessern, z.B. durch die Verringerung der durchschnittlichen Anzahl von Host-Befehlen pro simuliertem Befehl, wurden mehrere Schlüsselverarbeitungsbereiche identifiziert, die mehr Befehle als gewünscht verwendeten.
Zuerst wurde der Verarbeitungstask zur Speicherung der korrekten Werte der Bedingungscodes wie in EP-A-0,327,196 mit der internen Docket-Nummer AT9-88-002 beschrieben identifiziert. Das Verfahren verwendet eine Graphanalysetechnik, die zuvor in der Kompilertechnik Anwendung fand, und überträgt diese auf die CPU-Simulatortechnologie, um dynamisch festzulegen, ob Bedingungscodes von Befehlen benötigt werden. Der Simulator speichert ausreichend Informationen, um diese eventuell benötigten Bedingungscodes zu erzeugen. Andernfalls wird die Anzahl von benötigten übersetzten Befehlen für diesen Befehl verringert, wenn aus der Graphanalyse hervorgeht, daß Bedingungscodes nicht benötigt werden.
Ein weiterer Bereich zur Verringerung der durchschnittlichen Anzahl von erzeugten Befehlen, auf den sich die Erfindung bezieht, umfaßt die Übersetzung der Befehlsadressen. Die Adressen von sequentiellen Befehlen stellen kein Problem bei der Übersetzung dar, da die übersetzte Adresse auch die nächste sequentielle Adresse ist. Schwierig wird es erst bei den Befehlen, die bei der statischen Betrachtung des Programms nicht gemeinsam sind, sondern häufig in einer dynamischen Befehlsmischung auftreten. Ein Beispiel dafür ist die Rückkehr von einem Subroutine-Befehl.
Ein Verarbeitungssystem benötigt relativ viel Zeit, um eine Rückkehr von einer Subroutine auszuführen. Ein Unterschied bei dieser Befehlsart besteht darin, daß die Adresse des nächsten auszuführenden Befehls nicht statisch festgelegt werden kann, indem einfach das Programm betrachtet wird. Das Programm muß tatsächlich laufen, um die Adresse festzustellen, zu der dieser Befehl zurückkehren wird. Die meisten Programme kehren wahrscheinlich zur selben Stelle wie bei der letzten Ausführung des Befehls zurück, so wie dies häufig bei programmierten Schleifen geschieht. Für den Simulator ist es einfacher, die Adresse, die bei Laufzeit vom Rückkehrbefehl geladen wurde, mit der zuvor von diesem Befehl ausgeführten Rückkehradresse zu vergleichen. Wenn die letzte Rückkehradresse übereinstimmt, ist die Rückkehrstelle dieselbe. Nur wenn dies nicht funktioniert, kommen die ausgefeilteren Mechanismen eines übersetzungsumsetzpuffers und dann von Binärbäumen zum Einsatz, die als Suchverfahren zur Bestimmung der Adresse des nächsten Befehls nach einer Rückkehr verwendet werden.
Die dreistufige Vorgehensweise bei der Adreßbestimmung des nächsten Befehls vereinfacht das Verfahren, indem ein Vergleich in dem Fall verwendet wird, wo der aktuell ausgeführte Befehl zur selben Adresse wie bei der letzten Ausführung zurückkehrt, oder indem ein Übersetzungsumsetzpuffer verwendet wird, wenn der Befehl zu einer Adresse zurückkehrt, die mindestens einmal zuvor bereits benutzt wurde, wenn auch nicht unmittelbar zuvor, und indem Binärbäume als letztes Mittel verwendet werden, wenn die beiden zuvor genannten Fälle nicht funktionieren. Die Rückkehradresse wird allgemein dazu verwendet, auf eine Adresse eines beliebigen, steuerungsübertragenden Befehls zu verweisen, indem die nächste Zieladresse von einem Wert in einem Register oder Speicher berechnet wird.
Der dritte Verarbeitungsbereich zur Reduzierung der durchschnittlichen Anzahl von Rost-Befehlen pro simuliertem Befehl bezieht sich auf den Verarbeitungstask, der feststellen kann, was passiert, wenn ein Befehl wie in der Patentschrift EP-A 0,327,195 mit der internen Docket-Nummer AT9-88-007 beschrieben in einem Speicher speichert. Der Simulator prüft einen ersten Prozessorbefehl, der den Speicher aktualisiert, um festzustellen, ob der Befehl einen nachfolgenden Befehl ändert oder eine Videopufferaktualisierung durchführt. Der Prozeß verringert die Anzahl von benötigen Zyklen, d.h. Befehlen, zur Feststellung dieser Änderung.
Das hier beschriebene Ausführungsbeispiel stellt die genannten Verfahren vor.
Die vorliegende Erfindung wird im folgenden anhand von Ausführungsbeispielen mit Begleitzeichnungen beschrieben.
Fig. 1 ist ein Blockdiagramm mit der Verarbeitungssystemumgebung des bevorzugten Ausführungsbeispiels.
Fig. 2 ist ein Fließdiagramm mit den Anfangsschritten zum Starten des Simulators.
Fig. 3A zeigt eine Graphanalyse eines Beispielsteuerflusses von ersten Prozessorbefehlen&sub1; die vom Simulator übersetzt werden.
Fig. 3B zeigt einen zweiten Beispielsteuerfluß von ersten Prozessorbefehlen, die übersetzt werden.
Fig. 3C zeigt eine Graphanalyse der Bedingungscodes im Steuerfluß der ersten in Fig. 3B gezeigten Prozessorbefehle.
Fig. 3D zeigt den Steuerfluß von zweiten Prozessorbefehlen, die von der Graphanalyse von Fig. 3C übersetzt wurden.
Fig. 4 ist ein Fließdiagramm der Übersetzung.
Fig. 5 zeigt die Datenstrukturen der zweiten und dritten Verfahren zur Festlegung der übersetzten Befehlsadresse des nächsten auszuführenden Befehls, indem ein Befehl eines Befehlssatzes auf eine entsprechende Übersetzungsadresse eines Simulators mit einem unterschiedlichen Befehlssatz abgebildet wird.
Fig. 6 ist ein Fließdiagramm des dreistufigen Verfahrens, um die übersetzte Befehlsadresse des nächsten auszuführenden Befehls festzustellen.
Fig. 7 ist ein Blockdiagramm mit den Speichertypen und - inhalten eines Verarbeitungssystems.
Fig. 8 zeigt das Speicher-Mapping des ersten Verarbeitungssystems in den Speicher eines zweiten Verarbeitungssystems sowie eine Statustabelle, die den Inhaltstyp einer Speicherung in den Speicher angibt.
Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung simuliert ein Verarbeitungssystem, z.B. den IBM PC AT mit einem Intel 80286 Prozessor und einem komplexen Befehlssatz, auf einem Verarbeitungssystem 1 (siehe Fig. 1), z.B. einem IBM RT PC mit einem ROMP-Prozessor und RISC-Technologie (RISC, Computer mit verringertem Befehlssatz). obgleich der RISC-Prozessor weniger Funktionen pro Befehl hat, kann er Befehle schneller ausführen. Die Architekturen eines Geräts mit einem Intel 80286 und eines Geräts mit RISC sind sehr verschieden voneinander. Je größer der Unterschied zwischen den Architekturen von zwei Verarbeitungssystemen ist, desto schwieriger ist es, einen Prozessor auf einem anderen Verarbeitungssystem zu simulieren.
Mehr Informationen zu den Verarbeitungssystemen des RT PC und des IBM PC AT sowie zum 80286 Prozessor von Intel sind in folgenden Referenzwerken zu finden: Bach, M.J. The Design of the UNIX Operating System, Prentice Hall, 1986. Lang, T.G. und Mothersole, T. L., Design of the RT PC VRM Nucleus, September 1, 1986. AIX Operating System Commands Reference, Version 2.1, IBM Corporation, SC23-0790. AIX Operating System Managing the AIX Operating System, Version 2.1, IBM Corporation, SC23-0793. AIX Operating System Programming Tools and Interfaces, Version 2.1, IBM Corporation, SC23-0789. AIX Operating System Technical Reference, Version 2.1, Volumes 1 und 2, IBM Corporation, SC23-0808 und SC23-0809. IBM RT Personal Computer Technology, IBM Corporation, SA23-1057, 1986. Virtual Resource Manager Technical Reference, Version 2.1, Volumes 1 und 2, IBM Corporation, SC23-0816 und SC23-0817, IAPX 286 Programmer's Reference Manual Induding the iAPX 286 Numeric Supplement, Intel, 210498-003, 1985, und IBM PC AT Technical Reference Manual, IBM Corporation, März 1984.
Der Simulator 10 luft in Fig. 1 als Anwendungsprogramm auf dem Betriebssystem 12 des Verarbeitungssystems 1. Mit Hinweis auf Fig. 2 kopiert der Simulator 10 nach dem Start (Schritt 2) das BIOS 13 mit 80286-Befehlen aus dem Festwertspeicher (ROS, read only storage) 15, in anderem Zusammenhang auch als ROM bezeichnet, in das gemeinsam benutzte Speichersegment 16 des Betriebssystems 12 (Schritt 3). Der Simulator 10 übersetzt das BIOS 13 (Schritt 4), das das Betriebssystem (DOS) 18 lädt, für das die Anwendung 19 ursprünglich geschrieben wurde (Schritt 5). Der Simulator 10 übersetzt und führt das Betriebssystem 18 aus (Schritt 6). Ein Benutzer ruft die Anwendung 19 beim Betriebssystem-Prompt auf (Schritt 7), und der Simulator 10 übersetzt und führt das Anwendungsprogramm 19 aus (Schritt 9).
Um die Leistung der CPU-Simulation zu verbessern, d.h. die durchschnittliche Anzahl von Host-Befehlen pro simuliertem Befehl zu reduzieren, wurden verschiedene Schlüsselverarbeitungsbereiche identifiziert, die mehr Befehle als gewünscht verwendeten.

I. Graphanalyse der Bedingungscodes

Zuerst wurde der Verarbeitungstask zur Speicherung der korrekten Werte der Bedingungscodes identifiziert.
Viele Prozessorbefehle beziehen sich auf das Flags-Register 20 (Fig. 3C), indem die Bedingungscodes 21-26 darin aktualisiert werden, um das Ergebnis einer Operation wiederzuspiegeln. Es gibt sechs verschiedene Bedingungscodes, das Überlauf-Flag 21, das vorzeichen-Flag 22, das Null-Flag 23, das arithmetische Flag 24 (auch als Halbübertrag bezeichnet), das Paritäts-Flag 25 und das Übertrag-Flag 26. Diese Bedingungscodes 21-26 zeigen gemeinsame Bedingungen an, z.B. ob das Ergebnis null war, ob es negativ war, ob ein Übertrag aus einem Register stattfand, oder ob eine Überlaufbedingung vorliegt. Darüber hinaus enthalten sie Bedingungen, die die Parität (gerade oder ungerade) des unteren Bytes des Ergebnisses sowie den Übertrag aus den unteren 4 Bits der Operation (Halbübertrag) anzeigen.
Um einen ersten Prozessorbefehlssatz zu simulieren, indem eine aktualisierte Version des ersten Prozessor-Flagregisters gespeichert wird, würden zusätzliche Zyklen für jeden Befehl benötigt, die das Register beeinflußen. Dies trifft vor allem zu, wenn die Architektur des ersten Prozessors mehrere unterschiedliche Kombinationen von Bedingungscode-Aktualisierungen definiert. Die Bedingungscodes können z.B. immer gesetzt oder gelöscht, berechnet, unverändert gelassen oder undefiniert gelassen werden.
Ein älterer RSIM-Simulator, der RT PC Prozessorsimulator des IBM S/370, verwendete ein Verfahren zur Verringerung des Verfolgungsaufwands der Bedingungscodes. Register wurden zu diesem Zweck reserviert. Die reservierten Register enthielten die für eine Operation relevanten 32-Bit-Werte sowie die Art der durchgeführten Operation. Dadurch sollte die Wertbestimmung des Bedingungscodes verzögert werden, bis ein Befehl, der diesen tatsächlich benötigt, simuliert wird. Dabei müssen jedoch die Werte und Typen gespeichert werden. Dieser Zusatzaufwand ist unnötig, wenn alle möglichen nachfolgenden Pfade einen Befehl enthalten, der dieselben Bedingungscodes ohne anderen Befehl, der diese benötigt, ändert.
Um festzustellen, welche Änderungen des Flag-Registers 20 von nachfolgenden Befehlen verwendet werden, bezieht sich der Simulator 10 auf Informationen von der Graphanalyse 30, Fig. 3A, oder 50, Fig 3C, eines Blocks von ersten Prozessorbefehlen 100. Diese Techniken wurden zuvor verwendet, um leistungsstarke Sprachenkompiler zu optimieren. Dies scheint jedoch das erste Mal zu sein, daß diese Technik bei der Prozessorsimulation Anwendung findet.
Wenn der Simulator 10 einen neuen Block von ersten Prozessorbefehlen 100 erreicht (Schritt 131, Fig. 4), ruft der Simulator 10 den Übersetzer 27 auf, um eine zweite Prozessorübersetzung bereitzustellen (Schritt 132). Die Übersetzung erfolgt in drei Stufen.
Zuerst wird ein Graph 50 (Fig. 3C) in Schritt 133 von Fig. 4 gebildet, der die Struktur des Blocks der ersten Prozessorbefehle 100 darstellt. Jeder Knoten 101 im Graph entspricht einem Befehl 100. Ein erster Prozessorbefehlsdecoder 28 füllt jeden Knoten 101 mit Informationen über den Befehl 100, einschließlich der Information, welche Register und Bedingungscodes 21-26 der Befehl 100 zur Ausführung benötigt (Block 42), und welche Bedingungscodes 21-26 der Befehl 100 als Ergebnis der Ausführung setzt (Block 43). Das Verwendungsregister 42 und das Setzregister 43 haben ein separates Bit für das Überlauf-Flag 21 und das Übertrag-Flag 26 und fassen die übrigen Bedingungscodes 22-25 in einem Bit zusammen. Wenn einer dieser Bedingungscodes 22-25 vom Befehl 100 verwendet oder gesetzt wird, zeigt dies das mittlere Bit der Register 42 und 43 an.
Als nächstes wird in Schritt 134 (Fig. 4) der Graph 30 analysiert, um festzulegen, wo Interrupts abgerufen werden müssen, wie die Übersetzungen angefordert werden müssen, um Verzweigungen gering zu halten, und welche von einem Befehl definierten Bedingungscodes verwendet werden.
Im dritten Schritt 136 (Fig. 4) wird der Codegenerator 29 aufgerufen, um den Graph 30 in zweite Prozessorbefehle 130 (Fig. 3D) zu übersetzen.
Bei der Codeerzeugung (Schritt 136) geben die Informationen im Graph 50 an, ob die von einem Befehl definierten Bedingungscodes 21-26 verwendet werden. In den meisten Fällen z.B. werden die von einem Schiebebefehl (SHL) 125 (Fig. 3B, C) definierten Bedingungscodes nicht verwendet. Der Codegenerator 29 kann diese Tatsache nutzen und einen einzelnen zweiten Prozessorbefehl 135 (Fig. 3D) erzeugen, wo möglicherweise vier oder fünf Befehle benötigt worden wären, um die Operanden der Operation zu speichern, wenn Bedingungscodes benötigt worden wären. Aus dem Steuerfluß der Befehle 100 von Fig. 3B, C geht hervor, daß die Bedingungscodes 21-26 für den ADD-Befehl 126 in einem nachfolgenden Befehl 128 benötigt wurden. Die übersetzten Befehle 120 (Fig. 3D) führten zu sechs Befehlen anstatt nur einem Befehl, wenn diese nicht benötigt worden wären. Wenn aus der Graphanalyse 50 hervorgeht, daß die Bedingungscodes 21-26 nicht benötigt werden, werden die zusätzlichen übersetzten Befehle nicht erzeugt.
Der Simulator 10 übersetzt erste Prozessorbefehle 100 in zweite Prozessorbefehle 130, übersetzt jedoch nicht jeweils einen Befehl. Der Simulator 10 prüft den ersten Befehl, der ausgeführt werden soll und für den keine Übersetzung vorhanden ist, und prüft nachfolgende Befehle, während er einen Graph 30 der Befehle bildet (siehe Fig. 3A).
Jeder Knoten 101 im Graph 30 entspricht einem ersten Prozessorbefehl 100. Jeder Knoten 101 kann höchstens zwei Abkömmlinge haben. Im Fall der sequentiellen Befehle 102, 105, 106, 108, 110, 111 und 112, die die Steuerung nur zum nächsten sequentiellen Befehl im Speicher übertragen, haben die Knoten 101 nur einen Abkömmling 103, 106, 107, 109, 111, 112 bzw. 113 (siehe vertikale Linie 114 in Fig. 3A). Im Fall der bedingten Verzweigungsbefehle 103 und 104, die eine Bedingung prüfen und zu einem Befehl verzweigen, wenn die Bedingung wahr ist, und zum nächsten Befehl gehen, wenn die Bedingung falsch ist, können zwei Abkömmlinge vorhanden sein. Ein Knoten 101 kann auch keine Abkömmlinge haben, wie z.B. im Fall des Interrupt- Rückkehrbefehls 109. Der Befehl 109 ohne Abkömmlinge ist ein Beispiel für einen Befehl, der die Steuerung dynamisch übermittelt. Ein Knoten 101 kann auch einen Abkömmling haben, der kein sequentieller Befehl ist. Ein Beispiel hierfür ist der unbedingte Sprungbefehl 107.
Wie aus der Beschreibung oben hervorgeht, gibt es vier Arten von Befehlen 100. Diese Befehlsarten werden wie folgt im Code numeriert. Ein Knoten 101 erhält die Nummer "0", wenn der Befehl am Knoten keine Abkömmlinge hat, z.B. der Rückkehrbefehl 128 (Fig. 3C), der Interrupt-Rückkehrbefehl 109 (Fig. 3A) und der Rückkehrbefehl 113 (Fig. 3A). Ein Knoten 101 erhält die Nummer "1", wenn es sich um einen sequentiellen Befehl mit einem sequentiellen Abkömmling handelt, z.B. der Vergleichsbefehl 121, der Dekrementierbefehl 124 (Fig. 3C), der Vergleichsbefehl 102, der Inkrementierbefehl 108 (Fig. 3A). Ein Knoten 101 erhält die Nummer "2", wenn der Befehl zwei Abkömmlinge hat, z.B. der "Jump if below"-Befehl 122 (Fig. 3C) und 103 (Fig. 3A). Ein Knoten 101 erhält die Nummer "3", wenn der Befehl kein sequentieller Befehl ist, jedoch nur einen Abkömmling hat, z.B. Sprungbefehl 107 (Fig. 3A).
Nach der Bildung des Graphs 50 (Fig. 3C), der den Block von ersten Prozessorbefehlen 100 (Fig. 38) und einen Knoten 101 pro Befehl 100 beschreibt, nimmt der Simulator eine Analyse des Graphs 50 vor. Jeder Knoten 101 enthält Informationen darüber, welche Bedingungscodes 21-26 ein erster Prozessorbefehl 100 normalerweise zur Ausführung benötigt (Register 42), und welche Bedingungscodes 21-26 von diesem Befehl nach der Ausführung gesetzt werden (Register 43). Im Fall des Vergleichsbefehls 121, benötigt der Vergleichsbefehl 121 keine Bedingungscodes 21-26 zur Ausführung, sondern setzt alle (Register 43). Der JB-Befehl (Jump if below) 122 benötigt den Übertragbedingungscode 26, um auszuführen, da dies die geprüfte Bedingung ist (Register 42), der JB-Befehl 122 setzt jedoch nach der Ausführung keine Bedingungscodes (Register 43). Der JE-Befehl (Jump if equal) 123 benötigt ein Gleichbedingungscodebit zur Ausführung, der JE-Befehl 123 setzt jedoch keine Bedingungscodes nach der Ausführung. Der Dekrementierbefehl 124 setzt die Überlauf-Flags 21 und die arithmetischen Flags 24 (Register 43) und läßt den Übertragbedingungscode 26 unverändert (Register 43). Die Graphanalyse geht auf diese Art und Weise für die übrigen Befehle 100 weiter.
Die Knoten 101 sind im Speicher 120 sequentiell zugeordnet, wie sie das Anwendungsprogramm 19 findet. Die Suche durch das ursprünglich für den ersten Prozessor geschriebene Anwendungsprogramm 19 wird als Tiefendurchlauf bezeichnet. Bei einem Tiefendurchlauf werden die Befehle sequentiell bis zu einem Endknoten (Typ 0) durchsucht, bis z.B. der IRET-Befehl 109 in Fig. 3A erreicht ist. Nachdem ein Knoten des Typs 0 erreicht ist, kehrt der Durchlauf zum letzten Befehl mit mehr als einem Abkömmling zurück.
Die Befehle 100 (Fig. 3A) im Speicher 120 bestehen aus dem Vergleichsbefehl 102, Jump below 103, Jump if equal 104, Inkrementieren 108 und Interrupt-Rückkehr 109. Nach der Interrupt-Rückkehr 109 geht der Durchlauf zurück zum Jump if equal-Befehl 104 und prüft den zweiten Abkömmling. Der zweite Abkömmling, Interrupt-Befehl 109, ist ein Befehl, der bereits im Speicher gespeichert ist. Der Durchlauf geht daher zum nächsten vorherigen Knoten mit zwei Abkömmlingen zurück, zum Jump if below-Befehl 103 und folgt dem zweiten Pfad. Auf diesem Pfad wird ein neuer Code gefunden. Die nächsten Befehle werden in der Reihenfolge von Fig. 3A im Speicher gespeichert.
In den Fig. 3B und 3C hält der Simulator für jeden Knoten 101 zwei Felder im Speicher bereit; ein Feld ist für die Bedingungscodes 21-26 vorgesehen, die vom Befehl 100 benötigt werden (Register 42), das andere Feld ist für die Bedingungscodes 21-26 vorgesehen, die vom Befehl 100 gesetzt werden (Register 43). An dieser Stelle wird ein Laufzeitprozeß durchgeführt, um das Setzen der Bedingungscodes zu optimieren. Dies wird dadurch erreicht, daß vom letzten zugeordneten Befehl zum ersten zugeordneten Befehl gegangen wird. In dieser Reihenfolge werden Befehle aus einer kreisförmigen Warteschlange entnommen. Das Register 42 eines Knoten 101 wird aktualisiert, indem das Komplement von Register 43 dieses Knoten mit Register 42 aller Abkömmlingsknoten addiert wird, und das Ergebnis anschließend durch eine ODER-Operation in das Register 42 eines aktualisierten Knotens 101 gesetzt wird. Das aktualisierte Register 42 spiegelt den Bedarf des Abkömmlings an Bedingungscodes 21-26 wieder. Wenn alle Abkömmlinge verarbeitet wurden, d.h. der Knoten 101 ist aktualisiert, wird er aus der Warteschlange genommen. Wenn der Knoten nicht verarbeitet wurde, wird der Befehl an das Ende der Warteschlange gesetzt. Die Warteschlange wird durchlaufen, bis sie leer ist, womit angezeigt wird, daß alle Knoten verarbeitet wurden, oder einige Knoten bleiben in der Warteschlange, womit angezeigt wird, daß sich nichts geändert hat, d.h. ein Knoten wurde nicht aktualisiert.
Ein zweiter Durchlauf erfolgt durch den Graph. In diesem Durchlauf wird das Register 43 aktualisiert, indem die Bedingungscodes reduziert werden, die gesetzt wurden, um die Codes zu bestätigen, die nun von den Abkömmimgen benötigt werden.
Am Ende der Analyse zeigt jeder Knoten 101 an, welche Bedingungscodes 21-26 gesetzt werden müssen (Register 43). Die Anzahl der Bedingungscodes 21-26 kann niedriger als die ursprünglich von diesem Befehl gesetzte Zahl sein. Der Bedingungscodesatz enthält nur die Bedingungscodes, die von nachfolgenden Befehlen benötigt werden. Der Rückkehrbefehl 128 zeigt in Register 43 an, daß er als Vorsichtsmaßnahme alle Bedingungscodes 21-26 verwenden wird, da nachfolgende Befehle bis zur Ausführung nicht bekannt sind. Der Versetzungsbefehl 127 verwendet normalerweise (Register 42) die Bedingungscodes 21-26 nicht, zeigt jedoch eine Verwendung an (Register 42), da der nachfolgende Rückkehrbefehl 128 diese benötigt. Der Addierbefehl 126 verwendet die Bedingungscodes 21-26 nicht (Register 42), setzt jedoch alle (Register 43), so daß sie im folgenden verwendet werden können. Der Schiebebefehl 125 setzt normalerweise alle Bedingungscodes 21-26 (Register 43), braucht dies in diesem Fall jedoch nicht zu tun, da der nachfolgende Addierbefehl 126 sie nicht benötigt. Es wurde bereits festgestellt, daß der Addierbefehl 126 die Bedingungscodes 21- 26 für den nachfolgenden Gebrauch setzt. Die Analyse zur Aktualisierung des Verwendungsregisters 42 und des Setzregisters 43 geht in umgekehrter Reihenfolge durch die Liste der Befehle 100 weiter, die zuvor in einer bestimmten Folge gespeichert wurden, um die Graphanalyse durchzuführen.
Aus Fig. 3D geht hervor, daß die Übersetzung 130 nur jeweils einen Befehl für den Dekrementierbefehl 124 und den Schiebebefehl 125 benötigte (Fig. 3C). Im Gegensatz dazu benötigte der Addierbefehl 126, der die Bedingungscodes 21-26 für den nachfolgenden Gebrauch setzte, sechs Befehle.
Die Graphanalyse von Fig. 3A zeigt ebenfalls, daß der Vergleichsbefehl, der alle Bedingungscodes setzt, nur zwei von sechs Bedingungscodes für nachfolgende Befehle benötigt, das vom JE-Befehl (Jump if equal) 104 verwendete Nullbit sowie das vom JB-Befehl (Jump if below) 103 verwendete Übertragbit. Die anderen Bedingungscodes werden nicht benötigt. Darüber hinaus benötigt kein Abkömmling der bedingten Verzweigungen (Fig. 3A) die anderen Bedingungscodes. Der Simulator kann daher den Block der drei Befehle 102, 103 und 104 als Einheit übersetzen, ohne sich um das Setzen der Bedingungscodes kümmern zu müssen. Somit wurde die Zahl der Befehle verringert, die die Speicherung der entsprechenden Bedingungscodes benötigen.
Indem die bekannte Kompilertechnik der Graphanalyse auf einen Prozessorsimulator angewendet wird, können wichtige Erkenntnisse über die Verwendung von Bedingungscodes von nachfolgen den Befehlen gewonnen werden. Der Codegenerator 29, der die ersten Prozessorbefehle 100 in die zweiten Prozessorbefehle 130 übersetzt, verwendet die Bedingungscodeinformationen, um in vielen Fällen einen einzigen übersetzten zweiten Prozessorbefehl zu erzeugen. Dadurch wird die Zahl unnötiger Zyklen verringert, wenn das Flag-Register nach jedem Befehl aktualisiert wurde, und die Leistung des Simulators verbessert.
Die Ergebnisse der Graphanalyse, die dazu verwendet wurden, weniger übersetzte Befehle zur Simulierung des Steuerflusses zu erhalten, knnen auch zur Verringerung einer Interrupt- Abfrage verwendet werden, wie dies in der Patentschrift EP-A 0,327 197 mit der internen Docketnummer AT9-88-003 beschrieben wird.

II. Befehlsadreßübersetzung

Der Simulator übersetzt die Befehle des iAPX 80286 Prozessors von Intel (erster Prozessor) des IBM PC AT in Simulatorbefehle des ROMP-Prozessors (zweiter Prozessor) des IBM RT PC. Die Übersetzungen werden gespeichert, um sie wiederzuverwenden, wenn das ursprünglich für den simulierten ersten Prozessor geschriebene Programm die Steuerung auf dieselbe Adresse überträgt. Bei Befehlen, die die Steuerung nicht übertragen, wird der nächste Befehlszeiger (IP) bestimmt, indem die Länge des Befehls zum Befehlszeiger (IP) des Befehls addiert wird. Eine vergleichbare Sequenz von sequentiellen Simulatorbefehlen wird vom Simulator erzeugt. Da die Befehle sequentiell folgen, ist die Lokalisierung der entsprechenden Übersetzungen nicht erforderlich.
Eine andere Befehlsklasse überträgt die Steuerung statisch. Das heißt, daß ein neuer Befehlszeiger berechnet wird, indem eine feste Verschiebung vom Befehlszeiger addiert oder subtrahiert wird. Dies wird als relative Verzweigung bezeichnet. Der Simulator erzeugt relative Verzweigungen des zweiten Prozessors zur entsprechenden Übersetzung.
Der Befehlssatz enthält drei Befehle, die die Steuerung in einem Codesegment zu einem neuen Befehlszeiger übertragen, der statisch nicht bestimmt werden kann, da er von einem Register oder Speicher in Laufzeit geladen wird. Die Rückkehr (RET) vom Subroutine-Befehl gehört zu dieser Reihe. Die Geschwindigkeit, mit der dieser Befehl simuliert wird, beeinträchtigt die Gesamtleistung des Simulators, insbesondere wenn ein Verarbeitungssystem mehr Zeit zur Ausführung eines Rückkehrbefehls als zur Ausführung anderer Befehle benötigt. Die anderen beiden Befehle sind JUMP indirekt und CALL indirekt (Register oder Speicher). Sie werden ähnlich wie der Rückkehrbefehl (RET) behandelt.
Ein erster Prozessor adressiert Befehle, indem er zwei Register verwendet. Das Codesegmentregister 33 (Fig. 3B) beschreibt den Speicherplatz eines 64 K Blocks 119 von Speicher 120 (Fig. 3C). Das Befehlszeigerregister 31 (Fig. 3B) ist ein Offset in das Codesegment 33. Der Befehlszeiger 31 legt fest, bei welchem der 64 K Byte der Befehl 100 sich befindet. Der erste Prozessor adressiert Befehle, indem in ein Codesegment 33 mit einem Befehlszeiger 31 indexiert wird (Fig. 3C).
Der Simulator verwendet die in Fig. 5 gezeigten Datenstrukturen, um erste Prozessorbefehlsadressen 100, die aus einem Codesegment 33 und einem Befehlszeiger 31 bestehen, auf die Adresse im Speicher 120 des entsprechenden zweiten Prozessors abzubilden, wo eine Folge von zweiten Prozessorbefehlen 130 dieselbe Funktion durchführen.
Ein neuer Befehlszeiger 31 und das Codesegment 33, deren Werte bei Laufzeit festgelegt werden, werden in Simulatorgeräteadressen (zweiter Prozessor) der entsprechenden Übersetzung dieser Befehle, welche die Steuerung dynamisch übertragen, umgewandelt, so z.B. die Rückkehr vom Subroutine- Befehl, JUMP indirekt und CALL indirekt, oder Software- Interrupt-Befehle.
Der Simulator geht in drei Stufen (Fig. 6) vor, um die drei Befehle, welche die Steuerung dynamisch übertragen, zu simulieren. Dieser dreistufige Ansatz läuft in Folge ab. Der schnellste und wahrscheinlichste Fall wird zuerst behandelt. Der zweite Ansatz wird angewendet, sollte der erste Ansatz nicht funktionieren. Der dritte Ansatz ist der langsamste Ansatz, der eine erfolgreiche Umwandlung des Befehlszeigers auf eine Adresse des Simulatorgeräts garantiert. In Fig. 5 sind der zweite und dritte Ansatz dargestellt.
In Fig. 6 wird als erster Schritt der neue Befehlszeiger mit dem Wert verglichen, der bei einer zuvor stattgefundenen Ausführung des Befehls erzeugt wurde (Schritt 141). Wenn die Werte übereinstimmen, wird eine relative Verzweigung des Simulatorgeräts zur entsprechenden Adresse durchgeführt. In einer exklusiven ODER-Operation wird festgestellt, ob die Werte übereinstimmen (Schritt 142), und eine bedingte Verzweigung überträgt im positiven Fall die Steuerung (Schritt 143). Dadurch kann die Suchadresse schnell berechnet werden. Wenn die Suche erfolgreich ist, werden die XIL- und BEQ-Befehle entsprechend geändert. Der von XIL einer ODER-Operation unterzogene Wert enthält den neuen Befehiszeiger, und die relative Verschiebung des Verzweigungsbefehls gibt die neue Zieladresse an. Die Steuerung wird auf das neue Ziel übertragen.
Sollte der oben beschriebene Ansatz fehlschlagen (Figuren 5 und 6), d.h. der Befehlszeiger 31 unterscheidet sich von der zuvor stattgefunden Ausführung des Befehls, wird eine Tabellensuche unter Verwendung des Umsetzpuffers 34 zur Adreßabbildungsübersetzung verwendet, der einem Hardware-Übersetzungsumsetzpuffer gleicht. Die Umwandlung von einem ersten Prozessorbefehl in einen zweiten Prozessorbefehl erfolgt mit der unten beschriebenen Methode.
Die zweiten Prozessorbefehle 130 nehmen nach der Übersetzung bestimmte Werte der ersten Prozessorregister an, die als Attribute bezeichnet werden. Die Attribute können vom Übersetzer dazu verwendet werden, effizientere Codes in bestimmten Fällen zu erzeugen. Wenn die Stapelausrichtung z.B. gerade ist, können Halbwortbefehle verwendet werden, um Daten zum und vom Stapel zu übertragen. Andernfalls müssen zweite separate Bytebefehle verwendet werden. Der Wert des Codesegements 33 und die Ausrichtung des Stapelzeigers 35 für einen Block von ersten Prozessorbefehlen 100 sind als Attribute des Blocks bekannt. Sowohl das Codesegment 33 als auch der Stapelzeiger 35 sind 16-Bit-Felder. Die Attribute treten im Codeblockkopfbereich 36 und dem Umsetzpuffer 34 zur Adreßabbildungsübersetzung auf. Die Übersetzungen 130 der ersten Prozessorbefehle 100 mit anderen Attributen werden separat gespeichert.
Bei diesem Verfahren werden die unteren 13 Bits 32 des Befehlszeigers 31 genommen und als Index für die Tabelle 34 verwendet, die an einer 64 K Byte-Grenze bei einer festen virtuellen Adresse ausgerichtet ist (Schritt 144). Die Eingabe enthält zwei Wörter. Das erste Wort enthält die Attribute. Die ersten 16 Bits CS1 45 enthalten den Wert des Codesegments 33, das nächste Bit 47 enthält die Ausrichtung des Stapelzeigers 35 (als S1 bezeichnet), das nächste Bit 46 (V1) ist ein Gültigkeitsbit, das Null ist, wenn die Eingabe nicht gültig ist, und Eins ist, wenn es sich um eine gültige Eingabe handelt. Darüber hinaus gibt es einige unbenutzte Bits 51. Die letzten 3 Bits 48 des 32 Bit-Wortes sind die oberen drei Bits 49 des Befehlszeigers 31 (IP1).
Das Verfahren besteht daher darin, die Adreßabbildungstabelle 34 mit den unteren 13 Bits 32 des Befehlszeigers 31 zu indexieren (Schritt 144), und die ersten 16 Bits CS1 45 mit dem aktuellen Wert des Codesegments 33 zu vergleichen (Schritt 145). Dadurch wird angezeigt, daß sich die Befehle im selben Codesegment befinden, womit verdeutlicht wird, daß der vorherige Befehl vor kurzem ausgeführt wurde. Stimmen die Werte überein, wird das untere Bit 41 des Stapelzeigers 35 mit S1 47 verglichen, um sicherzustellen, daß die in den Übersetzungen über die Ausrichtung des Stapels gemachten Annahmen nicht verletzt werden (Schritt 146). Wenn dies übereinstimmt und V1 46 eine gültige Eingabe anzeigt, und IP1 48 mit den oberen 3 Bits 49 des Befehlszeigers 31 übereinstimmt, ist ein Treffer in der Umsetztabelle zur Adreßabbildungsübersetzung vorhanden. Das heißt, daß der aktuelle Befehl genau mit einem früheren übersetzten zweiten Prozessorbefehl identifiziert wird. Das nächste Wort 52 ist eine 32-Bit-Adresse der zweiten Prozessorbefehle 130, die den ersten Prozessorbefehl 100 simulieren (Schritt 175). Wenn keine Übereinstimmung vorhanden ist, d.h. jeder Vergleich schlägt fehl, wird die Übersetzung mit der im dritten Ansatz unten beschriebenen Hash-Tabelle 37 fortgesetzt, und die Eingabe des Umsetzpuffers 34 zur Adreßabbildungsübersetzung wird mit den neuen Attributen und den neuen Verzweigungsadressen für künftige Referenzen aktualisiert.
Der dritte Ansatz ist ebenfalls in den Figuren 5 und 6 abgebildet. Die mittleren 6 Bits 38 des Codesegments 33 werden mit der Verkettung der unteren fünf Bits 39 des Codesegments 33 und dem unteren Bit 41 des Stapelzeigers 35 einer XODER- Operation unterzogen. Dies ergibt einen 6-Bit-Index in die Codeblock-Hash-Tabelle 37 (Schritt 148). Die Codeblock-Hash- Tabelle hat 64 Einträge. Jeder Eintrag 53 zeigt entweder auf Null, d.h. es ist kein Eintrag vorhanden und eine neue Übersetzung wird benötigt (Schritt 174), oder enthält einen Zeiger auf den Codeblockkopfbereich 36.
Jeder Codeblockkopfbereich 36 beschreibt die verfügbaren zweiten Prozessorübersetzungen für ein gegebenes Attribut. Das erste Feld 55 im Codeblockkopfbereich 36 enthält einen Zeiger auf den nächsten Codeblockkopfbereich 56, der denselben Eintrag 53 in der Codeblock-Hashtabelle 37 einem Hash-Verfahren unterzogen hat. Das nächste Feld 57 enthält die Attribute des Codeblocks. Die Attribute umfassen das Codesegment 33 im Block 58 (CS2) und die Ausrichtung des Stapelzeigers 35 im Block S2 59. Aus Gründen der Vereinfachung wird das Gültigkeitsbit V1 46 als V2 60 wiederholt. Die Codeblockkopfbereiche 36 werden nach dem Codeblockkopfbereich 36 durchsucht, der dieselben Attribute wie der bei Laufzeit ausgeführte Befehl hat (Schritt 149). Die nächsten beiden Felder 62 und 63 enthalten die minimalen und maximalen ersten Prozessoradressen, für die Übersetzungen bei diesen Attributen vorhanden sind. Das nächste Feld 64 ist ein Zeiger auf die Wurzel eines Baums, der alle Codebl-cke 83 beschreibt, für die Übersetzungen eines spezifischen Attributs vorhanden sind.
Jeder Knoten des Baums, z.B. Codeblock 83, enthält die minimalen und maximalen Befehlszeiger 65 und 66, für die eine zweite Prozessorübersetzung 130 im Bereich der ersten Prozessorbefehlszeiger 31 vorhanden ist. Es ist ein Zeiger zum linken und rechten Sohn, 67 bzw. 68, vorhanden. Der linke Sohn 67 zeigt auf einen Unterbaum 69 mit niedrigeren oder gleichen minimalen Befehlszeigern 31. Der rechte Sohn 68 zeigt auf einen Unterbaum 70 mit größeren minimalen Befehlszeigern 31. Die Knoten des Baums werden abgesucht, um einen Unterbaum mit einem Befehlsadreßbereich zu finden, in den die aktuelle Befehlsadresse fällt (Schritt 151). Das nächste Feld 71 ist ein Zeiger auf das Ende 73 des Codeblocks 83 der zweiten Prozessorübersetzungen 130.
Es gibt ein Feld 44 mit so vielen Einträgen 72 wie im Bereich der Befehlszeiger 31 vorhanden sind, z.B. die untere Grenze des Feldes 44 ist der minimale Befehiszeiger, und die obere Grenze des Feldes 44 ist der maximale Befehlszeiger. Jeder Eintrag im Feld 44 enthält entweder 0, um einen ersten Prozessorbefehl 100 anzuzeigen, für den es keine zweite Prozessorübersetzung gibt, oder einen Zeiger, wenn dieser mit einem gültigen Eintragspunkt des ersten Prozessorbefehls übereinstimmt. Jeder Eintrag im Feld 44 ist ein Halbwort. Wenn ein gültiger Eintrag vorhanden ist, enthält dieser die Verschiebung vom Anfang des Feldes 44 zum entsprechenden Eintragspunkt für den bestimmten Befehlszeiger (Schritt 173).
Zusammenfassend läßt sich sagen, daß die Tabellensuche in dem unwahrscheinlichen Fall versagt, daß zwei Befehlszeiger denselben Eintrag in der Tabelle einem Hash-Verfahren unterziehen, oder wenn dies das erste Mal ist, daß das Anwendungsprogramm die Steuerung diesem Befehlszeiger überträgt. In jedem Fall greift der Simulator auflangsamere Datenstrukturen zu, z.B. dem Binärbaum 83, um die Adresse umzuwandeln. Wenn dies nicht gefunden wird, wird der Übersetzer 27 aufgerufen, um äquivalente Befehle des Simulatorgeräts (zweiter Prozessor) für den neuen Block erster Prozessorbefehle zu erzeugen (Schritt 74), und der Übersetzungsumsetzpuffer 34 sowie der Codeblock 83 werden aktualisiert.

III. Speicherabbildung

Der Speicher eines Verarbeitungssystems 1 kann in Typ und Inhalt klassifiziert werden (siehe Fig. 7). Der Bereich I ist der Direktzugriffsspeicher (RAM) 152. Im RAM 152 befinden sich Befehle und Daten. Die CPU 93 kann in diesen Speicherbereich lesen und schreiben.
Der zweite Speicherbereich wird als Adapterspeicher (Video) 153 bezeichnet. Die CPU kann explizite INIUT-Befehle verwenden, um auf den I/O-Adapter 91, der mit dem Ausgabegerät-92, z.B. einer Anzeige verbunden ist, zuzugreifen (siehe Linie 167), oder die CPU 93 kann die Speicherbefehle verwenden, um über einen Videopuffer 153 auf den I/O-Adapter zuzugreifen. Die Verwendung von Speicherbefehlen für einen Videopuffer 153 zur Ausgabe auf einer Einheit 92 wird als speicherabgebildete I/O bezeichnet, da tatsächlich die I/O zu einem Adapter gehen, wenn auch über eine Speicherstelle. Die speicherabgebildeten I/O ermöglicht es, einen größeren Bereich von Befehlen zu verwenden, da die CPU mehr Befehle hat, welche zum Speicher gehen, als explizite I/O (IN/OUT-Befehle) auszuführen. Der Inhalt des Videospeicherbereichs sind Ausgabedaten, z.B. speicherabgebildete I/O.
Der dritte Speichertyp ist der Bereich III, der als Festwertspeicher (ROS, read only storage) 154, in anderem Zusammenhang auch als ROM, bezeichnet wird. Im ROS 154 befinden sich zumeist Befehle, obgleich auch Daten darin gespeichert werden können. In jedem Fall wird der Inhalt des ROS nicht geändert.
Der Adreßbereich 150 eines Verarbeitungssystems, z.B. der IBM PC AT, ist logisch in diese drei Bereiche aufgeteilt. Der erste Bereich ist ein 640 K Byte-Bereich des Prozessor- Lese/Schreibspeichers, z.B. RAM 152. Der zweite Bereich ist ein 256 K Byte-Bereich für die I/O-Adapter, z.B. Video 153. Diese Speicher enthalten Datenpuffer für Einrichtungen und einrichtungsabhängige ROS. Der dritte Bereich ist ein 128 K Byte-Bereich des Prozessor-ROS 154. Der ROS enthält das BIOS und Basic. Es ist über dem 1 M-Bereich 166 noch Speicher vorhanden, der nach dem BIOS-Bereich 155 kommt. Da der Simulator des bevorzugten Ausführungsbeispiels den 286 geschützten Modus nicht unterstützt, steht der Bereich 176 des Speichers 150 nicht zur Verfügung.
Um die Adressen eines ersten Verarbeitungssystems in die Adressen eines zweiten Verarbeitungssystems zu übersetzen, muß der Speicher des ersten Verarbeitungssystems in den Speicher des zweiten Verarbeitungssystems abgebildet werden.
Um den Speicher abzubilden, werden zwei gemeinsam benutzte Speichersegmente 190 und 180 (Fig. 8) des Betriebssystems des zweiten Verarbeitungssystems verwendet. Das erste gemeinsam benutzte Speichersegment 190 wird dazu verwendet, ein Bild 150 des Speichers des ersten Verarbeitungssystems zu speichern. Das zweite gemeinsam benutzte Speichersegment 180 zeigt für jede Speicherstelle die in diesem Bild enthaltene Art des Inhalts an.
Im Speicher 190 des zweiten Verarbeitungssystems sind die 640 K Byte des Speichers 152 vorhanden, der sich im ersten Verarbeitungssystem befinden würde, sowie ein Videobereich 153, ein Bereich 154 für den ROS (read only storage, Festwertspeicher) und ein Bereich 155 für das BIOS. Vor dem ersten Speichersegment 152 wird der BIOS-Bereich 155 dupliziert. Dies dient zur Vereinfachung der Abbildung in dem Fall, wo eine Anwendung ein Seqmentregister in den ROM-Bereich 155 des Speichers 150 laden könnte, so daß die Verschiebung den RAM 152 umschließt. Die hexadezimalen Adressen 172-175 dieser Bereiche werden in das gemeinsam benutzte Speichersegment 190 (als Segment 0x9 gekennzeichnet) durch die 64 K der Adresse der Bereiche im Speicher 150 des ersten Verarbeitungssystems verschoben.
Als Ergebnis enthält ein virtuelles Speichersegment im Verarbeitungssystem, auf dem der Simulator läuft, ein Bild aller Prozessorspeicher des PC AT, die aus einem Bereich 1 152 und zwei Kopien des Bereichs 3 154 bestehen. Bereich 2 153 ist nicht vorhanden, wenn die Ausgabeeinrichtungen des ersten Verarbeitungssystems mit dem zweiten Verarbeitungssystem verbunden werden. Wenn die Ausgabeeinrichtungen des ersten Verarbeitungssystems nicht verbunden sind, existiert ein Bild des Bereichs 2 153 ebenfalls.
Die Adreßspeicherstellen 172-176 im Speichersegment 190 sind die Speicherstelle des eigentlichen Speicherbildes des ersten Verarbeitungssystems. Dieser Bereich 172-176 sieht wie die Architektur des simulierten ersten Verarbeitungssystems und des verfügbaren Speichers aus.
Zusätzlich zum Speicherbild 172-176 wird der übersetzte Code 130 im Bereich 157 gespeichert. Nachdem die übersetzten Befehle durch die Graphanalyse 30 (Figuren 3A, 38, 3C, 3D), die die Befehle 100 des ersten simulierten Verarbeitungssystems geprüft hat, erzeugt wurden, werden die übersetzten Befehle 130 im Bereich 157 gespeichert.
Der nächste Bereich 158 des gemeinsam benutzten Speichersegments 190 ist ein Interprozeßkommunikationsbereich und Laufzeitumgebungsbereich, wo in Laufzeit aufgerufene Routinen gespeichert werden.
Zusätzlich zum virtuellen gemeinsam benutzten Speichersegment 190 (als Segment 0x9 bezeichnet) reserviert das Verarbeitungssystem, auf dem der Simulator läuft, ein spezielles Segment für den I/O-Busspeicher, das als Segment 0xF 181 bezeichnet wird. Daten werden in das Segment OxF des zweiten Verarbeitungssystems geschrieben, wenn die Ausgabeeinrichtung des ersten Verarbeitungssystems an das zweite Verarbeitungssystem angeschlossen ist. Eine Adreßspeicherstelle des ersten Verarbeitungssystems, die im Bereich II, 153, liegt, hat eine entsprechende Speicherstelle in Segment 0x9, 190, oder im Segment 0xF, 181, des zweiten Verarbeitungssystems.
Der Simulator verwendet eine Verschiebetabelle 195, um den Speicher 150 des ersten Verarbeitungssystems entweder in Segment 0x9, 190, oder Segment 0xF, 181, des zweiten Verarbeitungssystems abzubilden. Ein erstes Verarbeitungssystem, z.B. der PC AT, adressiert Speicherstellen durch zwei Komponenten, einem Segment und einer Verschiebung. Im PC AT ist das Segment ein 16-Bit-Wert, der auf einen 64 K Speicherblock zeigt. Die Verschiebung beträgt ebenfalls 16 Bits und zeigt die Verschiebung innerhalb des Segments an. Die Adresse des Segments wird berechnet, indem der Segmentwert mit 16 multipliziert wird.
Der Simulator verwendet eine Tabelle 195 mit 16 Einträgen 201- 216 mit jeweils 32 Bits, um die Speicheradresse eines PC AT in die 32- Bit-Speicheradresse eines IBM RT PC abzubilden. Die oberen 4 Bits eines Segments einer PC AT Speicheradresse identifizieren einen der 16 Einträge der Tabelle. Die Simulator unterteilt die Speicheradressierungsberechnung in zwei Teile. Wenn das Segmentregister geladen wird, multipliziert der Simulator zuerst das Segment mit 16 und addiert es zum Eintrag in der Tabelle, die durch die oberen 4 Bits des Segments spezifiziert wird. Wenn ein Befehl einen Lese- oder Schreibvorgang im Speicher ausführt, wird die 16-Bit-Verschiebung zum im vorherigen Schritt berechneten 32-Bit-Wert hinzugezählt. Dies ist die Adresse, die zum Zugriff auf den Speicher des zweiten Verarbeitungssystems verwendet wird.
Beim Start des Simulators wird die Verschiebetabelle 195 initialisiert. Die ersten 10 Einträge 201-210 entsprechen dem RAM 152 und werden auf 0x90010000 initialisiert, um auf Segment 0x9 des zweiten Verarbeitungssystems zu zeigen. Dieser Initialisierungswert enthält eine 64 K Verschiebung, die Platz schafft für die Abbildung des BIOS 155 auf Segment 0x9, 190, vor dem RAM 152. Der letzte Eintrag 216, der dem Seqment entspricht, das das BIOS 155 adressiert, wird mit 0x90000000 - 0xFOOOO oder 0xBFF10000 initialisiert. Wenn das mit 16 multiplizierte Segment auf diese Art und Weise addiert wird, ist der sich ergebende Wert 0x90000000, der das BIOS 155 am Beginn des Segments 0x9, 190, abbildet. Der 11. bis 15. Eintrag 211- 215 wird mit 0xF4000000 oder 0x90010000 initialisiert, um entweder auf Segment 0xF, 181, oder Segment 0x9, 190, zu zeigen, je nachdem, ob die entsprechende Ausgabeeinrichtung an das erste Verarbeitungssystem angeschlossen ist.
Das Statussteuersegment, Segment 0x8, 180, ist in einem anderen gemeinsam benutzten Speichersegment des Betriebssystems gespeichert. Das Statussteuersegment 180 verfolgt die Art des Speicherinhalts des ersten Verarbeitungssystems für das Segment 0x9, 190. Mit Hilfe dieser Informationen bestimmt der Simulator, ob die Speicherstelle Daten oder einen Befehlscode enthält, oder ein Videoeintrag ist.
In der obigen Beschreibung wurde dargestellt, wie der Simulator die Adresse berechnet, die bei der Simulierung eines Befehls, der Lese- und Schreibvorgänge im Speicher durchführt, verwendet werden sollte. Beim Schreiben in den Speicher sind spezielle Maßnahmen erforderlich.
Wenn ein Befehl im Speicher gespeichert wurde, merkt sich der Simulator, ob der Befehl übersetzt wurde. Eine Prüfung auf Befehlsänderung wird durchgeführt, um sicherzustellen, daß der übersetzte Code immer korrekt ist. Wenn eine Anwendung Befehlsänderungen durchführt, wird der übersetzte Code für den ursprünglichen Codebefehl bereinigt, und der neue Befehl wird auf eine neue Befehisfolge des Simulatorprozessors übersetzt. Andere Schritte können durchgeführt werden, um sicherzustellen, daß die korrekte Übersetzung des Befehis ausgeführt wird.
Die Prüfung auf Videoaktualisierungen ist ebenfalls notwendig, um festzulegen, ob die Ausgabe an die Ausgabeeinrichtung weiterhin vom Simulator verarbeitet werden muß. Dies wäre dann der Fall, wenn die Ausgabeeinrichtung des ersten Verarbeitungssystems nicht mit dem zweiten Verarbeitungssystem, auf dem der Simulator läuft, verbunden ist, und die Ausgabeeinrichtung des ersten Verarbeitungssystems daher simuliert werden muß. Bei den speicherabgebildeten I/O muß beim Speichern festgestellt werden, ob die spezielle Hardware, die die Ausgabedaten darstellt, geändert wurde.
Beim Speichern wird das Segment 0x8, 180, verwendet, um festzulegen, ob eine spezielle Maßnahme bei einem Befehl oder speicherabgebildeten I/O erforderlich ist. Segment 0x8, 180, stimmt auf Bytebasis mit dem Segmentregister 0x9, 190, überein. Jedes Byte im segment 0x8 zeigt die Art des Inhalts des entsprechenden Bytes im Segment 0x9, 190, an. Ein Byte im Segment 0x8, 180, hat eine Null, wenn das entsprechende Byte im Segment 0x9, 190, eine Berechnungsdateneinheit ist. Das Byte im Segment 0x8, 180, hat entweder eine 1, 2, 4 oder 6, wenn das entsprechende Byte im Segment 0x9 einen Befehl enthält. Jedes Byte von Segment 0x8, 180, das dem Videobereich 153 des Segments 0x9 entspricht, enthält eine 16, wenn eine Ausgabeeinrichtung des ersten Verarbeitungssystems nicht angeschlossen ist. Der Wert 16 wird in das Segment 0x8, 180, beim Start des Simulators während der Konfiguration geladen.
Wenn während der Konfiguration festgelegt wird, daß eine Ausgabeeinrichtung eines ersten Verarbeitungssystems an ein zweites Verarbeitungssystem angeschlossen ist, sind die entsprechenden Bytes des Segments 0x8, 180, Null. Das zeigt an, daß die Verschiebetabelle 195, deren Einträge 211-215 ebenfalls während der Konfiguration initialisiert wurden, Ausgabedaten vom ersten Verarbeitungssystem auf das Segment 0xF, 181, abbildet, womit keine weitere Aktion vom Simulator notwendig ist, da eine Ausgabeeinrichtung des ersten Verarbeitungssystems angeschlossen ist.
Unabhängig von der Speicherstelle im Speicher, entweder das Segment 0x9 oder das Segment 0xF, wird der 32-Bit-Wert der Adresse mit 0x80FFFFF addiert, so daß sich die entsprechende Adresse von Segment 0x8, 180, ergibt.
Dieselbe Befehisfolge wird bei jeder Übersetzung eines ersten Verarbeitungssystembefehls verwendet, der den Speicher ändern kann. Die Segmentregister wurden so ausgewählt, daß die Adresse des Statusbytes durch die Addierung der Adresse des Speicherbytes mit 0x80FFFFF berechnet werden kann. Als Ergebnis werden beide Segmente 0xF und 0x9 auf Segment 0x8 abgebildet. Wenn die vier Befehle von Fig. 10 mit den zur Simulierung des ersten Verarbeitungssystembefehls verwendeten Befehle überlappen, werden nur 5 Zyklen zur Prüfung der Speicheraktualisierung benötigt, um festzustellen, ob eine spezielle Verarbeitung notwendig ist. Unter Umständen muß jedoch festgestellt werden, ob die Speicheradresse für Segment 0xF bestimmt war, um zu sehen, ob nach der Speicherung eine spezielle Maßnahme erforderlich ist.
Indem ein Statusbyte, das jedem Byte im Speicherbild 190 oder dem speicherabgebildeten I/O 181 entspricht, gespeichert wird, k:nnen Videoaktualisierungen, speicherabgebildete I/O und Befehlsänderungen festgestellt werden. Ein Flag im Statussegment 8, 180, wird gespeichert, um die Art des Speicherinhalts wie folgt anzuzeigen:
0 = Daten
1 = Befehlseintragspunkt
2 = nachfolgendes Byte eines Befehls
4 = gemischter Befehl (erstes Byte kein gültiger Eintragspunkt)
8 = Haltepunkt bei diesem Befehl gesetzt
16 = Video
Aus der Beschreibung oben geht hervor, daß bei einem Nicht- Nullwert weitere Maßnahmen des Simulators erforderlich sind. Eine "1" zeigt an, daß es sich um einen Eintragspunkt handelt, und daß eine Übersetzung des ersten Verarbeitungssystembefehls im Binärbaum vorhanden ist. Eine "2" bedeutet, daß ein Byte nachfolgt, d.h. daß ein erster Prozessorbefehl simuliert oder übersetzt wird, der länger als ein Byte ist. Das Byte entspricht dem nachfolgenden Byte. Daraus ergibt sich, daß mehr als ein Byte benötigt wird, um einen ersten Prozessorbefehl darzustellen. Ein Flag "4" zeigt an, daß ein Mischvorgang stattgefunden hat. Ein Mischvorgang bedeutet, daß als Ergebnis einer Graphanalyse festgelegt wurde, daß weniger übersetzte Simulatorbefehle benötigt werden, um mehrere kombinierte erste Prozessorbefehle zu simulieren, als für die separate Übersetzung jedes ersten Prozessorbefehls benötigt würden. Der PUSH-Befehl 105 und der POP-Befehl 106 von Fig. 3A wurden beispielsweise gemischt. Als Ergebnis wurde der Wert im CS- Register in das DS-Register verschoben. Da die Graphanalyse ergibt, daß dies alles ist, was die beiden Befehle 105 und 106 machen, können die beiden Befehle zu einem zusammengefaßt werden und somit schneller als zwei separate Befehle ausgeführt werden.
Ein Flag "8" zeigt an, daß ein Haltepunkt gesetzt wurde. Dadurch können Debugger auf dem Simulator verwendet werden. Ein Flag 16 zeigt an, daß es sich bei den Informationen um Videodaten handelt. Dadurch stellt der Simulator fest, daß eine Anwendung durchgeführt wird und den Videobildschirm aktualisiert hat.
Das oben beschriebene Verfahren erhöht die Leistung gegenüber vorherigen Simulatoren, die Verzweigung zu einer Subroutine benötigten, welche eine umfangreiche, zeitintensive Prüfung durchführte, die Speicheraktualisierung verarbeitete und zurückkehrte. Nur eine Verzweigung zu einer Subroutine benötigt normalerweise mindestens 5 Zyklen. Dies wird anhand der Tatsache verdeutlicht, daß das Speichern ein häufiger Vorgang ist. Eine Verringerung des Speicheraufwands erhöht die Effizienz des Simulators daher erheblich.

Claims

1. Ein Verfahren zur Reduzierung der Anzahl von übersetzten Befehlen, die zur Simulierung eines ersten Prozessors mit einem ersten Befehlssatz durch einen zweiten Prozessor mit einem zweiten Befehlssatz benötigt werden, wenn eine Anwendung für den ersten Befehlssatz vom zweiten Prozessor durchgeführt wird, wobei das Verfahren die Umwandlung eines Befehlszeigers (31) eines nächsten Befehls des ersten Prozessors bei Laufzeit beinhaltet, der sich aus einem dynamischen Steuerbefehl ergibt, in eine Adresse für die zweite Prozessorübersetzung des nächsten Befehis des ersten Prozessors;

wobei das Verfahren dadurch gekennzeichnet ist, daß verschiedene Schritte zur Durchführung der Umwandlung kombiniert werden, die jeweils folgendes beinhalten:

in einem ersten Schritt

ein neuer Befehlszeiger (31) des nächsten Befehls des ersten Prozessors unter Verwendung eines zweiten Prozessorbefehls mit einem vorherigen Befehlszeiger eines vorherigen dynamischen Steuerbefehls, welcher für den zweiten Prozessor übersetzt wurde, bei Laufzeit verglichen wird (141), wobei der Vergleichsschritt (142, 143) eine Adresse für eine zweite Prozessorübersetzung für den nächsten Befehl des ersten Prozessors festlegt, wenn der neue Befehlszeiger (31) zur selben Adresse wie der vorherige Befehlszeiger zurückkehrt; und

eine Verzweigung (143) zur Adresse der zweiten Prozessorübersetzung des nächsten Befehls, wenn der neue Befehlszeiger (31) mit dem vorherigen Befehlszeiger übereinstimmt;

in einem zweiten Schritt

die Anwendung (144) eines Übersetzungsumsetzpuffers (34) mit einer begrenzten Anzahl von ersten Prozessorbefehlszeigern und entsprechenden zweiten Prozessorübersetzungsadressen, um die Übersetzungsadresse des nächsten Befehls festzulegen (145, 146, 175), wenn der dynamische Steuerbefehl zur selben Adresse zurückkehrt, zu der mindestens einmal zurückgekehrt wurde; und

in einem dritten Schritt

das Suchen (149, 171, 151) in einer verbundenen Datenstruktur (37) mit mehr zweiten Prozessorübersetzungsadressen als im Umsetzpuffer, um die Übersetzungsadresse des nächsten Befehls festzulegen (172), wenn der dynamische Steuerbefehl zu einer neuen Adresse zurückkehrt, zu der zuvor noch nicht zurückkehrt wurde.

2. Ein Verfahren nach Anspruch 1, bei dem die verbundene Datenstruktur (37) zahlreiche Knoten enthält, die jeweils einen Block zweiter Befehle umfassen, welche von zahlreichen ersten Befehlen des ersten Befehlssatz übersetzt wurden, sowie eine Entsprechung zwischen einer ersten Befehlsadresse und einer zweiten Befehlsadresse.