DE19681660C2 - Verfahren zum Ausführen von Befehlssätzen, die Operationen an verschiedenen Datenarten und Register eines gemeinsamen logischen Registersatzes spezifizieren - Google Patents
Verfahren zum Ausführen von Befehlssätzen, die Operationen an verschiedenen Datenarten und Register eines gemeinsamen logischen Registersatzes spezifizierenInfo
- Publication number
- DE19681660C2 DE19681660C2 DE19681660T DE19681660T DE19681660C2 DE 19681660 C2 DE19681660 C2 DE 19681660C2 DE 19681660 T DE19681660 T DE 19681660T DE 19681660 T DE19681660 T DE 19681660T DE 19681660 C2 DE19681660 C2 DE 19681660C2
- Authority
- DE
- Germany
- Prior art keywords
- packed data
- command
- floating point
- tags
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 243
- 230000007704 transition Effects 0.000 claims description 134
- 230000008859 change Effects 0.000 claims description 56
- 230000004044 response Effects 0.000 claims description 45
- 230000015654 memory Effects 0.000 claims description 39
- 238000012545 processing Methods 0.000 claims description 34
- 230000008569 process Effects 0.000 description 104
- 239000000872 buffer Substances 0.000 description 74
- 238000013507 mapping Methods 0.000 description 55
- 238000012986 modification Methods 0.000 description 18
- 230000004048 modification Effects 0.000 description 18
- 230000007246 mechanism Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 15
- 238000012360 testing method Methods 0.000 description 11
- 238000005516 engineering process Methods 0.000 description 8
- 238000007726 management method Methods 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- 238000013500 data storage Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 5
- 230000000694 effects Effects 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000018109 developmental process Effects 0.000 description 3
- 239000003607 modifier Substances 0.000 description 3
- 230000000704 physical effect Effects 0.000 description 3
- 230000001737 promoting effect Effects 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 241000258241 Mantis Species 0.000 description 2
- 241001465754 Metazoa Species 0.000 description 2
- 235000010678 Paulownia tomentosa Nutrition 0.000 description 2
- 240000002834 Paulownia tomentosa Species 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 101100262292 Caenorhabditis elegans txdc-9 gene Proteins 0.000 description 1
- 241000153282 Theope Species 0.000 description 1
- 206010000210 abortion Diseases 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000002354 daily effect Effects 0.000 description 1
- 230000006837 decompression Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 210000003608 fece Anatomy 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- RKWPZPDLTYBKCL-RVZGXXANSA-N meproscillarin Chemical compound O[C@@H]1[C@H](O)[C@@H](OC)[C@H](C)O[C@H]1O[C@@H]1C=C2CC[C@H]3[C@@]4(O)CC[C@H](C5=COC(=O)C=C5)[C@@]4(C)CC[C@@H]3[C@@]2(C)CC1 RKWPZPDLTYBKCL-RVZGXXANSA-N 0.000 description 1
- 238000002156 mixing Methods 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 238000004321 preservation Methods 0.000 description 1
- 108090000623 proteins and genes Proteins 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000011664 signaling Effects 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/3017—Runtime instruction translation, e.g. macros
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
- G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30101—Special purpose registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
- G06F9/30109—Register structure having multiple operands in a single register
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
- G06F9/30112—Register structure comprising data of variable length
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/3012—Organisation of register space, e.g. banked or distributed register file
- G06F9/30134—Register stacks; shift registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
- G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3838—Dependency mechanisms, e.g. register scoreboarding
- G06F9/384—Register renaming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/461—Saving or restoring of program or task context
- G06F9/462—Saving or restoring of program or task context with multiple register sets
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Executing Machine-Instructions (AREA)
- Advance Control (AREA)
Description
Die vorliegende Erfindung betrifft Verfahren bei der
Ausführung von Befehlen verschiedener Befehlsarten, die Ope
rationen an verschiedenen Datenarten veranlassen, insbeson
dere von Befehlen für gepackte Daten und Befehlen für skala
re oder Gleitkommadaten, in einer Datenverarbeitungseinrich
tung.
Bei einem üblichen Computersystem bearbeiten ein oder
mehrere Prozessoren Datenwerte, die durch eine große Anzahl
von Bits (z. B. 16, 32, 64 usw.) dargestellt sind, um als
Antwort auf einen programmierten Befehl ein Ergebnis zu lie
fern. Beispielsweise werden bei der Ausführung eines Addi
tionsbefehls ein erster Datenwert und ein zweiter Datenwert
addiert, und das Ergebnis wird als dritter Datenwert gespei
chert. Jedoch erfordern Multimediaanwendungen (z. B. der com
putergestützten Kooperation gewidmete Anwendungen (CSC - die
Integration von Telekonferenz und Datenbearbeitung unter
schiedlicher Medien), 2D/3D-Grafiken, Bildverarbeitung, Vi
deo-Kompression/Dekompression, Erkennungsalgorithmen und
Tonbearbeitungen) die Bearbeitung großer Mengen von Daten,
die oft durch eine geringere Anzahl von Bits dargestellt
sind. Beispielsweise werden Multimediadaten üblicherweise
als 64-Bit-Zahlen dargestellt, obwohl es sein kann, daß nur
eine Handvoll der Bits die signifikanten Informationen tra
gen.
Um die Wirksamkeit von Multimediaanwendungen (sowie von
anderen Anwendungen, die die gleichen Charakteristika auf
weisen) zu verbessern, stellen bekannte Prozessoren gepackte
Datenformate zur Verfügung. Ein gepacktes Datenformat ist
ein Datenformat, bei dem die zur Darstellung eines einzelnen
Wertes verwendeten Bits auf eine Anzahl von Datenelementen
fester Größe aufgeteilt werden, wobei jedes Datenelement ei
nen separaten Wert darstellt. Beispielsweise können Daten in
einem 64-Bit-Register auf zwei 32-Bit-Elemente aufgeteilt
werden, von denen jedes Element einen separaten 32-Bit-Wert
darstellt.
Die grundlegende 32-Bit-Architektur-Maschine von Hew
lett-Packard ging entsprechend dieser Herangehensweise vor,
um Multimediadatenarten zu implementieren. Das heißt, der
Prozessor verwendete seine 32-Bit-Mehrzweck-Ganzzahlregister
parallel, um 64-Bit-Datenarten zu implementieren. Der Haupt
nachteil dieser einfachen Vorgehensweise besteht darin, daß
sie den verfügbaren Registerspeicherplatz stark beschränkt.
Außerdem wird der Leistungsvorteil bei der derartigen Bear
beitung von Multimediadaten im Hinblick auf die zur Erweite
rung der bestehenden Architektur erforderlichen Maßnahmen
als minimal angesehen.
Eine irgendwie ähnliche Vorgehensweise, die in dem Mo
torola® 88110TM-Prozessor gewählt wurde, besteht darin, Ganz
zahlregisterpaare zu kombinieren. Zu der Idee der Paarung
von 32-Bit-Registern gehört die Verkettung zufälliger Kombi
nationen von spezifizierten Registern für eine einzige Ope
ration oder einen einzigen Befehl. Jedoch besteht wiederum
der Hauptnachteil der Implementierung von 64-Bit-Multimedia-
Datenarten unter Verwendung von paarweisen Registern darin,
daß es nur eine begrenzte Anzahl von Registerpaaren gibt,
die verfügbar sind. Außer dem Hinzufügen von zusätzlichem
Registerspeicherplatz zu der Architektur wird eine andere
Technik zur Implementierung von Multimedia-Datenarten benö
tigt.
Aus WO 93/01543 ist ein Verfahren zum Ausführen ver
schiedener Sätze von Befehlen in einer Datenverarbeitungs
einrichtung bekannt, welches einen Prozessor in die Lage
versetzt, verschiedene Arten von Befehlssätzen auszuführen.
Eine Serie von Prozessoren, die über eine große Soft
ware- und Hardware-Basis verfügt, ist die Intel-Architektur-
Prozessorfamilie, zu der der Pentium®-Prozessor gehört, der
von der Intel Coporation aus Santa Clara, Kalifornien, her
gestellt wird. Fig. 1 zeigt ein Blockschaltbild, welches
ein beispielhaftes Computersystem 100 veranschaulicht, in
dem der Pentium-Prozessor eingesetzt ist. Der Pentium-Pro
zessor ist beispielsweise in WOPPERER, Bernhard "Pentium-
Prozessor", in MC, April 1993, S. 44-62 beschrieben. Im Hin
blick auf eine detailliertere als die hier gegebene Be
schreibung des Pentium-Prozessors wird auf das Pentium
Processor's Users Manual - Band 3: Architecture and Program
ming Manual, 1994 verwiesen, das von der Intel Corporation
in Santa Clara, CA, erhältlich ist. Das beispielhafte Compu
tersystem 100 enthält einen Prozessor 105, eine Speicherein
richtung 110 und einen Bus 115. Der Prozessor 105 ist mit
der Speichereinrichtung 110 über den Bus 115 verbunden. Au
ßerdem sind mehrere Benutzer-Eingabe/Ausgabeeinheiten, wie
zum Beispiel eine Tastatur 120 und eine Anzeige 125, mit dem
Bus 115 gekoppelt. Ein Netzwerk 130 kann außerdem mit dem
Bus 115 gekoppelt sein. Der Prozessor 105 repräsentiert den
Pentium-Prozessor. Die Speichereinrichtung 110 stellt einen
oder mehrere Mechanismen zur Datenspeicherung dar. Bei
spielsweise kann die Speichereinrichtung 110 einen Nur-Lese-
Speicher (ROM), einen Speicher mit wahlfreiem Zugriff (RAM),
magnetische Plattenspeichermedien, optische Speichermedien,
Flash-Speichereinrichtungen und/oder andere maschinenlesbare
Medien enthalten. Der Bus 115 stellt einen oder mehrere
Busse (z. B. PCI, ISA, X-Bus, EISA, VESA usw.) und Brücken
(auch als Bus-Steuereinrichtungen bezeichnet) dar.
Fig. 1 zeigt außerdem, daß in der Speichereinrichtung
110 ein Betriebssystem 132 zur Ausführung auf dem Prozessor
105 gespeichert ist. Natürlich enthält die Speichereinrich
tung 110 vorzugsweise zusätzliche (nicht dargestellte) Soft
ware. Fig. 1 zeigt außerdem, daß der Prozessor 105 eine
Gleitkommaeinheit 135 und ein Gleitkommastatusregister 155
enthält (die Bezeichnung "FP" wird im folgenden für den Be
griff "Gleitkomma" verwendet). Natürlich enthält der Prozes
sor 105 zusätzliche Schaltungen, die zum Verständnis der
vorliegenden Erfindung nicht notwendig sind.
Die Gleitkommaeinheit 135 wird zur Speicherung von
Gleitkommadaten verwendet und enthält einen Satz von Gleit
kommaregistern (der auch als Gleitkommaregisterdatei be
zeichnet wird) 145, einen Satz von Tags 150 und ein Gleit
kommastatusregister 155. Der Satz der Gleitkommaregister 145
enthält acht mit R0 bis R7 bezeichnete Register (hierbei
wird die Schreibweise Rn verwendet, um den physikalischen
Ort der Gleitkommaregister anzugeben). Jedes dieser acht Re
gister ist 80 Bits breit und enthält ein Vorzeichenfeld (Bit
79), ein Exponentenfeld (Bits [78:64]) und ein Mantissenfeld
(Bits [63:0]). Die Gleitkommaeinheit 135 betreibt den Satz
von Gleitkommaregistern 145 als Stapel. Mit anderen Worten,
die Gleitkommaeinheit 135 enthält eine Registerdatei, auf
die als Stapel Bezug genommen wird. Wenn ein Registersatz
als Stapel betrieben wird, werden Operationen unter Bezug
nahme auf das Kopfende des Stapels ausgeführt und nicht un
ter Bezugnahme auf die physikalischen Orte der Register in
dem Satz der Gleitkommaregister 145 (die Bezeichnung STn
wird hierbei verwendet, um den relativen Ort des logischen
Gleitkommaregisters n bezogen auf das Kopfende des Stapels
zu bezeichnen). Das Gleitkommastatusregister 155 enthält ein
Stapelkopfendefeld 160, welches angibt, welches Register des
Satzes der Gleitkommaregister 145 derzeit oben im Gleitkom
mastapel ist. In Fig. 1 kennzeichnet die Stapelkopfendean
zeige ein Register 165 an dem physikalischen Ort R4 als das
Stapelkopfende.
Der Satz von Tags 150 enthält acht Tags und ist in ei
nem einzigen Register gespeichert. Jedes Tag entspricht ei
nem anderen Gleitkommaregister und enthält zwei Bits. Wie in
Fig. 1 dargestellt ist, entspricht das Tag 170 dem Register
165. Ein Tag gibt Informationen an, welche den aktuellen In
halt desjenigen Gleitkommaregisters betreffen, zu dem das
Tag gehört - 00 = gültig; 01 = Null; 10 = speziell; und 11
= leer. Diese Tags werden von der Gleitkommaeinheit 135 zur
Unterscheidung zwischen leeren und nicht-leeren Register
speicherplätzen verwendet. Folglich kann man sich die Tags
vorstellen, als sollten sie zwei Zustände anzeigen: leer,
wobei dies mit Hilfe einer 11 angezeigt wird, und nicht-
leer, wobei dies mit 00, 01 oder 10 angezeigt wird.
Diese Tags können außerdem zur Bearbeitung von Ereig
nissen verwendet werden. Ein "Ereignis" ist jede Aktion oder
jeder Vorfall, auf welche ein Computersystem antworten
könnte, wozu Hardware-Interrupts, Software-Interrupts, Aus
nahmen, Fehler, Traps, Abbrüche, Maschinenprüfungen, Hilfen
und Fehlersuchereignisse gehören. Bei Empfang eines Ereig
nisses veranlaßt der Ereignisbehandlermechanismus des Pro
zessors den Prozessor, die Ausführung des aktuellen Prozes
ses zu unterbrechen, die Ausführungsumgebung des unterbro
chenen Prozesses zu speichern (d. h., die zur Wiederaufnahme
der Ausführung des unterbrochenen Prozesses erforderlichen
Informationen) und den geeigneten Ereignisbehandler zur Be
arbeitung des Ereignisses aufzurufen. Nach der Bearbeitung
des Ereignisses veranlaßt der Ereignisbehandler den Prozes
sor, den unterbrochenen Prozeß unter Verwendung der vorher
gespeicherten Ausführungsumgebung des Prozesses wiederaufzu
nehmen. Programmierer von Ereignisbehandlern können diese
Tags verwenden, um den Inhalt der verschiedenen Gleitkomma
register zu überprüfen, um ein Ereignis besser zu bearbei
ten.
Obwohl jedes Tag als aus zwei Bits bestehend beschrie
ben wurde, können alternative Ausführungsbeispiele nur ein
Bit für jedes Tag speichern. Jedes dieser Ein-Bit-Tags kenn
zeichnet entweder leer oder nicht-leer. Bei derartigen Aus
führungsbeispielen können diees Ein-Bit-Tags derart gestal
tet werden, daß es für den Benutzer erscheint, als ob sie
zwei Bits enthielten, indem der geeignete Zwei-Bit-Tagwert
bestimmt wird, wenn die Tagwerte benötigt werden.
Das Statusregister 140 enthält ein EM-Feld 175 und ein
TS-Feld 180, um eine EM-Anzeige bzw. eine TS-Anzeige zu
speichern. Wenn die EM-Anzeige gleich 1 und/oder die TS-An
zeige gleich 1 ist, veranlaßt die Prozessor-Hardware ein
Trap zum Betriebssystem bei der Ausführung eines Gleitkomma
befehls, indem sie eine "Einrichtung nicht verfügbar"-Aus
nahme erzeugt. Gemäß einer Software-Konvention, werden die
EM- bzw. TS-Anzeigen zum Emulieren von Gleitkommabefehlen
bzw. zum Implementieren von Multitasking verwendet. Jedoch
ist die Verwendung dieser Anzeigen nur eine Software-Konven
tion. Folglich können diese Anzeigen für jeden beliebigen
Zweck verwendet werden. Beispielsweise kann die EM-Anzeige
zur Implementierung eines Multitasking verwendet werden.
Gemäß der oben beschriebenen Software-Konvention wird
das EM-Feld 175 zur Speicherung einer Emuliere-Gleitkomma-
Anzeige ("EM-Anzeige") verwendet, welche angibt, ob die
Gleitkommaeinheit mit Hilfe von Software emuliert werden
soll. Üblicherweise werden bei einem Systemstart eine Reihe
von Befehlen oder ein einziger Befehl (z. B. CPUID) ausge
führt, um festzustellen, ob eine Gleitkommaeinheit vorhanden
ist, und um die EM-Anzeige ggf. zu ändern. Folglich wird die
EM-Anzeige üblicherweise geändert, um anzuzeigen, daß die
Gleitkommaeinheit emuliert werden soll, wenn der Prozessor
keine Gleitkommaeinheit enthält. Während die EM-Anzeige bei
einer Implementierung gleich 1 ist, wenn die Gleitkommaein
heit emuliert werden soll, können alternative Implementie
rungen andere Werte verwenden.
Durch die Verwendung des Betriebssystems sind viele
Prozessoren in der Lage, ein Multitasking mehrerer Prozesse
auszuführen (welche hierbei als Tasks bezeichnet werden),
wobei Techniken wie zum Beispiel kooperatives Multitasking,
Zeitscheiben-Multitasking usw. verwendet werden. Ein Multi-
Tasking-Verfahren ist beispielsweise aus dem US-Patent Nr.
5,127,098 bekannt. Da ein Prozessor jeweils nur eine Task
ausführen kann, muß ein Prozessor seine Verarbeitungszeit
auf die verschiedenen Tasks aufteilen, indem er zwischen den
verschiedenen Tasks hin und her schaltet. Wenn ein Prozessor
von einer Task zu einer anderen schaltet, spricht man davon,
daß eine Taskumschaltung aufgetreten ist (welche auch als
"Kontextumschaltung" oder als "Prozeßumschaltung" bezeichnet
wird). Um eine Taskumschaltung auszuführen, muß der Prozes
sor die Ausführung einer Task beenden und entweder die Aus
führung der anderen Tasks wiederaufnehmen oder diese begin
nen. Es gibt zahlreiche Register (einschließlich der Gleit
kommaregister), deren Inhalt gesichert werden muß, um die
Ausführung einer Task nach einer Taskumschaltung wiederauf
zunehmen. Der Inhalt dieser Register zu einem vorgegebenen
Zeitpunkt während der Ausführung einer Task wird als der
"Registerzustand" dieser Task bezeichnet. Beim Multitasking
verschiedener Prozesse wird der "Registerzustand" einer Task
während der Ausführung von anderen Prozessen dadurch be
wahrt, daß er in eine (als "Kontextstruktur" der Task be
zeichnete) Datenstruktur gespeichert wird, die in einem ex
ternen Speicher des Prozessors enthalten ist. Wenn die Aus
führung einer Task wiederaufgenommen werden soll, wird der
Registerzustand der Task mit Hilfe der Kontextstruktur der
Task wiederhergestellt (z. B. in den Prozessor zurückgela
den).
Die Bewahrung und die Wiederherstellung des Registerzu
standes einer Task kann mit Hilfe zahlreicher verschiedener
Techniken geschehen. Beispielsweise speichert ein Betriebs
system bei jeder Taskumschaltung den gesamten Registerzu
stand der vorangegangenen Task und stellt den gesamten Regi
sterzustand der nächsten Task wieder her. Da es jedoch zeit
aufwendig ist, sämtliche Registerzustände zu speichern und
wiederherzustellen, ist es wünschenswert, bei Taskumschal
tungen die Speicherung und/oder Wiederherstellung von unnö
tigen Abschnitten zu vermeiden. Wenn eine Task die Gleitkom
maeinheit nicht verwendet, ist es unnötig, den Inhalt der
Gleitkommaregister als Teil des Registerzustandes der Task
zu speichern und wiederherzustellen. Zu diesem Zweck wurde
bisher die TS-Anzeige von Betriebssystemen verwendet, gemäß
der im vorangegangenen beschriebenen Software-Konvention, um
das Speichern und Wiederherstellen des Inhalts der Gleitkom
maregister während Taskumschaltungen zu vermeiden (was im
allgemeinen als "partielle Kontextumschaltungen" oder
"Kontextumschaltungen bei Bedarf" bezeichnet wird).
Die Verwendung der TS-Anzeige zur Implementierung par
tieller Kontextumschaltungen ist wohlbekannt. Jedoch ist es
für die Erfindung von Bedeutung, daß der Versuch, einen
Gleitkommabefehl auszuführen, während die TS-Anzeige an
zeigt, daß eine partielle Kontextumschaltung durchgeführt
wurde (d. h. daß die Gleitkommaeinheit "nicht verfügbar" oder
"inaktiv" ist), zu einer "Einrichtung nicht verfügbar"-Aus
nahme führt. Als Antwort auf diese Ausnahme bestimmt der auf
dem Prozessor ausführende Ereignisbehandler, ob die aktuelle
Task im Besitz der Gleitkommaeinheit ist (ob die in der
Gleitkommaeinheit gespeicherten Daten zu der aktuellen Task
oder einer vorher ausgeführten Task gehören). Wenn die aktu
elle Task nicht der Besitzer ist, veranlaßt der Ereignisbe
handler den Prozessor, den Inhalt der Gleitkommaregister in
die Kontextstruktur der vorangegangenen Task zu speichern,
den Gleitkommazustand der aktuellen Task (sofern verfügbar)
wiederherzustellen, und identifiziert die aktuelle Task als
den Besitzer. Wenn jedoch die aktuelle Task der Besitzer der
Gleitkommaeinheit ist, war die aktuelle Task die letzte
Task, welche die Gleitkommaeinheit verwendet hat (der Gleit
kommaabschnitt des Registerzustandes der aktuellen Task ist
bereits in der Gleitkommaeinheit gespeichert) und es braucht
keine Aktion im Hinblick auf die Gleitkommaeinheit unternom
men zu werden, TS braucht nicht gesetzt zu werden und es
tritt keine Ausnahme auf. Die Ausführung des Behandlers ver
anlaßt den Prozessor außerdem, die TS-Anzeige so zu ändern,
daß sie anzeigt, daß die Gleitkommaeinheit der aktuellen
Task gehört (was auch als "verfügbar" oder "aktiviert" be
zeichnet wird).
Bei der Beendigung des Ereignisbehandlers wird die Aus
führung der aktuellen Task wiederaufgenommen, indem derje
nige Gleitkommabefehl erneut gestartet wird, welcher die
"Einrichtung nicht verfügbar"-Ausnahme verursachte. Da die
TS-Anzeige derart geändert wurde, daß sie die Verfügbarkeit
der Gleitkommaeinheit anzeigt, wird die Ausführung der fol
genden Gleitkommabefehle nicht zu weiteren "Einrichtung
nicht verfügbar"-Ausnahmen führen. Während der nächsten par
tiellen Kontextumschaltung wird die TS-Anzeige jedoch geän
dert, damit sie anzeigt, daß eine partielle Kontextumschal
tung durchgeführt wurde. Wenn und falls dann die Ausführung
eines weiteren Gleitkommabefehls versucht wird, wird folg
lich eine weitere "Einrichtung nicht verfügbar"-Ausnahme er
zeugt und der Ereignisbehandler wird erneut ausgeführt. Auf
diese Weise ermöglicht es die TS-Anzeige dem Betriebssystem,
die Speicherung und das Laden der Gleitkommaregisterdatei zu
verzögern und möglicherweise zu vermeiden. Auf diese Weise
wird der Systemaufwand für die Taskumschaltung verringert,
indem die Anzahl der zu speichernden und zu ladenden Regi
ster verringert wird.
Während ein Betriebssystem beschrieben wurde, bei dem
der Gleitkommazustand während Taskumschaltungen nicht ge
speichert oder wiederhergestellt wird, können alternative
Implementierungen eine beliebige Anzahl anderer Techniken
verwenden. Wie im Vorangegangenen erwähnt wurde, könnte ein
Betriebssystem beispielsweise derart implementiert werden,
daß es stets den gesamten Registerzustand bei jeder Taskum
schaltung speichert und wiederherstellt.
Neben den verschiedenen Zeitpunkten, zu denen der
Gleitkommazustand eines Prozesses gespeichert werden kann
(z. B. während Kontextumschaltungen, als Antwort auf ein
"Einrichtung nicht verfügbar"-Ereignis usw.) gibt es außer
dem verschiedene Techniken zur Speicherung des Gleitkommazu
standes. Beispielsweise kann ein Betriebssystem derart im
plementiert sein, daß es den gesamten Gleitkommazustand
speichert (was im folgenden als eine "einfache Taskumschal
tung" bezeichnet wird). Alternativ kann ein Betriebssystem
derart implementiert sein, daß es den Inhalt nur derjenigen
Gleitkommaregister speichert, deren zugehörige Tags einen
nicht-leeren Zustand anzeigen (was hier als "minimale Task
umschaltung" bezeichnet wird). Hierbei speichert das Be
triebssystem nur den Inhalt derjenigen Gleitkommaregister,
die nützliche Daten enthalten. Auf diese Weise wird der Sy
stemaufwand zur Speicherung des Gleitkommazustandes dadurch
verringert, daß die Anzahl der zu speichernden Register ver
ringert wird.
Fig. 2 zeigt ein Ablaufdiagramm, welches die Ausfüh
rung eines Befehls mit Hilfe des Pentium-Prozessors veran
schaulicht. Das Ablaufdiagramm beginnt mit dem Schritt 200;
wonach es mit dem Schritt 205 weitergeht.
Wie im Schritt 205 gezeigt ist, wird auf einen Satz von
Bits als Befehl zugegriffen und der Ablauf geht mit dem
Schritt 210 weiter. Der Bitsatz enthält einen Befehlscode,
welcher die Operation(en) kennzeichnet, welche von dem Be
fehl auszuführen ist (sind).
Im Schritt 210 wird bestimmt, ob der Befehlscode gültig
ist. Wenn der Befehlscode nicht gültig ist, geht der Ablauf
mit dem Schritt 215 weiter. Andernfalls geht der Ablauf mit
dem Schritt 220 weiter.
Wie im Schritt 215 gezeigt ist, wird eine "ungültiger
Befehlscode"-Ausnahme erzeugt und der geeignete Ereignisbe
handler ausgeführt. Dieser Ereignisbehandler kann derart im
plementiert sein, daß er den Prozessor veranlaßt, eine Nach
richt anzuzeigen, die Ausführung der aktuellen Task abzubre
chen und mit der Ausführung anderer Tasks fortzufahren. Na
türlich können alternative Ausführungsbeispiele diesen Er
eignisbehandler in beliebig vielen Varianten implementieren.
Im Schritt 220 wird festgestellt, ob der Befehl ein
Gleitkommabefehl ist. Wenn der Befehl kein Gleitkommabefehl
ist, geht der Ablauf mit dem Schritt 225 weiter. Andernfalls
geht der Ablauf mit dem Schritt 230 weiter.
Wie im Schritt 225 gezeigt ist, führt der Prozessor den
Befehl aus. Da dieser Schritt nicht notwendig ist, um die
Erfindung zu beschreiben, wird er hier nicht weiter erläu
tert.
Wie im Schritt 230 gezeigt ist, wird festgestellt, ob
die EM-Anzeige gleich 1 ist (gemäß der beschriebenen Soft
ware-Konvention ist dies der Fall, wenn die Gleitkommaein
heit emuliert werden soll) und ob die TS-Anzeige gleich 1
ist (gemäß der beschriebenen Software-Konvention gilt dies,
wenn eine partielle Kontextumschaltung durchgeführt wurde).
Wenn die EM-Anzeige und/oder die TS-Anzeige gleich 1 sind,
geht der Ablauf mit dem Schritt 235 weiter. Ansonsten geht
der Ablauf mit dem Schritt 240 weiter.
Im Schritt 235 wird die "Einrichtung nicht verfügbar"-
Ausnahme erzeugt und der zugehörige Ereignisbehandler wird
ausgeführt. Der zugehörige Ereignisbehandler kann derart im
plementiert sein, daß er als Antwort auf dieses Ereignis die
EM- und die TS-Anzeige abfragt. Wenn die EM-Anzeige gleich 1
ist, dann kann der Ereignisbehandler so implementiert sein,
daß er den Prozessor veranlaßt, den Befehl durch Emulation
der Gleitkommaeinheit auszuführen und die Ausführung des
nächsten Befehls wiederaufzunehmen (des Befehls, welcher dem
im Schritt 205 empfangenen Befehl logisch folgt). Wenn die
TS-Anzeige gleich 1 ist, dann kann der Ereignisbehandler so
implementiert sein, daß er so, wie oben unter Bezugnahme auf
die partielle Kontextumschaltungen beschrieben wurde, arbei
tet (Speicherung des Inhalts der Gleitkommaeinheit und ggf.
Wiederherstellung des richtigen Gleitkommazustandes) und den
Prozessor veranlaßt, die Ausführung wiederaufzunehmen, indem
er die Ausführung des im Schritt 205 empfangenen Befehls er
neut startet. Selbstverständlich können alternative Ausfüh
rungsbeispiele diesen Ereignisbehandler auf jede beliebige
Art implementieren.
Wenn bestimmte numerische Fehler während der Ausführung
eines Gleitkommabefehls erzeugt werden, bleiben diese Fehler
bis zu dem Versuch der Ausführung des nächsten Gleitkommabe
fehls anhängig, dessen Ausführung zur Bearbeitung der uner
ledigten numerischen Gleitkommafehler unterbrochen werden
kann. Wie im Schritt 240 gezeigt ist, wird festgestellt, ob
es irgendwelche derartigen unerledigten Fehler gibt. Wenn es
derartige unerledigte Fehler gibt, geht der Ablauf mit dem
Schritt 245 weiter. Ansonsten geht der Ablauf mit dem
Schritt 250 weiter.
Im Schritt 245 wird ein "unerledigter Gleitkommafeh
ler"-Ereignis erzeugt. Als Antwort auf dieses Ereignis
stellt der Prozessor fest, ob der Gleitkommafehler maskiert
ist. Falls dies der Fall ist, versucht der Prozessor das Er
eignis intern mit Hilfe eines Mikrobefehlscodes zu bearbei
ten, und die Gleitkommaeinheit wird "mit Mikrobefehlen er
neut gestartet". Der Begriff Mikro-Neustart bezieht sich auf
die Technik der Bearbeitung eines Ereignisses, ohne irgend
welche Nicht-Mikrobefehlscode-Behandler auszuführen (welche
auch als Betriebssystem-Ereignisbehandler bezeichnet wer
den). Ein derartiges Ereignis wird als internes Ereignis be
zeichnet (es wird auch als für Software unsichtbares Ereig
nis bezeichnet), da das Ereignis intern von dem Prozessor
bearbeitet wird und folglich nicht die Ausführung eines ex
ternen Betriebssystembehandlers erfordert. Wenn der Gleit
kommafehler nicht maskiert ist, ist das Ereignis dagegen ein
externes Ereignis (auch als "für Software sichtbares Ereig
nis" bezeichnet) und der zu dem Ereignis gehörige Ereignis
behandler wird ausgführt. Dieser Ereignisbehandler kann der
art implementiert sein, daß er den Fehler bedient und den
Prozessor zur Wiederaufnahme der Ausführung durch Neustart
der Ausführung des im Schritt 205 empfangenen Befehls veran
laßt. Diese Technik des Neustarts eines Befehls wird als ein
"Makro-Neustart" oder ein "Neustart auf Befehlsebene" be
zeichnet. Natürlich können alternative Ausführungsbeispiele
diesen Nicht-Mikrobefehlscode-Ereignisbehandler auf jede be
liebige Weise implementieren.
Wie im Schritt 250 gezeigt, wird der Gleitkommabefehl
ausgeführt. Während einer derartigen Ausführung werden die
Tags (soweit erforderlich) geändert, numerische Fehler, die
jetzt bedient werden können, werden berichtet, und alle an
deren numerischen Fehler bleiben anhängig.
Eine Einschränkung der bekannten Intel-Architektur-Pro
zessor-Familie (zu der der Pentium-Prozessor gehört) sowie
von bestimmten anderen Universalprozessoren besteht darin,
daß sie keinen Befehlssatz zum Bearbeiten von gepackten Da
ten enthalten.
Der Erfindung liegt die Aufgabe zugrunde, die Ausfüh
rung von Befehlen für die Bearbeitung von gepackten Daten in
einer Datenverarbeitungseinrichtung in einer Weise zu ermög
lichen, welche für existierende Software, die für bekannte
Datenverarbeitungseinrichtungen die keine Ausführung von
Befehlen für gepackte Daten aber eine Ausführung von Befeh
len an skalaren und/oder Gleitkommadaten ermöglichten, ge
schrieben wurde, kompatibel ist.
Diese Aufgabe wird erfindungsgemäß durch Verfahren mit
den Merkmalen der Patentansprüche 1, 17, 21, 32 bzw. 35 ge
löst. Die erfindungsgemäßen Verfahren bewirken das Ausführen
verschiedener Befehlssätze, die einen Prozessor veranlassen,
Operationen an verschiedenen Datenarten durchzuführen, in
einer Weise, die für verschiedene Betriebssystemtechniken
unsichtbar ist, die gute Programmierpraktiken unterstützt
und die für existierende Software-Konventionen unsichtbar
ist.
Bei einer Ausführungsform der Erfindung führt eine Da
tenverarbeitungseinrichtung eine erste Befehlsfolge einer
ersten Befehlsart (d. h., eines ersten Befehlssatzes) auf
einer Registerdatei aus, die der Software wenigstens logisch
als eine einzige logische Registerdatei erscheint. Während
die Datenverarbeitungseinrichtung die erste Befehlsfolge
ausführt, wird die einzige logische Registerdatei als eine
flache Registerdatei betrieben. Dann führt die Datenverar
beitungseinrichtung einen ersten Befehl einer zweiten Be
fehlsart (d. h., eines zweiten Befehlssatzes) mit Hilfe der
logischen Registerdatei aus. Während die Datenverarbeitungs
einrichtung den ersten Befehl der zweiten Art ausführt, wird
die logische Registerdatei jedoch als eine Registerdatei be
trieben, auf die als Stapel Bezug genommen wird. Außerdem
ändert die Datenverarbeitungseinrichtung alle Tags in einem
Tagsatz, der der einzigen logischen Registerdatei ent
spricht, in einen Nicht-leer-Zustand, und zwar irgendwann
zwischen dem Start der Ausführung der ersten Befehlsfolge
und der Beendigung der Ausführung des ersten Befehls der
zweiten Art. Die Tags kennzeichnen, ob die Register in der
einzelnen logischen Registerdatei leer oder nicht-leer sind.
Ein anderes Ausführungsbeispiel der Erfindung kenn
zeichnet ein Verfahren zum Implementieren einer partiellen
Kontextumschaltung bei der Ausführung von Befehlen für
skalare Daten und Befehlen für gepackte Daten. Gemäß diesem
Verfahren empfängt eine Datenverarbeitungseinrichtung einen
zu einer ersten Routine gehörigen Befehl. Die Ausführung des
Befehls erfordert entweder eine skalare Operation oder eine
Operation an gepackten Daten. Die Datenverarbeitungseinrich
tung stellt dann fest, ob die Datei, die wenigstens der
Software logisch als eine einzelne logische Registerdatei
für die Ausführung sowohl von skalaren als auch gepackten
Datenoperationen erscheint, aufgrund einer partiellen Kon
textumschaltung nicht verfügbar ist. Wenn die logische Re
gisterdatei nicht verfügbar ist, dann wird die Ausführung
der ersten Routine für die Ausführung einer zweiten Routine
unterbrochen, welche veranlaßt, daß der Inhalt der logischen
Registerdatei in einen Speicher kopiert wird. Wenn die logi
sche Registerdatei verfügbar ist, dann wird der Befehl je
doch auf der logischen Registerdatei ausgeführt.
Bei einem weiteren Ausführungsbeispiel der Erfindung
wird ein gepackter Datenbefehl empfangen, dessen Ausführung
veranlaßt, daß ein gepacktes Datenelement in ein Register
geschrieben wird, welches der Software wenigstens logisch
als ein Register in einer logischen Registerdatei erscheint,
die außerdem zum Speichern von Gleitkommadaten verwendet
wird. Als Folge der Ausführung dieses Befehls wird das ge
packte Datenelement in das Mantissenfeld des logischen Regi
sters geschrieben, und es wird ein Wert in das Vorzeichen-
und das Exponentenfeld des logischen Registers geschrieben,
welcher entweder keine Zahl oder unendlich darstellt.
Vorteilhafte Weiterbildungen der Erfindung sind in den
Unteransprüchen gekennzeichnet.
Die Erfindung ist am besten anhand der folgenden Be
schreibung und der zugehörigen Zeichnungen zu verstehen,
welche die Erfindung veranschaulichen. In der Zeichnung
zeigt:
Fig. 1 ein Blockschaltbild, welches ein beispielhaftes
Computersystem veranschaulicht, in welchem der Pentium-Pro
zessor eingesetzt ist;
Fig. 2 zeigt ein Ablaufdiagramm, welches die Ausfüh
rung eines Befehls durch den Pentium-Prozessor veranschau
licht;
Fig. 3A ist ein Funktionsdiagramm, welches das Alia
sing eines Zustands gepackter Daten und eines Gleitkommazu
standes gemäß einem Ausführungsbeispiel der vorliegenden Er
findung veranschaulicht;
Fig. 3B und 3C veranschaulichen die Abbildung der phy
sikalischen Gleitkommaregister und Register für gepackte Da
ten in Bezug auf die logischen Gleitkommaregister;
Fig. 3D veranschaulicht einen Ausführungsstrom mit Be
fehlen für gepackte Daten und Gleitkommabefehlen;
Fig. 4A zeigt ein Ablaufdiagramm, welches einen Teil
eines Verfahrens veranschaulicht, das Gleitkommabefehle und
Befehle für gepackte Daten auf eine Weise ausführt, die kom
patibel mit existierender Software ist, die für verschiedene
Betriebssystemtechniken unsichtbar ist und gemäß einem Aus
führungsbeispiel der Erfindung wirksame Programmiertechniken
unterstützt;
Fig. 4B zeigt ein Ablaufdiagramm, welches den Rest des
zum Teil in Fig. 4A veranschaulichten Verfahrens veran
schaulicht;
Fig. 5 zeigt ein Blockschaltbild, welches ein bei
spielhaftes Computersystem gemäß einem Ausführungsbeispiel
der Erfindung veranschaulicht;
Fig. 6A zeigt ein Blockschaltbild, welches eine Ein
richtung zum Aliasing des Zustandes des Registers für ge
packte Daten auf den Gleitkommazustand mit Hilfe von zwei
physikalischen Registerdateien gemäß einem Ausführungsbei
spiel der Erfindung veranschaulicht;
Fig. 6B zeigt ein Blockschaltbild, welches einen ver
größerten Ausschnitt der Gleitkommastapelreferenzdatei von
Fig. 6A gemäß Ausführungsbeispielen der Erfindung veran
schaulicht;
Fig. 7A zeigt ein Ablaufdiagramm, welches einen Teil
eines Verfahrens gemäß einem Ausführungsbeispiel der Erfin
dung veranschaulicht, wobei das Verfahren dazu dient, Befeh
le für gepackte Daten auf einem Registersatz, der auf einem
Satz von Gleitkommaregistern aliased ist, in einer Weise
auszuführen, welche für verschiedene Betriebssystemtechniken
unsichtbar ist, welche gute Programmierpraktiken unterstützt
und welche unter Verwendung der Hardwareanordnung gemäß
Fig. 6A realisiert werden kann;
Fig. 7B zeigt ein Ablaufdiagramm, welches einen weite
ren Teil des in Fig. 7A teilweise veranschaulichten Verfah
rens veranschaulicht;
Fig. 7C zeigt ein Ablaufdiagramm, welches den Rest des
in den Fig. 7A und 7B teilweise veranschaulichten Verfah
rens veranschaulicht;
Fig. 8 zeigt ein Ablaufdiagramm, welches ein Verfahren
zum Ausführen des Schrittes 734 der Fig. 7C gemäß einem
Ausführungsbeispiel der Erfindung veranschaulicht;
Fig. 9 zeigt ein Ablaufdiagramm, welches ein Verfahren
zum Ausführen des Schrittes 728 der Fig. 7B gemäß einem
Ausführungsbeispiel der Erfindung veranschaulicht,
Fig. 10 zeigt ein Blockschaltbild, welches den Daten
fluß durch eine Einrichtung zum Aliasing des gepackten Da
tenzustandes auf den Gleitkommazustand unter Verwendung ei
ner einzelnen Registerdatei gemäß einem anderen Ausführungs
beispiel der Erfindung veranschaulicht;
Fig. 11A zeigt einen Teil eines Verfahrens gemäß einem
weiteren Ausführungsbeispiel der Erfindung, um Befehle für
gepackte Daten und Gleitkommabefehle auf einer einzigen
aliased Registerdatei in einer Weise auszuführen, die mit
existierender Software kompatibel ist, die für verschiedene
Betriebssystemtechniken unsichtbar ist, die gute Program
mierpraktiken unterstützt und unter Verwendung der Hardware
anordnung gemäß Fig. 10 realisiert werden kann;
Fig. 11B zeigt ein Ablaufdiagramm, welches einen ande
ren Teil des in Fig. 11A teilweise veranschaulichten Ver
fahrens veranschaulicht;
Fig. 11C zeigt ein Ablaufdiagramm, welches den Rest
des in den Fig. 11A und 11B teilweise veranschaulichten
Verfahrens veranschaulicht;
Fig. 12A zeigt ein Gleitkommaspeicherformat gemäß ei
nem unter Bezugnahme auf Fig. 10 beschriebenen Ausführungs
beispiel der Erfindung;
Fig. 12B zeigt das Speicherformat für gepackte Daten
gemäß dem unter Bezugnahme auf Fig. 10 beschriebenen Aus
führungsbeispiel;
Fig. 12C veranschaulicht ein Speicherformat für Ganz
zahldaten gemäß dem unter Bezugnahme auf Fig. 10 beschrie
benen Ausführungsbeispiel;
Fig. 13 zeigt ein Verfahren gemäß einem Ausführungs
beispiel der Erfindung, um den Schritt 1138 der Fig. 11B
auszuführen, wenn die unter Bezugnahme auf die Fig. 12A,
12B und 12C beschriebenen Speicherformate implementiert
sind;
Fig. 14 zeigt ein Ablaufdiagramm, welches ein Verfah
ren zum Löschen der Tags gemäß einem Ausführungsbeispiel der
Erfindung veranschaulicht;
Fig. 15A zeigt einen Ausführungsstrom mit Befehlen für
gepackte Daten und Gleitkommabefehlen, um dasjenige Zeitin
tervall zu veranschaulichen, währenddessen separate physika
lische Registerdateien, die aliased sind, aktualisiert wer
den können; und
Fig. 15B zeigt einen weiteren Ausführungsstrom mit ge
packten Datenbefehlen und Gleitkommabefehlen, um dasjenige
Zeitintervall zu veranschaulichen, währenddessen separate
physikalische Registerdateien, die aliased sind, aktuali
siert werden können.
In der folgenden Beschreibung sind zahlreiche spezielle
Details angegeben, um ein vollständiges Verständnis der Er
findung zu ermöglichen. Es sollte jedoch klar sein, daß die
Erfindung ohne diese speziellen Details ausgeführt werden
kann. In anderen Fällen sind bekannte Schaltungen, Struk
turen und Techniken nicht detailliert dargestellt, damit die
Erfindung nicht schwer verständlich ist.
Gemäß einem Ausführungsbeispiel der Erfindung be
schreibt diese Anmeldung ein Verfahren und eine Einrichtung
zum Ausführen verschiedener Befehlssätze, welche einen Pro
zessor veranlassen, Operationen an verschiedenen Datenarten
in einer Weise auszuführen, die für verschiedene Betriebs
systemtechniken unsichtbar ist, die gute Programmierprak
tiken unterstützt und die für existierende Software unsicht
bar ist. Um dies zu erreichen, werden die verschiedenen Be
fehlssätze, welche einen Prozessor zur Ausführung von Ope
rationen an verschiedenen Datenarten veranlassen, auf einer
Registerdatei ausgeführt, welche der Software wenigstens
logisch als eine einzige aliased Registerdatei erscheint.
Die als Folge der Ausführung der verschiedenen Befehlssätze
ausgeführten Datenartoperationen können von beliebiger Art
sein. Beispielsweise kann ein Befehlssatz den Prozessor zur
Ausführung skalarer Operationen (Gleitkomma und/oder Ganz
zahl) veranlassen und ein anderer Befehlssatz kann den Pro
zessor zur Ausführung gepackter Operationen (Gleitkomma
und/oder Ganzzahl) veranlassen. Bei einem weiteren Beispiel
kann ein Befehlssatz den Prozessor zur Ausführung von Gleit
kommaoperationen (skalare und/oder gepackte) veranlassen und
ein anderer Befehlssatz kann den Prozessor zur Ausführung
von Ganzzahloperationen (skalare und/oder gepackte) veran
lassen. Bei einem anderen Beispiel kann die einzelne aliased
Registerdatei als eine Registerdatei betrieben werden, auf
die als Stapel Bezug genommen wird, und als eine flache bzw.
einfache Registerdatei (flat register file). Außerdem be
schreibt diese Anmeldung ein Verfahren und eine Einrichtung,
um diese verschiedenen Befehlssätze mit Hilfe separater phy
sikalischer Registerdateien auszuführen, welche der Software
logisch als eine einzige aliased Registerdatei erscheinen.
Außerdem beschreibt diese Anmeldung ein Verfahren und eine
Einrichtung, um diese verschiedenen Befehlssätze mit Hilfe
einer einzigen physikalischen Registerdatei auszuführen.
Der Klarheit wegen wird die Erfindung im Hinblick auf
die Ausführung von Gleitkommabefehlen und gepackten Daten
befehlen (Gleitkomma und/oder Ganzzahl) beschrieben. Es
sollte jedoch klar sein, daß Operationen für eine beliebige
Anzahl von unterschiedlichen Datenarten durchgeführt werden
könnten und daß die Erfindung keineswegs auf Gleitkomma
operationen und gepackte Datenoperationen beschränkt ist.
Fig. 3A zeigt ein Funktionsdiagramm, welches das
Aliasing des gepackten Datenzustandes und des Gleitkomma
zustandes gemäß einem Ausführungsbeispiel der Erfindung
veranschaulicht. Fig. 3A zeigt einen Satz von Gleitkomma
registern 300 zur Speicherung von Gleitkommadaten (der hier
in als der Gleitkommazustand bezeichnet wird) und einen Satz
von Registern 310 für gepackte Daten zur Speicherung von ge
packten Daten (der hierin als der gepackte Datenzustand be
zeichnet wird). Die Schreibweise PDn wird hierbei zur Be
zeichnung der physikalischen Orte der Register für gepackte
Daten verwendet. Fig. 3A zeigt außerdem, daß der gepackte
Datenzustand auf dem Gleitkommazustand aliased ist. Das
heißt, daß es wenigstens der Software erscheint, als ob die
Gleitkommabefehle und die gepackten Datenbefehle auf dem
gleichen Satz logischer Register ausgeführt werden. Es gibt
zahlreiche Techniken, um dieses Aliasing zu realisieren,
wozu die Verwendung mehrerer separater physikalischer Re
gisterdateien oder einer einzigen physikalischen Register
datei zählen. Beispiele derartiger Techniken sind im folgen
den unter Bezugnahme auf die Fig. 4 bis 13 beschrieben.
Wie im Vorangegangenen beschrieben wurde, sind exi
stierende Betriebssysteme derart implementiert, daß sie als
Folge von Multitasking den Prozessor zur Speicherung des
Gleitkommazustandes veranlassen. Da der gepackte Daten
zustand auf dem Gleitkommazustand aliased ist, veranlassen
die gleichen Betriebssysteme den Prozessor, einen gepackten
Datenzustand zu speichern, der auf dem Gleitkommazustand
aliased ist. Folglich erfordert es die Erfindung nicht, daß
alte Betriebssystem-Taskumschaltungsroutine(n) (natürlich
können Taskumschaltungsroutinen als ein oder mehrere Er
eignisbehandler implementiert sein) oder Ereignisbehandler
modifiziert werden oder neue Betriebssystem-Ereignisbehand
ler geschrieben werden. Daher muß kein neues oder modifi
ziertes Betriebssystem entwickelt werden, um den gepackten
Datenzustand beim Multitasking zu speichern. Damit werden,
die Zeit und die Kosten, die zur Entwicklung eines der
artigen Betriebssystems erforderlich sind, nicht benötigt.
Außerdem werden bei einem Ausführungsbeispiel alle von der
Ausführung der gepackten Datenbefehle erzeugten Ereignisse
intern vom Prozessor bearbeitet oder auf existierende Er
eignisse abgebildet, deren zugehörige Betriebssystem-Ereig
nisbehandler diese Ereignisse bearbeiten können. Folglich
werden die gepackten Datenbefehle in einer für das Betriebs
system unsichtbaren Weise ausgeführt.
Fig. 3A zeigt außerdem einen Satz von Gleitkommatags
320 und einen Satz von Tags 330 für gepackte Daten. Die
Gleitkommatags 320 operieren in ähnlicher Weise wie die Tags
150, welche unter Bezugnahme auf die Fig. 1 beschrieben
wurden. Folglich enthält jedes Tag zwei Bits, welche
anzeigen, ob der Inhalt des zugehörigen Gleitkommaregisters
leer oder nicht-leer ist (z. B. gültig, speziell oder null).
Die Tags 330 für gepackte Daten gehören zu den Registern 310
für gepackte Daten und sind auf den Gleitkommatags 320
aliased. Obwohl jedes Tag mit Hilfe von zwei Bits
implementiert werden kann, könnten alternative Ausfüh
rungsbeispiele nur ein Bit für jedes Tag speichern. Jedes
dieser Ein-Bit-Tags kennzeichnet entweder leer oder nicht-
leer. Bei derartigen Ausführungsbeispielen können diese Ein-
Bit-Tags derart realisiert werden, daß sie für Software als
aus zwei Bits bestehend erscheinen, indem der entsprechende
Zwei-Bit-Tagwert bestimmt wird, wenn die Tagwerte benötigt
werden. Betriebssysteme, die mit einer minimalen Taskum
schaltung arbeiten, lagern den Inhalt nur derjenigen Re
gister aus, deren zugehörige Tags den nicht-leeren Zustand
anzeigen. Da die Tags aliased sind, lagert ein derartiges
Betriebssystem jeden notwendigen gepackten Datenzustand und
Gleitkommadatenzustand aus. Dagegen lagern Betriebssysteme,
bei denen eine einfache Taskumschaltung implementiert ist,
den gesamten Inhalt der aliased logischen Registerdatei aus,
unabhängig von dem Zustand der Tags.
Bei einem Ausführungsbeispiel werden die Gleitkomma
register 300 auf eine ähnliche Weise wie die in Fig. 1
beschriebenen Gleitkommaregister 145 betrieben. Folglich
zeigt Fig. 3A zusätzlich ein Gleitkommastatusregister 340
mit einem Stapelkopfendefeld 350. Das Stapelkopfendefeld 350
wird zum Speichern einer Stapelkopfendeanzeige (TOS) zur
Kennzeichnung eines der Gleitkommaregister 300 verwendet.
Wenn die Gleitkommaregister 300 als ein Stapel betrieben
werden, werden Operationen in Bezug auf das obere Register
im Stapel durchgeführt im Gegensatz zu den physikalischen
Orten der Register. Dagegen werden die Register 310 für ge
packte Daten als feste Registerdatei betrieben (welche auch
als eine Registerdatei mit direktem Zugriff bezeichnet
wird). Folglich bezeichnen die gepackten Datenbefehle die
physikalischen Orte der zu verwendenden Register. Die Re
gister 310 für gepackte Daten werden auf die physikalischen
Orte der Gleitkommaregister 300 abgebildet und diese Ab
bildung ändert sich nicht, wenn sich das Stapelkopfende ver
ändert. Folglich erscheint es wenigstens der Software, als
ob eine einzige logische Registerdatei existiert, die als
Registerdatei auf die als Stapel Bezug genommen wird, oder
als einfache bzw. flache Registerdatei betrieben werden
kann.
Fig. 3B und 3C zeigen die Abbildung der aliased
Gleitkommaregister 300 und der Gleitkommatags 320 in Bezug
auf die Register 310 für gepackte Daten und die Tags 330 für
gepackte Daten, wie sie in Fig. 3A gezeigt sind. Wie oben
erörtert wurde, wird in der Gleitkommaumgebung jedes Re
gister n relativ zu dem durch den TOS-Zeiger gekennzeichne
ten Gleitkommaregister spezifiziert. Zwei Fälle sind in den
Fig. 3B und 3C dargestellt. Jede dieser Figuren stellt
die Beziehung dar zwischen den logischen oder für den Pro
grammierer sichtbaren Gleitkommaregistern (Stapel) und den
logischen oder für den Programmierer sichtbaren Registern
für gepackte Daten. Der in den Fig. 3B und 3C gezeigte
innere Kreis stellt die physikalischen Gleitkommare
gister/Register für gepackte Daten und die zugehörigen Tags
dar und der äußere Kreis stellt die logischen Gleitkommare
gister dar, wie auf sie von dem Stapelkopfendezeiger 370
verwiesen wird. Wie in Fig. 3B gezeigt ist, zeigt der Sta
pelkopfendezeiger 370 auf das physikalische Gleitkommare
gister/Register für gepackte Daten 0. Folglich entsprechen
die logischen Gleitkommaregister den physikalischen Gleit
kommaregistern/Register für gepackte Daten. Wenn der Stapel
kopfendezeiger 370 von einem Gleitkommabefehl geändert wird,
welcher entweder ein Einkellern oder ein Auskellern verur
sacht, ändert sich der Stapelkopfendezeiger 370 entspre
chend, wie in der Figur gezeigt ist. Ein Einkellern wird
durch die Drehung des Stapelkopfendezeigers gegen den Uhr
zeigersinn in der Figur dargestellt, und eine Gleitkommaaus
kelleroperation führt dazu, daß sich der Stapelkopfende
zeiger in Uhrzeigerrichtung dreht.
Bei dem in Fig. 3C dargestellten Ausführungsbeispiel
entspricht das logische Gleitkommaregister ST0 nicht dem
physikalischen Register 0. Folglich zeigt der Stapelkopf
endezeiger 370 in dem in Fig. 3C dargestellten Fall auf das
physikalische Gleitkommaregister/Register für gepackte Daten
2, welches dem logischen Gleitkommaregister ST0 entspricht.
Auf alle anderen logischen Gleitkommaregister wird unter Be
zugnahme auf den TOS 370 zugegriffen. Obwohl ein Ausfüh
rungsbeispiel beschrieben wurde, bei dem die Gleitkommare
gister als Stapel betrieben werden und die Register für
gepackte Daten als feste Registerdatei betrieben werden,
können alternative Ausführungsbeispiele diese Registersätze
beliebig implementieren. Obwohl ein Ausführungsbeispiel
unter Bezugnahme auf Gleitkommaoperationen und gepackte
Datenoperationen beschrieben wurde, sollte klar sein, daß
diese Technik zum Aliasing einer beliebigen festen Register
datei auf eine beliebige Registerdatei, auf die als Stapel
Bezug genommen wird, verwendet werden kann, unabhängig von
der Art der darauf ausgeführten Operationen.
Der gepackte Datenzustand kann auf einen beliebigen
Abschnitt oder den ganzen Gleitkommazustand aliased werden.
Bei einem Ausführungsbeispiel ist der gepackte Datenzustand
auf den Mantissenfeldern des Gleitkommazustandes aliased.
Außerdem kann das Aliasing vollständig oder partiell sein.
Ein vollständiges Aliasing wird verwendet, um ein Ausfüh
rungsbeispiel zu bezeichnen, bei dem der gesamte Inhalt der
Register aliased ist. Ein partielles Aliasing wird weiter
unter Bezugnahme auf Fig. 6A beschrieben.
Fig. 3D zeigt ein Blockschaltbild, welches die Aus
führung der Gleitkommabefehle und der gepackten Datenbefehle
über die Zeit gemäß einem Ausführungsbeispiel der Erfindung
veranschaulicht. Fig. 3D zeigt in chronologischer
Ausführungsreihenfolge einen ersten Satz von Gleitkomma
befehlen 380, einen Satz von gepackten Datenbefehlen 382 und
einen zweiten Satz von Gleitkommabefehlen 384. Die Ausfüh
rung des Satzes von gepackten Datenbefehlen 382 beginnt zum
Zeitpunkt T1 und endet zum Zeitpunkt T2, während die Ausfüh
rung des Satzes von Gleitkommabefehlen zum Zeitpunkt T3 be
ginnt. Andere Befehle können zwischen der Ausführung des ge
nannten Satzes von gepackten Datenbefehlen 382 und dem zwei
ten Satz von Gleitkommabefehlen 384 ausgeführt werden oder
nicht. Ein erstes Zeitintervall 386 kennzeichnet die Zeit
zwischen dem Zeitpunkt T1 und dem Zeitpunkt T3, während ein
zweites Zeitintervall 388 die Zeit zwischen dem Zeitpunkt T2
und T3 kennzeichnet.
Da die Gleitkommazustände und die gepackten Daten
zustände in einer aliased Registerdatei gespeichert sind,
sollten die Tags vor der Ausführung des zweiten Satzes von
Gleitkommabefehlen 384 auf leer geändert werden. Ansonsten
könnte eine Stapelüberlauf-Ausnahme erzeugt werden. Folglich
werden die Tags irgendwann während des ersten Zeitintervalls
386 in leer geändert. Dies kann auf zahlreiche verschiedene
Weisen geschehen. Beispielsweise kann ein Ausführungsbei
spiel dies dadurch erreichen, daß: 1) die Ausführung des
ersten gepackten Datenbefehls des Satzes von gepackten Da
tenbefehlen 382 veranlaßt wird, die Tags in den leeren Zu
stand zu ändern; 2) die Ausführung jedes gepackten Daten
befehls in dem Satz der gepackten Datenbefehle 382 veranlaßt
wird, die Tags in den leeren Zustand zu ändern; 3) die Tags
beim Versuch, den ersten Gleitkommabefehl auszuführen, des
sen Ausführung die aliased Registerdatei modifiziert, in den
leeren Zustand geändert werden; usw. Diese Ausführungsbei
spiele bleiben für das Betriebssystem unsichtbar, und zwar
für existierende Betriebssysteme, die eine einfache Kontext
umschaltung unterstützen (Speichern und Wiederherstellen des
gesamten Registerzustandes bei jeder Taskumschaltung), da
der gepackte Datenzustand zusammen mit dem Rest des
Registerzustandes gespeichert und wiederhergestellt wird.
Um kompatibel mit Betriebssystemen zu bleiben, die
einfache und/oder minimale Kontextumschaltungen unterstüt
zen, führt die Ausführung des Satzes von gepackten Datenbe
fehlen 382 bei einem anderen Ausführungsbeispiel dazu, daß
die Tags in den nicht-leeren Zustand in dem ersten Intervall
386 geändert werden, sofern kein durch den Block 390 darge
stellter Satz von Übergangsbefehlen nach dem Zeitpunkt T2
und vor dem Zeitpunkt T3 (dem Zeitpunkt, zu dem der zweite
Satz von Gleitkommabefehlen 384 begonnen wird) ausgeführt
wird. Man nehme beispielsweise an, daß der Satz von gepack
ten Datenbefehlen 382 zu einer Task A gehört. Außerdem nehme
man an, daß die Task A von einer vollständigen Taskumschal
tung (d. h. keine partielle Taskumschaltung) vor der Ausfüh
rung des Satzes von Übergangsbefehlen 390 unterbrochen wird.
Da er eine vollständige Taskumschaltung ausführt, enthält
der Taskumschaltungsbehandler Gleitkommabefehle (welche
durch den zweiten Satz von Gleitkommabefehlen 384 darge
stellt sind, und bei diesem Beispiel als "FP-Taskumschal
tungsroutine" bezeichnet werden), um den Gleitkommazu
stand/gepackten Datenzustand zu speichern. Da der Satz von
Übergangsbefehlen 390 nicht ausgeführt wurde, ändert der
Prozessor irgendwann vor der Ausführung der FP-Taskumschal
tungsroutine die Tags in den nicht-leeren Zustand. Folglich
lagert die FP-Taskumschaltungsroutine, ob sie minimal oder
einfach ist, den Inhalt der gesamten aliased Registerdatei
(in diesem Beispiel den gepackten Datenzustand der Task A)
aus. Dagegen ändert der Prozessor die Tags irgendwann wäh
rend des zweiten Zeitintervalls 388 in den leeren Zustand,
wenn der Satz der Übergangsbefehle 390 ausgeführt ist.
Folglich ändert der Prozessor unabhängig davon, ob eine
Taskumschaltung die Task A nach der Ausführung des Satzes
der Übergangsbefehle 390 unterbricht, die Tags irgendwann
vor der Ausführung des zweiten Satzes von Gleitkommabefehlen
384 in den leeren Zustand (unabhängig davon, ob der zweite
Satz von Gleitkommabefehlen 384 zu dem Taskumschaltungsbe
handler, zur Task A oder zu einem anderen Programm gehört).
Als weiteres Beispiel nehme man wiederum an, daß der
Satz von gepackten Datenbefehlen 382 zu einer Task A gehört
und daß die Task A von einer Taskumschaltung vor der Aus
führung des Satzes der Übergangsbefehle 390 unterbrochen
wird. Jedoch dieses Mal handelt es sich bei der Taskumschal
tung um eine partielle Taskumschaltung (d. h. der Gleitkomma
zustand/gepackte Datenzustand wird nicht gespeichert oder
wiederhergestellt). Falls keine anderen Tasks ausgeführt
werden, die Gleitkommabefehle oder gepackte Datenbefehle
verwenden, dann kehrt der Prozessor schließlich zur aus
führenden Task A zurück und der Satz von Übergangsbefehlen
390 wird ausgeführt. Wenn jedoch eine andere Task (z. B. Task
B) Gleitkommabefehle oder gepackte Datenbefehle verwendet,
wird der Versuch der Ausführung dieser Befehle einen Be
triebssystembehandleraufruf verursachen, um den Gleitkomma
zustand/gepackten Datenzustand der Task A zu speichern und
den Gleitkommazustand/gepackten Datenzustand der Task B
wiederherzustellen. Dieser Behandler enthält die FP-Taskum
schaltungsroutine (welche bei diesem Beispiel durch den
zweiten Satz von Gleitkommabefehlen 384 dargestellt ist), um
den Gleitkommazustand/gepackten Datenzustand zu speichern.
Da der Satz der Übergangsbefehle 390 nicht ausgeführt wurde,
ändert der Prozessor irgendwann vor der Ausführung der FP-
Taskumschaltungsroutine die Tags in den nicht-leeren Zu
stand. Folglich speichert die FP-Taskumschaltungsroutine,
unabhängig davon ob minimal oder einfach, den Inhalt der
gesamten aliased Registerdatei (d. h. den gepackten Daten
zustand der Task A). Auf diese Weise bleibt dieses
Ausführungsbeispiel unsichtbar für das Betriebssystem, und
zwar unabhängig von der zur Speicherung des Zustandes der
aliased Register verwendeten Technik.
Der Satz der Übergangsbefehle kann auf beliebig viele
Weisen implementiert werden. Bei einem Ausführungsbeispiel
kann der Satz von Übergangsbefehlen einen neuen Befehl ent
halten, der hierin als der EMMS(leerer Multimediazustand
- empty multimedia state)-Befehl bezeichnet wird. Dieser Be
fehl veranlaßt das Löschen der Gleitkommatags/Tags für ge
packte Daten, um jedem nachfolgend ausgeführten Befehlscode
anzuzeigen, daß alle Gleitkommaregister 300 für beliebige
nachfolgende Gleitkommabefehle verfügbar sind, welche mög
licherweise ausgeführt werden. Dies vermeidet die Erzeugung
eines Stapelüberlauf-Zustandes, welcher andernfalls auf
treten kann, wenn der EMMS-Befehl nicht nach gepackten Da
tenbefehlen und vor der Ausführung von Gleitkommabefehlen
ausgeführt wird.
Bei bekannten Gleitkommaprogrammierpraktiken, welche
den Intel-Architektur-Prozessor verwenden, ist es üblich,
Blöcke von Gleitkommabefehlscode mit einer Operation oder
mit Operationen zu beenden, welche den Gleitkommazustand
löschen. Unabhängig davon, ob eine partielle und/oder eine
minimale Kontextumschaltung verwendet wird, bleibt der
Gleitkommazustand in einem gelöschten Zustand bei der Be
endigung eines ersten Blockes von Gleitkommabefehlscode.
Daher soll der EMMS-Befehl bei gepackten Datensequenzen
verwendet werden, um den gepackten Datenzustand zu löschen.
Der EMMS-Befehl sollte nach einem Block aus gepacktem Da
tenbefehlscode ausgeführt werden. Auf diese Weise bleibt ein
Prozessor, der die hier beschriebenen Verfahren und Einrich
tungen implementiert, mit bekannten Gleitkommaprozessoren
voll kompatibel, die den Intel-Architektur-Prozessor ver
wenden, jedoch auch die Möglichkeit haben, gepackte Daten
befehle auszuführen, welche bei Programmierung mit guten
Programmiertechniken und bei entsprechender Verwaltung (Lö
schen des Zustandes vor Übergängen zwischen gepacktem
Datenbefehlscode und Gleitkommabefehlscode), Übergänge zwi
schen einem gepackten Datenbefehlscode und einem Gleitkomma
befehlscode erlauben, ohne weder den Gleitkommazustand noch
den gepackten Datenzustand ungünstig zu beeinträchtigen.
Bei einem anderen Ausführungsbeispiel kann der Satz von
Übergangsbefehlen mit Hilfe von existierenden Gleitkommabe
fehlen implementiert werden, welche den Prozessor veran
lassen, die Tags bei der Ausführung in den leeren Zustand zu
ändern.
Bei einem Ausführungsbeispiel ist das Umschalten zwi
schen der Ausführung gepackter Datenbefehle und der Aus
führung von Gleitkommabefehlen zeitaufwendig. Daher mini
miert eine gute Programmiertechnik die Anzahl dieser Über
gänge. Die Anzahl der Übergänge zwischen Gleitkommabefehlen
und gepackten Datenbefehlen kann dadurch verringert werden,
daß Gleitkommabefehle neben gepackten Datenbefehlen grup
piert werden. Da es wünschenswert ist, derart gute Program
miertechniken zu unterstützen, ist es wünschenswert, einen
Prozessor zu implementieren, der es schwer macht, derart
gute Programmiertechniken zu ignorieren. Daher ändert ein
Ausführungsbeispiel auch die Stapelkopfendeanzeige während
des ersten Zeitintervalls 386 in einen Initialisierungszu
stand (z. B. Null, um das Register R0 anzuzeigen). Dies kann
auf beliebig viele verschiedene Weisen geschehen, z. B. da
durch, daß: 1) die Ausführung des ersten gepackten Daten
befehls veranlaßt wird, die Stapelkopfendeanzeige zu ändern;
2) die Ausführung jedes gepackten Datenbefehls des Satzes
der gepackten Datenbefehle 382 veranlaßt wird, die Stapel
kopfendeanzeige zu ändern; 3) die Ausführung des EMMS-Be
fehls veranlaßt wird, die Stapelkopfendeanzeige zu setzen;
4) die Stapelkopfendeanzeige bei dem Versuch, einen Gleit
kommabefehl zum Zeitpunkt T3 der Fig. 3D auszuführen, geän
dert wird usw. Wiederum dient dies dazu, die volle Kompati
bilität eines Befehlscodes zu erhalten, welcher gepackte Da
tenbefehle mit Gleitkommabefehlen mischt. Außerdem speichert
ein Ausführungsbeispiel unter dem Gesichtspunkt der Förde
rung guter Programmiertechniken während des ersten Zeit
intervalls 386 einen keine Zahl anzeigenden Wert in den Vor
zeichen- und Exponentenfeldern jedes aliased Registers, in
welches gepackte Daten geschrieben werden.
Die Fig. 4A und 4B zeigen ein allgemeines Ablauf
diagramm, welches ein Verfahren veranschaulicht, um Gleit
kommabefehle und gepackte Datenbefehle auf eine Weise aus
zuführen, die für verschiedene Betriebssystemtechniken un
sichtbar ist und wirksame Programmiertechniken gemäß einem
Ausführungsbeispiel der Erfindung unterstützt. Das Ablauf
diagramm beginnt mit dem Schritt 400. Nach dem Schritt 400
geht der Ablauf mit dem Schritt 402 weiter.
Wie im Schritt 402 dargestellt ist, wird als Befehl auf
einen Bitsatz zugegriffen und der Ablauf geht mit dem
Schritt 404 weiter. Der Bitsatz enthält einen Befehlscode,
welcher die von dem Befehl auszuführende(n) Operation(en)
kennzeichnet.
Im Schritt 404 wird festgestellt, ob der Befehlscode
gültig ist. Wenn der Befehlscode nicht gültig ist, geht der
Ablauf mit dem Schritt 406 weiter. Ansonsten geht der Ablauf
mit dem Schritt 408 weiter. Man nehme an, daß die Ausführung
einer gepackte Datenbefehle enthaltenden Routine auf einem
Prozessor versucht wird, welcher gepackte Datenbefehle nicht
unterstützt, die Befehlscodes für die gepackten Datenbefehle
werden dann nicht gültig sein, und der Ablauf geht mit dem
Schritt 406 weiter. Wenn der Prozessor dagegen in der Lage
ist, gepackte Datenbefehle auszuführen, sind die Befehls
codes für diese Befehle gültig, und der Ablauf geht mit dem
Schritt 408 weiter.
Wie im Schritt 406 dargestellt ist, wird eine "un
gültiger Befehlscode"-Ausnahme erzeugt, und der geeignete
Ereignisbehandler wird ausgeführt. Wie im Vorangegangenen
unter Bezugnahme auf Schritt 215 in Fig. 2 beschrieben wur
de, kann dieser Ereignisbehandler derart implementiert sein,
daß er den Prozessor veranlaßt, eine Nachricht anzuzeigen,
die Ausführung der aktuellen Task abzubrechen und die Aus
führung anderer Tasks fortzuführen. Natürlich kann dieser
Ereignisbehandler auf beliebig viele Weisen implementiert
werden. Beispielsweise kann der Ereignisbehandler so imple
mentiert sein, daß er angibt, ob der Prozessor in der Lage
ist, gepackte Datenbefehle auszuführen. Der gleiche Ereig
nisbehandler könnte ebenfalls so implementiert sein, daß er
eine Anzeige setzt, die anzeigt, daß der Prozessor gepackte
Datenbefehle nicht ausführen kann. Andere auf dem Prozessor
ausführende Anwendungen könnten diese Anzeige verwenden, um
zu bestimmen, ob die Ausführung mit Hilfe eines Satzes ska
larer Routinen oder eines dupikativen Satzes gepackter Da
tenroutinen auszuführen ist. Jedoch würde eine derartige
Implementierung entweder die Änderung eines existierenden
Betriebssystems oder die Entwicklung eines neuen Betriebs
systems erfordern.
Im Schritt 408 wird festgestellt, welche Art von Befehl
empfangen wurde. Wenn es sich weder um einen Gleitkomma
befehl noch um einen gepackten Datenbefehl handelt, geht der
Ablauf mit dem Schritt 410 weiter. Wenn der Befehl jedoch
ein Gleitkommabefehl ist, geht der Ablauf mit dem Schritt
412 weiter. Wenn der Befehl dagegen ein gepackter Daten
befehl ist, geht der Ablauf mit dem Schritt 414 weiter.
Wie im Schritt 410 gezeigt ist, führt der Prozessor den
Befehl aus. Da dieser Schritt zum Verständnis der Erfindung
nicht nötig ist, wird er hier nicht weiter beschrieben.
Wie im Schritt 412 dargestellt ist, wird festgestellt,
ob die EM-Anzeige gleich 1 ist (gemäß der beschriebenen
Software-Konvention ist sie dies, falls die Gleitkomma
einheit emuliert werden soll) und ob die TS-Anzeige gleich 1
ist (gemäß der beschriebenen Software-Konvention ist sie
dies, wenn eine partielle Kontextumschaltung durchgeführt
wurde). Wenn die EM-Anzeige und/oder die TS-Anzeige gleich 1
ist, geht der Ablauf mit dem Schritt 416 weiter. Ansonsten
geht der Ablauf mit dem Schritt 420 weiter. Während ein Aus
führungsbeispiel derart implementiert ist, daß eine "Ein
richtung nicht verfügbar"-Ausnahme verursacht wird, wenn die
EM-Anzeige gleich 1 und/oder die TS-Anzeige gleich 1 ist,
könnten andere Ausführungsbeispiele so implementiert sein,
daß sie beliebige andere Werte verwenden.
Im Schritt 416 wird die "Einrichtung nicht verfügbar"-
Ausnahme erzeugt, und der zugehörige Ereignisbehandler wird
ausgeführt. Wie im Vorangegangenen unter Bezugnahme auf
Schritt 235 der Fig. 2 beschrieben wurde, kann der zuge
hörige Ereignisbehandler derart implementiert sein, daß er
die EM- und TS-Anzeige abfragt. Wenn die EM-Anzeige gleich 1
ist, dann emuliert der Ereignisbehandler die Gleitkommaein
heit zur Ausführung des Befehls und veranlaßt den Prozessor,
die Ausführung beim nächsten Befehl wiederaufzunehmen (bei
dem Befehl, welcher dem im Schritt 402 empfangenen Befehl
logisch folgt). Wenn die TS-Anzeige gleich 1 ist, dann ver
anlaßt der Ereignisbehandler den Prozessor so zu funktionie
ren, wie es im Vorangegangenen in Bezug auf partielle Kon
textumschaltungen beschrieben wurde (Speicherung des Inhalts
der Gleitkommaeinheit und Wiederherstellung des richtigen
Gleitkommazustandes, sofern erforderlich) und veranlaßt den
Prozessor, die Ausführung durch Neustart der Ausführung des
im Schritt 402 empfangenen Befehls wieder aufzunehmen.
Selbstverständlich können alternative Ausführungsbeispiele
diesen Ereignisbehandler auf beliebig viele Weisen implemen
tieren. Beispielsweise kann die EM-Anzeige zur Implementie
rung von Multitasking verwendet werden.
Da der gepackte Datenzustand auf dem Gleitkommazustand
aliased ist und da die EM- und die TS-Anzeigen die Änderung
des Gleitkommazustandes verursachen, muß der Prozessor auch
auf die EM- und die TS-Anzeigen antworten, wenn die gepack
ten Datenbefehle ausgeführt werden, um vollständig software
kompatibel zu bleiben.
Im Schritt 414 wird festgestellt, ob die EM-Anzeige
gleich 1 ist. Wie im Vorangegangenen beschrieben wurde, kann
der zur Bearbeitung der "Einrichtung nicht verfügbar"-Aus
nahme ausgeführte Ereignisbehandler derart implementiert
sein, daß er die EM-Anzeige abfragt und versucht die Gleit
kommaeinheit zu emulieren, wenn die EM-Anzeige gleich 1 ist.
Da existierende Ereignisbehandler nicht dafür geschrieben
wurden, um gepackte Datenbefehle zu emulieren, kann die ver
suchsweise Ausführung eines gepackten Datenbefehls, während
die EM-Anzeige gleich 1 ist, von diesem Ereignisbehandler
nicht bedient werden. Außerdem kann die Änderung dieses Er
eignisbehandlers durch den Prozessor nicht angefordert wer
den, da der Vorgang für das Betriebssystem unsichtbar blei
ben soll. Folglich geht der Ablauf anstelle mit dem Schritt
406 mit dem Schritt 416 weiter, wenn im Schritt 414 festge
stellt wird, daß die EM-Anzeige gleich 1 ist. Ansonsten geht
der Ablauf mit dem Schritt 418 weiter.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 406 die "ungültiger Befehlscode"-Ausnahme erzeugt
und der zugehörige Ereignisbehandler wird ausgeführt. Das
Ausführungsbeispiel bleibt dadurch unsichtbar für das Be
triebssystem, daß die versuchsweise Ausführung eines gepack
ten Datenbefehls bei EM gleich 1 in die "ungültiger Befehls
code"-Ausnahme umgelenkt wird.
Während ein Ausführungsbeispiel zur Behandlung der EM-
Anzeige in einer für das Betriebssystem unsichtbaren Weise
beschrieben wurde, könnten alternative Ausführungsbeispiele
andere Techniken verwenden. Beispielsweise könnte ein alter
natives Ausführungsbeispiel entweder die "Einrichtung nicht
verfügbar"-Ausnahme erzeugen, ein anderes existierendes Er
eignis oder ein neues Ereignis als Antwort auf die versuchs
weise Ausführung eines gepackten Datenbefehls, während die
EM-Anzeige gleich 1 ist. Außerdem könnte der ausgewählte
Ereignisbehandler derart geändert werden, daß er eine ge
eignete Maßnahme als Antwort auf diese Situation unternimmt,
wenn eine geringfügige Änderung des Betriebssystems annehm
bar ist. Beispielsweise könnte der Ereignisbehandler derart
geschrieben werden, daß er gepackte Dateninstruktionen emu
liert. Ein anderes alternatives Ausführungsbeispiel könnte
die EM-Anzeige beim Ausführen gepackter Datenbefehle einfach
ignorieren.
Wie im Schritt 418 gezeigt ist, wird festgestellt, ob
die TS-Anzeige gleich 1 ist (gemäß der existierenden Soft
ware-Konvention gilt dies, wenn eine partielle Kontextum
schaltung durchgeführt wurde). Wenn die TS-Anzeige gleich 1
ist, geht der Ablauf mit dem Schritt 416 weiter. Ansonsten
geht der Ablauf mit dem Schritt 422 weiter.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 416 die "Einrichtung nicht verfügbar"-Ausnahme er
zeugt und der entsprechende Ereignisbehandler wird ausge
führt. Auf diese Weise kann der entsprechende Ereignisbe
handler derart implementiert sein, daß er als Antwort auf
dieses Ereignis die EM- und TS-Anzeigen abfragt. Da der
Schritt 414 Situationen, in denen die EM-Anzeige gleich 1
ist, in eine "ungültiger Befehlscode"-Ausnahme umlenkt, muß
die EM-Anzeige gleich 0 und die TS-Anzeige gleich 1 sein. Da
die TS-Anzeige gleich 1 ist, funktioniert der Ereignisbe
handler wie im Vorangegangenen mit Bezug auf partielle Kon
textumschaltungen beschrieben wurde (Speicherung des Inhalts
der Gleitkommaeinheit und Wiederherstellung des richtigen
Gleitkommazustandes, sofern erforderlich) und veranlaßt den
Prozessor, die Ausführung durch Neustart der Ausführung des
im Schritt 402 empfangenen Befehls wiederaufzunehmen. Da der
gepackte Datenzustand auf dem Gleitkommazustand aliased ist,
arbeitet dieser Ereignisbehandler sowohl für den Gleitkomma
zustand als auch für den gepackten Datenzustand. Folglich
bleibt dieses Verfahren für das Betriebssystem unsichtbar.
Natürlich können alternative Ausführungsbeispiele diesen
Ereignisbehandler auf beliebig viele Weisen implementieren.
Beispielsweise kann ein alternatives Ausführungsbeispiel,
bei dem der gepackte Datenzustand nicht mit auf Gleitkomma
zustand aliased ist, einen neuen Ereignisbehandler verwen
den, der sowohl den Gleitkommazustand als auch den gepackten
Datenzustand speichert.
Während ein Ausführungsbeispiel zum Behandeln der TS-
Anzeige in einer für das Betriebssystem unsichtbaren Weise
beschrieben wurde, könnten alternative Ausführungsbeispiele
andere Techniken verwenden. Beispielsweise kann ein alter
natives Ausführungsbeispiel die TS-Anzeige nicht implemen
tieren. Ein derartiges alternatives Ausführungsbeispiel wäre
nicht mit Betriebssystemen kompatibel, welche die TS-Anzeige
zur Implementierung einer partiellen Kontextumschaltung ver
wenden. Jedoch wäre ein derartiges alternatives Ausführungs
beispiel mit existierenden Betriebssystemen kompatibel, wel
che partielle Kontextumschaltungen unter Verwendung der TS-
Anzeige nicht unterstützen. Als weiteres Beispiel kann die
versuchsweise Ausführung eines gepackten Datenbefehls, wäh
rend die TS-Anzeige gleich 1 ist, zu einem neuen Ereignis
behandler oder zu einem existierenden Ereignisbehandler, der
modifiziert wurde, umgeleitet werden. Dieser Ereignisbehand
ler könnte derart implementiert sein, daß er als Antwort auf
diese Situation eine geeignet erscheinende Maßnahme unter
nimmt. Beispielsweise könnte dieser Ereignisbehandler den
gepackten Datenzustand und/oder den Gleitkommazustand bei
einem Ausführungsbeispiel speichern, bei dem der gepackte
Datenzustand nicht auf dem Gleitkommazustand aliased ist.
Wie im Vorangegangenen in Bezug auf Fig. 2 beschrieben
wurde, bleiben, sofern bestimmte numerische Fehler während
der Ausführung eines Gleitkommabefehls erzeugt werden, diese
Fehler anhängig, bis zur versuchsweisen Ausführung des näch
sten Gleitkommabefehls, dessen Ausführung zu deren Bearbei
tung unterbrochen werden kann. Wie in den Schritten 420 und
422 gezeigt ist, wird dann festgestellt, ob es irgendwelche
derartigen unerledigten Fehler gibt, die nun bearbeitet wer
den können. Folglich ähneln diese Schritte dem Schritt 240
der Fig. 2. Falls es derartige unerledigte Fehler gibt,
geht der Ablauf von den beiden Schritten 420 und 422 zu dem
Schritt 424 weiter. Wenn jedoch im Schritt 420 festgestellt
wird, daß es keine derartigen unerledigten Fehler gibt, geht
der Ablauf mit dem Schritt 426 weiter. Wenn dagegen im
Schritt 422 festgestellt wird, daß es keine derartigen uner
ledigten Fehler gibt, geht der Ablauf mit dem Schritt 430
weiter. Bei einem alternativen Ausführungsbeispiel bleiben
derartige Fehler während der Ausführung der gepackten Daten
befehle anhängig.
Im Schritt 424 wird eine "unerledigter Gleitkommafeh
ler"-Ausnahme erzeugt. Wie im Vorangegangenen in Bezug auf
Schritt 245 der Fig. 2 beschrieben wurde, bestimmt der Pro
zessor als Antwort auf dieses Ereignis, ob der Gleitkomma
fehler maskiert ist. Falls dies der Fall ist, versucht der
Prozessor, das Ereignis intern zu behandeln, und der Gleit
kommabefehl wird mit Mikrobefehlen neu gestartet. Wenn der
Gleitkommafehler nicht maskiert ist, ist das Ereignis ein
externes Ereignis und der zugehörige Ereignisbehandler wird
ausgeführt. Dieser Ereignisbehandler kann derart implemen
tiert sein, daß er den Fehler bedient und den Prozessor ver
anlaßt, die Ausführung durch Neustart der Ausführung des im
Schritt 402 empfangenen Befehls wiederaufzunehmen. Selbst
verständlich können alternative Ausführungsbeispiele diesen
Ereignisbehandler auf beliebig viele Weisen implementieren.
Wie im Schritt 426 gezeigt ist, wird der Gleitkommabe
fehl ausgeführt. Um für das Betriebssystem unsichtbar zu
bleiben, ändert ein Ausführungsbeispiel außerdem die Tags,
soweit es erforderlich ist, berichtet alle numerischen Feh
ler, die nun bedient werden können, und läßt alle anderen
numerischen Fehler unerledigt. Da es viele Betriebssystem
techniken zum Speichern des Inhalts der Gleitkommaeinheit
gibt, ist es wünschenswert, die gepackten Datenbefehle und
die Gleitkommabefehle in einer Weise auszuführen, welche für
alle derartigen Betriebssystemtechniken unsichtbar ist. In
dem die Tags beibehalten werden, bleibt dieses Ausführungs
beispiel für das Betriebssystem unsichtbar, und zwar für
alle solchen Betriebssystemtechniken, welche den Inhalt nur
derjenigen Gleitkommaregister speichern, deren zugehöriges
Tag den nicht-leeren Zustand anzeigt. Jedoch könnten alter
native Ausführungsbeispiele so implementiert werden, daß sie
mit einer geringeren Anzahl dieser Betriebssystemtechniken
kompatibel sind. Wenn ein existierendes Betriebssystem z. B.
keine Tags verwendet, wäre ein Prozessor, der die Tags nicht
implementiert, weiterhin mit dem Betriebssystem kompatibel.
Außerdem ist es nicht für die Erfindung erforderlich, daß
numerische Gleitkommaausnahmen unerledigt bleiben und folg
lich fallen alternative Ausführungsbeispiele, bei denen dies
nicht so ist, noch unter den Schutzbereich der Erfindung.
Wie im Schritt 430 gezeigt ist, wird festgestellt, ob
der gepackte Datenbefehl der EMMS-Befehl ist (welcher auch
als der Übergangsbefehl bezeichnet wird) Wenn der gepackte
Datenbefehl der EMMS-Befehl ist, geht der Ablauf mit dem
Schritt 432 weiter. Ansonsten geht der Ablauf mit dem
Schritt 434 weiter. Der EMMS-Befehl wird verwendet, um die
Gleitkommatags in einen Initialisierungszustand zu ändern.
Wenn der gepackte Datenzustand auf dem Gleitkommazustand
aliased ist, sollte dieser Befehl folglich beim Übergang von
der Ausführung gepackter Datenbefehle zu der Ausführung von
Gleitkommabefehlen ausgeführt werden. Auf diese Weise wird
die Gleitkommaeinheit für die Ausführung der Gleitkommabe
fehle initialisiert. Alternative Ausführungsbeispiele, bei
denen der gepackte Datenzustand und der Gleitkommazustand
nicht aliased sind, müssen die Schritte 430 und 432 mögli
cherweise nicht ausführen. Außerdem werden die Schritte 430
und 432 nicht benötigt, wenn der EMMS-Befehl emuliert wird.
Wie im Schritt 432 gezeigt ist, werden alle Tags in den
leeren Zustand geändert und die Stapelkopfendeanzeige wird
auf einen Initialisierungswert geändert. Durch Änderung der
Tags in den leeren Zustand, wurde die Gleitkommaeinheit ini
tialisiert und ist für die Ausführung von Gleitkommabefehlen
bereit. Die Änderung der Stapelkopfendeanzeige auf den Ini
tialisierungswert (,welcher bei einem Ausführungsbeispiel
zur Kennzeichnung des Registers R0 gleich Null ist) fördert
die getrennte Gruppierung der Gleitkommabefehle und der ge
packten Datenbefehle und fördert folglich gute Programmier
techniken. Andere Ausführungsbeispiele müssen die Stapel
kopfendeanzeige nicht initialisieren. Bei Beendigung des
Schrittes 432 ist das System frei, den nächsten Befehl aus
zuführen (denjenigen Befehl, der logisch dem in Schritt 402
empfangenen Befehl folgt).
Wie im Schritt 434 gezeigt ist, wird der gepackte
Datenbefehl ausgeführt (ohne numerische Ausnahmen zu er
zeugen), und die Stapelkopfendeanzeige wird auf den Ini
tialisierungswert geändert. Um die Erzeugung irgendwelcher
numerischer Ausnahmen zu vermeiden, implementiert ein Aus
führungsbeispiel die gepackten Datenbefehle derart, daß Da
tenwerte gesättigt und/oder auf einen Maximal- oder Minimal
wert festgeklemmt werden. Da keine numerischen Ausnahmen er
zeugt werden, werden keine Ereignisbehandler zur Bedienung
von Ausnahmen benötigt. Folglich ist dieses Ausführungsbei
spiel der Erfindung für Betriebssysteme unsichtbar. Alterna
tiv könnte ein Ausführungsbeispiel derart implementiert wer
den, daß es als Antwort auf derartige numerischen Ausnahmen
Mikrobefehlscode-Ereignisbehandler ausführt. Alternative
Ausführungsbeispiele, welche für Betriebssysteme nicht voll
ständig unsichtbar sind, könnten derart implementiert wer
den, daß entweder zusätzliche Ereignisbehandler in das Be
triebssystem integriert werden oder daß existierende Ereig
nisbehandler für die Bearbeitung des Fehlers geändert wer
den. Das Stapelkopfende wird aus den gleichen oben ange
gebenen Gründen geändert. Alternative Ausführungsbeispiele
könnten derart implementiert sein, daß sie das Stapelkopf
ende zu beliebig vielen verschiedenen Zeitpunkten ändern.
Beispielsweise könnten alternative Ausführungsbeispiele
derart implementiert sein, daß sie die Stapelkopfendeanzeige
bei Ausführung aller gepackten Datenbefehle ausgenommen für
EMMS ändern. Andere alternative Ausführungsbeispiele könnten
derart implementiert sein, daß sie die Stapelkopfendeanzeige
außer bei EMMS bei keinem anderen gepackten Datenbefehl än
dern. Wenn irgendwelche Speicherereignisse als Folge des
Versuchs, den gepackten Datenbefehl auszuführen, erzeugt
werden, wird die Ausführung unterbrochen, die Stapelkopf
endeanzeige wird nicht geändert und das Ereignis wird be
arbeitet. Bei Beendigung der Bearbeitung des Ereignisses
wird der im Schritt 402 empfangene Befehl erneut gestartet.
Vom Schritt 434 geht der Ablauf mit dem Schritt 436 weiter.
Wie im Schritt 436 gezeigt ist, wird festgestellt, ob
der gepackte Datenbefehl den Prozessor veranlaßt, in ein
aliased Register zu schreiben. Falls dies der Fall ist, geht
der Ablauf mit dem Schritt 438 weiter. Ansonsten geht der
Ablauf mit dem Schritt 440 weiter.
Im Schritt 438 werden 1sen in den Vorzeichen- und Ex
ponentenfelder aller aliased Register gespeichert, in die
veranlaßt vom gepackten Datenbefehl vom Prozessor geschrie
ben wird. Vom Schritt 438 geht der Ablauf mit dem Schritt
440 weiter. Das Ausführen dieses Schrittes unterstützt gute
Programmiertechniken dadurch, daß es das separate Gruppieren
von Gleitkommabefehlen und gepackten Datenbefehle fördert.
Selbstverständlich könnten alternative Ausführungsbeispiele,
die dieses Problem nicht betrifft, die Implementierung die
ses Schrittes weglassen. Während bei einem Ausführungsbei
spiele 1sen in die Vorzeichen- und Exponentenfelder ge
schrieben werden, könnten alternative Ausführungsbeispiele
jeden ein NAN (keine Zahl) oder unendlich darstellenden Wert
verwenden.
Wie im Schritt 440 gezeigt ist, werden alle Tags in den
nicht-leeren Zustand geändert. Das Ändern der Tags in den
nicht-leeren Zustand unterstützt gute Programmiertechniken
dadurch, daß es die separate Gruppierung von Gleitkommabe
fehlen und gepackten Datenbefehlen fördert. Im Hinblick auf
Betriebssystemkompatibilität speichern außerdem bestimmte
Betriebssystemtechniken den Inhalt nur derjenigen Gleitkom
maregister, deren zugehörige Tags einen nicht-leeren Zustand
anzeigen (minimale Kontextumschaltung). Auf diese Weise ver
ursacht das Ändern aller Tags, die in einem nicht-leeren Zu
stand sind, bei einem Ausführungsbeispiel, bei dem der ge
packte Datenzustand auf dem Gleitkommazustand aliased ist,
derartige Betriebssysteme den gepackten Datenzustand zu er
halten, als ob es der Gleitkommazustand wäre. Alternative
Ausführungsbeispiele könnten nur diejenigen Tags ändern,
deren zugehörige Register gültige gepackte Datenelemente
enthielten. Ferner könnten alternative Ausführungsbeispiele
implementiert werden, die mit weniger dieser Betriebssystem
techniken kompatibel sind. Wenn ein existierendes Betriebs
system keine Tags verwendet (z. B. ein Betriebssystem, wel
ches den gesamten Registerzustand speichert und wiederher
stellt), wäre ein Ausführungsbeispiel beispielsweise, wel
ches keine Tags implementiert, weiterhin mit diesem Be
triebssystem kompatibel. Bei Beendigung des Schrittes 440
ist das System frei, den nächsten Befehl auszuführen (den
jenigen Befehl, welcher dem im Schritt 402 empfangenen Be
fehl logisch folgt).
Der Inhalt der Tags im Speicher nach einem Gleitkomma
zustandsspeicher (FSAVE)- oder nach einem Gleitkommaumge
bungsspeicher (FSTENV)-Befehl ist für dieses Ausführungsbei
spiel somit unter Bezugnahme auf die Tabelle 1 unten ge
zeigt:
Wie gezeigt ist, veranlassen alle gepackten Daten
befehle außer EMMS, daß die Tags 320 in einen nicht-leeren
Zustand (00) gesetzt werden. EMMS veranlaßt, daß das Gleit
kommatagregister auf leer (11) gesetzt wird. Außerdem ver
anlaßt jeder gepackten Datenbefehl einschließlich EMMS aus
serdem, daß die im Stapelkopfendefeld 350 gespeicherte Sta
pelkopfendeanzeige auf 0 zurückgesetzt wird.
Die verbleibenden Umgebungsregister, wie z. B. die
Steuer- und Statuswörter (außer TOS) bei dem Intel-Archi
tektur-Prozessor, bleiben unverändert. Leseoperationen von
gepackten Daten oder EMMS läßt die Mantissen- und Exponen
tenabschnitte der Gleitkommaregister 300 in einem unverän
derten Zustand. Bei einem Ausführungsbeispiel veranlassen
jedoch Schreiboperationen für gepackte Daten in ein gepack
tes Datenregister aufgrund des Aliasing-Mechanismus, daß der
Mantissenabschnitt des zugehörigen Gleitkommaregisters ent
sprechend der ausgeführten Operation geändert wird. Ferner
verursacht bei diesem Ausführungsbeispiel das Datenschreiben
in den Mantissenabschnitt der Gleitkommaregister durch Ände
rung der gepackten Datenregister 310, daß alle Bits in den
Vorzeichen- und Exponentenabschnitten der Gleitkommaregister
300 auf 1 gesetzt werden. Da die gepackten Datenbefehle die
Vorzeichen- und Exponentenabschnitte der Gleitkommaregister
nicht verwenden (es gibt kein Aliasing der gepackten Daten
register in den Vorzeichen- und Exponentenabschnitten der
Gleitkommaregister), hat dies auf gepackte Datenbefehle kei
ne Auswirkung. Wie im Vorangegangenen beschrieben wurde,
können alternative Ausführungsbeispiele ein Aliasing des ge
packten Datenzustandes auf jeden beliebigen Abschnitt des
Gleitkommazustandes ausführen. Außerdem können alternative
Ausführungsbeispiele irgendeinen anderen Wert in die Vorzei
chen- und/oder Exponentenabschnitte der Register schreiben
oder diese nicht ändern.
Um darüberhinaus die Ausführung von gepackten Datenbe
fehlen anzuzeigen, werden die Vorzeichen- und Exponentenab
schnitte der Gleitkommaregister, in die geschrieben wird,
alle auf 1 gesetzt. Dies geschieht, da die Gleitkomma
register den Exponentenabschnitt der Gleitkommaregister
verwenden, und es ist wünschenswert, daß dieser Abschnitt
der Register nach der Ausführung von gepackten Datenbefehlen
in einem entscheidenden Zustand gelassen wird. Bei dem
Intel-Architektur-Mikroprozessor wird ein Exponentenab
schnitt eines Gleitkommaregisters, der überall auf 1 gesetzt
wird, als Nicht-Zahl (NAN) interpretiert. Somit wird zusätz
lich zu dem Setzen der gepackten Datentags 330 auf einen
nicht-leeren Zustand der Exponentenabschnitt der Gleitkomma
register überall auf 1 gesetzt, was verwendet werden kann,
um anzuzeigen daß im Vorangegangenen gepackte Datenbefehle
ausgeführt wurden. Dies hält außerdem vom Datenmischen von
gepackten Datenbefehlen und von Gleitkommabefehlen ab, was
diese Daten modifizieren würde und unrichtige Ergebnisse
erzielen würde. Somit hat der Gleitkommabefehlscode eine
weitere Möglichkeit dazwischen zu unter 99999 00070 552 001000280000000200012000285919988800040 0002019681660 00004 99880scheiden, wann die
Gleitkommaregister Gleitkommadaten enthalten und wann sie
gepackten Daten enthalten.
Folglich wurde ein Verfahren zum Ausführen gepackter
Datenbefehle beschrieben, welches mit existierenden Be
triebssystemen kompatibel ist (z. B. Betriebsumgebungen der
Marke MS Windows, die von Microsoft Corporation aus Redmont,
Washington, erhältlich sind) und welches gute Programmier
techniken unterstützt. Da der gepackte Datenzustand auf dem
Gleitkommazustand aliased ist, wird der gepackte Datenzu
stand von existierenden Betriebssystemen so erhalten und
wiederhergestellt, als ob er der Gleitkommazustand wäre. Da
außerdem Ereignisse, die von der Ausführung der gepackten
Datenbefehle erzeugt werden, von Ereignisbehandlern existie
render Betriebssysteme bedienbar sind, müssen diese Ereig
nisbehandler nicht modifiziert werden, und es müssen keine
neuen Ereignisbehandler hinzugefügt werden. Folglich ist der
Prozessor mit älteren Programmfassungen kompatibel und eine
Erweiterung erfordert nicht dit Kosten und Zeit, die zur
Entwicklung oder Änderung eines Betriebssystems erforderlich
sind.
Verschiedene Ausführungsbeispiele dieses Verfahrens,
welche auch mit existierenden Betriebssystemen kompatibel
sind, werden unter Bezugnahme auf Fig. 7A-C, 8 und 9 und
unter Bezugnahme auf die Fig. 11A-C beschrieben. Obwohl
sich diese Ausführungsbeispiele unterscheiden, haben alle
diese Ausführungsbeispiele (das in den Fig. 4A-B gezeigte
Ausführungsbeispiel; das in den Fig. 7A-C, 8 und 9 ge
zeigte Ausführungsbeispiel; und das in den Fig. 11A-C
gezeigte Ausführungsbeispiel) die folgenden Gemeinsamkeiten:
1) Der Gleitkommazustand und der gepackte Datenzustand er
scheinen wenigstens der Software, als ob sie in einer einzi
gen logischen Registerdatei gespeichert wären; 2) die Aus
führung eines gepackten Datenbefehls bei Anzeige des EM-Bits
"Gleitkommabefehle sollen emuliert werden" führt statt zu
einer "Einrichtung nicht verfügbar"-Ausnahme zu einer
"ungültiger Befehlscode"-Ausnahme; 3) die Ausführung eines
gepackten Datenbefehls, bei der Anzeige des TS-Bits "eine
partielle Kontextumschaltung wurde durchgeführt" führt zu
einer "Einrichtung nicht verfügbar"-Ausnahme; 4) unerledigte
Gleitkommaereignisse werden von der versuchsweisen Ausfüh
rung eines der gepackten Datenbefehle bedient; 5) die Aus
führung eines der gepackten Datenbefehle führt dazu, daß die
Stapelkopfendeanzeige irgendwann vor der Ausführung des
nächsten Gleitkommabefehls auf 0 geändert wird; 6) wenn auf
die Ausführung des EMMS-Befehls nicht die Ausführung eines
anderen gepackten Datenbefehls folgt, führt die Ausführung
des EMMS-Befehls dazu, daß alle Tags irgendwann vor der Aus
führung des nächsten Gleitkommabefehls in den leeren Zustand
geändert werden; 7) wenn auf die Ausführung eines gepackten
Datenbefehls keine Ausführung des EMMS-Befehls folgt, werden
die Tags irgendwann vor der Ausführung des nächsten Gleit
kommabefehls in den nicht-leeren Zustand geändert; 8) ir
gendein NAN (keine Zahl) oder unendlich darstellender Wert
wird in den Vorzeichen- und Exponentenfeldern aller FP/PD-
Register gespeichert, in die von dem Prozessor als Antwort
auf die Ausführung eines gepackten Datenbefehls geschrieben
wird; und 9) es werden keine neuen Nicht-Mikrobefehlscode-
Ereignisbehandler benötigt.
Variationen des in den Fig. 4A-B dargestellten
Ausführungsbeispiels, von denen einige beschrieben wurden,
können vollständig oder teilweise mit derartigen Betriebs
systemen kompatibel sein und/oder gute Programmiertechniken
unterstützen. Beispielsweise kann ein alternatives Ausfüh
rungsbeispiel der Erfindung bestimmte Schritte an andere
Stellen in dem in den Fig. 4A-B gezeigten Ablaufdiagramm
umstellen. Andere Ausführungsbeispiele der Erfindung können
einen oder mehrere Schritte ändern oder entfernen. Bei
spielsweise kann ein alternatives Ausführungsbeispiel das
EM-Bit nicht unterstützen. Selbstverständlich soll die Er
findung für eine beliebige Anzahl von Systemarchitekturen
nützlich sein und ist nicht auf die hier beschriebene Archi
tektur beschränkt.
Bei Verwendung der obigen Verfahren für die Ausführung
von Gleitkommabefehlen und gepackten Datenbefehlen ist es
empfehlenswert, daß Programmierer, welche Ausführungsbei
spiele der vorliegenden Erfindung verwenden, ihren Befehls
code in Sektionen aufteilen, welche separate Blöcke von
Gleitkommabefehlen und gepackten Datenbefehlen enthalten,
wie in Fig. 3D gezeigt ist. Dies dient dazu, die Zustands
speicherung und -löschung des gepackten Datenzustandes vor
einem Übergang von einer Folge von Gleitkommaoperationen zu
einer Folge von gepackten Datenoperationen zu ermöglichen
und umgekehrt. Dies ermöglicht außerdem eine Kompatibilität
mit bekannten Taskumschaltungsmechanismen, zu denen jene
gehören, welche den Kontext während einer Taskumschaltung
sichern.
Da sich die gepackten Datenbefehle auf die Gleitkomma
register 300 auswirken (Fig. 3A) und jeder einzelne gepack
ten Datenbefehl alle Gleitkommatags auf den nicht-leeren Zu
stand setzt, wird die Aufteilung des Befehlscodes in Blöcke
unterschiedlicher Befehlscodearten daher zur richtigen Buch
haltung empfohlen. Ein Beispiel einer Ausführung einer Mi
schung von Gleitkommabefehlen und gepackten Datenbefehlen in
Blöcken ist in Fig. 3D dargestellt. Dazu kann der Betrieb
in einem kooperativen Multitasking-Betriebssystem gehören
oder ein gemischter Anwendungscode aus Gleitkomma- und ge
packten Befehlen in einer einzigen Anwendung. In jedem Fall
wird eine richtige Buchhaltung der Gleitkommaregister 300,
der zugehörigen Tags und der Stapelkopfendeanzeige dadurch
sichergestellt, daß die Funktionalität auf separate Blöcke
von Gleitkommacode und Befehlscode aufgeteilt wird.
Beispielsweise kann ein Ausführungsstrom, wie in Fig.
3D dargestellt, den ersten Satz von Gleitkommabefehlen 380
enthalten. Nach Beendung des Blockes von Gleitkommabefehlen
380 kann der Gleitkommastatus gesichert werden, falls die
Anwendung dies wünscht. Dies kann unter Verwendung irgend
einer der Anzahl von bekannten Techniken geschehen, zu denen
das Auskellern des Gleitkommastapels gehört oder die Verwen
dung der FSAVE/FNSAVE-Befehle bei dem Intel-Architektur-Pro
zessor gehören. Dies kann außerdem während minimaler Kon
textumschaltungen geschehen, welche die Gleitkommaumgebung
sichern und die individuellen Tags auf die Anzeige hin über
prüfen, daß das zugehörige Gleitkommaregister gültige Daten
enthält. Für jedes Tag, welches anzeigt, daß die zugehörigen
Gleitkommadaten gültige Daten enthalten, wird das zugehörige
Gleitkommaregister gesichert. Außerdem kann es unter diesen
Umständen außerdem erforderlich sein, eine Angabe über die
Anzahl der Gleitkommaregister zu sichern.
Nach der Ausführung des ersten Satzes von Gleitkomma
befehlen 380 wird in dem Ausführungsstrom der zweite Satz
von gepackten Datenbefehlen 382 ausgeführt. Man erinnere
sich, daß die Ausführung jedes gepackten Datenbefehls dazu
führt, daß alle gepackten Datentags 330 irgendwann in dem
Zeitintervall 386 auf einen nicht-leeren Zustand gesetzt
werden, wenn der Satz von Übergangsbefehlen 390 nicht aus
geführt wird.
Wenn nach der Ausführung des Satzes von gepackten Da
tenbefehlen 382 keine Taskumschaltungen auftreten, wird der
Satz von Übergangsbefehlen 390 ausgeführt. Dieser Satz von
Übergangsbefehlen 390 kann zur Sicherung des gepackten Da
tenzustandes implementiert sein. Dies kann mit Hilfe eines
beliebigen Mechanismus realisiert werden, einschließlich der
bekannten oben erörterten Gleitkommasicherungsbefehle oder
eines speziellen Befehls zur Sicherung nur des gepackten Da
tenzustandes. Der gepackte Datenzustand kann in bekannter
Weise gesichert werden, wozu die Mechanismen der partiellen
und minimalen Kontextumschaltung gehören. Der Satz von Über
gangsbefehlen 390 leert den gepackten Datenzustand unabhän
gig davon, ob der gepackte Datenzustand gesichert wurde oder
nicht. Bei diesem Ereignis wirkt sich der gepackte Datenzu
stand auf die gepackten Datentags 330 und die zugehörigen
aliased Gleitkommatags 320 aus. Wie im Vorangegangenen be
schrieben wurde, geschieht das Leeren des gepackten Datenzu
standes durch die Ausführung des einzelnen Befehls EMMS oder
einer Serie von Gleitkommaoperationen, wie unter Bezugnahme
auf Fig. 14 unten beschrieben wird. Als Folge leert der
Prozessor irgendwann im Zeitintervall 388 den gepackten
Datenzustand und wird für die Ausführung von Gleitkomma
befehlen initialisiert.
Nach der Ausführung des Übergangsbefehlssatzes 390 wird
der zweite Satz von Gleitkommabefehlen 384 ausgeführt. Da
die Tags geleert wurden und die Stapelkopfendeanzeige wäh
rend des zweiten Zeitintervalls 388 derart geändert wurde,
daß sie auf das erste physikalische Register 0 zeigt, sind
alle Gleitkommaregister zur Verwendung verfügbar. Dies ver
hindert die Erzeugung einer Gleitkommastapelüberlaufaus
nahme, welche ansonsten bei der Ausführung eines Gleitkomma
befehls auftreten kann. Bei einigen Softwareimplementier
ungen kann die Stapelüberlaufbedingung verursachen, daß der
Unterbrechungsbehandler den gepackten Datenzustand sichert
und leert. Daher sind bei den ausgeführten Ausführungsbei
spielen der vorliegenden Erfindung gemischte Blöcke aus
gepackten Datenbefehlen und Gleitkommadatenbefehlen erlaubt.
Jedoch muß eine geeignete Buchhaltung von dem Anwendungspro
grammierer oder dem kooperativen Multitaskingcode durchge
führt werden, um jeden gewünschten Gleitkommazustand oder
gepackten Datenzustand bei Übergängen zwischen gepackten
Datenbefehlen und Gleitkommabefehlen zu sichern, damit der
Taskzustand bei Übergängen nicht verfälscht wird. Außerdem
vermeidet dieses Verfahren unnötige Ausnahmen, welche an
sonsten bei der Verwendung von nicht empfohlenen Program
miertechniken auftreten würden die die implementierten
Ausführungsbeispiele der vorliegenden Erfindung verwenden.
Der EMMS-Befehl ermöglicht den reibungslosen Übergang
zwischen einem gepackten Datenbefehlsstrom und einem Gleit
kommabefehlsstrom. Wie im Vorangegangenen angegeben wurde,
löscht er die Gleitkommatags, um eine Gleitkommaüberlaufbe
dingung zu vermeiden, welche auftreten kann, und außerdem
setzt er die in dem Stapelkopfendefeld 350 gespeicherte
Stapelkopfendeanzeige zurück. Obwohl ein diese Operationen
ausführender spezieller Befehl implementiert werden kann,
ist es außerdem klar und liegt es in dem Schutzbereich die
ser Offenbarung, daß die Operation selbst mit Hilfe einer
Kombination existierender Gleitkommabefehle implementiert
werden kann. Ein Beispiel hierfür ist in Fig. 14 darge
stellt. Ferner kann dies funktionell in die Ausführung des
ersten Gleitkommabefehls gefalten werden, welcher der Aus
führung eines gepackten Datenbefehls folgt. Bei diesem Aus
führungsbeispiel würde die Ausführung des ersten Gleitkomma
befehls (anders als eines Befehls, der die Umgebung des
Gleitkommazustandes/gepackten Datenzustandes auslagert),
welcher der Ausführung eines gepackten Datenbefehls folgt,
den Prozessor veranlassen eine implizite EMMSoperation aus
zuführen (Setzen aller Tags auf den leeren Zustand).
Fig. 5 zeigt ein Blockschaltbild, welches ein bei
spielhaftes Computersystem 500 gemäß einem Ausführungs
beispiel der Erfindung veranschaulicht. Dieses beispielhafte
Computersystem 500 enthält einen Prozessor 505, eine Spei
chereinrichtung 510 und einen Bus 515. Der Prozessor 505 ist
mit der Speichereinrichtung 510 über den Bus 515 gekoppelt.
Außerdem sind eine Anzahl von Benutzereingabe/-ausgabeein
richtungen, wie z. B. eine Tastatur 520 und eine Anzeige 525,
ebenfalls mit dem Bus 515 gekoppelt. Ein Netzwerk 530 kann
außerdem mit dem Bus 515 gekoppelt sein. Der Prozessor 505
stellt eine zentrale Verarbeitungseinheit einer beliebigen
Architektur dar, wie beispielsweise eine CISC-, RISC-, VLIW-
oder eine Hybridarchitektur. Zusätzlich könnte der Prozessor
505 auf einem oder mehreren Chips implementiert werden. Die
Speichereinrichtung 510 repräsentiert einen oder mehrere
Mechanismen zur Datenspeicherung. Beispielsweise kann die
Speichereinrichtung 510 einen Nur-Lese-Speicher (ROM), einen
Speicher mit wahlfreiem Zugriff (RAM), magnetische Platten
speichermedien, optische Speichermedien, Flash-Speicherein
richtungen und/oder andere maschinenlesbare Medien enthal
ten. Der Bus 515 repräsentiert einen oder mehrere Busse
(z. B. PCI, ISA, X-Bus, EISA, VESA usw.) und Brücken (welche
auch als Bussteuereinrichtungen bezeichnet werden). Während
dieses Ausführungsbeispiel in Bezug auf ein Computersystem
mit einem einzigen Prozessor beschrieben ist, könnte die
Erfindung auch in einem Mehrprozessor-Computersystem imple
mentiert werden. Obwohl dieses Ausführungsbeispiel in Bezug
auf ein 32-Bit- und ein 64-Bit-Computersystem beschrieben
wird, ist die Implementierung der Erfindung ferner nicht auf
derartige Computersysteme beschränkt.
Fig. 5 zeigt zusätzlich, daß der Prozessor 505 eine
Buseinheit 504 enthält, einen Cache-Speicher 550, eine Be
fehlssatzeinheit 560, eine Speichermanagementeinheit 565 und
eine Ereignisbehandlereinheit 570. Natürlich enthält der
Prozessor 505 zusätzliche Schaltungen, welche für das Ver
ständnis der Implementierung der Erfindung nicht notwendig
sind.
Die Buseinheit 545 ist mit dem Cache-Speicher 550
gekoppelt. Die Buseinheit 545 wird zum Überwachen und zur
Beurteilung von außerhalb des Prozessors 505 erzeugten Si
gnalen verwendet, sowie zum Koordinieren der Ausgangssignale
als Antwort auf Eingangssignale und interne Nachfragen von
anderen Einheiten und Mechanismen in dem Prozessor 505.
Der Cache-Speicher 550 repräsentiert einen oder mehrere
Speicherbereiche zur Verwendung durch den Prozessor 505 als
Befehls-Cache-Speicher und als Daten-Cache-Speicher. Bei ei
nem Ausführungsbeispiel ist der Cache-Speicher 550 bei
spielsweise durch zwei separate Cache-Speicher implementiert
- einer für Befehle und einer für Daten. Der Cache-Speicher
550 ist mit der Befehlssatzeinheit 560 und der Speichermana
gementeinheit 565 gekoppelt.
Die Befehlssatzeinheit 560 enthält die Hardware
und/oder Firmware, um wenigstens einen Befehlssatz zu de
kodieren und auszuführen. Wie in Fig. 5 dargestellt ist,
enthält die Befehlssatzeinheit 560 eine Dekodier/Ausfüh
rungseinheit 575. Die Dekodiereinheit wird zum Dekodieren
von vom Prozessor 505 empfangenen Befehlen in Steuersignale
und/oder Mikrobefehlseintragspunkte verwendet. Als Antwort
auf diese Steuersignale und/oder Mikrobefehlseintragspunkte
führt die Ausführungseinheit die geeigneten Operationen
durch. Die Dekodiereinheit kann mit Hilfe beliebig vieler
verschiedener Mechanismen implementiert werden (z. B. einer
Nachschlagtabelle, einer Hardware-Implementierung, einer PLA
usw.). Während die Ausführung der verschiedenen Befehle
durch die Dekodier- und Ausführungseinheiten hier von einer
Reihe von wenn/dann-Anweisungen dargestellt ist, ist es
klar, daß die Ausführung eines Befehls nicht eine serielle
Verarbeitung dieser wenn/dann-Anweisungen erfordert. Statt
dessen wird davon ausgegangen, daß jeder Mechanismus zum lo
gischen Ausführen dieser wenn/dann-Verarbeitung innerhalb
des Schutzbereiches der erfindungsgemäßen Implementierung
liegt.
Die Dekodier/Ausführungseinheit 575 ist mit einem Be
fehlssatz 580 dargestellt, welcher gepackte Datenbefehle
enthält. Diese gepackten Datenbefehle können so implemen
tiert werden, daß sie eine beliebige Anzahl von verschiede
nen Operationen ausführen. Bei der Ausführung können diese
gepackten Datenbefehle den Prozessor beispielsweise veran
lassen, gepackte Gleitkommaoperationen und/oder gepackte
Ganzzahloperationen auszuführen.
Bei einem Ausführungsbeispiel handelt es sich bei die
sen gepackten Datenbefehlen um diejenigen, die in "A Set of
Instructions for Operating on Packed Data", eingereicht am
31. August 1995, Aktenzeichen 08/521,360 beschrieben sind.
Zusätzlich zu den gepackten Datenbefehlen kann der Befehls
satz 580 neue Befehle und/oder Befehle enthalten, welche
ähnlich oder gleich sind, wie diejenigen, die in existie
renden Universalprozessoren zu finden sind. Beispielsweise
unterstützt der Prozessor 505 bei einem Ausführungsbeispiel
einen Befehlssatz, welcher mit dem von existierenden Prozes
soren, wie z. B. dem Pentium-Prozessor, verwendeten Intel-
Prozessor-Architektur-Befehlssatz kompatibel ist.
Fig. 5 zeigt außerdem die Befehlssatzeinheit 560 mit
einer Speichereinheit 585. Die Speichereinheit 585 reprä
sentiert ein oder mehrere Registersätze auf dem Prozessor
505 zum Speichern von Informationen, einschließlich Gleit
kommadaten, gepackter Daten, Ganzzahldaten und Steuerdaten
(z. B. eine EM-Anzeige, eine TS-Anzeige, eine Stapelkopfende
anzeige usw.). Bei bestimmten Ausführungsbeispielen, von de
nen einige hier weiter beschrieben werden, führt die Spei
chereinheit 585 ein Aliasing des gepackten Datenzustandes
auf den Gleitkommazustand aus.
Die Speichermanagementeinheit 565 repräsentiert die
Hardware und Firmware, um ein oder mehrere Speichermanage
mentschemen, wie z. B. Paging bzw. Seitenaustausch und/oder
Segmentierung, zu implementieren. Während eine beliebige
Anzahl von Speichermanagementschemen verwendet werden kann,
wird bei einem Ausführungsbeispiel ein mit der Intel-Pro
zessor-Architektur kompatibles Speichermanagementschema
implementiert. Die Ereignisbehandlereinheit 570 ist mit der
Speichermanagementeinheit 565 und der Befehlssatzeinheit 560
gekoppelt. Die Ereignisbehandlungseinheit 570 repräsentiert
die Hardware und Firmware für die Implementierung eines oder
mehrerer Ereignisbehandlungsschemen. Während eine beliebige
Anzahl von Ereignisbehandlungsschemen verwendet werden kann,
ist bei einem Ausführungsbeispiel ein mit der Intel-Prozes
sor-Architektur kompatibles Ereignisbehandlungsschema imple
mentiert.
Fig. 5 zeigt außerdem, daß in der Speichereinrichtung
510 ein Betriebssystem 535 und eine gepackte Datenroutine
540 zur Ausführung durch das Computersystem 500 gespeichert
ist. Die gepackte Datenroutine 540 ist eine Befehlssequenz,
welche einen oder mehrere gepackte Datenbefehle enthält.
Selbstverständlich enthält die Speichereinrichtung 510
vorzugsweise zusätzliche (nicht dargestellte) Software, wel
che zum Verständnis der Erfindung nicht erforderlich ist.
Während bei einem Ausführungsbeispiel verschiedene
Anzeigen (z. B. die EM-Anzeige, die TS-Anzeige usw.) mit Hil
fe von Bits in Registern auf dem Prozessor 505 implementiert
sind, könnten alternative Ausführungsbeispiele eine
beliebige Anzahl von Techniken verwenden. Beispielsweise
könnten alternative Ausführungsbeispiele diese Anzeigen
außerhalb des Chips speichern (z. B. in der Speicherein
richtung 510) und/oder könnten mehrere Bits für jede Anzeige
verwenden. Der Begriff Speicherbereich wird hierin ver
wendet, um auf irgendeinen Mechanismus zum Datenspeichern zu
verweisen, einschließlich der Speicherplätze in der Spei
chereinrichtung 510, eines oder mehrerer Register in dem
Prozessor 505 usw.
Fig. 6A zeigt ein Blockschaltbild, welches eine
Einrichtung zum Aliasing des gepackten Datenregister
zustandes auf dem Gleitkommazustand mit Hilfe von zwei
separaten physikalischen Registerdateien gemäß einem Aus
führungsbeispiel der Erfindung veranschaulicht. Da diese
beiden physikalischen Registerdateien aliased sind, er
scheinen sie der auf dem Prozessor ablaufenden Software
logisch als eine einzige logische Registerdatei. Fig. 6A
zeigt eine Übergangseinheit 600, eine Gleitkommaeinheit 605
und eine gepackten Dateneinheit 610. Die Gleitkommaeinheit
605 ähnelt der Gleitkommaeinheit 135 der Fig. 1. Die Gleit
kommaeinheit 605 enthält einen Satz von Gleitkommaregistern
615, einen Satz von Tags 620, ein Gleitkommastatusregister
625 und eine Gleitkommastapelreferenzeinheit 630. Bei einem
Ausführungsbeispiel enthält die Gleitkommaeinheit 605 acht
Register (mit R0 bis R7 bezeichnet). Jedes dieser acht Re
gister ist 80 Bits breit und enthält ein Vorzeichenfeld, ein
Exponentenfeld und ein Mantissenfeld. Die Gleitkommastapel
referenzeinheit 630 bearbeitet den Satz von Gleitkommare
gistern 615 als einen Stapel. Die Gleitkommastatusregister
155 enthalten ein Stapelkopfendefeld 635 zum Speichern der
Stapelkopfendeanzeige. Wie im Vorangegangenen beschrieben
wurde, gibt die Stapelkopfendeanzeige an, welches Register
von dem Satz der Gleitkommaregister 615 aktuell oben in dem
Gleitkommastapel ist. In Fig. 6A gibt die Stapelkopfende
anzeige ein Register 640 an dem physikalischen Ort R4 als
ST(0)-Stapelkopfende an.
Bei einem Ausführungsbeispiel enthält der Satz von Tags
620 acht Tags und ist in einem einzigen Register gespei
chert. Jedes Tag entspricht einem anderen Gleitkommaregister
und enthält zwei Bits. Alternativ kann man sich denken, daß
jedes Tag zu einem anderen Register in der logischen Re
gisterdatei gehört, und zwar aufgrund des Aliasings. Wie in
Fig. 6A gezeigt ist, entspricht das Tag 645 dem Register
640. Wie im Vorangegangenen beschrieben wurde, werden diese
Tags von der Gleitkommaeinheit 605 verwendet, um zwischen
leeren und nicht-leeren Registerorten zu unterscheiden. Wie
im Vorangegangenen beschrieben wurde, kann ein Ausführungs
beispiel Ein-Bit-Tags verwenden, welche entweder den leeren
oder den nicht-leeren Zustand angeben, aber es muß dafür
sorgen, daß diese Ein-Bit-Tags der Software erscheinen, als
enthielten sie zwei Bits, indem die passenden Zwei-Bit-Tag
werte bestimmt werden, wenn die Tagwerte benötigt werden.
Selbstverständlich könnten alternative Ausführungsbeispiele
Zwei-Bit-Tags implementieren. In jedem Fall kann man sich
die Tags als Anzeige für die beiden Zustände denken: leer,
was durch 11 angezeigt wird, und nicht-leer, was durch eine
00, 01 oder 10 angezeigt wird.
Die gepackte Dateneinheit 610 wird zum Speichern
gepackter Daten verwendet und enthält einen Satz von Re
gistern für gepackte Daten (der auch als Registerdatei für
gepackte Daten bezeichnet wird) 650, ein Statusregister für
gepackte Daten 655 und eine Nicht-Stapel-Referenz-Einheit
für gepackte Daten 660. Bei einem Ausführungsbeispiel ent
hält der Registersatz für gepackte Daten 650 acht Register.
Jedes dieser acht Register entspricht einem anderen Register
in dem Satz von Gleitkommaregistern 615. Jedes der acht Re
gister für gepackte Daten ist 64 Bits breit und wird auf das
64-Bit-Mantissenfeld des zugehörigen Gleitkommaregisters ab
gebildet. Die Nicht-Stapel-Referenz-Einheit für geparkte
Daten 660 bearbeitet die Register für gepackte Daten 650 als
eine feste Registerdatei. Folglich bezeichnen die gepackten
Datenbefehle explizit, welche Register in dem Satz von Re
gistern für gepackte Daten 650 verwendet werden sollen.
Die Übergangseinheit 600 führt ein Aliasing der Re
gister für gepackte Daten 650 auf die Gleitkommaregister 615
dadurch aus, daß sie die Daten zwischen diesen beiden physi
kalischen Registerdateien kopiert. Auf diese Weise veranlaßt
die Übergangseinheit 600 die physikalischen Gleitkomma
register 615 und die physikalischen Register für gepackte
Daten 650, für den Benutzer/Programmierer logisch als eine
einzige logische Registerdatei zu erscheinen. Auf diese Wei
se erscheint es für die Software, als ob nur eine einzige
logische Registerdatei zum Ausführen von Gleitkommabefehlen
und gepackten Datenbefehlen verfügbar ist. Die Übergangs
einheit 600 könnte mit Hilfe einer beliebigen Anzahl von
Techniken implementiert sein, einschließlich Hardware
und/oder Mikrobefehlscode. Selbstverständlich könnte die
Übergangseinheit 600 bei alternativen Ausführungsbeispielen
irgendwo auf dem Prozessor angeordnet sein. Ferner könnte
die Übergangseinheit 600 bei alternativen Ausführungsbei
spielen ein Nicht-Mikrobefehlscode-Ereignisbehandler sein,
der außerhalb des Prozessors gespeichert wird.
Die Übergangseinheit 600 könnte derart implementiert
sein, daß sie ein vollständiges oder ein partielles Aliasing
ermöglicht. Wenn der Inhalt aller Gleitkommaregister während
der Übergänge in den gepackten Datenmodus in die Register
datei für gepackte Daten kopiert wird, ist die physikalische
Gleitkommaregisterdatei vollständig auf der Registerdatei
für gepackte Daten aliased. Wenn der Inhalt aller physi
kalischen Register für gepackte Daten während der Übergänge
in den Gleitkommamodus in die Gleitkommaregisterdatei ko
piert wird, ist die physikalische Registerdatei für gepackte
Daten in ähnlicher Weise vollständig auf der physikalischen
Gleitkommaregisterdatei aliased. Dagegen wird beim partiel
len Aliasing nur der Inhalt derjenigen Register kopiert, die
"nützliche" Daten enthalten. Welche Register nützliche Daten
enthalten, kann auf der Basis einer beliebigen Anzahl von
Kriterien bestimmt werden. Beispielsweise kann ein partiel
les Aliasing dadurch implementiert werden, daß in die physi
kalischen Register für gepackte Daten nur die in denjenigen
physikalischen Gleitkommaregistern gespeicherten Daten ko
piert werden, deren zugehörige Tags den nicht-leeren Zustand
anzeigen. Selbstverständlich könnte ein Ausführungsbeispiel
beim Ausführen gepackter Datenbefehle die Gleitkommatags
verwenden oder separate gepackte Datentags zum partiellen
Aliasing der physikalischen Register für gepackte Daten auf
die physikalischen Gleitkommaregister verwenden. Alternativ
können diejenigen Register für gepackte Daten und/oder die
Gleitkommaregister als nützliche Daten enthaltend betrachtet
werden, die berührt wurden (Leseoperation aus und/oder
Schreiboperation in). Anstelle oder zusätzlich zur Anzeige
von leer oder nicht-leer könnten die Gleitkommatags für die
sen Zweck verwendet werden. Alternativ könnten zusätzliche
Anzeigen für die Gleitkommaregister und/oder Register für
gepackte Daten integriert werden, um aufzuzeichnen, welche
Register berührt wurden. Beim Implementieren des partiellen
Aliasing sollte eine gute Programmiertechnik annehmen, daß
diejenigen Register, in welche keine Daten während eines
Übergangs kopiert wurden, als undefinierte Werte enthaltend
betrachtet werden müssen.
Das Statusregister für gepackte Daten 655 enthält einen
Satz von Dirty-Feldern für gepackte Daten 655, ein spekula
tives Feld 670, ein Modusfeld 675, ein Ausnahmestatusfeld
680 und ein EMMS-Feld 685. Jedes der Dirty-Felder für ge
packte Daten 665 entspricht einem anderen der Register für
gepackte Daten 650 und wird zum Speichern einer Dirty-An
zeige verwendet. Da es eine entsprechende Beziehung zwischen
den Registern für gepackte Daten 650 und den Gleitkommare
gistern 615 gibt, steht jede Dirty-Anzeige in einer entspre
chenden Beziehung zu einem anderen der Gleitkommaregister
615. Wird ein Wert in eines der Register für gepackte Daten
650 geschrieben, wird die zu diesem Register gehörige Dirty-
Anzeige derart geändert, daß sie einen Dirty-Zustand an
zeigt.
Wenn die Übergangseinheit 600 einen Übergang von der
gepackten Dateneinheit 610 zu der Gleitkommaeinheit 605
veranlaßt, werden 1sen in die Vorzeichen- und Exponenten
felder derjenigen Gleitkommaregister 615 geschrieben, deren
Dirty-Anzeige den Dirty-Zustand anzeigt. Auf diese Weise
kann Schritt 430 von Fig. 4B ausgeführt werden.
Das Modusfeld 675 wird zum Speichern einer Modusanzeige
verwendet, welche anzeigt, in welchem Modus der Prozessor
aktuell arbeitet - in einem Gleitkommamodus, in dem die
Gleitkommaeinheit 605 aktuell verwendet wird, oder in einem
Modus für gepackte Daten, in dem die gepackte Dateneinheit
610 verwendet wird. Wenn der Prozessor sich in dem Gleit
kommamodus befindet und ein gepackter Datenbefehl empfangen
wird, muß ein Übergang von dem Gleitkommamodus in den Modus
für gepackte Daten ausgeführt werden. Wenn der Prozessor
sich im Modus für gepackte Daten befindet und ein Gleit
kommabefehl empfangen wird, muß dagegen ein Übergang vom
Modus für gepackte Daten in den Gleitkommamodus ausgeführt
werden. Somit kann sowohl beim Empfang eines gepackten Da
tenbefehls als auch eines Gleitkommabefehls die Modusanzeige
abgefragt werden, um zu bestimmen, ob ein Übergang erfor
derlich ist. Falls ein Übergang erforderlich ist, wird der
Übergang ausgeführt und die Modusanzeige entsprechend geän
dert. Die Funktionsweise der Modusanzeige wird hierin weiter
unter Bezugnahme auf die Fig. 7A-9 beschrieben.
Das Ausnahmestatusfeld 680 wird zum Speichern einer
Ausnahmestatusanzeige verwendet. Die Ausnahmestatusanzeige
wird während der Ausführung von gepackten Datenbefehlen ver
wendet, um anzuzeigen, ob es unerledigte Ausnahmen von der
Ausführung von vorangegangenen Gleitkommabefehlen gibt. Bei
einem Ausführungsbeispiel werden derartige Ausnahmen vor dem
Übergang in den Modus für gepackte Daten ausgführt, wenn die
Ausnahmestatusanzeige anzeigt, daß derartige Ausnahmen an
stehen. Bei einem Ausführungsbeispiel werden die von der
Gleitkommaeinheit 605 zu diesem Zweck verwendeten Anzeigen
entweder kodiert oder direkt in das Ausnahmestatusfeld als
Ausnahmestatusanzeige kopiert.
Das EMMS-Feld 685 wird zum Speichern einer EMMS-Anzeige
verwendet, welche anzeigt, ob der zuletzt ausgeführte ge
packte Datenbefehl der EMMS-Befehl war. Bei einem Ausfüh
rungsbeispiel wird die EMMS-Anzeige bei der Ausführung des
EMMS-Befehls auf 1 geändert, um anzuzeigen, daß der zuletzt
ausgeführte gepackte Datenbefehl der EMMS-Befehl war. Wenn
dagegen alle anderen gepackten Datenbefehle ausgeführt wer
den, wird die EMMS-Anzeige auf 0 geändert. Die Übergangsein
heit 600 fragt die EMMS-Anzeige beim Übergang von dem Modus
für gepackte Daten in den Gleitkommamodus ab, um zu be
stimmen, ob der letzte Befehl für gepackte Daten der EMMS-
Befehl war. Wenn der zuletzt ausgeführte gepackte Daten
befehl der EMMS-Befehl war, ändert die Übergangseinheit 600
alle Tags 620 in den leeren Zustand. Wenn dagegen der EMMS
anzeigt, daß der zuletzt ausgeführte gepackte Datenbefehl
nicht der EMMS war, ändert die Übergangseinheit 600 alle
Tags 620 in den nicht-leeren Zustand. Auf diese Weise werden
die Tags ähnlich wie in den Schritten 432 und 440 von Fig.
4B geändert. Das spekulative Feld 670 wird zum Speichern
einer spekulativen Anzeige verwendet, die anzeigt, ob ein
Übergang von dem Gleitkommamodus in den Modus für gepackte
Daten spekulativ ist. Wenn der Übergang spekulativ ist, kann
Zeit gespart werden, wenn ein Übergang zurück zur Gleitkom
maeinheit 605 erforderlich ist. Die Funktionsweise der Mo
dusanzeige wird hierin weiter unter Bezugnahme auf die
Fig. 7A-9 beschrieben.
Fig. 6B zeigt ein Blockschaltbild, welches einen
vergrößerten Ausschnitt der Gleitkommastapelreferenzdatei
von Fig. 6A gemäß den Ausführungsbeispielen der Erfindung
veranschaulicht. Fig. 6B zeigt, daß die Gleitkommastapel
referenzeinheit 630 eine Tagmodifiziereinheit 690 zum selek
tiven Ändern von Tags in dem Satz von Tags 620 enthält. Bei
dem in Fig. 6B dargestellten Ausführungsbeispiel enthält
jedes Tag von dem Satz von Tags 620 nur ein Bit, um leer
oder nicht-leer anzuzeigen. Die Tagmodifiziereinheit 690
enthält eine TOS-Einstellungseinheit 696 und eine Prüf/Modi
fiziereinheit 698. Jede der TOS-Einstellungseinheiten 696
ist mit Mikrobefehlscodeleitungen 692 gekoppelt, um je nach
der Implementierung einen oder mehrere Mikrobefehlscode(s)
zu empfangen (z. B. könnte es nur eine TOS-Einstellungsein
heit geben, welche nur einen Mikrobefehlscode empfängt).
Wenigstens diejenigen Mikrobefehlscodes für die Gleitkom
mabefehle, welche eine Änderung der Tags erfordern, werden
von den TOS-Einstellungseinheiten 696 empfangen. Selbstver
ständlich kann die Gleitkommastapelreferenzeinheit 630 der
art implementiert sein, daß alle oder nur die relevanten
Teile jedes Mikrobefehlscodes von den TOS-Einstellungsein
heiten 696 empfangen werden.
Als Antwort auf den Empfang eines Mikrobefehlscode
überträgt eine TOS-Einstellungseinheit zu der Prüf/Modi
fiziereinheit 698 wenigstens: 1) die Adresse(n) des (der)
Tags in dem Satz von Tags 620, welche(s) von dem Mikro
befehlscode identifiziert wird; und 2) Signal(e), welche(s)
die an diesem(n) Tag(s) auszuführende Maßnahme anzeigen
(z. B. geändert auf 0 oder 1, abgefragt). Da das Abfragen von
Tags für das Verständnis der Erfindung nicht erforderlich
ist, wird es hier nicht weiter beschrieben. Jede der TOS-
Einstellungseinheiten 696 ist außerdem mit Leitungen 694 zum
Empfangen des aktuellen TOS-Wertes und zum entsprechenden
Einstellen der TAG-Adresse(n) gekoppelt. Die Prüf/Modifi
ziereinrichtung 698 ist mit jedem Tag 620 über wenigstens
eine Schreibleitung gekoppelt. Beispielsweise ist die
Prüf/Modifiziereinheit 698 mit dem Tag 645 über eine
Schreibleitung gekoppelt. Als Antwort auf den Empfang einer
(von) Tagadresse(n) und zugehöriger Signale führt die
Prüf/Modifiziereinheit 698 die benötigten Überprüfungen
und/oder Modifikationen durch. Bei einer Implementierung,
bei der mehrere Mikrobefehlscodes gleichzeitig empfangen
werden können, vergleicht die Prüf/Modifiziereinheit 698
außerdem die Mikrobefehlscodes, um zu bestimmen, ob sie die
gleichen Tags modifizieren (z. B. angenommen, Mikrobefehls
code 1 erfordert die Änderung von Tag eins auf 1, während
Mikrobefehlscode zwei, der gleichzeitig mit Mikrobefehlscode
eins empfangen wurde, die Änderung von Tag eins auf 0 erfor
dert). Wenn das gleiche Tag modifiziert wird, bestimmt die
Prüf/Modifiziereinheit 698, welcher Mikrobefehlscode zuletzt
ausgeführt werden soll und ändert den Tag gemäß diesem Mi
krobefehlscode. Bei dem obigen Beispiel würde die Prüf/Mo
difiziereinheit 698 unter der Annahme, daß der Mikrobe
fehlscode zwei nach dem Mikrobefehlscode eins ausgeführt
werden soll, Tag eins derart ändern, daß es 0 anzeigt.
Wenn eine Gleitkommaoperation durchgeführt wurde, die
die Änderung eines Tags (z. B. Tag 645) in den leeren Zustand
erfordert, würde eine TOS-Einstellungseinheit den aktuellen
TOS-Wert empfangen und einen ein Tag identifizierenden
Mikrobefehlscode auf den Mikrobefehlscodeleitungen 692. Die
TOS-Einstellungseinheit würde die Adresse des Tags bestimmen
(z. B. Tag 645) und diese Adresse sowie Signale, welche an
zeigen, daß dieses Tag in den leeren Zustand geändert werden
soll, an die Prüfmodifiziereinheit 698 übertragen. Als Ant
wort würde die Prüfmodifiziereinheit 698 das Tag 645 in den
leeren Zustand ändern, indem sie eine 0 auf der mit dem Tag
645 gekoppelten Schreibleitung übertragen würde.
Da die Gleitkommabefehle derart implementiert sein
können, daß nicht alle Tags gleichzeitig modifiziert werden
müssen, ist die Tagmodifiziereinheit 690 bei einem Aus
führungsbeispiel derart implementiert, daß sie nicht alle
Tags gleichzeitig modifizieren kann. Um eine zu komplexe
Schaltung zu vermeiden, kann das globale Ändern von Tags als
Antwort auf einen Übergang in den Gleitkommamodus mit Hilfe
dieses existierenden Mechanismus implementiert werden. In
diesem Zusammenhang steht, daß der Satz von Mikrobefehls
codebefehlen die Dekodiereinheit veranlassen würde, ver
schiedene existierende Mikrobefehlscodes zum Ändern der acht
Tags auszugeben, wenn die Übergangseinheit 600 im Mikrobe
fehlscode implementiert ist. Folglich würde die Dekodierein
heit als Antwort auf einen Übergang in den gepackten Da
tenmodus, während die EMMS-Anzeige anzeigt, daß der EMMS-
Befehl der zuletzt ausgeführte gepackte Datenbefehl war, auf
die Übergangseinheit 600 zugreifen und verschiedene existie
rende Mikrobefehlscodes ausgeben. Als Antwort auf diese Mi
krobefehlscodes würde die Tagmodifiziereinheit 690 die zuge
hörigen Tags in den leeren Zustand modifizieren. Dagegen
würde die Dekodiereinheit als Antwort auf einen Übergang in
den gepackten Datenmodus, während die EMMS-Anzeige anzeigt,
daß der EMMS-Befehl nicht der zuletzt ausgeführte gepackte
Datenbefehl war, auf die Übergangseinheit 00 zugreifen und
verschiedene existierende Mikrobefehlscodes ausgeben, welche
die Tagmodifiziereinheit 690 veranlassen würden, jedes Tag
in den nicht-leeren Zustand zu ändern. Bei einem derartigen
Ausführungsbeispiel kann das globale Ändern der Tags unge
fähr 4-8 Taktzyklen dauern.
Während ein Ausführungsbeispiel zum Ändern aller Tags
als Antwort auf einen Übergang in den gepackten Datenmodus
beschrieben wurde, können alternative Ausführungsbeispiele
jede beliebige Anzahl von Mechanismen verwenden. Beispiels
weise kann das Ändern der Tags in den leeren oder nicht-lee
ren Zustand in einem einzigen Taktzyklus abgeschlossen wer
den, indem ein neuer Mikrobefehlscode integriert wird und
die Tagmodifiziereinheit 690 derart implementiert wird, daß
sie die Tags als Antwort auf den neuen Mikrobefehlscode
global ändern kann. Bei diesem Ausführungsbeispiel kann die
Übergangseinheit 600 derart implementiert werden, daß sie
die Dekodiereinheit veranlaßt, diesen einzigen Mikrobe
fehlscode auszugeben (anstelle von verschiedenen separaten
Mikrobefehlscodes), um alle Tags in den leeren Zustand oder
den nicht-leeren Zustand zu ändern. Bei einem weiteren Bei
spiel könnte die Dekodiereinheit mit den Tags 620 gekoppelt
sein und zusätzliche Hardware zum Ändern aller Tags 620 als
Antwort auf den Empfang de EMMS-Befehls enthalten.
Obwohl der Satz von Tags 620 als aus Ein-Bit-Tags be
stehend beschrieben wurde, kann der Satz von Tags 620 so
gestaltet werden, daß es erscheint, als ob jedes Tag 2 Bits
enthält, wie im Vorangegangenen beschrieben wurde. Ein al
ternatives Ausführungsbeispiel könnte die beiden Bits für
jedes Tag dadurch implementieren, daß zusätzliche kodierte
oder nicht-kodierte Leitungen zur Anzeige der verschiedenen
Zustände (z. B. 00, 01, 10, 11), in die die Tags geändert
werden sollen, integriert werden.
Die Fig. 7A, 7B, 7C, 8 und 9 zeigen ein Verfahren
gemäß einem Ausführungsbeispiel der Erfindung zum Ausführen
von gepackten Datenbefehlen auf einem Satz von Registern,
welcher auf einen Satz von Gleitkommaregistern aliased ist,
in einer Weise, die für Betriebssysteme unsichtbar ist, gute
Programmierpraktiken unterstützt und mit Hilfe der Hardware
anordnung gemäß Fig. 6A realisiert werden kann. Dieses
Ablaufdiagramm ähnelt dem unter Bezugnahme auf die Fig.
4A und 4B beschriebenen Ablaufdiagramm. Unter Bezugnahme auf
die Fig. 4A und 4B wurden viele alternative Ausführungs
beispiele beschrieben, bei denen Schritte geändert, umge
stellt und/oder weggelassen wurden. Es sollte klar sein, daß
unter Bezugnahme auf die Fig. 7A, 7B, 7C, 8 und 9 be
schriebene Schritte, welche den in den Fig. 4A und 4B
ausgeführten Schritten ähneln, wenigstens unter Verwendung
solcher alternativen Ausführungsbeispiele ausgeführt werden
können. Das Ablaufdiagramm beginnt mit dem Schritt 700. Vom
Schritt 700 geht der Ablauf zum Schritt 702 weiter.
Wie im Schritt 702 gezeigt ist, wird als Befehl auf
einen Bitsatz zugegriffen und der Ablauf geht mit dem
Schritt 704 weiter. Dieser Bitsatz enthält einen Befehls
code, der die von dem Befehl auszuführende(n) Operation(en)
identifiziert. Somit ähnelt der Schritt 702 dem Schritt 402
der Fig. 4A.
Im Schritt 704 wird festgestellt, ob der Befehlscode
gültig ist. Wenn der Befehlscode nicht gültig ist, geht der
Ablauf mit dem Schritt 706 weiter. Ansonsten geht der Ablauf
mit dem Schritt 708 weiter. Der Schritt 704 ähnelt dem
Schritt 404 in Fig. 4A.
Wie im Schritt 706 gezeigt ist, wird die "ungültiger
Befehlscode"-Ausnahme erzeugt und der geeignete Ereignis
behandler ausgeführt. Somit ähnelt der Schritt 706 dem
Schritt 406 der Fig. 4A.
Im Schritt 708 wird festgestellt, welche Art von Befehl
empfangen wurde. Wenn der Befehl weder ein Gleitkommabefehl
noch ein gepackten Datenbefehl ist, geht der Ablauf mit dem
Schritt 710 weiter. Wenn der Befehl jedoch ein Gleitkomma
befehl ist, geht der Ablauf mit dem Schritt 712 weiter. Wenn
der Befehl dagegen ein gepackter Datenbefehl ist, geht der
Ablauf mit dem Schritt 714 weiter. Folglich ähnelt der
Schritt 708 dem Schritt 408 der Fig. 4A.
Wie im Schritt 710 gezeigt ist, führt der Prozessor den
Befehl aus. Da dieser Schritt nicht erforderlich für das
Verständnis der Erfindung ist, wird er hier nicht weiter
beschrieben. Der Schritt 710 ähnelt dem Schritt 410 der
Fig. 4A.
Wie im Schritt 712 gezeigt ist, wird festgestellt, ob
die EM-Anzeige gleich 1 ist (gemäß der beschriebenen Soft
warekonvention gilt dies, wenn die Gleitkommaeinheit emu
liert werden soll) und ob die TS-Anzeige gleich 1 ist (gemäß
der beschriebenen Softwarekonvention gilt dies, wenn eine
partielle Kontextumschaltung durchgeführt wurde. Wenn die
EM-Anzeige und/oder die TS-Anzeige gleich 1 ist, geht der
Ablauf mit dem Schritt 716 weiter. Ansonsten geht der Ablauf
mit dem Schritt 720 weiter. Folglich ähnelt der Schritt 712
dem Schritt 412 der Fig. 4A.
Im Schritt 716 wird die "Einrichtung nicht verfügbar"-
Ausnahme erzeugt und der zugehörige Ereignisbehandler wird
ausgeführt. Folglich ähnelt der Schritt 716 dem Schritt 416
der Fig. 4A. Wie im Vorangegangenen beschrieben wurde, kann
dieser Ereignisbehandler derart implementiert werden, daß er
die EM- und TS-Anzeige verwendet, um zu bestimmen, ob der
Gleitkommabefehl emuliert werden soll und/oder ob eine par
tielle Kontextumschaltung durchgeführt wurde.
Im Schritt 714 wird festgestellt, ob die EM-Anzeige
gleich 1 ist. Folglich ähnelt der Schritt 714 dem Schritt
414 der Fig. 4A. Wenn im Schritt 714 festgestellt wird, daß
die EM-Anzeige gleich 1 ist, geht der Ablauf folglich mit
dem Schritt 706 und nicht mit dem Schritt 716 weiter. Anson
sten geht der Ablauf mit dem Schritt 718 weiter.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 706 die "ungültiger Befehlscode"-Ausnahme erzeugt
und der zugehörige Ereignisbehandler wird ausgeführt. Da
durch, daß die versuchsweise Ausführung eines gepackten Da
tenbefehls bei EM = 1 in die "ungültiger Befehlscode"-Aus
nahme umgelenkt wird, ist das Ausführungsbeispiel für Be
triebssysteme unsichtbar, wie im Vorangegangenen unter Be
zugnahme auf Schritt 406 der Fig. 4A beschrieben wurde.
Während ein Ausführungsbeispiel zum Behandeln der EM-
Anzeige in einer für Betriebssysteme unsichtbaren Weise
beschrieben wurde, könnten alternative Ausführungsbeispiele
andere Techniken verwenden. Beispielsweise könnte ein alter
natives Ausführungsbeispiel entweder die "Einrichtung nicht
verfügbar"-Ausnahme, ein anderes existierendes Ereignis oder
ein neues Ereignis in Antwort auf die versuchsweise Ausfüh
rung eines gepackten Datenbefehls erzeugen, während die EM-
Anzeige gleich 1 ist. Als weiteres Beispiel könnte ein al
ternatives Ausführungsbeispiel die EM-Anzeige bei der Aus
führung gepackter Datenbefehle ignorieren.
Wie im Schritt 718 gezeigt ist, wird festgestellt, ob
die TS-Anzeige gleich 1 ist (gemäß der beschriebenen Soft
ware-Konvention gilt dies, wenn eine partielle Kontextum
schaltung durchgeführt wurde). Wenn die TS-Anzeige gleich 1
ist, geht der Ablauf mit dem Schritt 716 weiter. Ansonsten
geht der Ablauf mit dem Schritt 722 weiter. Folglich ähnelt
der Schritt 718 dem Schritt 418 der Fig. 4A.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 716 die "Einrichtung nicht verfügbar"-Ausnahme
erzeugt und der zugehörige Ereignisbehandler ausgeführt. Der
Schritt 716 ähnelt dem Schritt 418 der Fig. 4A. Da der
Schritt 714 Situationen, in denen die EM-Anzeige gleich 1
ist, in die "ungültiger Befehlscode"-Ausnahme umgeleitet
hat, muß die EM-Anzeige gleich 0 sein und die TS-Anzeige muß
gleich 1 sein. Da TS gleich 1 ist, veranlaßt der Ereignis
behandler den Prozessor so zu funktionieren, wie im Voran
gegangenen unter Bezugnahme auf die partiellen Kontextum
schaltungen beschrieben wurde (Speicherung des Inhalts der
Gleitkommaeinheit und Wiederherstellung des richtigen Gleit
kommazustandes, sofern erforderlich) und veranlaßt den Pro
zessor zur Wiederaufnahme der Ausführung, indem die Aus
führung des im Schritt 702 empfangenen Befehls neu gestartet
wird. Da der gepackte Datenzustand auf den Gleitkommazustand
aliased ist, arbeitet dieser Ereignisbehandler sowohl für
den Gleitkommazustand als auch für den gepackten Datenzu
stand. Folglich bleibt dieses Verfahren für Betriebssysteme
unsichtbar. Natürlich können alternative Ausführungsbei
spiele diesen Ereignisbehandler in beliebig vielen Weisen
implementieren.
Während ein Ausführungsbeispiel beschrieben wurde, um
die TS-Anzeige in einer für Betriebssysteme unsichtbaren
Weise zu behandeln, könnten alternative Ausführungsbeispiele
andere Techniken verwenden. Beispielsweise kann ein alter
natives Ausführungsbeispiel die TS-Anzeige nicht implemen
tieren. Ein derartiges alternatives Ausführungsbeispiel wäre
mit Betriebssystemen nicht kompatibel, welche die TS-Anzeige
zur Implementierung partieller Kontextumschaltung verwenden.
Jedoch wäre ein derartiges Ausführungsbeispiel mit existie
renden Betriebssystemen kompatibel, welche partielle Kon
textumschaltungen mit Hilfe der TS-Anzeige nicht unter
stützen. Als weiteres Beispiel könnte die versuchsweise Aus
führung eines gepackten Datenbefehls, während die TS-Anzeige
gleich 1 ist, zu einem neuen Ereignisbehandler oder zu einem
existierenden Ereignisbehandler umgelenkt werden, welcher
modifiziert wurde. Dieser Ereignisbehandler könnte derart
implementiert werden, daß er als Antwort auf diese Situation
jede geeignet erscheinende Maßnahme ergreift. Beispielsweise
könnte dieser Ereignisbehandler den gepackten Datenzustand
oder den Gleitkommazustand bei einem Ausführungsbeispiel
speichern, bei dem der gepackte Datenzustand nicht auf dem
Gleitkommazustand aliased ist.
Wenn bestimmte numerische Fehler während der Ausführung
eines Gleitkommabefehls erzeugt werden, werden diese Fehler,
wie im Vorangegangenen beschrieben wurde, bis zur versuchs
weisen Ausführung des nächsten Gleitkommabefehls anhängig
gelassen, dessen Ausführung zu deren Bearbeitung unter
brochen werden kann. Wie im Vorangegangenen beschrieben
wurde, wird in beiden Schritten 420 und 422 der Fig. 4
bestimmt, ob es derartige unerledigte Fehler gibt, die be
arbeitet werden können. Im Schritt 720 wird ähnlich zum
Schritt 420 in Fig. 4A festgestellt, ob es irgendwelche
derartigen unerledigten Fehler gibt, die bearbeitet werden
können. Wenn es irgendwelche derartigen unerledigten Fehler
gibt, geht der Ablauf vom Schritt 720 zum Schritt 724 wei
ter. Wenn im Schritt 720 jedoch festgestellt wird, daß es
keine derartigen unerledigten Fehler gibt, geht der Ablauf
mit dem Schritt 726 weiter. Dagegen wird die Bestimmung, ob
es irgendwelche unerledigten Fehler von den vorangegangenen
Gleitkommabefehlen während der versuchsweisen Ausführung ei
nes gepackten Datenbefehls gibt, in einem anderen Schritt
ausgeführt, welcher später weiter beschrieben wird. Folglich
unterscheidet sich der Schritt 722 vom Schritt 422.
Im Schritt 724 wird ein "unerledigter Gleitkommafeh
ler"-Ereignis erzeugt. Folglich ähnelt der Schritt 724 dem
Schritt 424 der Fig. 4A.
Wie im Vorangegangenen unter Bezugnahme auf Schritt 424
der Fig. 4A beschrieben wurde, kann dieses Ereignis als
internes oder externes Ereignis behandelt werden und ent
sprechend bearbeitet werden.
Wie im Schritt 726 gezeigt ist, wird festgestellt, ob
die Modusanzeige anzeigt, daß der Prozessor in dem Gleit
kommamodus arbeitet. Folglich unterscheidet sich der Schritt
726 vom Schritt 426 in Fig. 4B. Wenn der Prozessor nicht im
Gleitkommamodus ist, muß der Prozessor von dem gepackten Mo
dus in den Gleitkommamodus übergehen, um den Gleitkommabe
fehl auszuführen. Folglich geht der Ablauf zum Schritt 728
weiter, wenn der Prozessor nicht im Gleitkommamodus ist.
Ansonsten geht der Ablauf mit dem Schritt 732 weiter.
Im Schritt 728 wird der Prozessor von dem gepackten
Datenmodus in den Gleitkommamodus überführt und der Ablauf
geht mit dem Schritt 730 weiter. Der Schritt 728 wird von
der Übergangseinheit 600 der Fig. 6A ausgeführt und wird
unter Bezugnahme auf Fig. 9 weiter beschrieben.
Wie im Schritt 730 gezeigt ist, wird der im Schritt 702
empfangene Befehl durch Ausführung eines "Mikrobefehlscode-
Neustarts" neu gestartet. Da der Schritt 728 bei einem Aus
führungsbeispiel mit Hilfe von Mikrobefehlscodes ausgeführt
wird und der Befehl mit Mikrobefehlscodes neu gestartet
wird, muß kein Betriebssystemereignisbehandler ausgeführt
werden. Folglich kann die Ausführung der aktuellen Task wie
deraufgenommen werden, ohne daß außerhalb des Prozessors ir
gendeine Aktion durchgeführt werden muß - es müssen keine
Nicht-Mikrobefehlscode-Ereignisbehandler, wie z. B. Betriebs
systemereignisbehandler ausgeführt werden. Folglich kann der
Prozessor von dem gepackten Datenmodus in einer für Soft
ware, einschließlich Betriebssysteme, unsichtbaren Weise in
den Gleitkommamodus übergehen. Auf diese Weise ist dieses
Ausführungsbeispiel mit existierenden Betriebssystemen kom
patibel. Alternative Ausführungsbeispiele könnten derart im
plementiert sein, daß sie weniger kompatibel sind. Bei
spielsweise könnte ein zusätzliches Ereignis in den Prozes
sor integriert werden und ein zusätzlicher Ereignisbehandler
könnte zu dem Betriebssystem hinzugefügt werden, um diesen
Übergang auszuführen.
Wie im Schritt 732 gezeigt ist, wird der Gleitkomma
befehl ausgeführt. Der Schritt 732 ähnelt dem Schritt 426
der Fig. 4B. Um unsichtbar für das Betriebssystem zu blei
ben, ändert ein Ausführungsbeispiel außerdem die Tasks, so
weit erforderlich, berichtet alle numerischen Fehler, die
nun bearbeitet werden können, und läßt alle anderen nume
rischen Fehler anhängig. Wie im Vorangegangenen beschrieben
wurde, erlaubt es die Änderung der Tags diesem Ausführungs
beispiel, für derartige Betriebssystemtechniken unsichtbar
zu bleiben, die den Inhalt nur derjenigen Gleitkommaregister
speichern, deren zugehöriges Tag einen nicht-leeren Zustand
anzeigt. Wie im Vorangegangenen beschrieben wurde, könnten
alternative Ausführungsbeispiele derart implementiert wer
den, daß sie mit weniger von speziellen Betriebssystem
techniken kompatibel sind. Wenn ein existierendes Betriebs
system beispielsweise keine Tags verwendet, wäre ein Prozes
sor, der die Tags nicht implementiert, weiterhin mit diesem
Betriebssystem kompatibel. Ferner ist es für die Erfindung
nicht notwendig, daß numerische Gleitkommaausnahmen anhängig
bleiben, und folglich liegen alternative Ausführungsbeispie
le, welche dies nicht vorsehen, noch immer im Schutzbereich
der Erfindung.
Wie im Schritt 722 gezeigt ist, wird festgestellt, ob
die Modusanzeige anzeigt, daß der Prozessor in dem gepackten
Datenmodus ist. Folglich unterscheidet sich der Schritt 722
von dem Schritt 422 der Fig. 4A. Der Schritt 722 wird aus
geführt, um festzustellen, ob der Prozessor in dem richtigen
Modus zur Ausführung des gepackten Datenbefehls ist. Wenn
der Prozessor nicht in dem gepackten Datenmodus ist, muß der
Prozessor von dem Gleitkommamodus in den gepackten Datenmo
dus überführt werden, um den gepackten Datenbefehl auszufüh
ren. Wenn der Prozessor nicht in dem gepackten Datenmodus
ist, geht der Ablauf folglich mit dem Schritt 734 weiter.
Ansonsten geht der Ablauf mit dem Schritt 738 weiter.
Im Schritt 734 wird der Prozessor von dem Gleitkommamo
dus in den gepackten Datenmodus überführt, und der Ablauf
geht mit dem Schritt 736 weiter. Der Schritt 734 wird von
der Übergangseinheit 600 der Fig. 6A ausgeführt und wird
ferner unter Bezugnahme auf Fig. 8 beschrieben.
Wie im Schritt 736 gezeigt ist, wird der im Schritt 702
empfangene Befehl durch Ausführung eines Mikrobefehl-Neu
starts neu gestartet. Folglich ähnelt der Schritt 736 dem
Schritt 730.
Im Schritt 740 wird festgestellt, ob der gepackte Da
tenbefehl der EMMS-Befehl ist. Wenn der gepackte Datenbefehl
der EMMS-Befehl ist, geht der Ablauf mit dem Schritt 742
weiter. Ansonsten der Ablauf mit dem Schritt 744 weiter. Da
die gepackten Datenbefehle auf einer separaten Einheit aus
geführt werden (d. h. der gepackten Dateneinheit), ist es ef
fizienter, Anzeigen zu speichern (z. B. die EMMS-Anzeige),
welche anzeigen, was im Schritt 728 getan werden muß, wenn
in den Gleitkommamodus zurückgegangen wird, als bestimmte
Operationen tatsächlich auszuführen (z. B. Ändern der Tags in
den leeren Zustand als Antwort auf die Ausführung des EMMS-
Befehls und Ändern der Tags in einen nicht-leeren Zustand
als Antwort auf die Ausführung anderer gepackten Datenbe
fehle. Die Verwendung der EMMS-Anzeige sowie andere Anzeigen
wird unter Bezugnahme auf den Schritt des Übergangs von dem
gepackten Datenmodus in den Gleitkommamodus beschrieben,
welcher in Fig. 9 weiter beschrieben wird.
Wie im Schritt 742 gezeigt ist, wird die EMMS-Anzeige
derart geändert, daß sie anzeigt, daß der letzte gepackte
Datenbefehl der EMMS-Befehl war. Bei Beendigung des Schrit
tes 742 ist der Prozessor frei, den nächsten Befehl auszu
führen (den Befehl, welcher dem im Schritt 702 empfangenen
Befehl logisch folgt).
Wie im Schritt 744 dargestellt ist, wird die EMMS-An
zeige derart geändert, daß sie anzeigt, daß der letzte ge
packte Datenbefehl kein EMMS-Befehl war.
Wie im Schritt 744 gezeigt ist, wird die spekulative
Anzeige derart geändert, daß sie anzeigt, daß der Übergang
vom Gleitkommamodus in den gepackten Datenmodus nicht länger
spekulativ ist. Vom Schritt 744 geht der Ablauf zum Schritt
746 weiter. Wie es im Schritt 738 gezeigt ist, wird die Spe
kulativ-Anzeige so geändert, daß sie anzeigt, daß der Über
gang vom Gleitkommamodus in den Gepackte-Daten-Modus nicht
länger spekulativ ist. Vom Schritt 738 geht der Ablauf zum
Schritt 740 weiter. Die Funktionsweise der spekulativen An
zeige wird unter Bezugnahme auf Fig. 8 weiter beschrieben.
Wie im Schritt 746 gezeigt ist, wird festgestellt, ob
der gepackte Datenbefehl den Prozessor veranlaßt, in irgend
welche aliased Register zu schreiben. Falls dies der Fall
ist, geht der Ablauf mit dem Schritt 748 weiter. Ansonsten
geht der Ablauf mit dem Schritt 750 weiter. Folglich ähnelt
der Schritt 746 dem Schritt 436 der Fig. 4B.
Im Schritt 748 werden die zu den aliased Registern ge
hörigen Dirty-Anzeigen in den Dirty-Zustand geändert, und
der Ablauf geht mit dem Schritt 750 weiter. Diese Dirty-An
zeigen werden im Schritt 728 beim Übergang von dem gepackten
Datenmodus in den Gleitkommamodus verwendet. Wie im Vorange
gangenen beschrieben wurde, werden diese Dirty-Anzeigen ver
wendet, um diejenigen Gleitkommaregister zu kennzeichnen, in
deren Vorzeichen- und Exponentenfelder 1sen geschrieben wer
den sollen. Während bei einem Ausführungsbeispiel 1sen in
die Vorzeichen- und Exponentenfelder geschrieben werden,
könnten alternative Ausführungsbeispiele jeden NAN (keine
Zahl) oder unendlich darstellenden Wert verwenden. Die
Schritte 746 und 748 wären bei einem alternativen Ausfüh
rungsbeispiel nicht erforderlich, bei dem die Vorzeichen-
und Exponentenfelder nicht geändert werden.
Wie im Schritt 750 gezeigt ist, wird der gepackte Da
tenbefehl ohne die Erzeugung irgendwelcher numerischer Aus
nahmen ausgeführt. Folglich ähnelt der Schritt 750 dem
Schritt 440 der Fig. 4B, nur die Stapelkopfendeanzeige wird
nicht geändert. Wie im Vorangegangenen beschrieben wurde,
könnten alternative Ausführungsbeispiele, welche für Be
triebssysteme nicht vollständig unsichtbar sind, derart im
plementiert werden, daß entweder zusätzliche Ereignisbehand
ler in das Betriebssystem integriert werden oder daß exi
stierende Ereignisbehandler zur Bearbeitung der Fehler abge
ändert werden. Wenn irgendwelche Speicherereignisse als
Folge des Versuchs, den gepackten Datenbefehl auszuführen,
erzeugt werden, wird die Ausführung unterbrochen und das Er
eignis bearbeitet. Selbstverständlich benötigt ein Ausfüh
rungsbeispiel, welches den EMMS-Befehl nicht verwendet, die
Schritte 740, 742 und 744 nicht.
Folglich wurde ein Verfahren und eine Einrichtung zum
Ausführen gepackter Datenbefehle beschrieben, welche mit
exisiterenden Betriebssystemen kompatibel sind (z. B. Be
triebsumgebungen der Marke MS-DOS Windows, die von Microsoft
Corporation aus Redmond, Washingten, erhältlich sind) und
welche gute Programmiertechniken unterstützen. Da der ge
packte Datenzustand auf dem Gleitkommazustand aliased ist,
wird der gepackte Datenzustand erhalten und von existieren
den Betriebssystemen wiederhergestellt, als ob es der Gleit
kommazustand wäre. Da außerdem durch die Ausführung der ge
packten Datenbefehle erzeugte Ereignisse von existierenden
Betriebssystemereignisbehandlern bedienbar sind, müssen
diese Ereignisbehandler nicht modifiziert werden, und neue
Ereignisbehandler müssen nicht hinzugefügt werden. Folglich
ist der Prozessor mit älteren Programmen kompatibel, und ei
ne Erweiterung erfordert nicht die zur Entwicklung oder Än
derung eines Betriebssystems erforderlichen Kosten und Zeit.
Variationen dieses Ausführungsbeispiels, von denen
einige beschrieben wurden, können vollständig oder teilweise
mit derartigen Betriebssystemen kompatibel sein und/oder
gute Programmiertechniken unterstützen. Beispielsweise kann
ein alternatives Ausführungsbeispiel der Erfindung bestimmte
Schritte an andere Stellen in dem Ablaufdiagramm umstellen.
Andere Ausführungsbeispiele der Erfindung können einen oder
mehrere Schritte ändern oder weglassen. Wenn bestimmte
Schritte der Fig. 7A, 7B und/oder 7C weggelassen würden,
würde bestimmte Hardware in Fig. 6A nicht benötigt. Wenn
der EMMS-Befehl beispielsweise nicht verwendet wird, wird
die EMMS-Anzeige nicht benötigt. Selbstverständlich kann die
Erfindung für eine beliebige Anzahl von Systemarchitekturen
nützlich sein und ist nicht auf die hier beschriebene Archi
tektur beschränkt.
Während ein Verfahren und eine Einrichtung zum Aliasing
zweier physikalischer Registerdateien beschrieben wurde,
können alternative Ausführungsbeispiele jede beliebige An
zahl von physikalischen Registerdateien zur Ausführung einer
beliebigen Anzahl unterschiedlicher Befehlsarten durch
Aliasing verbinden. Während dieses Ausführungsbeispiel unter
Bezugnahme auf eine physikalische Stapelregisterdatei zum
Ausführen von Gleitkommabefehlen beschrieben wurde und auf
eine physikalische Einfach-Registerdatei zum Ausführen ge
packter Datenbefehle, kann die hier beschriebene Lehre zu
sätzlich zum Aliasing wenigstens einer physikalischen Sta
pelregisterdatei und wenigstens einer physikalischen Ein
fachregisterdatei verwendet werden, unabhängig von der Art
der Befehle, welche auf diesen Registerdateien ausgeführt
werden sollen.
Während ein Verfahren und eine Einrichtung zum Aus
führen von Gleitkommabefehlen und gepackten Datenbefehlen
beschrieben wurde, können alternative Ausführungsbeispiele
für die Ausführung einer beliebigen Anzahl verschiedener
Arten von Befehlen implementiert werden. Wie im Vorange
gangenen beschrieben wurde, könnten die gepackten Daten
befehle derart implementiert werden, daß sie den Prozessor
veranlassen, gepackte Ganzzahloperationen und/oder gepackte
Gleitkommaoperationen durchzuführen. Als weiteres Beispiel
könnte ein alternatives Ausführungsbeispiel ein Aliasing von
physikalischen Registerdateien zur Ausführung von skalaren
Gleitkommabefehlen und von skalaren Ganzzahlbefehlen durch
führen, anstelle von oder zusätzlich zu gepackten Daten
befehlen. Als weiteres Beispiel könnten alternative Ausfüh
rungsbeispiele statt eines Aliasings der Register für ge
packte Datenbefehle auf die Gleitkommaregister ein Aliasing
von Registern für gepackte Datenbefehle auf die Ganzzahl
register vorsehen. Als weiteres Beispiel könnten alternative
Ausführungsbeispiele ein Aliasing der Ausführung von ska
laren Gleitkommabefehlen, skalaren Ganzzahlbefehlen und ge
packten Befehlen (Ganzzahl und/oder Gleitkomma) auf eine
einzige logische Registerdatei durchführen. Folglich kann
die hier beschriebene Lehre verwendet werden, damit es Soft
ware logisch erscheint, als ob eine einzige logische Re
gisterdatei für die Ausführung von Befehlen verfügbar ist,
welche verschiedene Datenarten bearbeiten.
Fig. 8 zeigt ein Ablaufdiagramm, welches ein Verfahren
zur Ausführung des Schrittes 734 der Fig. 7C gemäß einem
Ausführungsbeispiel der Erfindung veranschaulicht. Wie im
Vorangegangenen beschrieben wurde, wird der Prozessor im
Schritt 754 von dem Gleitkommamodus in den Modus für gepack
te Daten überführt. Nach dem Schritt 722 geht der Ablauf mit
dem Schritt 800 weiter.
Wie im Schritt 800 gezeigt ist, wird festgestellt, ob
es irgendwelche unerledigten Fehler von vorangegangenen
Gleitkommabefehlen gibt. Falls dies der Fall ist, geht der
Ablauf mit dem Schritt 724 weiter. Ansonsten geht der Ablauf
mit dem Schritt 804 weiter. Folglich ähnelt der Schritt 800
dem Schritt 720 der Fig. 7 und Schritt 422 der Fig. 4A.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 724 die "unerledigter Gleitkommafehler"-Ausnahme er
zeugt, und der geeignete Ereignisbehandler wird ausgeführt.
Wie im Vorangegangenen unter Bezugnahme auf den Schritt 424
der Fig. 4A beschrieben wurde, kann dieses Ereignis als ein
internes oder ein externes Ereignis behandelt werden und
entsprechend bedient werden. Bei einem alternativen Aus
führungsbeispiel bleiben derartige Fehler während der Aus
führung von gepackten Datenbefehlen unerledigt.
Wie im Schritt 804 gezeigt ist, werden die in den Man
tissenfeldern der Gleitkommaregister gespeicherten Daten in
die zugehörigen gepackten Datenregister kopiert. Dadurch
können Daten, welche in den Gleitkommaregistern gespeichert
wurden, als gepackte Daten bearbeitet werden. Sofern ein
vollständiges Aliasing implementiert ist, werden die in den
Mantissenfeldern aller Gleitkommaregister gespeicherten Da
ten in die zugehörigen gepackten Datenregister kopiert. Wenn
dagegen ein partielles Aliasing implementiert ist, kann ein
Ausführungsbeispiel derart implementiert sein, daß nur die
in den Mantissenfeldern derjenigen Gleitkommaregister ge
speicherten Daten in die geeigneten, zugehörigen gepackten
Datenregister kopiert werden, deren zugehöriges Tag den
nicht-leeren Zustand anzeigt. Alternative Ausführungsbei
spiele, welche nicht erlauben, daß die in den Gleitkomma
registern gespeicherten Daten als gepackte Daten bearbeitet
werden, müssen den Schritt 804 nicht ausführen. Nach Schritt
804 geht der Ablauf mit dem Schritt 806 weiter.
Im Schritt 806 wird die EMMS-Anzeige derart geändert,
daß sie anzeigt, daß der letzte gepackte Datenbefehl nicht
der EMMS-Befehl war, und der Ablauf geht mit dem Schritt 808
weiter. Dieser Schritt wird zur Initialisierung des gepack
ten Datenmodus ausgeführt.
Wie im Schritt 808 dargestellt ist, wird jede der
Dirty-Anzeigen geändert, um den Clean-Zustand anzuzeigen,
und der Ablauf geht mit dem Schritt 810 weiter. Die Schritte
806 und 808 werden zur Initialisierung des gepackten Daten
modus ausgeführt.
Wie im Schritt 810 gezeigt ist, wird die spekulative
Anzeige derart geändert, daß sie anzeigt, daß der Gleit
komma/gepackte Daten-Übergang spekulativ ist. Obwohl im
Schritt 804 die in den Gleitkommaregistern gespeicherten
Daten in die gepackten Datenregister kopiert wurden, wurde
der Zustand der Gleitkommaeinheit nicht geändert. Daher ist
der Gleitkommazustand noch aktuell (z. B. die in den Mantis
senfeldern der Gleitkommaregistern gespeicherten Daten sind
äquivalent zu den in den den gepackten Datenregistern ge
speicherten Daten; die Tags wurden nicht geändert; und die
Stapelkopfendeanzeige wurde nicht geändert. Wenn ein ge
packter Datenbefehl nachfolgend ausgeführt wird, werden die
in den gepackten Datenregistern gespeicherten Daten geändert
und der Gleitkommazustand ist nicht länger aktuell. Folglich
erfordert ein Übergang vom Modus für gepackte Daten in den
Gleitkommamodus, daß der Gleitkommazustand aktualisiert wird
(z. B. müssen die in den gepackten Datenregistern ge
speicherten Daten in die Mantissenfelder der Gleitkomma
register kopiert werden; die Stapelkopfendeanzeige muß auf
Null geändert werden und die Tags müssen in den leeren
Zustand geändert werden). Wenn die Ausführung eines Gleit
kommabefehls jedoch vor der Ausführung von gepackten Daten
befehlen versucht wird (dies kann sich ergeben, wenn ein Er
eignis vor der Ausführung des gepackten Datenbefehls erzeugt
wird, welches den Übergang zwischen Gleitkommamodus und ge
packtem Datenmodus erzeugte - z. B. wenn ein Speicherfehler
während der versuchsweisen Ausführung des gepackten Daten
befehls auftrat -, muß der Gleitkommazustand nicht aktuali
siert werden, da er weiterhin aktuell ist. Durch die Ver
meidung dieser Aktualisierung wird der Systemaufwand für den
Übergang vom gepackten Datenmodus zurück in den Gleitkomma
modus signifikant verringert. Um diesen Vorteil zu nutzen,
wird die spekulative Anzeige in diesem Schritt so geändert,
daß sie anzeigt, daß der Übergang von der Gleitkommaeinheit
zu der gepackten Dateneinheit weiterhin spekulativ ist - der
Gleitkommazustand weiterhin aktuell ist. Wenn ein gepackter
Datenbefehl nachfolgend ausgeführt wird, wird die spekula
tive Anzeige derart geändert, daß sie anzeigt, daß der Über
gang nicht länger spekulativ ist, wie im Vorangegangenen un
ter Bezugnahme auf Schritt 744 der Fig. 7 beschrieben wur
de. Die Verwendung der spekulativen Anzeige wird weiter un
ter Bezugnahme auf Fig. 9 beschrieben. Während ein Ausfüh
rungsbeispiel beschrieben wurde, bei dem die spekulative An
zeige verwendet wird, können alternative Ausführungsbeispie
le die Implementierung einer derartigen spekulativen Anzeige
vermeiden.
Im Schritt 812 wird die Modusanzeige derart geändert,
daß sie anzeigt, daß der Prozessor nun in dem gepackten
Datenmodus ist. Nach dem Schritt 812 geht der Ablauf mit dem
Schritt 736 weiter.
Fig. 9 zeigt ein Ablaufdiagramm, welches ein Verfahren
zum Ausführen des Schrittes 728 der Fig. 7 gemäß einem Aus
führungsbeispiel der Erfindung veranschaulicht. Wie im Vor
angegangenen beschrieben wurde, wird der Prozessor im
Schritt 728 vom gepackten Datenmodus in den Gleitkommamodus
überführt. Nach dem Schritt 726 geht der Ablauf mit dem
Schritt 900 weiter.
Im Schritt 900 wird festgestellt, ob die spekulative
Anzeige anzeigt, daß der Übergang von dem gepackten Daten
modus weiterhin spekulativ ist. Wie im Vorangegangenen be
schrieben wurde, kann die spekulative Anzeige verwendet wer
den, um den Systemaufwand beim Übergang vom gepackten Daten
modus in den Gleitkommamodus zu verringern. Wenn im Schritt
900 festgestellt wird, daß der Übergang von Gleitkomma zu
gepackten Daten spekulativ ist, dann werden die Schritte 902
bis 912 vermieden, der Ablauf geht direkt mit dem Schritt
914 weiter, und der Systemaufwand für den Übergang wird
verringert. Ansonsten geht der Ablauf mit dem Schritt 902
weiter.
Wie im Schritt 902 gezeigt ist, wird festgestellt, ob
die EMMS-Anzeige anzeigt, daß der letzte gepackte Daten
befehl der EMMS-Befehl war. Falls dies der Fall ist, geht
der Ablauf mit dem Schritt 904 weiter. Ansonsten geht der
Ablauf mit dem Schritt 906 weiter. Wie im Vorangegangenen
beschrieben wurde, ist es durch die Tatsache, daß die ge
packten Datenbefehle auf einer separaten Einheit ausgeführt
werden (d. h. der gepackten Dateneinheit) effizienter,
Anzeigen zu speichern (z. B. die EMMS-Anzeige), welche an
zeigen, was bei der Rücküberführung in den Gleitkommamodus
getan werden muß, anstelle bestimmte Operationen auszuführen
(z. B. die Tags zu ändern). Folglich wird als Antwort auf den
EMMS-Befehl anstelle der Änderung der Tags die EMMS-Anzeige
geändert. Bei der Ausführung der Rücküberführung in den
Gleitkommamodus werden die Tags dann entsprechend geändert,
wie hier gezeigt ist.
Im Schritt 904 werden die Tags in den leeren Zustand
geändert und der Ablauf geht mit dem Schritt 908 weiter. Auf
diese Weise werden die Tags in ähnlicher Weise wie im
Schritt 432 der Fig. 4B geändert.
Im Schritt 906 werden die Tags in einen nicht-leeren
Zustand geändert und der Ablauf geht mit dem Schritt 908
weiter. Auf diese Weise werden die Tags in ähnlicher Weise
wie im Schritt 440 der Fig. 4B geändert.
Wie im Schritt 908 gezeigt ist, wird der Inhalt der
gepackten Datenregister in die Mantissenfelder der Gleit
kommaregister kopiert, und der Ablauf geht mit dem Schritt
910 weiter. Auf diese Weise können die in den gepackten Da
tenregistern gespeicherten Daten als Gleitkommadaten bear
beitet werden. Da existierende Betriebssysteme den Gleit
kommazustand beim Ausführen von Multitasking bereits spei
chern, wird der gepackte Datenzustand gespeichert und von
den verschiedenen Kontextstrukturen wiederhergestellt, als
ob es der Gleitkommazustand sei. Auf diese Weise sind die
physikalischen Register für gepackte Daten auf den physi
kalischen Gleitkommaregistern aliased, und der Prozessor
erscheint logisch, als ob er eine einzige logische Register
datei habe. Folglich ist das Ausführungsbeispiel für Soft
ware, einschließlich für das Betriebssystem, unsichtbar.
Sofern vollständiges Aliasing implementiert ist, werden die
in allen gepackten Datenregistern gespeicherten Daten in die
Mantissenfelder der zugehörigen Gleitkommaregister kopiert.
Wenn dagegen partielles Aliasing implementiert ist, kann ein
Ausführungsbeispiel derart implementiert sein, daß nur die
Daten in die Mantissenfelder der geeigneten, zugehörigen
Gleitkommaregister kopiert werden, die in denjenigen
gepackten Datenregistern gespeichert sind, welche berührt
wurden.
Wie im Schritt 910 dargestellt ist, wird das Stapel
kopfende auf einen Initialisierungswert geändert. Bei einem
Ausführungsbeispiel ist dieser Wert gleich Null. Bei einem
alternativen Ausführungsbeispiel setzt die Ausführung eines
gepackten Datenbefehls die Stapelkopfendeanzeige auf den
Initialisierungswert. Nach dem Schritt 910 geht der Ablauf
mit dem Schritt 912 weiter.
Wie im Schritt 912 dargestellt ist, werden 1sen in den
Vorzeichen- und Exponentenfeldern derjenigen Gleitkomma
register gespeichert, deren zugehörige Dirty-Anzeigen in dem
Dirty-Zustand sind. Auf diese Weise wird der Schritt 438 der
Fig. 4B ausgeführt. Nach dem Schritt 912 geht der Ablauf
mit dem Schritt 914 weiter.
Im Schritt 914 wird die Modusanzeige derart geändert,
daß sie anzeigt, daß der Prozessor im Gleitkommamodus ar
beitet, und der Ablauf geht mit dem Schritt 736 weiter. Auf
diese Weise wird der Übergang vom gepackten Datenmodus in
den Gleitkommamodus ausgeführt.
Fig. 10 zeigt ein Blockschaltbild, welches den Da
tenablauf in einer Einrichtung zum Aliasing des gepackten
Datenzustandes auf den Gleitkommazustand veranschaulicht,
wobei eine einzige physikalische Registerdatei gemäß einem
anderen Ausführungsbeispiel der Erfindung verwendet wird.
Die in Fig. 10 gezeigte Einrichtung könnte als Befehlssatz
einheit 560 der Fig. 5 verwendet werden. Bei einem Ausfüh
rungsbeispiel ist die Einrichtung in Fig. 10 wenigstens in
der Lage, den Befehlssatz 580 auszuführen. Fig. 10 zeigt
eine Dekodiereinheit 1002, eine Umbenennungseinheit 1004,
eine Befehlsabschlußeinheit 1006, eine Ausgabeeinheit 1008,
eine Ausführungseinheit 1010, einen Satz von Statusregistern
1012 und einen Mikrobefehlscode-ROM 1014.
Die Dekodiereinheit 1002 wird zum Dekodieren von von
dem Prozessor empfangenen Befehlen in Steuersignale und/oder
Mikrobefehlscode-Eintragspunkte verwendet. Diese Mikrobe
fehlscode-Eintragspunkte identifizieren Sequenzen von Mikro
befehlscodes (auch als "uops" bezeichnet), welche von der
Dekodiereinheit 1002 an die verschiedenen Einheiten in dem
Prozessor übertragen werden. Während bestimmte Mikrobe
fehlscodes in der Dekodiereinheit 1002 gespeichert sein
können, ist bei einem Ausführungsbeispiel die Mehrzahl der
Mikrobefehlscodes in dem Mikrobefehlscode-ROM 1014 ge
speichert. Bei diesem Ausführungsbeispiel überträgt die
Dekodiereinheit 1002 die Mikrobefehlscode-Eintragspunkte an
den Mikrobefehlscode-ROM 1014, und dieser antwortet, indem
er den (die) benötigten Mikrobefehlscode(s) zurücküberträgt.
Die meisten von der Dekodiereinheit 1002 empfangenen
Befehle enthalten einen oder mehere Operanden (entweder Da
ten, einen Registerort oder einen Speicherplatz im Spei
cher), an denen die Operation(en) der Befehle ausgeführt
werden sollen. Diejenigen Operanden, welche Register identi
fizieren, werden an die Umbenennungseinheit 1004 übertragen.
Die Umbenennungseinheit 1004 und die Befehlsabschluß
einheit 1006 werden zur Implementierung der Registerumbenen
nung verwendet. Die Technik der Registerumbenennung ist
wohlbekannt und wird ausgeführt, um Speicherkonflikte zu
vermeiden, welche daraus resultieren, daß verschiedene Be
fehle versuchen, eine begrenzte Anzahl von Speicherorten,
wie z. B. von Registern zu verwenden. Man spricht davon, daß
ein Speicherkonflikt aufgetreten ist, wenn sich derartige
Befehle gegenseitig stören, obwohl die im Konflikt stehenden
Befehle ansonsten unabhängig sind. Speicherkonflikte können
dadurch beseitigt werden, daß zusätzliche Register zur
Verfügung gestellt werden (welche hier als Pufferregister
bezeichnet werden), welche zur Wiederherstellung der
Korrespondenz zwischen Registern und Werten verwendet wer
den. Zur Implementierung der Registerumbenennung weist der
Prozessor üblicherweise jedem erzeugten neuen Wert ein ande
res Pufferregister zu: d. h. für jeden Befehl, welcher in ein
Register schreibt. Ein Befehl, welcher das Originalregister
kennzeichnet - um dessen Wert zu lesen - erhält stattdessen
den Wert in dem zugewiesenen Pufferregister. Somit benennt
die Hardware das die Befehle kennzeichnende Originalregister
derart um, daß es das Pufferregister und den richtigen Wert
identifiziert. Die gleichen Registerbezeichner bzw. -identi
fizierer können bei mehreren verschiedenen Befehlen auf un
terschiedliche Hardwareregister zugreifen, und zwar ab
hängig von den Orten der Registerreferenzen im Hinblick auf
Registerzuweisungen. Bezüglich einer weiteren Beschreibung
von Registerumbenennung vgl. Jonson, Mike Superscalar Micro
Processor Design, 1991 von PTR Prentice-Hall, Inc., New
Jersey; "Flag Renaming and Flag Mask Within Register Alias
Table", Aktenzeichen 08/204,521, von Colwell et al.,
"Integer and Floating Point Register Alias Table Within
Processor Device", Aktenzeichen 08/129,678 von Clift et al.;
und "Partial Width Stalls Within Register Alias Table",
Aktenzeichen 08/174,841 von Colwell et al. Wenn ein Befehl
die Ausführung erfolgreich beendet hat (ohne irgendwelche
Ereignisse zu verursachen, welche nicht anhängig bleiben),
werden die den Befehlen zugewiesenen Pufferregister
"retired" bzw. "abgeschlossen" - die Werte werden von den
Pufferregistern in die in dem Befehl identifizierten Ori
ginalregister übertragen. Alternative Ausführungsbeispiele
können eine beliebige Anzahl von Techniken implementieren,
um Speicherkonflikte zu beheben, z. B. Verriegelungen bzw.
Interlocks, partielle Umbenennung usw.
Die Befehlsabschlußeinheit 1006 enthält einen Satz von
Pufferregistern 1020, einen Satz von FP/PD-Registern 1022
und einen Satz von Ganzzahlregistern 1024. Der Satz von Puf
ferregistern 1020 liefert die zur Registerumbenennung ver
wendeten zusätzlichen Register. Während der Satz von Puf
ferregistern 1020 bei einem Ausführungsbeispiel vierzig Re
gister enthält, können alternative Ausführungsbeispiele eine
beliebige Anzahl von Registern implementieren. Bei diesem
Ausführungsbeispiel wird der Satz von Pufferregistern 1020
als ein Umordnungspuffer bearbeitet.
Bei einem Ausführungsbeispiel sind die FP/PD-Register
1022 und das Ganzzahlregister 1024 für Software sichtbar:
das heißt, daß es diese Register sind, welche in den Be
fehlen identifiziert werden, und folglich erscheint es der
Software, daß diese Register die einzigen Register zum Aus
führen von Gleitkommadaten, gepackten Daten und Ganzzahl
daten sind. Dagegen sind die Pufferregister 1020 für Soft
ware unsichtbar. Folglich stellen die FP/PD-Register 1022
eine einzige physikalische Registerdatei dar, welche der
Software als eine einzige logische Registerdatei erscheint.
Bei einem Ausführungsbeispiel enthält der Satz von FP/PD-
Registern 1022 und der Satz von Ganzzahlregistern 1024
jeweils acht Register, um mit existierender Intel-Architek
tur-Software kompatibel zu bleiben. Alternative Ausführungs
beispiele könnten jedoch jede beliebige Anzahl von Registern
implementieren.
Die Umbenennungseinheit 1004 enthält eine FP/PD-Ab
bildungseinheit 1030, eine FP/PD-Abbildungstabelle 1032,
einen Satz von Tags 1034, eine Ganzzahlabbildungseinheit
1040 und eine Ganzzahl-Abbildungstabelle 1042. Wenn ein
Operand von der Umbenennungseinheit 1004 empfangen wird,
wird festgestellt, ob der Operand ein Gleitkommaoperand, ein
gepackter Datenoperand oder ein Ganzzahloperand ist.
Ganzzahloperanden werden von der Ganzzahlabbildungs
einheit 1040 empfangen. Die Ganzzahlabbildungseinheit 1040
steuert die Ganzzahlabbildungstabelle 1042. Bei einem Aus
führungsbeispiel enthält die Ganzzahlabbildungstabelle 1042
genau so viele Einträge, wie es Register in den Ganzzahlre
gistern 1024 gibt. Jeder Eintrag in der Ganzzahlabbildungs
tabelle 1042 entspricht einem anderen Ganzzahlregister 1024;
in Fig. 10 entspricht der Eintrag 1050 dem Ganzzahlregister
1052. Wenn ein Befehl empfangen wird, der den Prozessor ver
anlaßt, in ein Ganzzahlregister zu schreiben (z. B. Ganzzahl
register 1052), weist die Ganzzahlabbildungseinheit 1040 ei
nes der Pufferregister 1020 zu, indem ein Zeiger in dem zu
dem Ganzzahlregister gehörigen Eintrag in der Ganzzahl
abbildungstabelle 1042 gespeichert wird (z. B. Eintrag 1050),
welcher ein verfügbares Register in dem Satz von Puffer
registern 1020 identifiziert (z. B. Pufferregister 1054). Die
Daten werden in das ausgewählte Pufferregister geschrieben
(z. B. Pufferregister 1054). Wenn die Ausführung des Befehls,
der den Operand erzeugte, ohne Interrupts beendet wurde
(ohne daß irgendwelche Ereignisse unternommen wurden),
schreibt die Befehlsabschlußeinheit 1006 die Daten fest
("commits" the data), indem sie sie aus dem ausgewählten
Pufferregister (z. B. Pufferregister 1054) in das geeignete
Ganzzahlregister (z. B. Ganzzahlregister 1052) kopiert und
veranlaßt die Ganzzahlabbildungseinheit 1040, den Inhalt des
Eintrags zu aktualisieren (z. B. Eintrag 1050), um anzuzei
gen, daß die Daten in dem zu dem Eintrag gehörigen Register
gespeichert sind.
Wird ein Befehl empfangen, welcher den Prozessor veran
laßt, ein Ganzzahlregister zu lesen, greift der Prozessor
unter Verwendung der FP/PD-Abbildungseinheit 1030 auf den
Inhalt des zu dem Ganzzahlregister gehörigen Eintrags in der
Ganzzahlabbildungstabelle 1042 zu (z. B. Eintrag 1050). Wenn
der Eintrag einen Zeiger auf ein Pufferregister enthält
(z. B. Pufferregister 1054), liest der Prozessor den Inhalt
dieses Pufferregisters. Wenn der Inhalt des Eintrags jedoch
anzeigt, daß die Daten in dem zu dem Eintrag gehörigen Ganz
zahlregister gespeichert sind (z. B. Ganzzahlregister 1052),
liest der Prozessor den Inhalt des zu dem Eintrag gehörigen
Ganzzahlregisters. Somit sind die Ganzzahlregister 1024 bei
diesem Ausführungsbeispiel der Erfindung als feste Register
datei implementiert.
Die FP/PD-Abbildungseinheit 1030 steuert die FP/PD-Ab
bildungstabelle 1032 und die Tags 1036. Wie im Vorangegan
genen beschrieben wurde, kann jedes dieser Tags mit Hilfe
einer beliebigen Anzahl von Bits implementiert werden. Ähn
lich wie die Ganzzahlabbildungseinheit 1040 enthält die
FP/PD-Abbildungstabelle 1032 genau so viele Einträge, wie es
Register in den FP/PD-Registern 1022 gibt. Jeder Eintrag in
der FP/PD-Abbildungstabelle 1032 entspricht einem anderen
FP/PD-Register 1022. Gleitkommaoperanden und gepackte Daten
operanden werden von der FP/PD-Abbildungseinheit 1030
empfangen, auf die Pufferregister 1020 abgebildet und in die
FP/PD-Register 1022 verabschiedet. Somit sind der Gleitkom
mazustand und der gepackte Datenzustand auf einer einzigen
für den Benutzer sichtbaren Registerdatei aliased. Da exi
stierende Betriebssysteme derart implementiert sind, daß sie
den Prozessor veranlassen, den Gleitkommazustand bei einem
Multitasking zu speichern, werden diese Betriebssysteme den
Prozessor zur Speicherung jedes gepackten Datenzustandes
veranlassen, welcher auf den Gleitkommaregistern aliased
ist.
Bei einem Ausführungsbeispiel werden die gepackten Da
tenoperanden in ähnlicher Weise wie die Ganzzahloperanden
behandelt - die gepackten Datenregister werden als feste
Registerdatei implementiert. Wenn ein gepackter Datenbefehl
empfangen wird, der den Prozessor veranlaßt, in ein FP/PD-
Register zu schreiben, weist die FP/PD-Abbildungseinheit
1030 dann ein Pufferregister 1020 zu, indem ein Zeiger in
dem zu dem FP/PD-Register gehörigen Eintrag in der FP/PD-
Abbildungstabelle 1032 gespeichert wird, welcher ein ver
fügbares Register in dem Satz von Pufferregistern 1020
identifiziert. Die Daten werden an das ausgewählte Puffer
register geschrieben. Wenn die Ausführung des Befehls, der
den Operand erzeugte, ohne Interrupts (ohne daß irgendwelche
Ereignisses unternommen wurden) abgeschlossen wurde,
schreibt die Befehlsabschlußeinheit 1006 die Daten dadurch
fest, daß sie diese von dem ausgewählten Pufferregister in
das entsprechende FP/PD-Register kopiert (das FP/PD-Regi
ster, welches dem Eintrag in der FP/PD-Abbildungstabelle
1032 entspricht) und veranlaßt die FP/PD-Abbildungseinheit
1030, den Eintrag in der FP/PD-Abbildungstabelle 1032 zu ak
tualisieren, um anzuzeigen, daß die Daten in dem zu dem Ein
trag gehörigen FP/PD-Register gespeichert sind.
Während die Register bei der Ausführung von gepackten
Datenbefehlen als feste Registerdatei implementiert sind,
implementiert ein Ausführungsbeispiel der Erfindung die Re
gister bei der Ausführung von Gleitkommabefehlen als eine
Registerdatei, auf die als Stapel Bezug genommen wird, und
zwar in einer mit existierender Intel-Architektur-Software
(einschließlich Betriebssysteme) kompatiblen Weise. Folglich
muß die FP/PD-Abbildungseinheit 1030 in der Lage sein, die
FP/PD-Abbildungstabelle 1032 sowohl als feste Registerdatei
für gepackte Datenoperanden als auch als einen Stapel für
Gleitkommaoperanden zu bearbeiten. Zu diesem Zweck enthält
die FP/PD-Abbildungseinheit 1030 ein Gleitkommastatusregi
ster 1070 mit einem Stapelkopfendefeld 1072. Das Stapelkopf
endefeld 1072 wird zum Speichern einer Stapelkopfendeanzeige
verwendet, welche einen Eintrag in der FP/PD-Abbil
dungstabelle 1032 identifiziert, welcher das Register dar
stellt, welches aktuell das oberste des Gleitkommastapels
ist. Selbstverständlich können alternative Ausführungsbei
spiele beim Ausführen von Gleitkommabefehlen die Register
als einfache Registerdatei betreiben.
Wenn ein Gleitkommabefehl empfangen wird, welcher den
Prozessor veranlaßt, in ein FP/PD-Register zu schreiben,
ändert die FP/PD-Abbildungseinheit 1030 die Stapelkopfende
anzeige und weist ein Pufferregister 1020 zu, indem in dem
zu dem Stapelkopfenderegister zugehörigen Eintrag in der
FP/PD-Abbildungstabelle 1032 ein Zeiger gespeichert wird,
welcher ein verfügbares Register in dem Satz von Pufferregi
stern 1020 identifiziert. Die Daten werden in das ausge
wählte Pufferregister geschrieben. Sobald die Ausführung
desjenigen Befehls ohne Interrupts (ohne, daß irgendwelche
Ereignisse unternommen wurden) abgeschlossen wurde, welcher
den Operanden erzeugt hat, "schreibt" die Befehlsabschluß
einheit 1006 die Daten "fest", indem sie diese von dem
ausgewählten Pufferregister in das entsprechende FP/PD-Regi
ster kopiert (das FP/PD-Register, welches dem Eintrag in der
FP/PD-Abbildungstabelle 1032 entspricht) und veranlaßt die
FP/PD-Abbildungseinheit 1030, den Eintrag in der FP/PD-Ab
bildungstabelle 1032 derart zu ändern, daß er anzeigt, daß
die Daten in dem zu dem Eintrag gehörigen FP/PD-Register ge
speichert sind.
Wird ein Gleitkommabefehl empfangen, welcher den Pro
zessor veranlaßt, ein FP/PD-Register zu lesen, greift der
Prozessor auf den Inhalt des zu dem Stapelkopfenderegister
gehörigen Eintrags in der FP/PD-Abbildungstabelle 1032 zu
und ändert den Stapel entsprechend. Wenn in diesem Eintrag
ein Zeiger auf ein Pufferregister gespeichert ist, liest der
Prozessor den Inhalt dieses Pufferregisters. Wenn der Inhalt
dieses Eintrags anzeigt, daß die Daten in dem zu dem Eintrag
gehörigen FP/PD der FP/PD-Register 1022 gespeichert sind,
liest der Prozessor den Inhalt dieses FP/PD-Registers.
Da die FP/PD-Abbildungseinheit 1030 Gleitkommaoperanden
auf eine Registerdatei abbildet, auf die als Stapel Bezug
genommen wird, muß auf die Einträge in der FP/PD-Abbildungs
tabelle 1032 unter Bezugnahme auf das Stapelkopfende
zugegriffen werden. Da die FP/PD-Abbildungseinheit 1030
gepackte Datenoperanden dagegen auf eine feste Registerdatei
abbildet, muß auf Einträge in der FP/PD-Abbildungstabelle
1032 unter Bezugnahme auf das Register R0 zugegriffen wer
den. Um den Prozessor dazu zu veranlassen, auf die Einträge
in der FP/PD-Abbildungstabelle unter Bezugnahme auf das Re
gister R0 zuzugreifen, muß die Stapelkopfendeanzeige derart
geändert werden, daß sie das Register R0 angibt. Daher muß
die Stapelkopfendeanzeige so geändert werden, daß sie das
Register R0 anzeigt, während der Prozessor gepackte Daten
befehle ausführt. Dies kann dadurch erreicht werden, daß die
Stapelkopfendeanzeige während Übergängen von dem Gleitkomma
modus in den gepackten Datenmodus derart geändert wird, daß
sie das Registers R0 anzeigt, und die Stapelkopfendeanzeige
während der Ausführung der gepackten Datenbefehle nicht ge
ändert wird. Auf diese Weise kann die gleiche Schaltung,
welche zum Abbilden des Gleitkommastapels verwendet wird,
zum Abbilden der festen Registerdatei für gepackte Daten
verwendet werden. Folglich wird die Schaltungskomplexität
verringert und gegenüber dem unter Bezugnahme auf Fig. 6A
beschriebenen Ausführungsbeispiel wird Platz auf dem Chip
gespart. Während ein Ausführungsbeispiel beschrieben wurde,
welches die gleiche Schaltung zum Abbilden sowohl der ge
packten Datenoperanden als auch der Gleitkommaoperanden ver
wendet, können alternative Ausführungsbeispiele separate
Schaltungen verwenden.
Bei einem einem Ausführungsbeispiel wird die Zuweisung
und die Freigabe der Pufferregister unabhängig von der Art
des ausgeführten Befehls in gleicher Weise behandelt. Die
Befehlsabschlußeinheit 1006 enthält ein Steuerregister 1060
mit einem Zuweisungsfeld 1062 und einem Befehlsabschlußfeld
1064. Das Zuweisungsfeld 1062 speichert einen Zuweisungszei
ger, welcher das als nächstes zu verwendete Pufferregister
identifiziert. Wenn entweder die FP/PD-Abbildungseinheit
1030 oder die Ganzzahlabbildungseinheit 1040 ein Register
benötigen, wird der aktuelle Zuweisungszeiger in der ent
sprechenden Abbildungstabelle gespeichert (d. h. der FP/PD-
Abbildungseinheit 1030 oder der Ganzzahlabbildungstabelle
1042) und der Zuweisungszeiger wird inkrementiert. Die Umbe
nennungseinheit 1004 überträgt zusätzlich an die Befehlsab
schlußeinheit 1006 Signale, welche anzeigen, ob der Befehl
ein gepackter Datenbefehl ist und ob der Prozessor in dem
gepackten Datenmodus ist.
In dem zugewiesenen Pufferregister speichert die Befehl
sabschlußeinheit 1006 eine Bereitanzeige bzw. Ready-Anzeige
in einem Bereitfeld 1082. Die Bereitanzeige wird zu Beginn
derart geändert, daß sie anzeigt, daß das Pufferregister
nicht bereit zum Verabschieden ist. Wenn jedoch Daten in ein
Datenfeld 1080 des Pufferregisters geschrieben werden, wird
die Bereitanzeige des Pufferregisters derart geändert, daß
sie anzeigt, daß das Pufferregister zur Verabschiedung be
reit ist.
Das Befehlsabschlußfeld 1064 des Steuerregisters 1060
speichert einen Befehlsabschlußzeiger, welcher das nächste
zu verabschiedende Pufferregister identifiziert. Wenn die
Bereitanzeige dieses Pufferregisters in den Bereitzustand
geändert wird, muß die Befehlsabschlußeinheit 1006 feststel
len, ob die Daten in dem Pufferregister festgeschrieben wer
den können. Wie später weiter beschrieben wird, schreibt die
Befehlsabschlußeinheit 1006 bei einem Ausführungsbeispiel
die Daten nicht fest, wenn irgendwelche Ausnahmen erzeugt
werden müssen (z. B. die "Einrichtung nicht verfügbar"-Aus
nahme, die "unerledigter Gleitkommafehler"-Ausnahme, die
"ungültiger Befehlscode"-Ausnahme usw.) oder wenn Übergänge
zwischen dem gepackten Datenmodus und dem Gleitkommamodus
benötigt werden. Wenn die Daten festgeschrieben werden kön
nen, werden die Daten in das entsprechende FP/PD- oder Ganz
zahlregister kopiert, und der Befehlsabschlußzeiger wird auf
das nächste Pufferregister inkrementiert. Während beschrie
ben wurde, daß die Befehlsabschluß- und Zuweisungszeiger in
einem Steuerregister gespeichert werden, kann ein alternati
ves Ausführungsbeispiel diese Zeiger sowie beliebige hier
beschriebene andere Informationen (z. B. die EMMS-Anzeige,
die Modusanzeige usw.) in einer Art sequentiellem Element,
beispielsweise einem Satz von Flipflops, speichern.
Während ein Ausführungsbeispiel beschrieben wurde, bei
dem die Befehlsabschlußeinheit 1006 drei separate Sätze von
Registern enthält und bei dem Daten von den Pufferregistern
in den FP/PD-Registern oder den Ganzzahlregistern festge
schrieben werden, kann ein alternatives Ausführungsbeispiel
derart implementiert sein, daß es eine beliebige Anzahl ver
schiedener Registersätze enthält. Beispielsweise kann ein
alternatives Ausführungsbeispiel einen einzigen Registersatz
enthalten. Bei diesem Ausführungsbeispiel würde jedes Regi
ster in diesem Registersatz eine Anzeige enthalten, welche
identifiziert, ob die darin gespeicherten Daten festge
schrieben wurden.
Bei einem Ausführungsbeispiel ist der Prozessor ent
weder in einem Gleitkommamodus oder in einem gepackten Da
tenmodus. Wenn der Prozessor nicht in dem gepackten Daten
modus ist, kann der Prozessor gepackte Datenbefehle nicht
ordentlich ausführen und umgekehrt. Folglich bestimmt die
Befehlsabschlußeinheit 1006 vor dem Festschreiben von in
einem Pufferregister gespeicherten Daten, ob die Daten ge
packte Daten sind und ob der Prozessor in dem gepackten Da
tenmodus ist. Wenn die Daten gepackte Daten sind und der
Prozessor nicht in dem gepackten Datenmodus ist, wird eine
in dem Mikrobefehlscode-ROM 1014 enthaltende Übergangsein
heit 1036 aufgerufen, um einen Übergang in den gepackten Da
tenmodus auszuführen. Bei einem Ausführungsbeispiel wird da
durch festgestellt, ob der Prozessor in dem gepackten Da
tenmodus ist, daß festgestellt wird, ob die Stapelkopfende
anzeige auf den Initialisierungswert geändert ist (z. B. um
auf das Register R0 zu zeigen) und ob alle Tags 1034 in
einem nicht-leeren Zustand sind.
Es gibt eine Anzahl von Techniken, um den Prozessor zu
veranlassen, die Stapelkopfendeanzeige und die Tags 1034 ab
zufragen, um zu bestimmen, ob der Prozessor in dem gepackten
Datenmodus ist. Wie im Vorangegangenen beschrieben wurde,
greift die Dekodiereinheit 1002 beispielsweise auf Mi
krobefehlscodes von dem Mikrobefehlscode-ROM 1014 zu. Diese
Mikrobefehlscodes enthalten ein kodiertes Feld, welches die
von der FP/PD-Abbildungseinheit 1030 auszuführende geeignete
Abbildung identifiziert (z. B. inkrementiere die Stapelkopf
endeanzeige, dekrementiere die Stapelkopfendeanzeige usw.).
Bei einem Ausführungsbeispiel ist wenigstens ein zusätz
liches kodiertes Bitmuster (hier als das "Bitmuster für ge
packte Daten" bezeichnet) enthalten, um das Abbilden für ge
packte Datenbefehle zu identifizieren. Wenn die Dekodier
einheit 1002 einen gepackten Datenbefehl empfängt und auf
den Mikrobefehlscode-ROM 1014 zugreift, enthält somit wenig
stens einer der an die Dekodiereinheit 1002 übertragenen Mi
krobefehlscodes das Bitmuster für gepackte Daten.
Bei Empfang eines Mikrobefehlscodes, welcher das Bit
66371 00070 552 001000280000000200012000285916626000040 0002019681660 00004 66252muster für gepackte Daten enthält, führt die FP/PD-Abbil
dungseinheit 1030 folgendes aus: 1) Sie bestimmt den Zustand
der Tags 1034 und die Stapelkopfendeanzeige; 2) überträgt an
die Befehlsabschlußeinheit 1006 (ein) Signal(e), welche(s)
anzeigt (anzeigen), ob ein Übergang in den gepackten Daten
modus benötigt wird (bei einem Ausführungsbeispiel wird der
Modus des Prozessors und die Befehlsart übertragen). Als
Antwort speichert die Befehlsabschlußeinheit 1006 in allen
von dem Befehl zugewiesenen Pufferregistern eine Übergangs
anzeige in ein Übergangsfeld 1084 (bei einem Ausführungsbei
spiel enthält die Übergangsanzeige ein erstes Bit, welches
den Modus des Prozessors anzeigt, und ein zweites Bit, wel
ches die Befehlsart anzeigt). Wenn der Befehl ein gepackter
Datenbefehl ist und der Prozessor nicht in dem gepackten Da
tenmodus ist, wird die Modusanzeige der entsprechenden Puf
ferregister somit so geändert, daß sie anzeigen, daß ein
Übergang benötigt wird. Ansonsten wird die Modusanzeige der
art geändert, daß sie anzeigt, daß kein Übergang benötigt
wird. Wenn die Bereitanzeige des von dem Befehlsab
schlußzeiger identifizierten Pufferregisters in den
Bereitzustand geändert wird, prüft die Befehlsabschlußein
heit 1006 die Übergangsanzeige. Wenn die Übergangsanzeige
anzeigt, daß kein Übergang benötigt wird, und wenn die Daten
ansonsten verabschiedet werden können (z. B. wenn es keine zu
bedienenden Ereignisses gibt), werden die Daten verabschie
det. Wenn die Übergangsanzeige dagegen anzeigt, daß ein
Übergang benötigt wird, überträgt die Befehlsabschlußeinheit
1006 den Mikrobefehlscode-Eintragspunkt für die Über
gangseinheit 1036 an den Mikrobefehlscode-ROM 1014. Als Ant
wort überträgt der Mikrobefehlscode-ROM 1014 die notwendigen
Mikrobefehlscodes, um den Prozessor in den gepackten Daten
modus zu überführen.
Auf diese Weise erfordert die Integration des Übergangs
zu dem gepackten Datenmodus nur eine geringfügige Erhöhung
der Komplexität. Selbstverständlich können alternative Aus
führungsbeispiele diese Funktionalität auf beliebig viele
Weisen implementieren, einschließlich: 1) man läßt die Deko
diereinheit 1002 bei Empfang eines gepackten Datenbefehls
spezielle Signale übertragen, welche die Umbenennungseinheit
1004 veranlassen, die Tags und die Stapelkopfendeanzeige ab
zufragen; 2) man fügt Bits zu allen Mikrobefehlscodes hinzu,
welche anzeigen, ob die Tags und das Stapelkopfende abge
fragt werden sollen; 3) man läßt die FP/PD-Abbildungseinheit
1030 die Tags und die Stapelkopfendeanzeige bei jeder Zu
weisung eines Pufferregisters abfragen 4) man sorgt dafür,
daß die Befehlsabschlußeinheit 1006 der FP/PD-Abbildungsein
heit 1030 anzeigt, wann ein gepacktes Datenelement zum Fest
schreiben bereit ist, und läßt die FP/PD-Abbildungseinheit
1030 die Übergangseinheit 1036 aufrufen, wenn der Prozessor
nicht in dem gepackten Datenmodus ist; usw. Während bei ei
nem Ausführungsbeispiel anhand der Stapelkopfendeanzeige und
der Tags 1034 festgestellt wird, ob der Prozessor in dem ge
packten Datenmodus ist, können alternative Ausführungs
beispiele beliebig viele Techniken verwenden, einschließlich
einer im Vorangegangenen beschriebenen Modusanzeige.
Wie im Vorangegangenen beschrieben wurde, wird die
Übergangseinheit 1036 verwendet, um den Prozessor von dem
Gleitkommamodus in den gepackten Datenmodus zu überführen.
Die Übergangseinheit 1036 veranlaßt den Prozessor, die Sta
pelkopfendeanzeige auf den Initialisierungswert zu ändern
und alle Tags 1034 in den nicht-leeren Zustand zu ändern.
Auf diese Weise wird die Umbenennungseinheit 1004 für die
Ausführung von gepackten Datenbefehlen initialisiert. Bei
Beendigung des Übergangs wird der Befehl, welcher den Über
gang vom Gleitkommamodus in den gepackten Datenmodus verur
sachte, mit Mikrobefehlen erneut gestartet. Folglich werden
keine Nicht-Mikrobefehlscode-Ereignisbehandler (zu denen Be
triebssystemereignisbehandler zählen) benötigt, und das Aus
führungsbeispiel ist für Betriebssysteme unsichtbar. Während
die Übergangseinheit 1036 als in dem Mikrobefehlscode-ROM
1014 angeordnet dargestellt ist, können alternative Ausfüh
rungsbeispiele die Übergangseinheit 1036 irgendwo auf dem
Prozessor anordnen. Bei einem anderen alternativen Ausfüh
rungsbeispiel kann die Übergangseinheit 1036 derart imple
mentiert sein, daß sie Übergänge von dem Gleitkommamodus in
den gepackten Datenmodus ausführt. Während dieses Übergangs
würde die Übergangseinheit 1036 die aktuelle Stapelkopfende
anzeige in einem Speicherbereich aufbewahren und die Stapel
kopfendeanzeige auf den Initialisierungswert ändern. Wird
die Übergangseinheit 1036 erneut aufgerufen, um wieder in
den Gleitkommamodus überzugehen, würde die Übergangseinheit
1036 die vorherige Stapelkopfendeanzeige wiederherstellen.
Bei alternativen Ausführungsbeispielen könnte die
Übergangseinheit 1036 hardwaremäßig oder als ein außerhalb
des Prozessors gespeicherter Nicht-Mikrobefehlscode-Ereig
nisbehandler implementiert werden.
Wie im Vorangegangenen unter Bezugnahme auf ein Aus
führungsbeispiel beschrieben wurde, dient jede Gruppierung
der gepackten Datenbefehle dazu, mit dem EMMS-Befehl aufzu
hören. Als Anwort auf die Ausführung des EMMS-Befehls veran
laßt die Ausführungseinheit 1010 die Umbenennungseinheit
1004, die Tags 1034 in den leeren Zustand zu ändern. Auf
diese Weise ist der Prozessor nach Ausführung des EMMS-
Befehls in dem Gleitkommamodus: das heißt, alle Tags 1034
sind in dem leeren Zustand und die Stapelkopfendeanzeige ist
in dem Initialisierungszustand (wie im Vorangegangenen be
schrieben wurde, wurde die Stapelkopfendeanzeige beim Über
gang in den gepackten Datenmodus auf den Initialisierungs
wert geändert und wurde während der Ausführung der gepackten
Datenbefehle nicht geändert). Folglich wird keine Übergangs
einheit zur Ausführung eines Übergangs von dem gepackten Da
tenmodus in den Gleitkommamodus benötigt. Dies ist anders
als bei der unter Bezugnahme auf Fig. 6A beschriebenen
Übergangseinheit, welche aufgerufen werden mußte, um dem
Prozessor zwischen dem Gleitkommamodus und dem gepackten Da
tenmodus hin und her zu bewegen. Da eine einzige aliased
Registerdatei für den Gleitkommazustand und den gepackten
Datenzustand verwendet wird, muß dieser Übergang außerdem
keine Daten zwischen zwei separaten Registerdateien kopie
ren. Folglich wird die Schaltungskomplexität verringert und
Chipfläche auf dem Prozessor eingespart.
Bei anderen alternativen Ausführungsbeispielen kann die
Änderung der Tags und der Stapelkopfendeanzeige vollständig
oder teilweise bei der Ausführung der gepackten Datenbefehle
ausgeführt werden. Beispielsweise kann das Erfordernis der
Übergangseinheit dadurch vermieden werden, daß: 1) die Aus
führung jedes gepackten Datenbefehls, welcher kein EMMS-Be
fehl ist, veranlaßt wird, die Stapelkopfendeanzeige auf den
Initialisierungswert zu ändern und die Tags in den nicht-
leeren Zustand zu ändern; und 2) daß die Ausführung des
EMMS-Befehls veranlaßt wird, die Tags in den leeren Zustand
zu ändern. Bei einem anderen alternativen Ausführungsbei
spiel ist der EMMS-Befehl nicht implementiert, sondern wird
unter Verwendung von Gleitkommabefehlen emuliert, wie später
unter Bezugnahme auf Fig. 14 beschrieben wird.
Die Ausgabeeinheit 1008 stellt einen Puffer zum Spei
chern von Befehlen und deren Operanden dar. Die Ausgabeein
heit 1008 kann als eine Reihe von Reservierungsstationen,
als zentrales Befehlsfenster oder als Hybrid von beiden im
plementiert werden. Bei Verwendung von Reservierungssta
tionen hat jede funktionelle Einheit (z. B. ALUs) ihren ei
genen Puffer zur Speicherung von Befehlen und Informationen,
welche deren zugehörige Operanden identifizieren. Wenn da
gegen ein zentrales Befehlsfenster verwendet wird, wird ein
für alle Funktionseinheiten gemeinsamer zentraler Puffer zur
Speicherung der Befehle und derjenigen Informationen ver
wendet, welche deren zugehörige Operanden identifizieren.
Die zu einem Befehl gehörigen Operanden können in mehreren
verschiedenen Formen davon abhängen, welche Informationen
verfügbar sind. Wenn die aktuellen Daten nicht verfügbar
sind, dann identifizieren die zu einem Befehl gehörigen
Operanden entweder Register in dem Satz von FP/PD-Registern
1022, dem Satz von Ganzzahlregistern 1024 oder dem Satz von
Pufferregistern 1020, und zwar in Abhängigkeit von der Da
tenart und davon, ob die Daten festgeschrieben wurden. Wenn
die aktuellen Daten verfügbar sind, werden diese Daten in
dem Puffer gespeichert. Bei einem Ausführungsbeispiel em
pfängt die Ausgabeeinheit 1008 außerdem Informationen von
der Umbenennungseinheit 1004. Diese Informationen sind für
das Verständnis der Erfindung jedoch nicht erforderlich. Die
Ausgabeeinheit 1008 gibt die Befehle an die Ausführungsein
heit 1010 aus, wenn die notwendigen Informationen erworben
werden.
Die Ausführungseinheit 1010 führt die Befehle aus. Die
Ausführungseinheit 1010 überträgt alle Operandeninforma
tionen, welche gespeichert werden müssen, an die Befehlsab
schlußeinheit 1006 zur Speicherung, wie im Vorangegangenen
oben beschrieben wurde. Da Befehle in der Ausgabeeinheit
1008 aufgrund des Fehlens von Operandeninformationen ver
zögert sein können, überträgt die Ausführungseinheit 1010
bei einem Ausführungsbeispiel außerdem alle Operandenin
formationen an die Ausgabeeinheit 1008. Auf diese Weise wird
jede weitere Verzögerung, welche durch das Übersenden der
Operandeninformationen an die Befehlsabschlußeinheit 1006
und danach an die Ausgabeeinheit 1008 verursacht würde, ver
mieden. Die Ausführungseinheit 1010 ist mit den Status
registern 1012 gekoppelt. Die Statusregister 1012 speichern
Steuerinformationen für die Verwendung durch die Ausfüh
rungseinheit 1010. Derartige Steuerinformationen können eine
EM-Anzeige und eine TS-Anzeige enthalten, wie sie hier im
Vorangegangenen beschrieben wurden. Die Ausführungseinheit
enthält eine Datenausrichtungseinheit 1090 (auch als eine
"Lade/Speichere-Konvertierungseinheit" bezeichnet) zum Aus
richten der verschiedenen Datenarten, auf die von der Be
fehlsabschlußeinheit 1006 zugegriffen werden. Die Arbeits
weise der Datenausrichtungseinheit wird unter Bezugnahme auf
die Fig. 12 und 13 weiter beschrieben.
Die Änderung der Tags 1034 kann mit Hilfe beliebig vie
ler verschiedener Mechanismen implementiert werden. Fig. 10
zeigt beispielsweise, daß die FP/PD-Abbildungseinheit 1030
außerdem eine Tagmodifiziereinheit 1092 zum Ändern der Tags
enthält. Die Tagmodifiziereinheit 1092 kann auf beliebig
viele Weisen implementiert werden, einschließlich der unter
Bezugnahme auf Fig. 6B beschriebenen Weisen.
Da die Gleitkommabefehle derart implementiert werden
können, daß nicht alle Tags gleichzeitig modifiziert werden
müssen, kann die Tagmodifiziereinheit 1092 bei einem Ausfüh
rungsbeispiel beispielsweise derart implementiert sein, daß
sie nicht alle Tags gleichzeitig modifizieren kann (ein der
artiges Ausführungsbeispiel wurde im Vorangegangenen unter
Bezugnahme auf Fig. 6B beschrieben). Um Schaltungskomplexi
tät zu vermeiden, kann die globale Änderung der Tags als
Antwort auf einen Übergang in den gepackten Datenzustand
oder als Antwort auf die Ausführung des EMMS-Befehls mit
Hilfe dieses existierenden Mechanismus implementiert werden.
Zu diesem Zweck kann ein Satz von Mikrobefehlscodesbefehlen,
welcher durch die EMMS-Einheit 1094 dargestellt ist, in dem
Mikrobefehlscode-ROM 1014 zur Implementierung des EMMS-Be
fehls gespeichert werden. Die Mikrobefehlscodebefehle in der
EMMS-Einheit 1094 und in der Übergangseinheit 1036 würden
die Dekodiereinheit 1002 veranlassen, verschiedene existie
rende Mikrobefehlscodes auszugeben, um jedes der acht Tags
zu ändern. Folglich würde die Dekodiereinheit 1002 als Ant
wort auf den Empfang des EMMS-Befehls auf die EMMS-Einheit
1094 zugreifen und die verschiedenen existierenden Mikrobe
fehlscodes ausgeben. Als Antwort auf jeden dieser Mikrobe
fehlscodes würde die Tagmodifiziereinheit 1092 die zuge
hörigen Tags in den leeren Zustand modifizieren. Dagegen
würde die Dekodiereinheit 1002 als Antwort auf den Zugriff
auf die Übergangseinheit 1036 die verschiedenen existie
renden Mikrobefehlscodes ausgeben, welche die Tagmodifizier
einheit 1092 veranlassen würden, alle Tags in den nicht-
leeren Zustand zu ändern. Bei einem derartigen Ausführungs
beispiel kann das globale Ändern der Tags ungefähr 4 bis 8
Taxtzyklen erfordern.
Während ein Ausführungsbeispiel zum Ändern aller Tags
als Antwort auf einen Übergang oder den EMMS-Befehl be
schrieben wurde, könne alternative Ausführungsbeispiele
beliebig viele Mechanismen verwenden. Beispielsweise kann
das Ändern aller Tags in den leeren oder nicht-leeren Zu
stand in einem einzigen Taktzyklus dadurch beendet werden,
daß ein neuer Mikrobefehlscode integriert wird und die Tag
modifiziereinheit 1092 derart implementiert wird, daß sie
alle Tags als Antwort auf den neuen Mikrobefehlscode global
ändern kann (ein derartiges Ausführungsbeispiel für die Tag
modifiziereinheit 1092 ist unter Bezugnahme auf Fig. 6B be
schrieben). Bei diesem Ausführungsbeispiel ist die EMMS-Ein
heit 1094 derart implementiert, daß sie die Dekodiereinheit
1002 veranlaßt, diesen einzelnen Mikrobefehlscode (anstelle
der verschiedenen separaten Mikrobefehlscodes) zur Änderung
aller Tags in den leeren Zustand auszugeben. Dagegen ist die
Übergangseinheit 1036 derart implementiert, daß sie die De
kodiereinheit 1002 veranlaßt, zur Änderung aller Tags in den
nicht-leeren Zustand diesen einzigen Mikrobefehlscode (an
stelle der verschiedenen separaten existierenden Mikrobe
fehlscodes) auszugeben. Als weiteres Beispiel kann ein al
ternatives Ausführungsbeispiel einen Bus enthalten, welche
die Ausführungseinheit 1010 mit den Tags 1034 und der Be
fehlsabschlußeinheit 1006 koppelt. Dieses alternative Aus
führungsbeispiel kann derart implementiert sein, daß der
Prozessor als Antwort auf den EMMS-Befehl serialisiert wird
(dies kann von der Umbenennungseinheit 1004 ausgeführt wer
den), die Signale zur Veranlassung der Tagänderung auf den
Bus gesendet werden (dies kann von der Ausführungseinheit
1010 ausgeführt werden) und der Prozessor erneut seriali
siert wird (dies kann von der Umbenennungseinheit 1004 aus
geführt werden). Ein derartiges Ausführungsbeispiele kann
ungefähr 10-20 Taktzyklen zur Änderung aller Tags benötigen.
Dagegen kann dieses alternative Ausführungsbeispiel derart
implementiert werden, daß die Vorab- und/oder Nachseriali
sierung von einer anderen Einheit ausgeführt wird oder nicht
erforderlich ist. Als weiteres Beispiel kann die Dekodier
einheit 1002 mit den Tags 1034 gekoppelt sein und zusätz
liche Hardware enthalten, um als Antwort auf den Empfang des
EMMS-Befehls alle Tags 1034 zu ändern.
Folglich verwendet das in Fig. 10 dargestellte Ausfüh
rungsbeispiel einen einzigen Registersatz zur Ausführung von
Gleitkommabefehlen und gepackten Datenbefehlen, anstelle ei
ner separaten Gleitkommaeinheit und einer separaten ge
packten Dateneinheit, wie im Vorangegangenen unter Bezug
nahme auf Fig. 6A beschrieben wurde. Außerdem benötigt das
Ausführungsbeispiel gemäß Fig. 6A eine separate Schaltung
für den Zugriff auf die Gleitkommaregister als Stapel und
auf die gepackten Datenregister als feste Registerdatei,
wogegen die FP/PD-Abbildungseinheit 1030 die gleiche Schal
tung verwendet. Anders als die unter Bezugnahme auf Fig. 6A
beschriebene Übergangseinheit, welche aufgerufen werden muß,
um den Prozessor zwischen dem Gleitkommamodus und dem ge
packten Datenmodus hin und zu her zu überführen, wird die
unter Bezugnahme auf Fig. 10 beschriebene Übergangseinheit
außerdem nur benötigt, um den Prozessor vom Gleitkommamodus
in den gepackten Datenmodus zu überführen. Da eine einzige
aliased Registerdatei für den Gleitkommazustand und den ge
packten Datenzustand verwendet wird, muß dieser Übergang
außerdem keine Daten zwischen zwei separaten Registerdateien
kopieren. Folglich benötigt das in Fig. 10 gezeigte Aus
führungsbeispiel eine geringere Schaltungskomplexität und
spart Chipplatz des Prozessors.
Während ein Ausführungsbeispiel beschrieben wurde, wel
ches Befehle zum Ausführen von Gleitkommaoperationen und ge
packten Datenoperationen enthält, kann ein alternatives Aus
führungsbeispiel, wie im Vorangegangenen beschrieben wurde,
verschiedene Sätze von Befehlen implementieren, welche einen
Prozessor veranlassen, Operationen an verschiedenen Da
tenarten auszuführen. Beispielsweise kann ein Befehlssatz
den Prozessor veranlassen, skalare Operationen (Gleitkomma
und/oder Ganzzahl) auszuführen und ein anderer Befehlssatz
kann den Prozessor veranlassen, gepackte Operationen (Gleit
komma und/oder Ganzzahl) auszuführen. Als weiteres Beispiel
kann ein Befehlssatz den Prozessor veranlassen, Gleitkomma
operationen auszuführen (skalare und/oder gepackte) und ein
anderer Befehlssatz kann den Prozessor veranlassen, Ganz
zahloperationen auszuführen (skalare und/oder gepackte). Als
weiteres Beispiel kann die einzelne aliased Registerdatei
als Registerdatei, auf die als Stapel Bezug genommen wird,
und als eine einfache Registerdatei bearbeitet werden.
Während ein Ausführungsbeispiel beschrieben wurde, bei dem
ein vollständiges Aliasing implementiert ist, können außer
dem alternative Ausführungsbeispiele mit einer einzigen phy
sikalischen Registerdatei derart implementiert werden, daß
sie als teilweise aliased operieren.
Dies würde irgendeinen Mechanismus erfordern (z. B. eine
Tabelle), um zu verfolgen, welche Daten in der einzelnen
aliased physikalischen Registerdatei gespeichert werden
sollten.
Die Fig. 11A, 11B und 11C zeigen ein Verfahren gemäß
einem anderen Ausführungsbeispiel der Erfindung, um gepackte
Datenbefehle und Gleitkommabefehle auf einer einzigen
aliased Registerdatei in einer Weise auszuführen, welche für
Betriebssysteme unsichtbar ist, gute Programmierpraktiken
unterstützt und unter Verwendung der Hardwareanordnung gemäß
Fig. 10 realisiert werden kann. Dieses Ablaufdiagramm
ähnelt den unter Bezugnahme auf die Fig. 4A-4B und die
Fig. 7A-C, 9 und 10 beschriebenen Ablaufdiagrammen. Unter
Bezugnahme auf diese vorangegangenen Ablaufdiagramme wurden
viele alternative Ausführungsbeispiele beschrieben, bei de
nen Schritte geändert, umgestellt und/oder weggelassen wur
den. Es sollte klar sein, daß unter Bezugnahme auf die
Fig. 11A-C beschriebene Schritte, welche den in den im Vor
angegangenen beschriebenen Ablaufdiagrammen ausgeführten
Schritten ähneln, unter Verwendung derartiger alternativer
Ausführungsbeispiele ausgeführt werden können. Die Ablauf
diagramme beginnen mit dem Schritt 1100. Vom Schritt 1100
geht der Ablauf zu dem Schritt 1102 weiter.
Wie im Schritt 1102 gezeigt ist, wird als Befehl auf
einen Bitsatz zugegriffen, und der Ablauf geht mit dem
Schritt 1104 weiter. Dieser Bitsatz enthält einen Befehls
code, welcher die von dem Befehl auszuführende(n) Opera
tion(en) identifiziert. Folglich ähnelt der Schritt 1102 dem
Schritt 402 der Fig. 4A.
Bei einem Ausführungsbeispiel werden die folgenden
Schritte in der Dekodierungsstufe der Pipeline ausgeführt.
Im Schritt 1104 wird festgestellt, ob der Befehlscode
gültig ist. Wenn der Befehlscode nicht gültig ist, geht der
Ablauf mit dem Schritt 1106 weiter. Ansonsten geht der Ab
lauf mit dem Schritt 1108 weiter. Der Schritt 1104 ähnelt
dem Schritt 404 in Fig. 4.
Im Schritt 1106 werden ein oder mehrere Ereignissignal-
Mikrobefehlscodes eingefügt, welche anzeigen, daß die "un
gültiger Befehlscode"-Ausnahme erzeugt werden soll. Ereig
nissignal-Mikrobefehlscodes werden verwendet, um bis zu der
(den) Befehlsabschlußstufe(n) der Pipeline die Bedienung von
Fehlern zu vermeiden. Wenn ein Befehl ein Ereignissignal-
Mikrobefehlscode ist, läuft er durch die Dekodierstufe(n),
die Registerumbennnungsstufe(n) und die Ausführungsstufe(n).
Wenn der Ereignissignal-Mikrobefehlscode in der (den) Be
fehlsabschlußstufe(n) empfangen wird, wird der Zustand der
Pufferregister jedoch nicht festgeschrieben und das entspre
chende Ereignis wird erzeugt. Ereignissignal-Mikrobe
fehlscodes werden vor oder anstelle des Befehls eingefügt,
welcher das Ereignis veranlaßt. Die Verwendung von Mikrobe
fehlscodes wird weiter unter Bezugnahme auf "Method and
Apparatus for Signaling an Occurrence of an Event in a
Processor", Aktenzeichen 08/203,790, von Darrel D. Boggs et
al. beschrieben. Vom Schritt 1106 geht der Ablauf mit dem
Schritt 1108 weiter.
Im Schritt 1108 wird festgestellt, welche Befehlsart
empfangen wurde. Wenn der Befehl weder ein Gleitkommabefehl
noch ein gepackter Datenbefehl ist, geht der Ablauf mit dem
Schritt 1110 weiter. Wenn ein oder mehrere Ereignissignal-
Mikrobefehlscodes im Schritt 1106 eingefügt wurden, geht der
Ablauf folglich mit dem Schritt 1110 weiter. Wenn der Befehl
ein Gleitkommabefehl ist, geht der Ablauf dagegen mit dem
Schritt 1112 weiter. Wenn der Befehl ein gepackter Daten
befehl ist, geht der Ablauf dagegen mit dem Schritt 1114
weiter. Folglich ähnelt der Schritt 1108 dem Schritt 408 der
Fig. 4A.
Wie im Schritt 1110 dargestellt ist, führt der Prozes
sor den Befehl aus. Wenn im Schritt 1106 ein oder mehrere
Mikrobefehlscodes eingefügt wurden, welche anzeigen, daß die
"ungültiger Befehlscode"-Ausnahme erzeugt werden sollte,
laufen die Mikrobefehlscodes durch die Dekodierstufe(n), die
Registerumbenennungsstufe(n) und die Ausführungsstufe(n).
Wenn jedoch der (die) Ereignissignal-Mikrobefehlscode(s) die
Befehlsabschlußstufe(n) erreichen, wird der Zustand der Puf
ferregister nicht festgeschrieben und die "ungültiger Be
fehlscode"-Ausnahme wird erzeugt. Wie im Vorangegangenen
unter Bezugnahme auf Schritt 215 in der Fig. 2 beschrieben
wurde, kann dieser Ereignisbehandler derart implementiert
werden, daß er den Prozessor veranlaßt, eine Nachricht anzu
zeigen, die Ausführung der aktuellen Task abzubrechen und
andere Tasks weiter auszuführen. Natürlich können alterna
tive Ausführungsbeispiele diesen Behandler auf beliebig vie
le Weisen implementieren, welche im Vorangegangenen be
schrieben wurden. Da die Ausführung anderer Befehle für das
Verständnis der Erfindung nicht erforderlich ist, wird sie
hier nicht weiter beschrieben.
Im Schritt 1112 wird festgestellt, ob die EM-Anzeige
gleich 1 ist (gemäß der beschriebenen Software-Konvention
gilt dies, wenn die Gleitkommaeinheit emuliert werden soll)
und ob die TS-Anzeige gleich 1 ist (gemäß der beschriebenen
Software-Konvention gilt dies, wenn eine partielle Kontext
umschaltung durchgeführt wurde). Wenn die EM-Anzeige
und/oder die TS-Anzeige gleich 1 ist, geht der Ablauf mit
dem Schreitt 1116 weiter. Ansonsten geht der Ablauf mit dem
Schritt 1120 weiter. Folglich ähnelt der Schritt 1112 dem
Schritt 412 der Fig. 4A.
Im Schritt 1116 werden ein oder mehrere Ereignissignal-
Mikrobefehlscodes eingefügt, um anzuzeigen, daß die "Ein
richtung nicht verfügbar"-Ausnahme erzeugt werden sollte.
Vom Schritt 1116 geht der Ablauf mit dem Schritt 1120
weiter.
Wie in den beiden Schritten 1114 und 1120 gezeigt ist,
wird die Registerumbenennung durchgeführt. Vom Schritt 1120
geht der Ablauf mit dem Schritt 1122 weiter. Dagegen geht
der Ablauf vom Schritt 1114 mit dem Schritt 1134 weiter. Bei
einem Ausführungsbeispiel werden die Schritte 1114 und 1120
in der (den) Umbenennungsstuffe(n) der Pipeline ausgeführt.
Bei einem Ausführungsbeispiel werden die folgenden
Schritte in der (den) Ausführungsstufe(n) der Pipeline aus
geführt.
Wie im Schritt 1122 dargestellt ist, wird der Gleit
kommabefehl ausgeführt. Der Schritt 1122 ähnelt dem Schritt
426 der Fig. 4B. Um für das Betriebssystem unsichtbar zu
bleiben, ändert ein Ausführungsbeispiel auch die Tags sofern
erforderlich, berichtet alle numerischen Fehler, welche nun
bearbeitet werden können und läßt alle anderen numerischen
Fehler anstehen. Wie im Vorangegangenen beschrieben wurde,
erlaubt es die Änderung der Tags diesem Ausführungsbeispiel,
für Betriebssysteme unsichtbar zu bleiben, und zwar für der
artige Betriebssystemtechniken, welche den Inhalt nur der
jenigen Gleitkommaregister speichern, deren zugehöriges Tag
einen nicht-leeren Zustand anzeigt. Es können jedoch alter
native Ausführungsbeispiele derart implementiert werden, daß
sie mit bestimmten Betriebssystemtechniken kompatibel sind.
Wenn ein existierendes Betriebssystem beispielsweise keine
Tags verwendet, wäre ein Prozessor, der die Tags nicht im
plementiert, weiterhin mit diesem Betriebssystem kompatibel.
Außerdem ist es für die Erfindung nicht nötig, daß nume
rische Gleitkommaausnahmen anhängig bleiben, und folglich
liegen alternative Ausführungsbeispiele, welche derart nicht
verfahren, noch im Schutzbereich der Erfindung. Vom Schritt
1122 geht der Ablauf mit dem Schritt 1124 weiter.
Im Schritt 1134 wird festgestellt, ob der gepackte Da
tenbefehl der EMMS-Befehl ist. Folglich ähnelt der Schritt
1134 dem Schritt 430 von Fig. 4B. Wenn der gepackte Daten
befehl der EMMS-Befehl ist, geht der Ablauf mit dem Schritt
1136 weiter. Ansonsten geht der Ablauf mit dem Schritt 1138
weiter. Wie im Vorangegangenen beschrieben wurde, wird der
EMMS-Befehl verwendet, um die Gleitkommatags in einen Ini
tialisierungszustand zu ändern und sollte nach der Ausfüh
rung eines gepackten Datenbefehls und/oder vor der Ausfüh
rung eines Gleitkommabefehls ausgeführt werden, um den Pro
zessor in den Gleitkommamodus zu überführen.
Wie im Schritt 1136 gezeigt ist, werden alle Tags in
den leeren Zustand geändert. Auf diese Weise wurden die Tags
initialisiert und sind für die Ausführung von Gleitkomma
befehlen bereit. Bei Beendigung des Schritts 1136 geht der
Ablauf mit dem Schritt 1144 weiter. Bei einem Ausführungs
beispiel, bei dem der EMMS-Befehl nicht implementiert ist,
würden die Schritte 1134 und 1136 fehlen, und der Ablauf
würde vom Schritt 1114 zu dem Schritt 1138 weitergehen.
Wie im Schritt 1138 dargestellt ist, wird der gepackte
Datenbefehl ausgeführt. Während dieses Schritts werden 1sen
in den Vorzeichen- und Exponentenfeldern aller FP-Register
oder aller als FP/PD-Register dienenden Pufferregister ge
speichert, in die gepackte Daten geschrieben werden. Folg
lich ähnelt der Schritt 1138 den Schritten 434, 436 und 438
von Fig. 4B. Diese Verfahrensweise unterstützt dadurch gute
Programmiertechniken, daß die Trennung von Gleitkommabe
fehlen und gepackten Datenbefehlen gefördert wird. Jedoch
können alternative Auführungsbeispiele die Implementierung
dieses Merkmals weglassen, wie im Vorangegangenen beschrie
ben wurde. Während bei einem Ausführungsbeispiel 1sen in die
Vorzeichen- und Exponentenfelder geschrieben werden, können
alternative Ausführungsbeispiele einen beliebigen NAN (keine
Zahl) oder unendlich darstellenden Wert verwenden. Außerdem
wird dieser Schritt ohne Erzeugung von numerischen Ausnahmen
ausgeführt. Werden Speichereignisse als Folge der versuchs
weisen Ausführung des gepackten Datenbefehls erzeugt, wird
die Ausführung unterbrochen und das Ereignis wird bearbei
tet. Vom Schritt 1138 geht der Ablauf mit dem Schritt 1144
weiter.
Bei einem Ausführungsbeispiel werden die folgenden
Schritte in der (den) Befehlsabschlußstufe(n) ausgeführt.
Im Schritt 1124 wird festgestellt, ob der Befehl ein
Ereignissignal-Mikrobefehlscode ist, welcher die "Einrich
tung nicht verfügbar"-Ausnahme anzeigt. Falls dies der Fall
ist, wurde im Schritt 1112 festgestellt, daß entweder die
TS- oder die EM-Anzeige oder beide gleich 1 sind. Wenn der
Befehl ein Ereignissignal-Mikrobefehlscode ist, welcher die
"Einrichtung nicht verfügbar"-Ausnahme anzeigt, geht der Ab
lauf mit dem Schritt 1126 weiter. Ansonsten geht der Ablauf
somit mit dem Schritt 1128 weiter. Auf diese Weise kann die
"Einrichtung nicht verfügbar"-Ausnahme in einen Prozessor
integriert werden, welcher eine Registerumbenennung verwen
det.
Im Schritt 1126 wird die "Einrichtung nicht verfügbar"-
Ausnahme erzeugt und der zugehörige Ereignisbehandler wird
ausgeführt. Folglich ähnelt der Schritt 1126 dem Schritt 416
der Fig. 4A. Wie im Vorangegangenen beschrieben wurde, kann
dieser Ereignisbehandler derart implementiert werden, daß er
die EM- und TS-Anzeige verwendet, um festzustellen, ob der
Gleitkommabefehl emuliert werden soll und/oder ob eine par
tielle Kontextumschaltung durchgeführt wurde. Wie im Voran
gegangenen beschrieben wurde, ist die Verwendung der EM- und
TS-Anzeigen eine Software-Konvention und kann daher für an
dere Zwecke verwendet werden.
Wie im Schritt 1144 gezeigt ist, wird festgestellt, ob
die EM-Anzeige gleich eins ist. Folglich ähnelt der Schritt
1144 dem Schritt 414 der Fig. 4A. Wenn im Schritt 1144
festgestellt wird, daß die EM-Anzeige gleich eins ist, geht
der Ablauf mit dem Schritt 1146 anstelle mit dem Schritt
1126 weiter. Ansonsten geht der Ablauf mit dem Schritt 1148
weiter.
Im Schritt 1146 wird die "ungültiger Befehlscode"-Aus
nahme erzeugt und der geeignete Ereignisbehandler wird aus
geführt. Es handelt sich hierbei um die gleiche "ungültiger
Befehlscode"-Ausnahme, welche unter Bezugnahme auf Schritt
1110 der Fig. 11A beschrieben wurde. Die Erzeugung der "un
gültiger Befehlscode"-Ausnahme ähnelt der im Schritt 406 der
Fig. 4A erzeugten "ungültiger Befehlscode"-Ausnahme. Wie im
Vorangegangenen unter Bezugnahme auf Schritt 215 in Fig. 2
beschrieben wurde, kann dieser Ereignisbehandler derart im
plementiert werden, daß er den Prozessor veranlaßt, eine
Nachricht anzuzeigen, die Ausführung der aktuellen Task
abzubrechen und andere Tasks weiter auszuführen. Selbst
verständlich können alternative Ausführungsbeispiele diesen
Behandler auf beliebig viele Weisen implementieren, die im
Vorangegangenen beschrieben wurden. Indem die versuchsweise
Ausführung des gepackten Datenbefehls, während EM gleich 1
ist, in die "ungültiger Befehlscode"-Ausnahme umgeleitet
wird, bleibt dieses Ausführungsbeispiel für Betriebssysteme
unsichtbar.
Während ein Ausführungsbeispiel zum Behandeln der EM-
Anzeige in einer für Betriebssysteme unsichtbaren Weise be
schrieben wurde, können alternative Ausführungsbeispiele an
dere Techniken verwenden. Beispielsweise kann ein alterna
tives Ausführungsbeispiel entweder die "Einrichtrung nicht
verfügbar"-Ausnahme, ein anderes existierendes Ereignis oder
ein neues Ereignis als Antwort auf die versuchsweie Aus
führung eines gepackten Datenbefehls erzeugen, während die
EM-Anzeige gleich 1 ist. Als weiteres Ausführungsbeispiel
kann ein alternatives Ausführungsbeispiel die EM-Anzeige
beim Ausführen von gepackten Datenbefehlen ignorieren.
Wie im Schritt 1148 dargestellt ist, wird festgestellt,
ob die TS-Anzeige gleich eins ist (gemäß der beschriebenen
Software-Konvention gilt dies, wenn eine partielle Kontext
umschaltung durchgeführt wurde). Wenn eine partielle Kon
textumschaltung durchgeführt wurde, geht der Ablauf mit dem
Schritt 1126 weiter. Ansonsten geht der Ablauf mit dem
Schritt 1150 weiter.
Wie im Vorangegangenen beschrieben wurde, wird im
Schritt 1126 die "Einrichtung nicht verfügbar"-Ausnahme
erzeugt und der zugehörige Ereignisbehandler wird aus
geführt. Folglich kann der Ereignisbehandler derart im
plementiert werden, daß er als Antwort auf dieses Ereignis
die EM- und TS-Anzeigen abruft. Wenn jedoch gepackte Da
tenbefehle ausgeführt werden, geht der Ablauf mit dem
Schritt 1144 weiter, und Situationen, in denen die EM-An
zeige gleich eins ist, werden in die "ungültiger Befehls
code"-Ausnahme umgeleitet. Folglich muß die EM-Anzeige
gleich 0 und die TS-Anzeige gleich 1 sein, wenn gepackte
Datenbefehle ausgeführt werden und der Schritt 1126 erreicht
ist. Da die TS-Anzeige gleich 1 ist, funktioniert der Ereig
nisbehandler, wie im Vorangegangenen unter Bezugnahme auf
partielle Kontextumschaltungen beschrieben wurde, und veran
laßt den Prozessor, die Ausführung durch Neustart des im
Schritt 1102 empfangenen Befehls wieder aufzunehmen. Da der
gepackte Datenzustand auf dem Gleitkommazustand aliased ist,
arbeitet dieser Ereignisbehandler sowohl für den Gleitkomma
zustand als auch für den gepackten Datenzustand. Folglich
bleibt dieses Verfahren für Betriebssysteme unsichtbar. Na
türlich können andere Ausführungsbeispiel diesen Ereignis
behandler auf beliebig viele Weisen implementieren, wie im
Vorangegangenen beschrieben wurde. Während ein Ausführungs
beispiel beschrieben wurde, um die TS-Anzeige in einer für
Betriebssysteme unsichtbaren Weise zu behandeln, können al
ternative Ausführungsbeispiele andere Techniken verwenden,
wie im Vorangegangenen beschrieben wurde.
Wenn bestimmte numerische Fehler während der Ausführung
eines Gleitkommabefehls erzeugt werden, werden diese Fehler
bis zu der versuchsweisen Ausführung des nächsten Gleitkom
mabefehls anhängig gehalten, dessen Ausführung zu deren Be
arbeitung unterbrochen werden kann, wie im Vorangegangenen
beschrieben wurde. Wie sowohl in den Schritten 1128 als auch
1150 dargestellt ist, wird festgestellt, ob es irgendwelche
derartigen anhängigen Fehler gibt, die bearbeitet werden
können. Folglich ähneln diese Schritte den Schritten 420 und
422 der Fig. 4A. Wenn es irgendwelche derartigen anhängigen
Fehler gibt, geht der Ablauf von den Schritten 1128 und 1150
zu dem Schritt 1130 weiter. Wenn jedoch im Schritt 1128
festgestellt wird, daß es keine derartigen anhängigen Fehler
gibt, geht der Ablauf mit dem Schritt 1132 weiter. Wenn
dagegen im Schritt 1150 festgestellt wird, daß es keine
anhängigen Fehler gibt, geht der Ablauf mit dem Schritt 1152
weiter. Bei einem alternativen Ausführungsbeispiel wird der
Schritt 1150 nicht ausgeführt und der Gleitkommafehler
bleibt während der Ausführung des gepackten Datenbefehls
anhängig.
Im Schritt 1130 wird ein "unerledigter Gleitkommafeh
ler"-Ereignis erzeugt. Folglich ähnelt der Schritt 1130 dem
Schritt 424 der Fig. 4A. Wie im Vorangegangenen unter Be
zugnahme auf den Schritt 424 der Fig. 2 beschrieben wurde,
kann dieses Ereignis entweder als internes Ereignis oder als
externes Ereignis behandelt werden und entsprechend bedient
werden.
Wie im Schritt 1152 dargestellt ist, wird festgestellt,
ob der Prozessor in dem gepackten Datenmodus ist. Wenn der
Prozessor in dem gepackten Datenmodus ist, wurde die Aus
führung des gepackten Datenbefehls erfolgreich beendet und
der Ablauf geht mit dem Schritt 1132 weiter. Wenn der Pro
zessor jedoch nicht in dem gepackten Datenmodus ist, wurde
der gepackte Datenbefehl in dem Gleitkommamodus ausgeführt.
Folglich ist die Ausführung des gepackten Datenbefehls nicht
genau. Um dies zu beheben, muß der Prozessor von dem Gleit
kommamodus in den gepackten Datenmodus umgeschaltet werden
und der gepackte Datenbefehl muß erneut ausgeführt werden.
Zu diesem Zweck geht der Ablauf mit dem Schritt 1154 weiter,
wenn der Prozessor nicht in dem gepackten Datenmodus ist.
Die Feststellung im Schritt 1152 kann auf beliebig viele
Weisen erfolgen. Beispielsweise kann eine Modusanzeige ver
wendet werden, wie im Vorangegangenen unter Bezugnahme auf
Fig. 6A beschrieben wurde. Als weiteres Beispiel könnten
die Stapelkopfendeanzeige und die Tags abgerufen werden.
Wenn die Stapelkopfendeanzeige in dem Initialisierungszu
stand ist und alle Tags in dem nicht-leeren Zustand sind,
dann ist der Prozessor in dem gepackten Datenmodus. Wenn die
Stapelkopfendeanzeige dagegen nicht in dem Initialisierungs
zustand ist oder alle Tags nicht in dem nicht-leeren Zustand
sind, ist der Prozessor nicht in dem Modus für gepackte
Daten.
Im Schritt 1154 wird der Prozessor von dem Gleitkomma
modus in den gepackten Datenmodus überführt und der Ablauf
geht mit dem Schritt 1156 weiter. Im Schritt 1154 wird der
Prozessor von dem Gleitkommamodus in den gepackten Daten
modus dadurch überführt, daß alle Tags in den nicht-leeren
Zustand geändert werden und die Stapelkopfendeanzeige auf
den Initialisierungswert geändert wird. Das Ändern aller
Tags in den nicht-leeren Zustand unterstützt gute Program
miertechniken, da es die separate Gruppierung der Gleitkom
mabefehle und der gepackten Datenbefehle fördert. Unter dem
Aspekt der Betriebssystemkompatibilität sei außerdem ange
merkt, daß bestimmte Betriebssystemtechniken den Inhalt nur
derjenigen Gleitkommaregister speichern, deren zugehörige
Tags einen nicht-leeren Zustand anzeigen. Folglich verur
sacht bei einem Ausführungsbeispiel, bei dem der gepackte
Datenzustand auf dem Gleitkommazustand aliased ist, das Än
dern aller Tags in den nicht-leeren Zustand, daß derartige
Betriebssysteme den gepackten Datenzustand erhalten, als ob
es der Gleitkommazustand sei. Alternative Ausführungsbei
spiele können derart implementiert werden, daß sie mit weni
ger von diesen Betriebssystemtechniken kompatibel sind. Wenn
ein Betriebssystem beispielsweise keine Tags verwendet, ist
ein Ausführungsbeispiel, welches keine Tags verwendet, wei
terhin mit diesem Betriebssystem kompatibel. Die Änderung
der Stapelkopfendeanzeige auf Null wird verwendet, um effi
ziente Programmiertechniken auszuführen, wie im Vorangegan
genen beschrieben wurde. Dadurch, daß die Stapelkopfende
anzeige auf den Initialisierungswert geändert wird und die
Stapelkopfendeanzeige nicht während der Ausführung der
gepackten Datenbefehle geändert wird, kann die gleiche
Schaltung zur Bearbeitung der FP/PD-Register als Gleitkomma
stapelregisterdatei und als feste Registerdatei verwendet
werden, wie im Vorangegangenen unter Bezugnahme auf Fig. 10
beschrieben wurde. Da der Gleitkommazustand und der gepackte
Datenzustand auf einer einzigen Registerdatei aliased sind,
erfordert der Übergang nicht, daß Daten zwischen einer
separaten Gleitkommaregisterdatei und einer separaten
Registerdatei für gepackte Daten kopiert werden müssen. Dies
verringert die für den Übergang zwischen dem Gleitkommamodus
und dem gepackten Datenmodus benötigte Zeit. Wie im
Vorangegangenen beschrieben wurde, kann der Übergang vom
Gleitkommamodus zum gepackten Datenmodus im Mikrobefehlscode
implementiert werden. Bei einem alternativen
Ausführungsbeispiel ändert die Ausführung jedes gepackten
Datenbefehls die Stapelkopfendeanzeige auf den Initialisie
rungswert.
Wie im Schritt 1156 dargestellt ist, wird der im
Schritt 1102 empfangene Befehl durch Ausführung eines Mikro
befehls-Neustarts erneut gestartet. Da ein Mikrobefehls-Neu
start verwendet wird, kann die Ausführung der aktuellen Task
wieder aufgenommen werden, ohne daß eine Aktion außerhalb
des Prozessors unternommen werden muß - es muß kein Nicht-
Mikrobefehlscode-Ereignisbehandler ausgeführt werden. Auf
diese Weise ist dieses Ausführungsbeispiel mit existierenden
Betriebssystemen kompatibel. Alternative Ausführungs
beispiele können derart implementiert werden, daß sie weni
ger kompatibel sind. Beispielsweise könnte ein zusätzliches
Ereignis in den Prozessor integriert werden und ein zusätz
licher Ereignisbehandler könnte zu dem Betriebssystem zur
Ausführung dieses Übergangs hinzugefügt werden.
Im Schritt 1132 wird der Zustand der Pufferregister in
deren zugehörigen FP/PD- oder Ganzzahlregistern festge
schrieben. Bei Beendigung des Schrittes 1132 ist der Prozes
sor frei, die Ausführung fortzusetzen.
Folglich wurde ein Verfahren zur Ausführung gepackter
Datenbefehle beschrieben, welches mit existierenden Be
triebssystemen kompatibel ist und gute Programmiertechniken
unterstützt. Da der gepackte Datenzustand auf dem Gleit
kommazustand aliased ist, wird der gepackte Datenzustand von
den existierenden Betriebssystemen erhalten und wieder
hergestellt, als ob es der Gleitkommazustand sei. Da ferner
von der Ausführung der gepackten Datenbefehle erzeugte Er
eignisses von existierenden Betriebssystembehandlern bear
beitet werden können, müssen diese Ereignisbehandler nicht
geändert werden, und es müssen keine neuen Behandler hinzu
gefügt werden. Folglich ist der Prozessor mit älteren Pro
grammen kompatibel, und die Erweiterung erfordert nicht den
Kosten- und Zeitaufwand, um ein Betriebssystem zu entwickeln
oder zu ändern.
Varianten dieses Ausführungsbeispiels, von denen einige
beschrieben wurden, können vollständig oder teilweise mit
derartigen Betriebssystemen kompatibel sein und/oder gute
Programmiertechniken unterstützen. Beispielsweise kann ein
alternatives Ausführungsbeispiel einen oder mehrere Schritte
aus diesem Ablaufdiagramm umstellen, ändern und/oder ent
fernen. Sofern bestimmte Schritte der Fig. 11A, 11B
und/oder 11C weggelassen werden, wird bestimmte Hardware in
Fig. 10 nicht benötigt. Wenn die TS-Anzeige nicht verwendet
wird, ist die TS-Anzeige beispielsweise nicht erforderlich.
Selbstverständlich kann die Erfindung für eine beliebige An
zahl von Systemarchitekturen nützlich sein und ist nicht auf
die hier beschriebene Architektur beschränkt.
Die Fig. 12A, 12B und 12C zeigen die Speicherfor
mate, um Gleitkommadaten, gepackte Daten und Ganzzahldaten
gemäß dem unter Bezugnahme auf Fig. 10 beschriebenen Aus
führungsbeispiel zu speichern. Selbstverständlich können al
ternative Ausführungsbeispiele beliebig viele verschiedene
Speicherformate zur Speicherung der Gleitkommadaten, gepack
ten Daten und Ganzzahldaten verwenden.
Fig. 12A zeigt ein Gleitkommaspeicherformat gemäß ei
nem Ausführungsbeispiel der Erfindung, welches unter Bezug
nahme auf Fig. 10 beschrieben wurde. Fig. 12A zeigt ein
Gleitkommaspeicherformat 1200, welches ein Vorzeichenfeld
1202 mit Bit 85 und ein Exponentenfeld 1204 mit Bits
[84:68], ein Mantissenfeld 1206 mit Bits [67:3] und ein Run
dungsfeld 1208 mit Bits [2:0] enthält. Wie im Vorangegan
genen beschrieben wurde, müssen die gleichen Gleitkommabe
fehle, welche zum Speichern des Gleitkommazustandes im Spei
cher bei Taskumschaltungen verwendet werden, auch zum Spei
chern eines gepackten Datenzustandes funktionieren, welcher
auf den Gleitkommaregistern aliased ist. Bei einem Ausfüh
rungsbeispiel speichert der Prozesser die Rundungsbits nicht
in dem Rundungsfeld 1208. Folglich müssen die gepackten Da
ten irgendwo in dem Mantissenfeld 1206 des Gleitkommaspei
cherformats 1200 gespeichert werden.
Fig. 12B zeigt das Speicherformat für gepackte Daten
gemäß dem Ausführungsbeispiel der Erfindung, welches unter
Bezugnahme auf Fig. 10 beschrieben wurde. Fig. 12B zeigt
ein Speicherformat für gepackte Daten 1210, welches ein Vor
zeichen/Exponentenfeld 1212 mit Bits [85:68], ein erstes
reserviertes Feld 1214 mit Bit [67], ein Feld für gepackte
Daten 1216 mit Bits [66:3] und ein zweites reserviertes Feld
1218 mit Bits [2:0] enthält. Wie im Vorangegangenen be
schrieben wurde, werden alle 1sen in dem Vorzeichen/Expo
nentenfeld 1212 gespeichert, wenn gepackte Daten in ein
Register geschrieben werden. Wie auch im Vorangegangenen
beschrieben wurde, ist das gepackte Datenfeld 1216 auf dem
Mantissenfeld 1206 aliased, so daß die existierenden Gleit
kommabefehle den gepackten Datenzustand speichern werden.
Bei einem Ausführungsbeispiel werden die ersten und zweiten
reservierten Felder 1214 und 1218 auf Null geschrieben, wenn
gepackte Daten in ein Register geschrieben werden. Während
ein Ausführungsbeispiel der Erfindung beschrieben wurde, bei
dem das gepackte Datenfeld 1216 des Speicherformats für ge
packte Daten 1210 mit dem gleichen Bitort wie das Mantis
senfeld 1206 des Gleitkommaspeicherformats 1200 beginnt,
könnten alternative Ausführungsbeispiele diese Beziehung
ändern.
Fig. 12C veranschaulicht das Speicherformat für Ganz
zahldaten gemäß dem unter Bezugnahme auf Fig. 10 beschrie
benen Ausführungsbeispiel der Erfindung. Fig. 12C zeigt ein
Ganzzahldatenspeicherformat 1220, welches ein reserviertes
Feld 1222 mit Bits [85:32] und ein Ganzzahldatenfeld 1224
mit Bits [31:0] enthält. Während ein Ausführungsbeispiel
beschrieben ist, bei dem Ganzzahldaten in 32 Bits gespei
chert werden, könnte ein alternatives Ausführungsbeispiel
derart implementiert werden, daß es Ganzzahldaten in einem
oder mehreren Formaten unter Verwendung einer beliebigen
Anzahl von Bits speichert. Beispielsweise könnten alter
native Ausführungsbeispiele ein 64-Bit-Format unterstützen.
Bei einem Ausführungsbeispiel enthält jedes Ganzzahlregister
1024, welches für Software sichtbar ist, 32 Bits. Folglich
wird das Ganzzahlspeicherformat 1220 nur in den Pufferregi
stern 1020 verwendet.
Fig. 13 veranschaulicht ein Verfahren gemäß einem
Ausführungsbeispiel der Erfindung, um den Schritt 1138 der
Fig. 11B auszuführen, wenn die unter Bezugnahme auf die
Fig. 12A, 12B und 12C beschriebenen Speicherformate
implementiert sind. Der Ablauf geht vom Schritt 1138 zu dem
Schritt 1300 weiter.
Im Schritt 1300 wird festgestellt, ob der gepackte
Datenbefehl gepackte Daten von irgendeinem FP/PD-Register
oder einem als FP/PD-Register dienenden Pufferregister
abruft. Falls dies der Fall ist, geht der Ablauf mit dem
Schritt 1302 weiter. Ansonsten geht der Ablauf mit dem
Schritt 1308 weiter.
Wie im Schritt 1302 dargestellt ist, werden die Bits
[66:3] von diesen aliased Puffer- oder FP/PD-Registern
abgerufen, und der Ablauf geht mit dem Schritt 1308 weiter.
Dieser Schritt ist notwendig, damit die gepackten Daten
nicht beginnend mit Bit Null, sondern beginnend mit Bit 3
gespeichert werden, wie in Fig. 12B dargestellt ist. Folg
lich müssen die Bits [2:0] gelöscht werden. Bei einem Aus
führungsbeispiel wird dieser Schritt von der Datenausrich
tungseinheit 1090 der Fig. 10 ausgeführt. Bei diesem Aus
führungsbeispiel werden die Daten von der Befehlsabschluß
einheit 1006 über die Ausgabeeinheit 1008 und zu der Ausfüh
rungseinheit 1010 in dem in Fig. 12B gezeigten Format über
tragen. Folglich werden die Daten von der Ausführungseinheit
1010 in dem in Fig. 12B gezeigten Format empfangen und die
Datenausrichtungseinheit 1090 kann die Bits [66:3] extra
hieren. Während Fig. 10 eine einzige Datenausrichtungsein
heit zeigt, enthält bei einem Ausführungsbeispiel jede Funk
tionseinheit in der Ausführungseinheit 1010, welche gepackte
Daten bearbeitet, eine Datenausrichtungseinheit zum Extra
hieren der Bits [63:3]. Da die Daten in der Ausführungsein
heit 1010 ausgerichtet sind, ist die Verwendung des gepack
ten Datenformats für den Rest des Prozessors transparent.
Die Datenausrichtungseinheit(en) kann (können) mit beliebig
vielen Techniken derart implementiert sein, daß sie auf die
Bits [66:3] zugreift(en). Beispielsweise ist (sind) die
Datenausrichtungseinheit(en) bei einem Ausführungsbeispiel
derart konzipiert, daß sie alle von den FP/PD-Registern oder
den als FP/PD-Registern dienenden Pufferregistern abgerufe
nen gepackten Daten um 3 Bits nach rechts verschiebt(en).
Bei einem alternativen Ausführungsbeispiel könnte die Be
fehlsabschlußeinheit oder Ausgabeeinheit derart imple
mentiert sein, daß sie die Bits [2:0] und/oder Bits [85:67]
entfernt bzw. strips away. Als weiteres Beispiel könnte ein
alternatives Ausführungsbeispiel derart implementiert
werden, daß die gepackten Daten beginnend bei Bit Null
gespeichert werden.
Im Schritt 1304 wird festgestellt, ob der gepackte
Datenbefehl gepackte Daten von irgendeinem Ganzzahlregister
oder einem als Ganzzahlregister dienenden Pufferregister ab
ruft. Falls dies der Fall ist, geht der Ablauf mit dem
Schritt 1306 weiter. Ansonsten geht der Ablauf mit dem
Schritt 1308 weiter.
Wie im Schritt 1306 gezeigt ist, werden die Bits [31:0]
von diesen aliased Puffern oder Ganzzahlregistern abgerufen,
und der Ablauf geht mit dem Schritt 1308 weiter. Dieser
Schritt ist notwendig, damit die Daten beginnend mit Bit
Null gespeichert werden. Wie im Vorangegangenen beschrieben
wurde, wird dieser Schritt bei einem Ausführungsbeispiel von
der Datenausrichtungseinheit 1090 der Fig. 10 ausgeführt.
Bei diesem Ausführungsbeispiel werden die Daten von der Be
fehlsabschlußeinheit 1006 über die Ausgabeeinheit 1008 und
an die Ausführungseinheit 1010 übertragen. Wenn auf die Da
ten von den Pufferregistern 1020 zugegriffen wird, werden
die Daten von der Ausführungseinheit 1010 in dem in Fig.
12C dargestellten Format empfangen und die Datenausrich
tungseinheit(en) können die Bits [31:0] extrahieren.
Wenn dagegen auf Daten von den Ganzzahlregistern 1024
zugegriffen wird, bei einem Ausführungsbeispiel, bei dem die
Ganzzahlregister 1024 32-Bit-Register sind, werden die Daten
von der Ausführungseinheit 1010 in dem 32-Bit-Format empfan
gen. In jedem Fall können die 32-Datenbits behandelt werden
als beliebige der 64-Bits des gepackten Datenelements.
Beispielsweise könnte ein erster Bewegebefehl derart
implementiert sein, daß er 32-Bits von einem Ganzzahlregi
ster in die oberen Bits eines gepackten Datenelementes be
wegt, während ein zweiter Bewegebefehl derart implementiert
werden könnte, daß er 32-Bits von einem Ganzzahlregister in
die unteren 32-Bits eines gepackten Datenelementes bewegt.
Wie im Schritt 1308 dargestellt ist, werden die von dem
Befehl benötigten Operationen ausgeführt, und der Ablauf
geht mit dem Schritt 1310 weiter.
Im Schritt 1310 wird festgestellt, ob der gepackte
Datenbefehl den Prozessor veranlaßt, in ein FP/PD-Register
oder ein als FP/PD-Register dienendes Pufferregister zu
schreiben. Falls dies der Fall ist, geht der Ablauf mit dem
Schritt 1312 weiter. Ansonsten geht der Ablauf mit dem
Schritt 1314 weiter.
Wenn der gepackte Datenbefehl den Prozessor veranlaßt,
in eine FP/PD-Register oder ein als FP/PD-Register dienendes
Pufferregister zu schreiben, müssen die Daten in dem rich
tigen Format gespeichert werden. Somit werden die gepackten
Daten im Schritt 1312 in den Bits [66:3] dieser FP/PD-Regi
ster oder Pufferregister gespeichert. Bei einem Ausführungs
beispiel wird wieder die Datenausrichtungseinheit 1090 gemäß
Fig. 10 verwendet. Wiederum gibt es eine Anzahl von
Techniken, um diese Funktionen auszuführen. Beispielsweise
kann (können) die Datenausrichtungseinheit(en) derart im
plementiert werden, daß die Daten um drei Bits nach links
verschoben werden, die Bits [2:0] mit Nullen aufgefüllt wer
den, das Bit [67] mit Null ausgefüllt wird und 1sen in den
Bits [85:68] gespeichert werden. Bei einem alternativen
Ausführungsbeispiel könnte die Befehlsabschlußeinheit zur
Speicherung der Daten in diesem Format implementiert sein.
Im Schritt 1314 wird festgestellt, ob der gepackte Da
tenbefehl den Prozessor veranlaßt, in irgendein Ganzzahl
register oder eine als Ganzzahlregister dienendes Puffer
register zu schreiben. Falls dies der Fall ist, geht der
Ablauf mit dem Schritt 1316 weiter. Ansonsten geht der Ab
lauf mit dem Schritt 1144 weiter.
Wenn der gepackte Datenbefehl den Prozessor veranlaßt,
in irgendein Ganzzahlregister oder ein als Ganzzahlregister
dienendes Pufferregister zu schreiben, müssen die gepackten
Daten in dem richtigen Ganzzahlspeicherformat gespeichert
werden. Somit werden die Daten im Schritt 1316 in den Ganz
zahlregistern als Bits [31:0] oder in den Pufferregistern
als Bits [63:0] oder [31:0] gespeichert (in Abhängigkeit von
der Implementierung. Da es 64-Datenbits gibt, können belie
bige 32-Datenbits in diesen Registern gespeichert werden.
Beispielsweise könnte ein erster Bewegebefehl derart imple
mentiert werden, daß er die oberen Bits eines gepackten Da
tenelementes in ein Ganzzahlregister bewegt, während ein
zweiter Bewegebefehl derart implementiert werden könnte, daß
er die unteren 32 Bits eines gepackten Datenelementes in ein
Ganzzahlregister bewegt. Bei einem Ausführungsbeispiel wird
dieser Schritt wiederum von der Datenausrichtungseinheit
1090 gemäß Fig. 10 ausgeführt. Selbstverständlich können
beliebig viele Techniken verwendet werden, um den Schritt
1316 zu implementieren, einschließlich derjenigen im Voran
gegangenen beschriebenen Techniken.
Auf diese Weise werden die von den verschiedenen Daten
arten verwendeten Speicherarten in den Registern des Prozes
sors richtig ausgerichtet. Bei einem Ausführungsbeispiel
werden die gleichen Speicherformate in den Pufferregistern
1020 verwendet, welche in den FP/PD-Registern 1022 und den
Ganzzahlregistern 1024 verwendet werden. Selbstverständlich
könnten alternative Ausführungsbeispiele beliebig viele an
dere Speicherformate verwenden und folglich liegen derartige
alternative Ausführungsbeispiele noch in dem Schutzbereich
der Erfindung. Beispielsweise verwendet ein alternatives
Ausführungsbeispiel diese Datenspeicherformate in dem Satz
von Pufferregistern 1020 und verwendet andere Datenspeicher
formate in den für Software sichtbaren Registern (z. B.
FP/PD-Registern 1022 und Ganzzahlregistern 1024).
Wie im Vorangegangenen beschrieben wurde, kann der
Übergang zwischen dem Gleitkommamodus und dem gepackten Da
tenmodus zeitaufwendig sein und stellt keine wirksame Pro
grammierpraktik dar. Um Programmierern bei der Feststellung
zu helfen, ob sie viele derartige Übergänge ausführen, kön
nen verschiedene Leistungsüberwachungstechniken verwendet
werden. Beispielsweise wird bei einem Ausführungsbeispiel
ein Leistungsüberwachungszähler verwendet. Ein Leistungs
überwachungszähler ist für den Programmierer sichtbar und
zählt die Male, bei denen unterschiedliche Bedingungen in
dem Prozessor aufeinandertreffen. Bei einem Ausführungsbei
spiel der Erfindung handelt es sich bei einer dieser Bedin
gungen um Übergänge zwischen dem Gleitkommamodus und dem
gepackten Datenmodus. Auf diese Weise kann ein Programmierer
erfahren, wieviele Übergänge ein Programm benötigt. Hin
sichtlich weiterer Informationen in Sachen Programmzählern
wird auf "Apparatus for Monitoring the Performance of a
Processor" Aktenzeichen 07/883,845 von Robert S. Dreyer et
al. verwiesen.
Da bekannte Gleitkommaprozessoren keine direkte Bear
beitung der Gleitkommatags erlauben, kann eine Emulation des
EMMS-Befehls mit Hilfe von Gleitkommabefehlen durchgeführt
werden.
Fig. 14 zeigt ein Ablaufdiagramm, welches ein Ver
fahren zum Löschen der Tags gemäß einem Ausführungsbeispiel
der Erfindung veranschaulicht. Dieses Ablaufdiagramm beginnt
mit dem Schritt 1402, in dem die Gleitkommaumgebung an einem
vorgegebenen Speicherplatz im Speicher gespeichert wird.
Dies wird dadurch ausgeführt, daß der FNSAVE- oder FSAVE-
Befehl in dem Intel-Architektur-Prozessor verwendet wird.
Sobald dies erledigt wurde, können die Tag- und/oder TOS-
Abschnitte des vorgegebenen Speicherplatzes, in den die
Umgebung gespeichert wurde, im Schritt 1404 in den leeren
Zustand geändert werden. Dies wird mit Hilfe einer be
liebigen Anzahl bekannter Befehle ausgeführt, einschließlich
der MOV-Befehle mit Direktoperanden für das entsprechende
Bitmuster für die Tag- und TOS-Bits. Es kann jeder andere
geeignete Befehl verwendet werden, welcher die Tag- und TOS-
Abschnitte des vorgegebenen Speicherplatzes in einen leeren
Zustand setzt. Anschließend kann die Umgebung dann im
Schritt 1406 von dem geänderten vorgegebenen Speicherplatz
erneut geladen werden. Da die anderen Abschnitte der Um
gebung (z. B. das Steuerwort, Statuswort usw.) unverändert
bleiben sollten, wenn nur die Gleitkommatags geändert wer
den, bleibt der Rest der Umgebung unverändert gegenüber der
"Speichere-Umgebung"-Operation 1402. Man beachte ferner, daß
dieses Ausführungsbeispiel des Prozesses mit Hilfe belie
biger bekannter Techniken durchgeführt werden kann, ein
schließlich der Verwendung von Befehlen, welche Interrupts
(z. B. FNSTENV) entaktivieren, um das Auftreten von unvor
hergesehenen Interrupts zu verhindern. Da die Umgebung nun
mit Hilfe einer beliebigen bekannten Technik, beispielsweise
FRSTOR oder FLDENV, erneut geladen wurde, wurde die Umgebung
nun auf jeden Fall derart erneut geladen, daß nur die Gleit
kommatags in den leeren Zustand geändert wurden. Man be
achte, daß der Schritt 1404 einen zusätzlichen Schritt
enthalten kann, welcher denjenigen Abschnitt der Gleitkomma
umgebung löscht, welcher die in dem Stapelkopfendefeld 350
gespeicherte Stapelkopfendeanzeige löscht.
Bei noch einem weiteren alternativen Ausführungsbei
spiel kann der EMMS-Befehl dadurch emuliert werden, daß die
Gleitkommaregister genügend oft abgerufen werden, bis alle
Tagbits leer sind. In jedem Fall kann der EMMS-Befehl als
Spezialbefehl ausgeführt werden, oder er kann emuliert wer
den, und beide Verfahren liegen innerhalb der Lehre dieser
Offenbarung.
Fig. 15A zeigt einen Ausführungsstrom mit gepackten
Datenbefehlen und Gleitkommabefehlen, um das Zeitintervall
zu veranschaulichen, in dem separate physikalische Register
dateien, welche aliased sind, aktualisiert werden können.
Fig. 15A zeigt einen Gleitkommabefehl 1500, dem ein Satz
von gepackten Datenbefehlen 1510 folgt. Außerdem zeigt Fig.
15A, daß der Gleitkommabefehl 1500 zum Zeitpunkt T1
ausgeführt wird, während die Ausführung des Satzes von ge
packten Datenbefehlen 1510 zum Zeitpunkt T2 beginnt.
Die Ausführung des Gleitkommabefehls 1500 veranlaßt den
Prozessor, einen Wert in ein Gleitkommaregister zu schrei
ben. Ein Intervall 1520 kennzeichnet die Zeit zwischen dem
Zeitpunkt T1 und dem Zeitpunkt T2, währenddessen dieser Wert
aliased werden muß. Bei einem unter Bezugnahme auf die
Fig. 6A-9 beschriebenen Ausführungsbeispiel, bei dem separate
physikalische Registerdateien zur Ausführung von Gleitkomma
befehlen und gepackten Datenbefehlen verwendet werden, wird
der Gleitkommazustand erst zum Zeitpunkt T2 von den physi
kalischen Gleitkommaregistern in die entsprechenden physi
kalischen Register für gepackte Daten kopiert (unter der An
nahme, daß vor dem Zeitpunkt T2 kein anderer Wert in das
gleiche Gleitkommaregister geschrieben wird). Wenn dagegen
eine einzige physikalische Registerdatei verwendet wird (die
unter Bezugnahme auf die Fig. 10-11C beschriebenen Aus
führungsbeispiele), wird der Gleitkommawert zum Zeitpunkt T1
in dem aliased Register gespeichert.
Somit sind die beiden Extrema des Intervalls 1520 be
schrieben. Jedoch könnten alternative Ausführungsbeispiele
derart implementiert werden, daß sie ein Aliasing der Regi
ster zu jeder beliebigen Zeit während des Zeitintervalls
1520 ausführen. Beispielsweise können alternative Ausfüh
rungsbeispiele, welche physikalische Registerdateien für die
Ausführung von Gleitkommabefehlen und gepackten Datenbefeh
len verwenden, derart implementiert werden, daß in die phy
sikalische Gleitkommaregisterdatei geschriebene Daten zum
Zeitpunkt T1 ebenfalls in die physikalische Registerdatei
für gepackte Daten geschrieben werden. Bei einem Ausfüh
rungsbeispiel, welches den Wert zum gleichen Zeitpunkt (z. B.
Zeitpunkt T1) in beide physikalische Registerdateien
schreibt, kann der Abschnitt der Übergangseinheit, welcher
die Daten von den Gleitkommaregistern in die Register für
gepackte Daten kopiert, als Hardware implementiert werden
(selbstverständlich können alternative Ausführungsbeispiele
Software, Firmware und/oder Hardware verwenden). Als weite
res Beispiel können alternative Ausführungsbeispiele, welche
separate physikalische Registerdateien für die Ausführung
von Gleitkommabefehlen und gepackten Datenbefehlen ver
wenden, derart implementiert werden, daß in die physika
lische Gleitkommaregisterdatei geschriebene Daten in die
physikalische Registerdatei für gepackte Daten geschrieben
werden, wenn während des Intervalls 1520 freie Verarbei
tungszeit verfügbar ist (jedoch irgendwann vor dem Zeitpunkt
T2). Auf diese Weise können diese Ausführungsbeispiele die
Übergangszeit verringern.
Fig. 15B zeigt einen Ausführungsstrom mit gepackten
Datenbefehlen und Gleitkommabefehlen, um das Zeitintervall
zu veranschaulichen, in dem separate physikalische Register
dateien, welche aliased sind, aktualisiert werden können.
Fig. 15A ähnelt Fig. 15B, abgesehen davon, daß auf einen
gepackten Datenbefehl 1530 ein Satz von Gleitkommabefehlen
1540 folgt. Fig. 15A zeigt, daß der gepackte Datenbefehl
1530 zum Zeitpunkt T1 ausgeführt wird, während die Aus
führung des Satzes von Gleitkommabefehlen 1540 zum Zeitpunkt
T2 begonnen wird. Die Ausführung des gepackten Datenbefehls
1530 veranlaßt den Prozessor, einen Wert in ein gepacktes
Datenregister zu schreiben. Ein Intervall 1550 kennzeichnet
die Zeit zwischen dem Zeitpunkt T1 und dem Zeitpunkt T2, in
der dieser Wert aliased werden muß. Alle unter Bezugnahme
auf Fig. 15A (unter Bezugnahme auf einen Gleitkommabefehl,
dem gepackte Datenbefehle folgen) beschriebenen alternativen
Ausführungsbeispiele können auch unter Bezugnahme auf Fig.
15B (unter Bezugnahme auf einen gepackten Datenbefehl, dem
Gleitkommabefehle folgen) implementiert werden.
Während die Erfindung anhand verschiedener Ausführungs
beispiele beschrieben wurde, ist es für den Fachmann klar,
daß die Erfindung nicht auf die beschriebenen Ausführungs
beispiele beschränkt ist. Das Verfahren und die Einrichtung
der Erfindung können innerhalb des Erfindungsgedankens und
des Schutzbereichs der beigefügten Ansprüche mit Modifi
kationen und Veränderungen realisiert werden. Folglich dient
die Beschreibung der Veranschaulichung und soll die Erfin
dung nicht beschränken.
Claims (35)
1. Verfahren zum Ausführen von Befehlen verschiedener
Befehlsarten, die Operationen an verschiedenen Datenarten
veranlassen, in einer Datenverarbeitungseinrichtung mit den
Schritten:
Ausführen einer ersten Folge von Befehlen einer ersten Befehlsart an den Inhalten einer einzigen logischen Regi sterdatei, wobei die logische Registerdatei beim Ausführen der ersten Folge von Befehlen als flache Registerdatei be trieben wird;
Ausführen eines ersten Befehls einer zweiten Befehlsart ebenfalls an den Inhalten der einzigen logischen Registerda tei, wobei die logische Registerdatei bei der Ausführung des ersten Befehls als Registerdatei betrieben wird, auf die als Stapel Bezug genommen wird; und
Ändern aller Tags in einem Satz von Tags, welche der logischen Registerdatei entsprechen, in einen Nicht-leer- Zustand irgendwann zwischen dem Beginn des Schrittes der Ausführung der ersten Folge von Befehlen und der Beendigung des Schrittes der Ausführung des ersten Befehls der zweiten Befehlsart, und wobei der Satz von Tags kennzeichnet, ob die Register in der logischen Registerdatei leer oder nicht-leer sind.
Ausführen einer ersten Folge von Befehlen einer ersten Befehlsart an den Inhalten einer einzigen logischen Regi sterdatei, wobei die logische Registerdatei beim Ausführen der ersten Folge von Befehlen als flache Registerdatei be trieben wird;
Ausführen eines ersten Befehls einer zweiten Befehlsart ebenfalls an den Inhalten der einzigen logischen Registerda tei, wobei die logische Registerdatei bei der Ausführung des ersten Befehls als Registerdatei betrieben wird, auf die als Stapel Bezug genommen wird; und
Ändern aller Tags in einem Satz von Tags, welche der logischen Registerdatei entsprechen, in einen Nicht-leer- Zustand irgendwann zwischen dem Beginn des Schrittes der Ausführung der ersten Folge von Befehlen und der Beendigung des Schrittes der Ausführung des ersten Befehls der zweiten Befehlsart, und wobei der Satz von Tags kennzeichnet, ob die Register in der logischen Registerdatei leer oder nicht-leer sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Tags in dem Satz von Tags als Antwort auf die Aus
führung der ersten Folge von Befehlen geändert werden.
3. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Tags in dem Satz von Tags als Antwort auf den Ver
such der Ausführung des ersten Befehls der zweiten Befehls
art geändert werden.
4. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Tags in dem Satz von Tags zwischen dem Schritt der
Ausführung der ersten Folge von Befehlen und der Ausführung
des ersten Befehls der zweiten Befehlsart geändert werden.
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Tags in dem Satz von Tags als Antwort auf den Ver
such der Ausführung des ersten Befehls der ersten Folge von
Befehlen geändert werden.
6. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß irgendwann zwischen dem Beginn des Schrittes der Ausfüh
rung der ersten Folge von Befehlen und der Beendigung des
Schrittes der Ausführung des ersten Befehls der zweiten Be
fehlsart eine Stapelkopfendeanzeige auf einen Initialisie
rungswert geändert wird, wobei die Stapelkopfendeanzeige ein
Register in der logischen Registerdatei als aktuell oberstes
Register des Stapels kennzeichnet.
7. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß entweder ein keine Zahl oder ein unendlich anzeigender
Wert in ein Vorzeichen- und Exponentenfeld jedes Registers
in der logischen Registerdatei, in welches während des
Schrittes der Ausführung der ersten Folge von Befehlen ge
schrieben wird, irgendwann zwischen dem Beginn des Schrittes
der Ausführung der ersten Folge von Befehlen und dem Beginn
des Schrittes der Ausführung des ersten Befehls der zweiten
Befehlsart geschrieben wird.
8. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß jedes Tag in dem Satz von Tags einem anderen Register in
der logischen Registerdatei entspricht und angibt, ob das
zugehörige Register leer oder nicht-leer ist.
9. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß bei der Ausführung des ersten Befehls der zweiten Be
fehlsart die in der logischen Registerdatei enthaltenen Da
ten in einen Speicher kopiert werden.
10. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Tags in dem Satz von Tags als Antwort auf die Aus
führung jedes Befehls der ersten Folge von Befehlen geändert
werden.
11. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Ausführung der ersten Folge von Befehlen die Ausfüh
rung gepackter Operationen umfaßt.
12. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Ausführung der ersten Folge von Befehlen die Ausfüh
rung gepackter Ganzzahloperationen umfaßt.
13. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die Ausführung der ersten Folge von Befehlen die Ausfüh
rung gepackter Gleitkommaoperationen umfaßt.
14. Verfahren nach Ansprüch 1, dadurch gekennzeichnet,
daß die zweite Befehlsart Befehle umfaßt, welche die Ausfüh
rung von Gleitkommaoperationen veranlassen.
15. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die zweite Befehlsart Befehle umfaßt, welche die Ausfüh
rung von skalaren Operationen veranlassen.
16. Verfahren nach Anspruch 1, dadurch gekennzeichnet,
daß die zweite Befehlsart Befehle umfaßt, welche die Ausfüh
rung von gepackten Operationen veranlassen.
17. Verfahren zum Ausführen von Befehlen verschiedener
Arten, die Operationen an verschiedenen Daten veranlassen,
in einer Datenverarbeitungseinrichtung mit den Schritten:
Ausführen einer Folge von Befehlen für gepackte Daten und einer Folge von Gleitkommabefehlen an den Inhalten einer einzigen logischen Registerdatei, die wenigstens teilweise aliased ist, wobei die Folge von Befehlen für gepackte Daten vor der Folge von Gleitkommabefehlen ausgeführt wird, wobei eine Mehrzahl von Tags der logischen Registerdatei ent spricht; und
Ändern zumindest derjenigen Tags der Mehrzahl von Tags, welche aliased Registern in der logischen Registerdatei ent sprechen, in einen Nicht-leer-Zustand irgendwann zwischen dem Versuch der Ausführung des ersten Befehls der Folge von Befehlen für gepackte Daten und der Beendigung der Ausfüh rung des ersten Befehls der Folge von Gleitkommabefehlen, und wobei die Tags angeben, ob die Register in der logischen Registerdatei leer oder nicht-leer sind.
Ausführen einer Folge von Befehlen für gepackte Daten und einer Folge von Gleitkommabefehlen an den Inhalten einer einzigen logischen Registerdatei, die wenigstens teilweise aliased ist, wobei die Folge von Befehlen für gepackte Daten vor der Folge von Gleitkommabefehlen ausgeführt wird, wobei eine Mehrzahl von Tags der logischen Registerdatei ent spricht; und
Ändern zumindest derjenigen Tags der Mehrzahl von Tags, welche aliased Registern in der logischen Registerdatei ent sprechen, in einen Nicht-leer-Zustand irgendwann zwischen dem Versuch der Ausführung des ersten Befehls der Folge von Befehlen für gepackte Daten und der Beendigung der Ausfüh rung des ersten Befehls der Folge von Gleitkommabefehlen, und wobei die Tags angeben, ob die Register in der logischen Registerdatei leer oder nicht-leer sind.
18. Verfahren nach Anspruch 17, dadurch gekennzeich
net, daß der Ausführungsschritt die Schritte umfaßt:
Ausführen der Folge von Befehlen für gepackte Daten auf der logischen Registerdatei als feste Registerdatei; und
Ausführen der Folge von Gleitkommabefehlen auf der lo gischen Registerdatei als Registerdatei, auf die als Stapel Bezug genommen wird.
Ausführen der Folge von Befehlen für gepackte Daten auf der logischen Registerdatei als feste Registerdatei; und
Ausführen der Folge von Gleitkommabefehlen auf der lo gischen Registerdatei als Registerdatei, auf die als Stapel Bezug genommen wird.
19. Verfahren nach Anspruch 17, dadurch gekennzeich
net, daß der Ausführungsschritt die Schritte umfaßt:
Ausführen der Folge von Befehlen für gepackte Daten zur Durchführung von gepackten Ganzzahloperationen;
Ausführen der Folge von Gleitkommabefehlen zur Durch führung von skalaren Gleitkommaoperationen.
Ausführen der Folge von Befehlen für gepackte Daten zur Durchführung von gepackten Ganzzahloperationen;
Ausführen der Folge von Gleitkommabefehlen zur Durch führung von skalaren Gleitkommaoperationen.
20. Verfahren nach Anspruch 17, dadurch gekennzeich
net, daß der Ausführungsschritt die Schritte umfaßt:
Ausführen der Folge von Befehlen für gepackte Daten zur Durchführung von gepackten Gleitkommaoperationen;
Ausführen der Folge von Gleitkommabefehlen zur Durch führung von skalaren Gleitkommaoperationen.
Ausführen der Folge von Befehlen für gepackte Daten zur Durchführung von gepackten Gleitkommaoperationen;
Ausführen der Folge von Gleitkommabefehlen zur Durch führung von skalaren Gleitkommaoperationen.
21. Verfahren zum Implementieren einer partiellen Kon
textumschaltung bei der Ausführung von Befehlen für skalare
Daten und Befehlen für gepackte Daten in einer Datenverar
beitungseinrichtung, wobei:
ein zu einer ersten Routine gehöriger Befehl empfangen wird, welcher entweder zu den Befehlen für skalare Daten oder zu den Befehlen für gepackte Daten gehört;
bestimmt wird, ob eine einzige logische Registerdatei zum Ausführen sowohl von Befehlen für skalare als auch von Befehlen für gepackte Daten aufgrund einer partiellen Kon textumschaltung nicht verfügbar ist; und
dann, wenn die logische Registerdatei nicht verfügbar ist, die Ausführung der ersten Routine unterbrochen und eine zweite Routine ausgeführt wird, um den Inhalt der logischen Registerdatei in einen Speicher zu kopieren; und
anderenfalls der Befehl an den Inhalten der logischen Registerdatei ausgeführt wird.
ein zu einer ersten Routine gehöriger Befehl empfangen wird, welcher entweder zu den Befehlen für skalare Daten oder zu den Befehlen für gepackte Daten gehört;
bestimmt wird, ob eine einzige logische Registerdatei zum Ausführen sowohl von Befehlen für skalare als auch von Befehlen für gepackte Daten aufgrund einer partiellen Kon textumschaltung nicht verfügbar ist; und
dann, wenn die logische Registerdatei nicht verfügbar ist, die Ausführung der ersten Routine unterbrochen und eine zweite Routine ausgeführt wird, um den Inhalt der logischen Registerdatei in einen Speicher zu kopieren; und
anderenfalls der Befehl an den Inhalten der logischen Registerdatei ausgeführt wird.
22. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß
festgestellt wird, ob eine skalare Emulationsanzeige in einem Emulationszustand ist;
dann, wenn die skalare Emulationsanzeige in dem Emula tionszustand ist,
die Ausführung der ersten Routine unterbrochen wird;
dann, wenn der Befehl ein Befehl für skalare Daten ist, die zweite Routine ausgeführt wird; und
anderenfalls, wenn der Befehl ein Befehl für ge packte Daten ist, eine dritte Routine anstelle der zweiten Routine ausgeführt wird.
festgestellt wird, ob eine skalare Emulationsanzeige in einem Emulationszustand ist;
dann, wenn die skalare Emulationsanzeige in dem Emula tionszustand ist,
die Ausführung der ersten Routine unterbrochen wird;
dann, wenn der Befehl ein Befehl für skalare Daten ist, die zweite Routine ausgeführt wird; und
anderenfalls, wenn der Befehl ein Befehl für ge packte Daten ist, eine dritte Routine anstelle der zweiten Routine ausgeführt wird.
23. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner
dann, wenn der Befehl ein Befehl für gepackte Daten ist, festgestellt wird, ob der Befehl veranlaßt, daß ein gepack tes Datenelement in die logische Registerdatei geschrieben wird; und
dann, wenn der Befehl veranlaßt, daß das gepackte Datenelement in die logische Registerdatei geschrieben wird, das gepackte Datenelement in ein Mantissenfeld eines Regi sters der logischen Registerdatei und ein keine Zahl oder unendlich darstellender Wert in ein Vorzeichenfeld und ein Exponentenfeld des Registers geschrieben wird.
dann, wenn der Befehl ein Befehl für gepackte Daten ist, festgestellt wird, ob der Befehl veranlaßt, daß ein gepack tes Datenelement in die logische Registerdatei geschrieben wird; und
dann, wenn der Befehl veranlaßt, daß das gepackte Datenelement in die logische Registerdatei geschrieben wird, das gepackte Datenelement in ein Mantissenfeld eines Regi sters der logischen Registerdatei und ein keine Zahl oder unendlich darstellender Wert in ein Vorzeichenfeld und ein Exponentenfeld des Registers geschrieben wird.
24. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner dann, wenn
der Befehl ein Übergangsbefehl der Befehle für gepackte Da
ten ist, jedes Tag in einem Satz von Tags in einen Leer-Zu
stand geändert wird, wobei jedes Tag in dem Satz von Tags
einem anderen Register in der logischen Registerdatei ent
spricht und angibt, ob das zugehörige Register leer oder
nicht-leer ist; und
der Satz von Tags in einen Nicht-leer-Zustand geändert wird, wenn der Befehl kein Übergangsbefehl, jedoch ein Be fehl für gepackte Daten ist.
der Satz von Tags in einen Nicht-leer-Zustand geändert wird, wenn der Befehl kein Übergangsbefehl, jedoch ein Be fehl für gepackte Daten ist.
25. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner dann, wenn
der Befehl ein skalarer Befehl ist,
ein Satz von Tags in einen Nicht-leer-Zustand ge ändert wird, wenn ein Übergangsbefehl der Befehle für ge packte Daten vor kürzerer Zeit als ein skalarer Befehl und vor kürzerer Zeit als ein anderer Befehl für gepackte Daten ausgeführt wurde, wobei jedes Tag in dem Satz von Tags einem anderen Register in der logischen Registerdatei entspricht und angibt, ob das zugehörige Register leer oder nicht-leer ist; und
der Satz von Tags in einen Leer-Zustand geändert wird, wenn ein Befehl für gepackte Daten vor kürzerer Zeit als ein skalarer Befehl und vor kürzerer Zeit als der Über gangsbefehl ausgeführt wurde.
ein Satz von Tags in einen Nicht-leer-Zustand ge ändert wird, wenn ein Übergangsbefehl der Befehle für ge packte Daten vor kürzerer Zeit als ein skalarer Befehl und vor kürzerer Zeit als ein anderer Befehl für gepackte Daten ausgeführt wurde, wobei jedes Tag in dem Satz von Tags einem anderen Register in der logischen Registerdatei entspricht und angibt, ob das zugehörige Register leer oder nicht-leer ist; und
der Satz von Tags in einen Leer-Zustand geändert wird, wenn ein Befehl für gepackte Daten vor kürzerer Zeit als ein skalarer Befehl und vor kürzerer Zeit als der Über gangsbefehl ausgeführt wurde.
26. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner dann, wenn
der Befehl ein Befehl für gepackte Daten ist, ein Satz von
Tags in einen Nicht-leer-Zustand geändert wird, wenn ein
skalarer Befehl vor kürzerer Zeit als ein Befehl für gepack
te Daten ausgeführt wurde, wobei jedes Tag in dem Satz von
Tags einem anderen Register in der logischen Registerdatei
entspricht und angibt, ob das zugehörige Register leer oder
nicht-leer ist; und
der Satz von Tags in einen Leer-Zustand geändert wird, wenn der Befehl ein Übergangsbefehl der Befehle für gepackte Daten ist.
der Satz von Tags in einen Leer-Zustand geändert wird, wenn der Befehl ein Übergangsbefehl der Befehle für gepackte Daten ist.
27. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner eine Sta
pelkopfendeanzeige auf einen Initialisierungswert geändert
wird, wenn der Befehl ein Befehl für gepackte Daten ist.
28. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner
eine Stapelkopfendeanzeige auf einen Initialisierungs
wert geändert wird, wenn der Befehl ein skalarer Befehl ist
und wenn ein Befehl für gepackte Daten vor kürzerer Zeit als
ein skalarer Befehl ausgeführt wurde.
29. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß bei der Ausführung des Befehls ferner
eine Stapelkopfendeanzeige auf einen Initialisierungs
wert geändert wird, wenn der Befehl ein gepackter Datenbe
fehl ist und wenn ein skalarer Befehl vor kürzerer Zeit als
ein Befehl für gepackte Daten ausgeführt wurde.
30. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß die skalaren Befehle dazu dienen, skalare Gleitkom
maoperationen auszuführen, und die Befehle für gepackte Da
ten dazu dienen, gepackte Ganzzahloperationen auszuführen.
31. Verfahren nach Anspruch 21, dadurch gekennzeich
net, daß die skalaren Befehle dazu dienen, skalare Gleitkom
maoperationen auszuführen, und die Befehle für gepackte Da
ten dazu dienen, gepackte Gleitkommaoperationen auszuführen.
32. Verfahren zum Ausführen von skalaren Befehlen und
Befehlen für gepackte Daten in einer Datenverarbeitungsein
richtung, wobei:
ein Befehl, welcher entweder ein Befehl für gepackte Daten oder ein Befehl für skalare Daten ist, empfangen wird;
festgestellt wird, ob die Ausführung von skalaren Be fehlen emuliert werden soll und ob eine einzige logische Re gisterdatei zur Ausführung von sowohl skalaren Befehlen als auch von Befehlen für gepackte Daten, aufgrund einer parti ellen Kontextumschaltung nicht verfügbar ist;
eine erste Routine ausgeführt wird, wenn der Befehl der skalare Befehl ist und wenn entweder die logische Register datei nicht verfügbar ist oder die Ausführung von skalaren Befehlen emuliert werden soll; und
wenn anderenfalls der Befehl der Befehl für gepackte Da ten ist, die erste Routine ausgeführt wird, wenn die logi sche Registerdatei nicht verfügbar ist oder eine zweite Rou tine anstelle der ersten Routine ausgeführt wird, wenn die Ausführung von skalaren Befehlen emuliert werden soll.
ein Befehl, welcher entweder ein Befehl für gepackte Daten oder ein Befehl für skalare Daten ist, empfangen wird;
festgestellt wird, ob die Ausführung von skalaren Be fehlen emuliert werden soll und ob eine einzige logische Re gisterdatei zur Ausführung von sowohl skalaren Befehlen als auch von Befehlen für gepackte Daten, aufgrund einer parti ellen Kontextumschaltung nicht verfügbar ist;
eine erste Routine ausgeführt wird, wenn der Befehl der skalare Befehl ist und wenn entweder die logische Register datei nicht verfügbar ist oder die Ausführung von skalaren Befehlen emuliert werden soll; und
wenn anderenfalls der Befehl der Befehl für gepackte Da ten ist, die erste Routine ausgeführt wird, wenn die logi sche Registerdatei nicht verfügbar ist oder eine zweite Rou tine anstelle der ersten Routine ausgeführt wird, wenn die Ausführung von skalaren Befehlen emuliert werden soll.
33. Verfahren nach Anspruch 32, dadurch gekennzeich
net, daß die skalaren Befehle dazu dienen, skalare Gleitkom
maoperationen durchzuführen, und die Befehle für gepackte
Daten dazu dienen, gepackte Ganzzahloperationen durchzufüh
ren.
34. Verfahren nach Anspruch 32, dadurch gekennzeich
net, daß die skalaren Befehle dazu dienen, skalare Gleitkom
maoperationen durchzuführen, und die Befehle für gepackte
Daten dazu dienen, gepackte Gleitkommaoperationen durchzu
führen.
35. Verfahren zum Ausführen von Befehlen für gepackte
Daten in einer Datenverarbeitungseinrichtung, wobei:
ein Befehl für gepackte Daten empfangen wird, welcher veranlaßt, daß ein gepacktes Datenelement in ein Register geschrieben wird, welches wenigstens logisch der Software als ein Register in einer logischen Registerdatei erscheint, welche außerdem zum Sichern von Gleitkommadaten verwendet wird;
das gepackte Datenelement in ein Mantissenfeld des lo gischen Registers geschrieben wird; und
ein keine Zahl oder unendlich darstellender Wert in ein Vorzeichenfeld und ein Exponentenfeld des logischen Regi sters geschrieben wird.
ein Befehl für gepackte Daten empfangen wird, welcher veranlaßt, daß ein gepacktes Datenelement in ein Register geschrieben wird, welches wenigstens logisch der Software als ein Register in einer logischen Registerdatei erscheint, welche außerdem zum Sichern von Gleitkommadaten verwendet wird;
das gepackte Datenelement in ein Mantissenfeld des lo gischen Registers geschrieben wird; und
ein keine Zahl oder unendlich darstellender Wert in ein Vorzeichenfeld und ein Exponentenfeld des logischen Regi sters geschrieben wird.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/574,500 US5701508A (en) | 1995-12-19 | 1995-12-19 | Executing different instructions that cause different data type operations to be performed on single logical register file |
PCT/US1996/020573 WO1997022924A1 (en) | 1995-12-19 | 1996-12-17 | A method of performing different data type operations that is invisible to various operating system techniques |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19681660T1 DE19681660T1 (de) | 1998-10-29 |
DE19681660C2 true DE19681660C2 (de) | 2000-11-02 |
Family
ID=24296415
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19681660T Expired - Lifetime DE19681660C2 (de) | 1995-12-19 | 1996-12-17 | Verfahren zum Ausführen von Befehlssätzen, die Operationen an verschiedenen Datenarten und Register eines gemeinsamen logischen Registersatzes spezifizieren |
Country Status (9)
Country | Link |
---|---|
US (2) | US5701508A (de) |
KR (1) | KR100286416B1 (de) |
AU (1) | AU1430597A (de) |
DE (1) | DE19681660C2 (de) |
GB (1) | GB2326494B (de) |
HK (1) | HK1016711A1 (de) |
TW (1) | TW345649B (de) |
WO (1) | WO1997022924A1 (de) |
ZA (1) | ZA9610677B (de) |
Families Citing this family (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1326033C (zh) | 1994-12-02 | 2007-07-11 | 英特尔公司 | 可以对复合操作数进行压缩操作的微处理器 |
US6385634B1 (en) | 1995-08-31 | 2002-05-07 | Intel Corporation | Method for performing multiply-add operations on packed data |
US7395298B2 (en) | 1995-08-31 | 2008-07-01 | Intel Corporation | Method and apparatus for performing multiply-add operations on packed data |
US5857096A (en) * | 1995-12-19 | 1999-01-05 | Intel Corporation | Microarchitecture for implementing an instruction to clear the tags of a stack reference register file |
US6792523B1 (en) * | 1995-12-19 | 2004-09-14 | Intel Corporation | Processor with instructions that operate on different data types stored in the same single logical register file |
US5940859A (en) | 1995-12-19 | 1999-08-17 | Intel Corporation | Emptying packed data state during execution of packed data instructions |
US5701508A (en) * | 1995-12-19 | 1997-12-23 | Intel Corporation | Executing different instructions that cause different data type operations to be performed on single logical register file |
DE19600004C2 (de) * | 1996-01-02 | 1998-11-19 | Siemens Ag | Durchlaufdampferzeuger mit spiralförmig angeordneten Verdampferrohren |
US5991531A (en) * | 1997-02-24 | 1999-11-23 | Samsung Electronics Co., Ltd. | Scalable width vector processor architecture for efficient emulation |
US6009511A (en) * | 1997-06-11 | 1999-12-28 | Advanced Micro Devices, Inc. | Apparatus and method for tagging floating point operands and results for rapid detection of special floating point numbers |
US6094719A (en) * | 1997-06-25 | 2000-07-25 | Sun Microsystems, Inc. | Reducing data dependent conflicts by converting single precision instructions into microinstructions using renamed phantom registers in a processor having double precision registers |
US5978901A (en) * | 1997-08-21 | 1999-11-02 | Advanced Micro Devices, Inc. | Floating point and multimedia unit with data type reclassification capability |
US6256659B1 (en) * | 1997-12-09 | 2001-07-03 | Mci Communications Corporation | System and method for performing hybrid preemptive and cooperative multi-tasking in a computer system |
US6192464B1 (en) * | 1997-12-31 | 2001-02-20 | Intel Corporation | Method and apparatus for decoding one or more instructions after renaming destination registers |
US6272453B1 (en) * | 1998-01-05 | 2001-08-07 | Trw Inc. | Concurrent legacy and native code execution techniques |
US6237083B1 (en) * | 1998-02-13 | 2001-05-22 | Advanced Micro Devices, Inc. | Microprocessor including multiple register files mapped to the same logical storage and inhibiting sychronization between the register files responsive to inclusion of an instruction in an instruction sequence |
US6105129A (en) * | 1998-02-18 | 2000-08-15 | Advanced Micro Devices, Inc. | Converting register data from a first format type to a second format type if a second type instruction consumes data produced by a first type instruction |
EP0942357A3 (de) * | 1998-03-11 | 2000-03-22 | Matsushita Electric Industrial Co., Ltd. | Mit einer Mehrzahl von Befehlsformaten vereinbarer Datenprozessor |
US20010049780A1 (en) * | 1998-03-27 | 2001-12-06 | Shreekant Thakkar | Method and apparatus for performing integer operations in response to a result of a floating point operation |
US6230257B1 (en) | 1998-03-31 | 2001-05-08 | Intel Corporation | Method and apparatus for staggering execution of a single packed data instruction using the same circuit |
US6230253B1 (en) | 1998-03-31 | 2001-05-08 | Intel Corporation | Executing partial-width packed data instructions |
US6233671B1 (en) | 1998-03-31 | 2001-05-15 | Intel Corporation | Staggering execution of an instruction by dividing a full-width macro instruction into at least two partial-width micro instructions |
US6192467B1 (en) | 1998-03-31 | 2001-02-20 | Intel Corporation | Executing partial-width packed data instructions |
US6370639B1 (en) * | 1998-10-10 | 2002-04-09 | Institute For The Development Of Emerging Architectures L.L.C. | Processor architecture having two or more floating-point status fields |
US6163764A (en) * | 1998-10-12 | 2000-12-19 | Intel Corporation | Emulation of an instruction set on an instruction set architecture transition |
US6321327B1 (en) * | 1998-12-30 | 2001-11-20 | Intel Corporation | Method for setting a bit associated with each component of packed floating-pint operand that is normalized in SIMD operations |
US6526431B1 (en) * | 1999-02-26 | 2003-02-25 | Intel Corporation | Maintaining extended and traditional states of a processing unit in task switching |
US6542862B1 (en) * | 2000-02-18 | 2003-04-01 | Hewlett-Packard Development Company, L.P. | Determining register dependency in multiple architecture systems |
US7496734B1 (en) * | 2000-04-28 | 2009-02-24 | Stmicroelectronics, Inc. | System and method for handling register dependency in a stack-based pipelined processor |
JP3786644B2 (ja) | 2001-04-23 | 2006-06-14 | アトメル・コーポレイション | バイトコンパイルされたJava(R)コードを実行するためのマイクロプロセッサ |
US7430578B2 (en) | 2001-10-29 | 2008-09-30 | Intel Corporation | Method and apparatus for performing multiply-add operations on packed byte data |
US7117346B2 (en) * | 2002-05-31 | 2006-10-03 | Freescale Semiconductor, Inc. | Data processing system having multiple register contexts and method therefor |
US7478224B2 (en) * | 2005-04-15 | 2009-01-13 | Atmel Corporation | Microprocessor access of operand stack as a register file using native instructions |
US7644258B2 (en) * | 2005-08-29 | 2010-01-05 | Searete, Llc | Hybrid branch predictor using component predictors each having confidence and override signals |
US9176741B2 (en) * | 2005-08-29 | 2015-11-03 | Invention Science Fund I, Llc | Method and apparatus for segmented sequential storage |
US8296550B2 (en) * | 2005-08-29 | 2012-10-23 | The Invention Science Fund I, Llc | Hierarchical register file with operand capture ports |
US20070083735A1 (en) * | 2005-08-29 | 2007-04-12 | Glew Andrew F | Hierarchical processor |
US8275976B2 (en) * | 2005-08-29 | 2012-09-25 | The Invention Science Fund I, Llc | Hierarchical instruction scheduler facilitating instruction replay |
US20090292212A1 (en) * | 2008-05-20 | 2009-11-26 | Searete Llc, A Limited Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US20090287094A1 (en) * | 2008-05-15 | 2009-11-19 | Seacrete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US20090287101A1 (en) * | 2008-05-13 | 2009-11-19 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US20090287191A1 (en) * | 2007-12-18 | 2009-11-19 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US20090287120A1 (en) | 2007-12-18 | 2009-11-19 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US20090287109A1 (en) * | 2008-05-14 | 2009-11-19 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Circulatory monitoring systems and methods |
US9717896B2 (en) | 2007-12-18 | 2017-08-01 | Gearbox, Llc | Treatment indications informed by a priori implant information |
US8636670B2 (en) | 2008-05-13 | 2014-01-28 | The Invention Science Fund I, Llc | Circulatory monitoring systems and methods |
US7877582B2 (en) * | 2008-01-31 | 2011-01-25 | International Business Machines Corporation | Multi-addressable register file |
US7849294B2 (en) * | 2008-01-31 | 2010-12-07 | International Business Machines Corporation | Sharing data in internal and memory representations with dynamic data-driven conversion |
US8284046B2 (en) | 2008-08-27 | 2012-10-09 | The Invention Science Fund I, Llc | Health-related signaling via wearable items |
US20100056873A1 (en) * | 2008-08-27 | 2010-03-04 | Allen Paul G | Health-related signaling via wearable items |
US8094009B2 (en) * | 2008-08-27 | 2012-01-10 | The Invention Science Fund I, Llc | Health-related signaling via wearable items |
US8125331B2 (en) * | 2008-08-27 | 2012-02-28 | The Invention Science Fund I, Llc | Health-related signaling via wearable items |
US8130095B2 (en) * | 2008-08-27 | 2012-03-06 | The Invention Science Fund I, Llc | Health-related signaling via wearable items |
GB2471138B (en) * | 2009-06-19 | 2014-08-13 | Advanced Risc Mach Ltd | Handling integer and floating point registers during a context switch |
US9727336B2 (en) | 2011-09-16 | 2017-08-08 | International Business Machines Corporation | Fine-grained instruction enablement at sub-function granularity based on an indicated subrange of registers |
US9411585B2 (en) | 2011-09-16 | 2016-08-09 | International Business Machines Corporation | Multi-addressable register files and format conversions associated therewith |
EP3025230A4 (de) * | 2013-07-23 | 2017-04-05 | Intel Corporation | Verfahren und vorrichtung zur betriebssystemumschaltung |
US9286097B2 (en) * | 2013-07-23 | 2016-03-15 | Intel Corporation | Switching a first OS in a foreground to a standby state in response to a system event and resuming a second OS from a background |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5127098A (en) * | 1989-04-12 | 1992-06-30 | Sun Microsystems, Inc. | Method and apparatus for the context switching of devices |
WO1993001543A1 (en) * | 1991-07-08 | 1993-01-21 | S-Mos Systems, Inc. | Risc microprocessor architecture implementing multiple typed register sets |
Family Cites Families (42)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US3711692A (en) * | 1971-03-15 | 1973-01-16 | Goodyear Aerospace Corp | Determination of number of ones in a data field by addition |
US3723715A (en) * | 1971-08-25 | 1973-03-27 | Ibm | Fast modulo threshold operator binary adder for multi-number additions |
US4161784A (en) * | 1978-01-05 | 1979-07-17 | Honeywell Information Systems, Inc. | Microprogrammable floating point arithmetic unit capable of performing arithmetic operations on long and short operands |
US4229801A (en) * | 1978-12-11 | 1980-10-21 | Data General Corporation | Floating point processor having concurrent exponent/mantissa operation |
US4418383A (en) * | 1980-06-30 | 1983-11-29 | International Business Machines Corporation | Data flow component for processor and microprocessor systems |
US4393468A (en) * | 1981-03-26 | 1983-07-12 | Advanced Micro Devices, Inc. | Bit slice microprogrammable processor for signal processing applications |
US4498177A (en) * | 1982-08-30 | 1985-02-05 | Sperry Corporation | M Out of N code checker circuit |
US4707800A (en) * | 1985-03-04 | 1987-11-17 | Raytheon Company | Adder/substractor for variable length numbers |
JPS6297060A (ja) * | 1985-10-23 | 1987-05-06 | Mitsubishi Electric Corp | デイジタルシグナルプロセツサ |
US4992938A (en) * | 1987-07-01 | 1991-02-12 | International Business Machines Corporation | Instruction control mechanism for a computing system with register renaming, map table and queues indicating available registers |
US4989168A (en) * | 1987-11-30 | 1991-01-29 | Fujitsu Limited | Multiplying unit in a computer system, capable of population counting |
US5008812A (en) * | 1988-03-18 | 1991-04-16 | Digital Equipment Corporation | Context switching method and apparatus for use in a vector processing system |
US5241635A (en) | 1988-11-18 | 1993-08-31 | Massachusetts Institute Of Technology | Tagged token data processing system with operand matching in activation frames |
KR920007505B1 (ko) * | 1989-02-02 | 1992-09-04 | 정호선 | 신경회로망을 이용한 곱셈기 |
JPH03139726A (ja) | 1989-10-26 | 1991-06-13 | Hitachi Ltd | 命令読出し制御方式 |
EP0510429A3 (en) | 1991-04-24 | 1993-12-01 | Ibm | Millicode register management system |
US5187679A (en) * | 1991-06-05 | 1993-02-16 | International Business Machines Corporation | Generalized 7/3 counters |
US5657253A (en) | 1992-05-15 | 1997-08-12 | Intel Corporation | Apparatus for monitoring the performance of a microprocessor |
US5522051A (en) * | 1992-07-29 | 1996-05-28 | Intel Corporation | Method and apparatus for stack manipulation in a pipelined processor |
US5367650A (en) * | 1992-07-31 | 1994-11-22 | Intel Corporation | Method and apparauts for parallel exchange operation in a pipelined processor |
US5519841A (en) * | 1992-11-12 | 1996-05-21 | Digital Equipment Corporation | Multi instruction register mapper |
KR0122528B1 (ko) | 1993-01-08 | 1997-11-20 | 윌리엄 티.엘리스 | 슈퍼스칼라 프로세서 시스템에서 중간 기억 버퍼의 할당을 인덱스하기 위한 방법 및 시스템 |
US5467473A (en) | 1993-01-08 | 1995-11-14 | International Business Machines Corporation | Out of order instruction load and store comparison |
US5535397A (en) * | 1993-06-30 | 1996-07-09 | Intel Corporation | Method and apparatus for providing a context switch in response to an interrupt in a computer process |
US5499352A (en) * | 1993-09-30 | 1996-03-12 | Intel Corporation | Floating point register alias table FXCH and retirement floating point register array |
EP0651321B1 (de) | 1993-10-29 | 2001-11-14 | Advanced Micro Devices, Inc. | Superskalarmikroprozessoren |
US5546554A (en) * | 1994-02-02 | 1996-08-13 | Sun Microsystems, Inc. | Apparatus for dynamic register management in a floating point unit |
US5696955A (en) * | 1994-06-01 | 1997-12-09 | Advanced Micro Devices, Inc. | Floating point stack and exchange instruction |
US5649225A (en) * | 1994-06-01 | 1997-07-15 | Advanced Micro Devices, Inc. | Resynchronization of a superscalar processor |
US5481719A (en) * | 1994-09-09 | 1996-01-02 | International Business Machines Corporation | Exception handling method and apparatus for a microkernel data processing system |
US5507000A (en) * | 1994-09-26 | 1996-04-09 | Bull Hn Information Systems Inc. | Sharing of register stack by two execution units in a central processor |
EP1302848B1 (de) | 1994-12-01 | 2006-11-02 | Intel Corporation | Ein Mikroprozessor mit Mulitplizierungsoperation |
US5537606A (en) * | 1995-01-31 | 1996-07-16 | International Business Machines Corporation | Scalar pipeline replication for parallel vector element processing |
US5634118A (en) | 1995-04-10 | 1997-05-27 | Exponential Technology, Inc. | Splitting a floating-point stack-exchange instruction for merging into surrounding instructions by operand translation |
US5760792A (en) | 1995-05-01 | 1998-06-02 | Intergraph Corporation | Fifo logical addresses for control and error recovery |
US5721892A (en) | 1995-08-31 | 1998-02-24 | Intel Corporation | Method and apparatus for performing multiply-subtract operations on packed data |
US5857096A (en) | 1995-12-19 | 1999-01-05 | Intel Corporation | Microarchitecture for implementing an instruction to clear the tags of a stack reference register file |
US5701508A (en) * | 1995-12-19 | 1997-12-23 | Intel Corporation | Executing different instructions that cause different data type operations to be performed on single logical register file |
US5835748A (en) | 1995-12-19 | 1998-11-10 | Intel Corporation | Method for executing different sets of instructions that cause a processor to perform different data type operations on different physical registers files that logically appear to software as a single aliased register file |
US5852726A (en) | 1995-12-19 | 1998-12-22 | Intel Corporation | Method and apparatus for executing two types of instructions that specify registers of a shared logical register file in a stack and a non-stack referenced manner |
US5940859A (en) | 1995-12-19 | 1999-08-17 | Intel Corporation | Emptying packed data state during execution of packed data instructions |
US5687336A (en) | 1996-01-11 | 1997-11-11 | Exponential Technology, Inc. | Stack push/pop tracking and pairing in a pipelined processor |
-
1995
- 1995-12-19 US US08/574,500 patent/US5701508A/en not_active Expired - Lifetime
-
1996
- 1996-12-17 KR KR1019980704687A patent/KR100286416B1/ko not_active IP Right Cessation
- 1996-12-17 WO PCT/US1996/020573 patent/WO1997022924A1/en active IP Right Grant
- 1996-12-17 DE DE19681660T patent/DE19681660C2/de not_active Expired - Lifetime
- 1996-12-17 GB GB9811430A patent/GB2326494B/en not_active Expired - Lifetime
- 1996-12-17 AU AU14305/97A patent/AU1430597A/en not_active Abandoned
- 1996-12-19 ZA ZA9610677A patent/ZA9610677B/xx unknown
-
1997
- 1997-03-21 TW TW086103614A patent/TW345649B/zh not_active IP Right Cessation
- 1997-07-22 US US08/898,720 patent/US6170997B1/en not_active Expired - Lifetime
-
1999
- 1999-04-09 HK HK99101457A patent/HK1016711A1/xx not_active IP Right Cessation
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5127098A (en) * | 1989-04-12 | 1992-06-30 | Sun Microsystems, Inc. | Method and apparatus for the context switching of devices |
WO1993001543A1 (en) * | 1991-07-08 | 1993-01-21 | S-Mos Systems, Inc. | Risc microprocessor architecture implementing multiple typed register sets |
Non-Patent Citations (1)
Title |
---|
WOPPERER, Bernhard: Pentium-Prozessor, in: MC, April 1993, S. 44-46, 48, 54, 56-58, 60, 62 * |
Also Published As
Publication number | Publication date |
---|---|
KR20000064489A (ko) | 2000-11-06 |
US5701508A (en) | 1997-12-23 |
HK1016711A1 (en) | 1999-11-05 |
DE19681660T1 (de) | 1998-10-29 |
US6170997B1 (en) | 2001-01-09 |
GB2326494B (en) | 2000-08-23 |
AU1430597A (en) | 1997-07-14 |
TW345649B (en) | 1998-11-21 |
WO1997022924A1 (en) | 1997-06-26 |
ZA9610677B (en) | 1997-06-24 |
GB9811430D0 (en) | 1998-07-22 |
GB2326494A (en) | 1998-12-23 |
KR100286416B1 (ko) | 2001-04-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19681660C2 (de) | Verfahren zum Ausführen von Befehlssätzen, die Operationen an verschiedenen Datenarten und Register eines gemeinsamen logischen Registersatzes spezifizieren | |
DE69904189T2 (de) | Konfigurierter prozessor zur abbildung von logischen registernummern auf physikalische registernummern unter verwendung von virtuellen registernummern | |
DE112007000812B4 (de) | Vorrichtung mit einer speichereinheit und drei logiken, verfahren zum durchführen der verfahrensschritte der vorrichtung undsystem mit einem speicher und einem prozessor zur bereitstellung eines effizienten mechanismus‘ für transaktionalspeicherausführungen in out-of-order-prozessoren | |
DE69308548T2 (de) | Vorrichtung und verfahren zum befehlsabschluss in einem superskalaren prozessor. | |
RU2179331C2 (ru) | Способ и устройство для выполнения команд с плавающей запятой и упакованных данных, используя одиночный файл регистра | |
DE69506623T2 (de) | Datenprozessor mit einer Ausführungseinheit zur Durchführung von Ladebefehlen und Verfahren zu seinem Betrieb | |
DE69329778T2 (de) | System und verfahren zur handhabung von laden und/oder speichern in einem superskalar mikroprozessor | |
DE112006002237B4 (de) | Verfahren zur selbstinitiierenden Synchronisierung in einem Computersystem | |
DE112018000848T5 (de) | Registerkontextwiederherstellung auf der Grundlage der Wiedergewinnung von Umbenennungsregistern | |
DE60011797T2 (de) | Ausführung von mehreren fäden in einem parallelprozessor | |
DE69033331T2 (de) | Sprungvorhersage | |
DE69612991T2 (de) | System zur bearbeitung von selbstmodifizierendem kode | |
US5835748A (en) | Method for executing different sets of instructions that cause a processor to perform different data type operations on different physical registers files that logically appear to software as a single aliased register file | |
US6266686B1 (en) | Emptying packed data state during execution of packed data instructions | |
DE69623146T2 (de) | Verfahren und Vorrichtung zum Koordinieren der Benutzung von physikalischen Registern in einem Mikroprozessor | |
DE112010004322T5 (de) | Vorhersagen und Vermeiden von Operand-Speichervorgang-Vergleich-Gefahren in Mikroprozessoren mit abweichender Reihenfolge | |
DE102012216592A1 (de) | Präfix-Computeranweisung zur Erweiterung der Anweisungsfunktionalität | |
DE4329336A1 (de) | Einrichtung und Verfahren zur Identifizierung eines Computer-Mikroprozessors | |
US7149882B2 (en) | Processor with instructions that operate on different data types stored in the same single logical register file | |
DE10296798T5 (de) | SMM-Lader und -Ausführungsmechanismus für Komponentensoftware für mehrere Architekturen | |
DE19506734A1 (de) | Computersystem und Verfahren zum Aufrechterhalten der Speicherkonsistenz in einer Busanforderungswarteschlange | |
DE112007001171T5 (de) | Verfahren für virtualisierten Transaktionsspeicher bei globalem Überlauf | |
DE69727177T2 (de) | Emulation von asynchronen Signalen mit Verzweigungsmechanismus | |
DE69429612T2 (de) | Schreibpuffer für einen superskalaren Mikroprozessor mit Pipeline | |
DE102018002525A1 (de) | Hybridatomaritätsunterstützung für einen binärübersetzungsbasierten mikroprozessor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
8125 | Change of the main classification |
Ipc: G06F 9/46 |
|
8607 | Notification of search results after publication | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
R071 | Expiry of right |