-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung betrifft im Allgemeinen Computer und insbesondere
die Emulation von Software beziehungsweise die Ausführung von Interpreter-Software.
-
Hintergrund
der Erfindung
-
In
der Computerindustrie liegt momentan ein Schwerpunkt auf Emulationstechnologien
und der Ausführung
von Interpretercomputersprachen, um die Ausführung von Software auf vielen
unterschiedlichen Hardwareplattformen zu ermöglichen. Der Vorteil der Verwendung
von Emulation und der Ausführung
von Interpretersprachen liegt darin, dass wenn die Software für die Ausführung auf
einer einzelnen Hardwareplattform geschrieben ist, kann die gleiche Software
auf andere Hardwareplattformen ohne großen zusätzlichen Aufwand portiert werden.
Die Emulationen und die Ausführung von
Interpretersprachen benötigt
jedoch eine zusätzliche
Softwareschicht zwischen dem ausführbaren Softwarecode des Benutzers
und der physikalischen Hardware, um eine Hardwareunabhängigkeit
des Softwarecodes des Benutzers zu erreichen. Diese zusätzliche
Softwareschicht ist ein Emulationsoverhead, der üblicherweise in anderen Computersystemen
nicht vorhanden ist, in denen Software direkt für eine spezielle Hardwareplattform
kompiliert wird und direkt auf dieser Hardwareplattform ausgeführt wird.
Obwohl die zusätzliche
Softwareschicht bei der Emulation zu einer größeren Kompatibilität führt, unabhängig von
Hardwarefeinheiten, kann sich eine langsamere Ausführung der
Benutzersoftware ergeben.
-
Ein
Ziel in der Computerindustrie liegt darin, den Leistungseinfluss
dieser zusätzlichen
Softwareschicht zu reduzieren, um dadurch die Ausführungsgeschwindigkeit
verschiedener Emulatoren oder Maschinen für Interpretersprachen (z. B.
Java, Smalltalk und BASIC) zu erhöhen. Um den Emulationsoverhead
zu reduzieren, wird in der Industrie versucht, kundenspezifische
Hardware herzustellen und die Softwarezwischenschicht zu vereinfachen,
wodurch die Leistung verbessert wird. Demnach bedarf es einer neuen
Emulationsabruf- und -decodierroutine mit reduziertem Overhead,
wodurch die Emulations-/Interpretationsleistung verbessert wird.
-
Die
US-A-5 619 666 beschreibt ein System und ein Verfahren zum Extrahieren
komplexer Computeranweisungen mit variabler Länge aus einem Strom komplexer
Anweisungen. Jede komplexe Anweisung ist in eine variable Anzahl
an Anweisungsbytes unterteilt und richtet die Anweisungsbytes einiger einzelner
der komplexen Anweisung aus.
-
"Hardware Realization
of a Java Virtual Machine For High Performance Multimedia Applications", Berekovic et al.,
IEEE Workshop on Signal Processing Systems, November 1997, Seiten
479–488, beschreibt
eine Architektur für
inhaltsbasierte Multimedia-Anwendungen. Eine Hardwareimplementierung
einer virtuellen Javamaschine ermöglicht eine direkte Ausführung von
Javabytecodes, in dem in einem einzelnen Taktzyklus bis zu drei
Bytecodeanweisungen parallel decodiert und ausgeführt werden können.
-
Die
US-A-3 982 229 beschreibt eine logische Anordnung zur Verwendung
in einem Datenprozessor, der selektiv eine Mehrzahl von Bitmanipulationen oder
logischer Operationen durchführt,
einschließlich Verschieben,
Rotieren und Einfügen
unter Maske ("insert
under mask"). Die
Anordnung wird durch ein einzelnes Anweisungsformat gesteuert, das
die Parameter spezifiziert, die für jede der Operationen benötigt werden.
-
Die
EP-A-0 762 270 beschreibt, dass eine Mehrfachladeanweisung in einem
superskalaren Mikroprozessor dadurch ausgeführt werden kann, dass eine
Mehrfachladeanweisung an eine Lade-/Speichereinheit befördert wird.
Die Lade-/Speichereinheit beginnt
die Ausführung
einer beförderten
Mehrfachladeeinheit und die Mehrfachladeeinheit lädt Daten vom
Speicher in eine Mehrzahl von Registern.
-
Zusammenfassung
der Erfindung
-
Gemäß einem
ersten Aspekt stellt die vorliegende Erfindung einen Prozessor zur
Verfügung,
der zur Ausführung
einer Multifunktionsanweisung ausgelegt ist, wie in Anspruch 1 beansprucht.
-
Weitere
Aspekte werden in den abhängigen Ansprüchen beansprucht.
-
Kurze Beschreibung
der Zeichnungen
-
Die
Eigenschaften und Vorteile der vorliegenden Erfindung werden aus
der folgenden detaillierten Beschreibung klarer verständlich,
die im Zusammenhang mit den begleitenden Figuren zu sehen ist, in
denen sich ähnliche
Bezugszeichen auf ähnliche
und entsprechende Teile beziehen.
-
1 veranschaulicht
in einem Blockdiagramm eine Emulatorsoftwarearchitektur zur Verwendung
gemäß der vorliegenden
Erfindung;
-
2 veranschaulicht
in einem Blockdiagramm den spezifischen Softwareanweisungsinhalt des
Softwareemulators der 1, wobei dieser Softwareinhalt
im Stand der Technik bekannt ist und einen großen Anteil an Emulationsoverhead
aufweist;
-
3 veranschaulicht
in einem Blockdiagramm einen verbesserten Softwareanweisungsinhalt,
der verwendet werden kann, um den Softwareemulator der 1 mit
einem reduzierten Emulationsoverhead gemäß der vorliegenden Erfindung
zu implementieren;
-
4 veranschaulicht
in einem Blockdiagramm ein Verfahren zum Erzeugen der Vektoradresse
einer Softwareanweisungsemulationsroutinik gemäß der vorliegenden Erfindung;
-
5 veranschaulicht
in einem Blockdiagramm einen verbesserten Softwareanweisungsinhalt,
der verwendet werden kann, um den Softwareemulator der 1 mit
einem verrin gerten Emulationsoverhead gemäß der vorliegenden Erfindung
zu implementieren;
-
6 veranschaulicht
in einem Blockdiagramm einen verbesserten Softwareanweisungsinhalt,
der dazu verwendet werden kann, den Softwareemulator der 1 mit
einem verringerten Emulationsoverhead gemäß der vorliegenden Erfindung zu
implementieren;
-
7 veranschaulicht
in einem Blockdiagramm spezielle Hardware zum Implementieren der in 6 veranschaulichten
Software gemäß der vorliegenden
Erfindung;
-
8 ist
ein Blockdiagramm, das einen Mehrzweckcomputer ("general purpose computer"), veranschaulicht,
der die in 7 gezeigte spezifische Hardware
umfasst.
-
Es
sollte klar sein, dass aus Gründen
der Einfachheit und Klarheit der Darstellung in den Zeichnungen
dargestellte Elemente nicht notwendigerweise maßstabsgetreu gezeichnet sind.
Beispielsweise sind die Abmessungen einiger Elemente relativ zu anderen
Elementen aus Gründen
der Klarheit übertrieben.
Des weiteren wurden, wo es für
geeignet erschien, Bezugszeichen innerhalb der Zeichnungen wiederholt,
um einander entsprechende oder analoge Elemente anzuzeigen.
-
Detaillierte
Beschreibung
-
Im
Allgemeinen ist die vorliegende Erfindung ein Verfahren und eine
Vorrichtung zum Reduzieren des Abruf- und Decodieremulatoroverheads
sowie des Opcode-emulierten Ausführungsoverheads
für ein
Emulatorsystem. Das hier gelehrte System kann zur Durchführung einer
beliebigen Emulation beziehungsweise einer Ausführung von Interpretersprache ver wendet
werden, um die Emulation einer beliebigen Computersprache oder die
Ausführung
beispielsweise von Java-, Smalltalk- oder BASIC-Computercode zu
ermöglichen.
Insbesondere wird hier eine neue Computeranweisung verwendet, wobei
die neue Computeranweisung Anweisungsoperanden verarbeitet, um eine
Mehrzahl von Ergebnissen zu erzeugen, die in mehreren Registern
gespeichert werden, wobei jedes Register das Ergebnis in einem unterschiedlichen
Datenformat enthält.
Da diese Anweisung (hierin mit LGMDT abgekürzt) das Ergebnis in verschiedenen
Registern unter Verwendung verschiedener Formate oder durch das
Vorverarbeiten hinsichtlich des Ergebnisses zur Verfügung stellt, kann
die Anzahl an Opcodeemulationsanweisungen, die in den Emulatorroutinen
benötigt
werden, reduziert werden, wodurch die Emulation oder die Ausführung der
Interpretersprache mit einer schnelleren Rate erfolgt. Zusätzlich wird
aufgrund dieser LGMDT-Anweisung der Abruf- und Decodieremulationsoverhead,
der für
jede emulierte Anweisung in dem System ausgeführt wird, auch reduziert, wobei die
Emulationsleistung weiterhin verbessert wird. Experimentelle Ergebnisse
haben gezeigt, dass die Verbesserung, die jemand durch die hierin
gelehrten Verfahren erhält,
größer oder
gleich 10 ist.
-
Die
Erfindung kann weiterhin unter Bezugnahme auf die 1-8 verstanden
werden. Die 1 veranschaulicht ein Blockdiagramm
eines Emulatorsystem 10, das dazu verwendet wird, eine Emulation
oder die Ausführung
einer Interpretersprache gemäß der vorliegenden
Erfindung durchzuführen.
-
Das
Emulationssystem 10 umfasst einige Abschnitte/Routinen,
wobei jede eine oder mehrere Softwareanweisungen um fasst. Die 1 veranschaulicht,
dass ein derartiger Abschnitt/eine derartige Routine der Einstellungscode 11 ist,
wobei der Einstellungscode 11 Computeranweisungen umfasst,
die Register initialisieren, um eine korrekte Softwareemulation
zu ermöglichen.
Das Emulationssystem 10 umfasst auch eine Abruf- und- Decodierschleife 12,
die Vektoranweisungs-Emulationsopcodes
und Operandendaten aus dem Speicher 124 (siehe 8)
abruft und korrekte Decodieroperationen auf die Anweisungen hin
durchführt,
um zu bestimmten, welche Vektoremulationsroutine ausgeführt werden
soll. Das von der Routine 12 durchgeführte "Decodier-"Verarbeiten bedingt die Erzeugung einer
Tabellenvektoradresse, die den Emulationssoftware-Ausführungsablauf
zu einer oder mehrerer Emulationsroutinen innerhalb einer Tabelle 14 leitet.
-
1 veranschaulicht
eine Mehrzahl von Vektoremulationsroutinen innerhalb einer Nachschlagetabelle 14.
Direkte Emulationsroutinen in 1 veranschaulichen
insbesondere fünf
Emulationsroutinen 16–24.
Dies ist jedoch lediglich beispielhaft, es kann eine beliebige Anzahl
an Emulationsroutinen verwendet werden. Jede Routine 16–24 in 1 umfasst
sechzehn 32-Bit-Wörter
mit Informationen. Demnach beginnt eine erste Emulationsroutine
an einer Adresse, die als TABLEBASE in 1 bezeichnet
wird, und endet an einer Adresse TABLEBASE+63, bei einer Verwendung
einer Adressierung auf Byte-Ebene. Eine zweite Emulationsroutine
beginnt mit einer Adresse, die in 1 als TABLEBASE+64 bezeichnet
ist und endet 64 Bytes (d. h. 16 Wörter) weiter im Speicherarray.
Wenn 64 Bytes nicht genug Platz zum Emulieren einer bestimmten Anweisung sind,
muss eine Verzweigung oder eine Sprunganweisung an dem Ende des
Blocks in Tabelle 14 verwendet werden, um zu einer anderen Stelle
außerhalb
der Tabelle 14 zu verzweigen/zu springen, um die Emulation
dieser bestimmten Anweisung abzuschließen. Bei jeder Emulationsroutine
(üblicherweise
gibt es eine Routine für
jede emulierte Anweisung) 64 Bytes (d. h. 16 Wörter) als Platz zugewiesen
sind, in denen eine Emulationsroutine gespeichert werden kann, beginnt
jede Emulationsroutine an einem Adresswert, der ein Vielfaches von
64 von der Adresse TABLEBASE ist. Es sei bemerkt, dass auch andere
Größen für die Tabelleneinträge als 64
Bytes verwendet werden können.
-
1 veranschaulicht
eine Nicht-Operations-Routine (NOP), die an der Adresse TABLEADDRESS
beginnt und an der Adresse TABLEADDRESS+63 endet. Es muss nicht
der gesamte Tabellenplatz, der für
eine Routine zur Verfügung
gestellt ist, von der jeweiligen Routine verwendet werden, wobei
etwas verschwendeter Platz leicht toleriert werden kann. 1 veranschaulicht
eine Byteganzzahlablegeroutine ("BIPUSH
= Bite Integer PUSH Routine")
für eine
BIPUSH-Anweisung. Die BIPUSH-Routine befindet sich an der Adresse
TABLEBASE+64×N.
Die BIPUSH-Routine 20 umfasst Computeranweisungen, die
ein Byteganzzahlablegen während
einer Emulation durchführen.
Eine Emulation-POP-Routine 22 in 1 beginnt
an einer Adresse TABLEBASE+64×M
und umfasst Computeranweisungen, die dazu verwendet werden, ein
oberstes Wort von einem Operandenstapel im Speicher zu holen (POP).
Eine letzte Emulationsroutine 24 ist in 1 veranschaulicht
und beginnt an einer Adresse TABLEBASE+64×255. Mit anderen Worten veranschaulicht 1 insbesondere,
dass es 28 = 256 Routinen innerhalb der Tabelle 14 in 1 gibt.
In dieser Ausführungsform
mit 256 Routinen kann ein einzelnes Opcodebite, wie es in Java verwendet
wird, ein deutig eine beliebige der 256 Routinen in 1 adressieren.
Es sei bemerkt, dass eine beliebige Anzahl an Routinen verwendet
werden kann, wobei die Emulation von etwa Java, Pentium-Code, BASIC, Smalltalk,
etc. unter Verwendung des hierin gelehrten Verfahrens durchgeführt werden
kann.
-
2 veranschaulicht
einen spezifischen Softwarecode, der dazu verwendet wird, verschiedene
ausgehende in 1 veranschaulichte Funktionen
zu implementieren. Beispielsweise veranschaulicht 2 (eine)
spezifische Instruktion(en), die dazu verwendet wird/werden, um
den Einstellungscode 11 der 1 zu implementieren. 2 veranschaulicht,
dass eine Ladeadresseanweisung (LA-Anweisung) als Teil des Einstellungscodes 11 ausgeführt wird,
um die assemblerbestimmte TABLEBASE-Adresse in ein TABLEBASE-Register zu kopieren,
wo dieses Hardwareregister der zentralen Verarbeitungseinheit ("CPU = Central processing Unit") als RTABLEBASE
bezeichnet wird. Zusätzlich zu
dieser Ladeadressenanweisung (LA-Anweisung) können andere Anweisungen als
Teil des Einstellungscodes 11 in 2 ausgebildet
werden, um ein Hardwaresystem für
die Emulation oder die Ausführung
von Interpretersprache vorzubereiten.
-
Nach
der Ausführung
des Einstellungscodes 11 wird die Abhol- und Decodierschleife 12 der 2 ausgeführt. Die
Abhol- und Decodierschleife 12 der Figur umfasst zwei Assemblerbezeichnungen,
die mit "Fetch" und "Fetch2" benannt sind, die
symbolisch die Adressen veranschaulichen, wenn der Computercode 12 ausgeführt wird.
Die Abhol- und Decodieroperation der Abhol- und Decodiereinheit 12 beginnt
mit dem Ausführen
einer LBZU-Anweisung ("LBZU
= Load Byte Zero with Update"/Lade
Nullbyte mit Aktualisierung). Die Ausführung diese Anweisung lädt einen
Opcode von einer Adresse, die innerhalb eines RPC ("RPC = Programm Counter
Register"/Programmzählerregister)
gespeichert ist, in ein CPU-Hardwareregister,
das als ROPCODE bezeichnet wird. Insbesondere addiert die erste
LBZU-Anweisung in der Schleife 12 der 2 die
ganze Zahl eins zu dem Programmzählerregister
(RPC) und verwendet diese inkrementierte Adresse, um auf einen Opcode
aus dem Speicher zuzugreifen und diesen Opcode in dem ROPCODE-Register
zu speichern. Der ROPCODE-Registerwert
ist ein 32 Bit großer Wert,
der eine der 256 eindeutigen Werte für Java enthalten kann. Dieser
acht Bits lange eindeutige Opcode-Wert wird als ein Indexwert verwendet,
um auf eine spezifische Emulationsroutine innerhalb der Tabelle 14 der 2 zuzugreifen.
Da die Routinen innerhalb der Tabelle 14 Speicherblöcke mit
einer Länge
von 16 Worten (oder 64 Bytes) sind, muss der über die erste LBZU-Anweisung
in 2 gelesene Opcode-Wert nach links um sechs Bitpositionen
geschoben werden. Um diese Indexschiebefunktion durchzuführen, wird
eine SWLI-Anweisung ("SWLI
= Shift Word Left Immediate"/Schiebe
Wort direkt nach links) verwendet, um den in dem ROPCODE-Register
gespeicherten Wert sechs Bitpositionen nach links zu schieben, wobei
das geschobene Resultat zurück
in ROPCODE gespeichert wird.
-
Es
wird dann eine ADD-Anweisung verwendet, um den innerhalb des ROPCODE-Registers
gespeicherten verschobenen Index zu der TABLEBASE-Adresse, die innerhalb
des RTABLEBASE-Registers gespeichert ist, zu addieren. Diese Addition
des RTABLEBASE-Registerwertes und des ROPCODE-Registerwertes wird
für einen
Zielort durchgeführt,
der ein mit RTEMP bezeichnetes temporäres Register ist. Der RTEMP-Wert
enthält
nun die Adresse der spezifischen Emulatoranweisung in Tabelle 14,
die durch den Emulator ausgeführt
werden muss, um die korrekte Emulation der gewünschten Computeranweisung durchzuführen.
-
Um
korrekt zu der spezifischen Emulationsroutine innerhalb der Tabelle 14 zu
verzweigen, wird eine MTCTR-Anweisung
("MTCTR = Move To
CounT Register"/Bewege
zum Zählregister)
ausgeführt,
um die in dem RTEMP-Register gespeicherte Adresse zu dem Zählregister
("RCTR = Count Register") innerhalb der CPU-Hardwarearchitektur
zu bewegen. Das Zählerregister
ist ein Register innerhalb der Architektur der zentralen Verarbeitungseinheit
(CPU) oder des Prozessors, wo dieses Zählregister an eine Verzweigungsverarbeitungseinheit
("BPU = Branch Processing
Unit") der CPU gekoppelt
ist. Eine nachfolgende BCTR-Anweisung ("BCTR = Branch CounT Register"/Verzweigungszählregister),
welche der MTCTR-Anweisung in Routine 12 folgt, bewirkt
dann, dass das emulierte Programm zu der Adresse verzweigt, die
innerhalb des Zählregisters
gespeichert ist, um einen Wechsel des Ausführungsablaufes zu einer Routine
innerhalb Tabelle 14 zu ermöglichen. Wie in 2 veranschaulicht,
ist die letzte Anweisung in der Abholdecodierschleife 12 diese
BCTR-Anweisung, die dann eine nachfolgende Ausführung eine der Routinen innerhalb
der Tabelle 14 erlaubt.
-
Zwischen
der Ausführung
der MTCTR-Anweisung und der BCTR-Anweisung in Routine 12 der 2 wird
eine Vor-Abholoperation ("pre-fetch
operation") durchgeführt. Die
Vor-Abholoperation
wird dadurch ausgeführt,
dass eine zusätzliche
LBZU-Anweisung nahe dem Ende der Abholdecodierschleife 12 in 2 ausgeführt wird.
Diese zweite LBZU-Anweisung innerhalb der Routine 12 inkrementiert
das Programmzählregister
(RPC) um eins und greift dann auf einen Datenwert aus dem Speicher
zu, der sich an diesem inkrementierten Programmzählerwert befindet. Zu diesem
Zeitpunkt ist für
das Programm nicht klar, ob die Daten, auf die über diese zweite LBZU-Anweisung
zugegriffen wird, ein Emulationsdatenoperand oder ein neuer Emulationsanweisungscode
ist. Die Bestimmung dessen, was in dieser Vor-Abholanweisung enthalten
ist, wird durch den Code durchgeführt, der innerhalb der Tabelle 14 nachfolgend
der Ausführung
der BCTR-Anweisung in Routine durch die 2 ausgeführt wird.
-
2 veranschaulicht
insbesondere drei Emulationsroutinen 16, 20 und 22,
die ursprünglich
in 1 veranschaulicht sind. Die Routine 16 ist
die erste Routine innerhalb der Tabelle 14 und wird durch einen
8-Bit-Opcodewert Null (z. B. 00000000 binär) zugegriffen. Wenn der Opcode
mit einem Wert von lauter Nullen durch die Routine 12 gelesen
wird, wird dieser Nullwert verschoben und als ein Index zu dem TABLEBASE-Wert
addiert, wobei das RTEMP-Register TABLEBASE+0 enthält. Wenn
der gelesene Opcodewert gleich Null ist, resultiert die Ausführung der
BCTR-Anweisung in Routine 12 in der Ausführung der
Softwareanweisungen in Routine 16 innerhalb der Tabelle 14 nach
der Ausführung
der BCTR-Anweisung. Die Routine 16 implementiert eine Nicht-Operationsroutine
(NOP), wobei keine funktionale Operation durch das System durchgeführt wird und
das System einfach versucht, Zeit vergehen zu lassen. Da durch die
Routine 16 keine Operation durchgeführt wird, umfasst die Routine 16 einfach eine
Verzweigung zurück
in eine Abholdecodierschleife 12 der 2.
Da die Routine eine NOP-Anweisungssimulationsroutine
ist und da die NOP-Anweisung keine Operanden hat, versteht die Routine 16,
dass der Vor-Abholwert
aus der zweiten LBZU-Anweisung in Routine 12 ein Opcode
ist und keine Daten/Operand(en) ist/sind. Dies bedeuted, dass der
Vor-Abholwert von dem Speicher, auf den über die zweite LBZU-Anweisung
in Routine 12 zugegriffen wurde, ein Opcode ist. Da dieser
Vor-Abholwert ein Opcode ist, verzweigt die Routine 16 zu
der Bezeichnung FETCH2 in Routine 12, um den Vor-Abholwert
als einen Opcode zu verarbeiten. Durch das Durchführen einer
FETCH2- oder FETCH-Verzweigung an den Enden aller Routinen der Tabelle 14 wird ein
kontinuierliches Durchlaufen einer Schleife und die Ausführung von
Abhol- und Decodieroperationen durch den Emulator durchgeführt, bis
eine Softwarebeendigung angetroffen wird.
-
Wenn
der über
die Routine 12 in 2 gelesene
Opcode der Binärwert
N (z. B. N = 01101100 binär)
ist, enthalten der RTEMP-Wert und das Zählregister nach der Ausführung der
Routine 12 den Wert TABLEBASE+N×64. Demnach bewirkt die BCTR-Anweisung
an dem Ende der Routine 12 einen Wechsel des Ausführungsablaufs,
so dass Anweisungen innerhalb der Routine 20 der Tabelle 14 ausgeführt werden.
In Routine 20 ist die erste Anweisung eine EXTSB-Anweisung
("EXTSB = EXTend
Sign Byte/Erweitere Vorzeichen Byte), die auf den Inhalten von ROPCODE
durchgeführt
wird. Diese Operation wird auf dem Opcode-Register durchgeführt, da die
Routine 20 versteht, dass der Vor-Abholwert, der von der
zweiten LBZU-Anweisung in Routine 12 abgefragt wird, einen
Datenwert darstellen muss, da die BIPUSH-Anweisung eine emulierte
Anweisung ist, die einen Anweisungsoperanden umfasst, der für eine korrekte
Emulation benötigt
wird. Die Anweisung zur Erweiterung des Vorzeichens des Bytes muss
ausgeführt
werden, da die BIPUSH-Operation, die von Routine 20 durchgeführt wird,
einen Datenwert mit Vorzeichen benö tigt, wohingegen die Anweisung
LBZU lediglich einen 8-Bit-Wert
ohne Vorzeichen in eine 32-Bit-Stelle gelesen hat.
-
Nach
dem Erweitern des Vorzeichens des Wertes in dem ROPCODE-Register
wird eine STWU-Anweisung ("STWU
= Store Word With Update"/Speichere
Wort mit Aktualisierung) ausgeführt. Diese
Anweisung legt den Wert in ROPCODE auf den Javaoperandenstapel,
in dem zuerst der Javastapelzeiger (RSP) um vier dekrementiert und
dann der 32-Bitwert (4 Byte) von ROPCODE an diesem ROPCODE-Ort angeordnet
wird. Nachdem der Stapel durch den Code in Routine 20 korrekt
verarbeitet wurde, wird eine Verzweigung zurück auf die Assemblerbezeichnung
FETCH innerhalb der Routine 12 durchgeführt. Die Verzweigung der Routine 20 kehrt nicht
zu der Bezeichnung FETCH2 zurück,
da die Routine 20 das Vor-Abholbyte von Routine 12 verwendet/verbraucht
hat und jetzt die Routine 12 mit einer neuen Anweisungsabholung
beginnen muss.
-
Wenn
der von der Routine 12 gelesene Opcode gleich M (z. B.
gleich M = 11100110 binär)
ist, dann sind der RTEMP-Wert
und das Zählregister
an dem Ende der Routine 12 gleich TABLEBASE+M×64. In
diesem Fall resultiert die BCTR-Anweisung am Ende der Routine 12 darin,
dass der Ausführungsablauf
der Routine 22 in Tabelle 14 fortfährt. Die
Routine 22 führt
eine POP-Operation auf einem Operandenstapel durch. Um diese POP-Operation durchzuführen, wird
eine Ladeadressenanweisung (LA) unter Verwendung des Operandenstapelzeigers (RSP)
durchgeführt.
Diese Ladeadressenanweisung addiert den Wert 4 aus dem Operandenstapelzeiger und
platziert diesen Adressenwert zurück in dem Stapelzeiger (RSP),
indem tatsächlich
ein Wort von dem Operandenstapel entfernt wird. Nachdem diese Adressverarbeitung
in Routine 22 durchgeführt
ist, ist die POP-Operation durchgeführt und die Ausführung kehrt
zur Bezeichnung FETCH2 in Routine 12 zurück, da der
Vor-Abholwert von der zweiten LBZU-Anweisung in Routine 12 einen
Opcode enthält, der
jetzt als ein Opcode in Routine 12 verarbeitet werden muss,
ohne dass eine weitere Neuanweisung über die erste LBZU-Anweisung
in Routine 12 geholt werden muss.
-
Demnach
veranschaulicht 2 eine spezifische Emulatorroutine 12,
die nach der Art einer Schleife ausgeführt wird, um eine oder mehrere
Opcodes und Daten aus einem externen Speicher abzufragen. Diese über die
Routine 12 gelesenen Opcodes werden verarbeitet, um einen
geeigneten Softwareemulationsvektor abzuleiten, der von der Verzweigungsanweisung
BCTR verwendet wird, um Emulationsroutinen für diesen speziellen Opcode aufzurufen.
Durch das Durchführen
der Anweisung BCTR werden entsprechende Routinen innerhalb der Tabelle 14 geeignet
ausgeführt,
wobei alle Routinen schließlich
die Ausführungssteuerung
an die abgeholte Decodierroutine 12 zurückgeben. Die iterative Emulation/Interpretation
fährt in
dieser schleifenartigen Weise fort, bis das Programm beendet ist.
-
2 kann
verwendet werden, um die Auswirkungen des Emulationsoverheads sowohl
auf die Emulation als auch die Ausführung von Interpretersprache
zu veranschaulichen. Als Beispiel für den Overhead führt Routine 22 in 2 eine
POP-Operation durch. Um diese POP-Operation unter Verwendung einer
Emulationsumgebung durchzuführen, müssen die
sechs Anweisungen der Routine 12 und die zwei Anweisungen
der Routine 22 durchgeführt werden,
um die emulierte POP-Operation
durchzuführen.
Von diesen insgesamt acht Anweisungen innerhalb der kombinierten
Routinen 12 und 22 führt lediglich eine dieser acht
Anweisungen (die "LA
RSP, 4(RSP)"-Anweisung)
die tatsächliche
POP-Operation durch, wohingegen der Rest von sieben der acht Anweisungen
als Teil des Emulationsoverheads ausgeführt werden. Der sich ergebende
POP-Emulationsoverhead beträgt über 80%
für den
Prozess der 2. Darüber hinaus beeinflusst ein
beliebiger Overhead innerhalb der Routine 12, da die Routine
in 2 für
jede Anweisung, die einer Emulation bedarf, ausgeführt wird,
die Gesamtleistung der Emulation, da die Routine 12 kontinuierlich
nach Art einer Schleife wieder ausgeführt wird. Dem gemäß kann eine
beliebige Reduzierung der Anweisungszahl für die Routine 12 die
Gesamtleistung für
die Emulationszeit beeinflussen, indem der in der Schleife ausgeführte Overhead
stark reduziert wird, der für
jede emulierte Anweisung benötigt
wird. Zusätzlich
können,
wenn die Abhol- und Decodierschleife 12 so eingestellt
werden kann, dass der innerhalb der Routine 16–22 der
Tabelle 14 befindliche Code auch auf wenigere Anweisungen
optimiert werden kann, noch größere Leistungsverbesserungen
während
der Emulation erhalten werden.
-
Diese
Overhead- und Leistungsreduzierung wird mittels der 3–7 erreicht,
welche die Architektur der 1 verwenden. 3 veranschaulicht
eine Neu-Abhol- und Decodierschleife 12', die anstatt der Abhol- und Decodierschleife 12 gemäß dem Stand
der Technik, die in 2 veranschaulicht ist, verwendet
werden kann. Die Neu-Abhol- und
Decodierschleife 12' in 3 bedingt,
dass der TABLEBASE-Adresssenwert in einer 16K-Bytemehrfachadresse
(z. B. 32K, 128K, 2048K, etc.) innerhalb des Speicherabbilds positioniert
wird. Wenn dieser L·16K TABLEBASE-Wert
gesetzt ist, wobei L eine endliche positive ganze Zahl ist, kann
der Code der 3 dazu verwendet werden, den
O verhead der Abhol- und Decodierschleife 12 der 2 zu
reduzieren.
-
Der
Code in 3 beginnt mit dem Durchführen der
gleichen LBZU-Anweisung, die vorausgehend unter Bezugnahme auf 2 diskutiert
wurde. 3 jedoch ersetzt die SWLI- und ADD-Anweisung der 2 durch
eine einzige Anweisung INSRWI, was für "Einfügen
von der rechten Seite des Registers mit einem Wort-Direkt-Wert" ("INSRWI = INsert from
the right Side of the Register with a Word Immediate value"). Der Betrieb, der
von der INSRWI-Anweisung durchgeführt wird, wird graphisch in
dem Blockdiagramm der 4 weiter veranschaulicht.
-
4 veranschaulicht,
dass der TABLEBASE-Wert an einer 16K-Speichergrenze positioniert wird.
Da der TABLEBASE-Wert so positioniert wird, enthalten die höchstwertigen
Bits ("MSBs = Most
Significant Bits")
von Position 0 bis Bitposition 17 die höherwertigen Bits des TABLEBASE-Wertes,
wohingegen die niederwertigen Bitpositionen 18 bis 31 der TABLEBASE-Wertes
den inhärenten
Binärwert
0 aufweisen. Die INSRWI-Anweisung nimmt den Opcodewert, der in dem
ROPCODE-Register
gespeichert ist, und verschiebt diesen Wert um 6. Diese Verschiebung
um 6 Bitpositionen nach links richtet den Opcodewert an den Bitpositionen
18 bis 25 des RTABLEBASE-Registers aus, wie in 4 veranschaulicht. Dieser
verschobene Opcodewert kann dann, ohne dass es einer ADD-Anweisung bedarf,
direkt in die Bitpositionen bis 25 der 4 eingefügt werden,
die vorhergehend 0 aufgrund der 16K-Byteausrichtung des TABLEBASE-Wertes
waren. Die INSRWI-Anweisung
weist Anweisungoperanden auf, welche die Werte 8 und 6 spezifizieren,
was anzeigt, dass 8 Bits in RTABLEBASE nach dem Durchführen der
Schiebeoperation um 6 Bitpositio nen einzufügen sind. Da diese 8 Opcodebits
in das RTRBLEBASE-Register in einen Abschnitt eingefügt werden,
der mit binären
logischen Nullwerten in der RTABLEBASE-Basisadresse ausgefüllt war,
muss keine Hinzufügeoperation
durchgeführt
werden, wodurch in der Routine 12' gegenüber der Routine 12 eine
Anweisung gespart wird. Zusätzlich
verbleiben die niederwertigen Bitpositionen 26–31 als Null wie in 4 veranschaulicht. Diese
niederwertigen Nullbitwerte werden benötigt, da die Tabelle 14 Routinen
enthält,
die 16 Wörter
lang sind. Demnach kann durch das korrekte Positionieren und Einstellen
des TABLEBASE-Wertes eine einzige Anweisung INSRWI in 3 verwendet
werden, um die vorausgehenden zwei Anweisungen SWLI und ADD der 2 zu
ersetzen. Es wurde experimentell gezeigt, dass diese Vereinfachung
der Routine 12' alleine
in einer Verbesserung in der Leistung eines javabasierten Emulators
um grob 10% gegenüber
der in 2 gezeigten resultiert.
-
Nach
dem Durchführen
der INSRWI-Anweisung in 3 wird der in RTABLEBASE gespeicherte
Wert in das Zählregister
(RCTR) bewegt und die Vor-Abholoperation LBZU wird durchgeführt. Diese Anweisungen,
MTCTR und LBZU, sind vergleichbar zu dem vorher diskutierten in 2.
Nach der Ausführung
der Vor-Abhol-LBZU-Operation wird die Verzweigungszählregisteranweisung
(BCTR) verwendet, um mit dem Ausführungsablauf des Emulators
in einer der Routinen 16–24, die sich in Tabelle 14 befinden,
fortzufahren.
-
Während das
Verfahren der 3 und 4 eine Verbesserung
gegenüber
der Routine in 2 gemäß dem Stand der Technik bringt,
kann die Routine der 5 zusätzliche Leistungsvorteile gegenüber der
in 3 diskutierten bringen. Die 5 veranschaulicht
eine Neu-Abhol-Deco dierschleife 12'', die
gegenüber
der in den 2 oder 3 veranschaulichten
weiter optimiert ist. Darüber
hinaus erlaubt die Routine 12'' der 5 eine
verbesserte Optimierung der individuellen Anweisungsemulationsroutinen 16–24,
die sich in Tabelle 14 befinden. Insbesondere kann die
BIPUSH-Routine 20'' der 2 zu
der BIPUSH-Routine 20'' der 5,
aufgrund von Veränderungen
der Abhol-Decodierschleife 12'' in 5 vereinfacht
werden.
-
Die
Abhol- und Decodierschleife 12''der 5 beginnt
mit dem Ausführen
der LBZU-Anweisung und der INSRWI-Anweisung, wie vorhergehend unter Bezugnahme
auf 3 diskutiert. Demnach weist der Prozess der 5 all
diejenigen Vorteile auf, die vorhergehend für das Emulationsverfahren der 3 diskutiert
wurden. Nach der Ausführung dieser
zwei Anweisungen der 5 umfasst das RTABLEBASE-Register
die Vektoradresse der Emulationsroutine, die mit der Tabelle 14 ausgeführt werden
soll. Diese Vektoradresse in RTABLEBASE wird durch das Bewegen des
Wertes in RTABLEBASE zu den Zählregistern
(RCTR) mittels der MTCTR-Anweisung bewahrt. Nach der Ausführung der
MTCTR-Anweisung
wird eine neue Anweisung durchgeführt, die als LGMDT ("LGMDT = Load and
Generate Multiple Data Types"/Lade
und erzeuge Mehrfachdatenarten) bezeichnet wird. Die LGMDT ist im
Allgemeinen eine beliebige ausführbare
Computeranweisung, die einen Eingabewert aus dem Speicher oder einer ähnlichen
Quelle lädt
und eine Mehrzahl von Ergebniswerten aus dem Eingangswert erzeugt,
wobei jeder Ergebniswert ein unterschiedliches Datenformat aufweist.
Die LGMDT-Anweisung speichert im Allgemeinen jeden Ergebniswert,
der ein unterschiedliches Datenfeld aufweist, in unterschiedliche
Register in einer Mehrzahl von CPU-Registern, so dass der Emula tor
ein beliebiges der Datenformate verwenden kann, der Ausführung der
LGMDT-Anweisung folgend.
-
Insbesondere
inkrementiert die LGMDT-Anweisung, wie in 5 veranschaulicht
ist, den Javaprogrammzähler
(RPC) um 1 und liest einen Bytewert (d. h. 8 Bits) von der von dem
Javaprogrammzähler (RPC)
angezeigten Adresse. Die LGMDT-Anweisung in 5 behandelt
den von dem Speicher gelesenen Bytewert als Datenoperanden, obwohl
der Bytewert tatsächlich
ein Opcode sein kann, der von dem Speicher gelesen wurde. Durch
das Behandeln des Bytewertes als Datenoperanden wandelt die LGMDT-Anweisung
das gelesene Datenbyte in einen 32 Bit-Datenwert mit Vorzeichen
und ohne Vorzeichen, wobei der Datenwert ohne Vorzeichen in einem
ersten ROPCODE-Register (z. B. ROPCODE-Register) gespeichert wird
und der Datenwert mit Vorzeichen in dem zweiten ROPCODE-Register
(z. B. ROPCODE+1-Register) gespeichert wird. Nach der Ausführung der
LGMDT-Anweisung wird die BCTR-Anweisung
dazu verwendet, den Ausführungsablauf
so zu verändern,
dass eine der Routinen innerhalb der Tabelle 14, wie hierin
obenstehend diskutiert, ausgeführt
wird.
-
5 veranschaulicht
insbesondere die Vorteile der LGMDT-Anweisung durch die Verwendung der
BIPUSH-Anweisung. Die BIPUSH-Routine 20'' wurde
in 5 aufgrund des Vorhandenseins der LGMDT-Anweisung
in Routine 12'' vereinfacht.
Aufgrund der Ausführung
der LGMDT-Anweisung kann die vorher bestehende Anweisung zur Erweiterung des
Vorzeichens des Bytes, wie in 2 veranschaulicht,
aus der Routine 20'' in 5 entfernt
werden. Diese Entfernung ist erlaubt, da die LGMDT-Anweisung sowohl
Ergebnisse mit als auch ohne Vorzeichen für die Routinen in Tabelle 14 zur
Verwendung zur Verfügung
stellt. Zusätzlich
greift die STWU-Anweisung in Routine 20'' nicht
länger
auf den ROPCODE-Ort, wie in 2 veranschaulicht, sondern
greift auf das ROPCODE+1-Register zu, das die LGMDT-Anweisung in
Routine 12'' erzeugten Wert
mit Vorzeichen enthält.
Das Register ROPCODE enthält
den Wert ohne Vorzeichen, der von der Routine 12'' nicht benötigt wird. Demnach werden vergleichsweise
neun Anweisungen in 2 benötigt, um eine BIPUSH-Anweisung
zu emulieren, wohingegen lediglich sieben Anweisungen benötigt werden,
um eine BIPUSH-Anweisung unter Verwendung der Herangehensweise der 5 zu
emulieren.
-
6 veranschaulicht
eine weitere Leistungsverbesserung und eine Overheadreduzierung verglichen
mit der in 5 veranschaulichten. 6 veranschaulicht
eine weitere und kompliziertere LGMDT-Anweisung als die in 5 veranschaulichte.
Diese verbesserte LGMDT-Anweisung kann jedoch dazu verwendet werden,
um die Emulationsalgorithmen, die unter Verwendung des Emulationssystem 10 durchgeführt werden,
weiter zu vereinfachen. Die LGMDT-Anweisung in 6 enthält vier Anweisungsoperanden.
Der erste Operand ist die ROPCODE-Registerbestimmung, der zweite
Operand ist die Adresse des nächsten
aus dem Speicher abzuholenden Opcodes unter Verwendung des Javaprogrammzählers (RPC),
der dritte Operand ist die Anzahl an Bits in dem Opcode, der von
einem externen Speicher (z. B. 8 in diesem Beispiel) gelesen wurde
und der vierte Operand für
die LGMDT-Anweisung ist die Anzahl an Bitpositionen, um die der
Opcode nach links vor der Vektorerzeugung geschoben werden soll
(z. B. 6 in diesem Beispiel). Es ist wichtig festzuhalten, dass
die Operanden für
die LGMDT-Anweisung durch ein Festverdrahten oder durch ein Festlegen
bestimmter Operanden auf spezifische Werte oder Orte in der Hardware
oder in der LGMDT-Anweisungsdecodierverarbeitung reduziert werden
können.
Auf diese Weise kann die Bitgröße von 8
und der Linksschiebewert von 6 "festverdrahtet" in der LGMDT-Anweisung
werden, wodurch diese Parameter nicht programmierbar sind, sondern
für die
Anweisungsausführung
fest sind.
-
Die
LGMDT-Anweisung liest den 8-Bit-Wert aus dem externen Speicher und
erzeugt drei Ergebnisse in drei unterschiedlichen internen CPU-Registern.
Der erste durch die LGMDT-Anweisung in 6 erzeugte
Wert ist eine Vektoradresse, die gemäß der Figur bei einem ähnlichen
Prozess erzeugt wird. Ein zweiter von der LGMDT-Anweisung erzeugte
Wert ist ein 32-Bit-Operand/Datenwert ohne Vorzeichen, wie vorausgehend
zu 5 diskutiert. Ein dritter von der LGMDT-Anweisung
in Figur erzeugter Wert ist ein 32-Bit-Operand/Datenwert mit Vorzeichen,
der von dem ROPCODE erzeugt wurde und in einem der internen ROPCODE-Register
platziert wird. Im Allgemeinen werden die Vektoradressen von der LGMDT-Anweisung
in dem ROPCODE+2-Register platziert, der 32-Bit-Operand/Datenwert
mit Vorzeichen wird in dem ROPCODE+1-Register platziert und der
32-Bit-Operand/Datenwert ohne Vorzeichen wird in dem ROPCODE-Register
platziert. Unter Annahme dieser Anordnung der drei Ergebnisse der LGMDT-Anweisung bewegt
die MTCTR-Anweisung die Inhalte des ROPCODE+2-Registers zu dem Zählregister
(RCTR). Eine zweite LGMDT-Anweisung wird ausgeführt, um ein Vor-Abholen des
beliebigen der folgenden zu ermöglichen:
ein neuer Opcode, ein Operand mit Vorzeichen oder ein Operand ohne
Vorzeichen. Die BCTR-Anweisung ermöglicht es, dass der Ausführungsablauf
in einer der Routinen fortgeführt
wird, die sich innerhalb der Tabelle 14 befinden.
-
6 veranschaulicht
insbesondere die BIPUSH-Operation 20'''. Die Routine 20''' ist ähnlich, so
dass sie unter Bezug auf 5 erläutert wird.
-
6 veranschaulicht
eine POP-Operation 22'''. Da die LGMDT-Anweisung eine Vektorberechnung
zusätzlich
zu den 32-Bit-Datenwerten mit und ohne Vorzeichen zur Verfügung gestellt
hat, kann die Routine 22''' der 6 zu der
MTCTR-Anweisung statt zu einer INSRWI-Anweisung oder einer SWLI-Anweisung
zurückzukehren,
wie in 5 beziehungsweise in 2 veranschaulicht.
Mit anderen Worten, die Routine 22''' kann einfach
zu einem Ort innerhalb der Routine 12''' zurückkehren,
was das Zählregister
(RCTR) aktualisiert, und nicht eine Vorverarbeitung irgendeines
Registers durchführen,
bevor sie eine Bewegung zu dem Zählerregister
durchführt.
Demnach spart der in 6 verwendete Code eine Anweisung
in der Ausführung
der POP-Operation 22''' und spart eine zusätzliche
Anweisung gegenüber
der in 5 veranschaulichten, wenn die BIPUSH-Operation 20''' ausgeführt wird.
Im Ergebnis benötigt
der in 6 verwendete Code sechs Anweisungen um eine BIPUSH-Operation
durchzuführen, wohingegen
der Stand der Technik neun Operationen benötigt, um den gleichen BIPUSH-Prozess
in 2 durchzuführen.
Dies bedeutet Einsparungen von über
30 % in der Anweisungsverwendung in der BIPUSH-Routine. Ähnliche
Einsparungen zeigen sich für
alle anderen Anweisungen in dem Emulationspaket oder dem Interpretersprachensystem.
Zusammenfassend wurden hierin verschiedene neue Anweisungen eingeführt, die
eine Reduzierung des Overheads bei der Codeemulation und der Ausführung von
Interpretersprachen ermöglicht,
wodurch die Computerleistung stark verbessert werden kann.
-
7 veranschaulicht
eine Registerdatei 100 und eine Ladeeinheit 101,
die verwendet werden können,
um die LGMDT-Anweisung, wie in 6 veranschaulicht,
zu implementieren. Die Registerdatei 100 umfasst wie gezeigt
sechs Register: ROPCODE 102, ROPCODE+1 104, ROPCODE+2
oder RTABLEBASE 106, RSP 108, RPC 110 und
RCTR 112. Das RSP-Register 108 der zentralen Verarbeitungseinheithardware
(CPU-Hardware) ist
der Operanden-"Stapelzeiger", das RPC-Register 110 ist
der Emulations-"Programmzähler" und das RCTR-Register 112 ist
das CPU-"Zählregister" zum Durchführen von
Verzweigungsoperationen unter Verwendung der Verzweigungseinheit.
Die RSP-108- und RPC-110-Register ermöglichen es der Ladeeinheit 101,
Informationen vom Cache und/oder von externen Speichern zu lesen.
-
Die
Ladeeinheit 101 liest ein Byte aus dem Speicher als Antwort
auf eine LGMDT-Anweisung. Dieses Byte wird parallel drei Ladeuntereinheiten 114, 116 und 118 zur
Verfügung
gestellt. Die Nullausdehnungseinheit dehnt den Bytewert auf einen 32-Bit-Wert
ohne Vorzeichen aus, als ob der Bytewert ein Operand ohne Vorzeichen
wäre. Dieser Operand
ohne Vorzeichen wird dann dem ROPCODE-Register 102 zur
Verfügung
gestellt. Das Vorzeichen des Bytewertes wird unter Verwendung einer Vorzeichenerweiterungseinheit 116 erweitert.
Die Vorzeichenerweiterungseinheit 116 wandelt den Bytewert
in einen 32-Bit-Wert mit Vorzeichen zur Verwendung als ein Operand
mit Vorzeichen unter Zugriff auf ein ROPCODE+1-Register 104 um
(dieses ist das Register, das numerisch um 1 größer ist als das ROPCODE-Register 102).
Der Vektorbitprozessor 118 der 7 führt entweder
die Schiebe- und Hinzufügeoperation
der SWLI- und ADD-Anweisungen
durch oder führt
die Operation durch, die in
-
4 diskutiert
wurde, um den RTABLEBASE/ROPCODE+2- und den Byte-Wert in einen Nachschlagevektor
umzuwandeln, der dazu verwendet werden kann, auf zumindest eine
Routine innerhalb der Tabelle 14 zuzugreifen. Der Code
in Tabelle 14 und in Routine 12 kann auf ein beliebiges
der drei Register zugreifen, um den Wert zu erhalten, der benötigt wird
und kann alle anderen nicht benötigten
Werte in den Registern 102–106 ignorieren.
-
8 ist
ein Blockdiagramm, das einen Mehrzweckcomputer 120 veranschaulicht,
der die Lade-/Speichereinheit 101 und die in 7 gezeigte Registerdatei 100 umfasst.
Der Mehrzweckcomputer 120 weist eine zentrale Verarbeitungseinheit
(CPU) oder einen Prozessor 122 auf, der die Lade-/Speichereinheit 101 und
die Registerdatei 100 umfasst. Der Speicher 124 ist
an den Prozessor 122 mittels eines Busses 126 verbunden.
Der Speicher 124 ist ein Medium, das mittels einer Hochgeschwindigkeitsmaschine
lesbar ist und umfasst flüchtige
Speicher wie etwa DRAM und SRAM als auch nicht-flüchtige Speicher
wie etwa ROM, FLASH, EPROM, EEPROM und Blasenspeicher. Mit dem Bus 126 sind
auch ein Sekundärspeicher 130,
ein externer Speicher 132, Ausgabegeräte wie etwa ein Monitor 134,
Eingabegeräte wie
etwa eine Tastatur (mit Maus) 136 und Drucker 138 verbunden.
Der Sekundärspeicher 130 umfasst maschinenlesbare
Medien wie etwa Festplattenlaufwerke, magnetische Trommeln und Blasenspeicher. Der
externe Speicher 132 umfasst maschinenlesbare Medien wie
etwa Diskettenlaufwerke, Wechselfestplattenlaufwerke, magnetische
Bänder,
CD-ROM und sogar andere Computer, möglicherweise über eine
Kommunikationsverbindung verbunden. Hier getroffene Unterscheidung
zwischen Sekundärspeicher 130 und
externen Speicher 132 geschieht lediglich vorrangig zur
Erleichterung der Beschreibung der Erfindung. Demnach sollte klar
sein, dass es eine wesentliche funktionelle Überschneidung zwischen diesen
Elementen gibt. Computersoftware wie etwa ein Emulationscode 10–24 und
Benutzerprogramme können
in einem Computersoftwarespeichermedium, wie etwa dem Speicher 124,
dem sekundären
Speicher 130 und dem externen Speicher 132 gespeichert
werden. Ausführbare
Versionen der Computersoftware 133 können von einem nicht-flüchtigem Speichermedium
wie etwa einem externen Speicher 132, einem sekundären Speicher 130 und
einem nicht-flüchtigem
Speicher gelesen werden und zur Ausführung direkt in den flüchtigen
Speicher geladen werden, direkt aus dem nicht-flüchtigem Speicher ausgeführt werden
oder in dem sekundären
Speicher 130 vor dem Laden in den flüchtigen Speicher zur Ausführung gespeichert
werden.
-
Obwohl
die Erfindung unter Bezugnahme auf spezielle Ausführungsformen
beschrieben und veranschaulicht wurde, ist nicht vorgesehen, dass
die Erfindung auf diese veranschaulichende Ausführungsformen beschränkt ist.
Der Fachmann wird erkennen, dass Modifikationen und Variationen
durchgeführt
werden können,
ohne von dem Geist und dem Geltungsbereich der Erfindung abzuweichen. Beispielsweise
muss die hierin gelehrte LGMDT-Anweisung nicht nur für die Ausgabe
von 8-Bit-Werten arbeiten, sondern kann beliebig große (16 Bit,
4 Bit, 32 Bit, 64 Bit, etc.) Werte unterschiedlicher Datenformate
zur Speicherung in getrennten Registern verarbeiten. Der hierin
verwendete Prozess kann dazu verwendet werden, eine Zahl mit Vorzeichen,
eine Zahl ohne Vorzeichen, ein Fließkommaformat, unterschiedliche
ganzzahFormate, rechts oder links ausgerichtete Zahlen, verschobene
oder rotierte Werte, Big-endian-Werte, Little endian-Werte, ASCII-Ausgaben
oder andere numerische Formate parallel zu beliebigen anderen numerischen
Formaten zur Verbesserung der Emulationsleistung oder der Ausführung von
Interpretersprache zu erzeugen. In einigen Fällen kann der Code der Routine 12 in
die Routinen in Tabelle 14 platziert werden, um eine Verzweigungsvorhersage
und ein Verzweigungscacheladen einzusparen. Demnach ist vorgesehen,
dass diese Erfindung all die Variationen und Modifikationen umfasst, die
innerhalb des Geltungsbereichs der angehängten Ansprüche fällt.