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 spezifizieren

Info

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
Application number
DE19681660T
Other languages
English (en)
Other versions
DE19681660T1 (de
Inventor
Andrew Glew
Ramamohan R Vakkalagadda
Derrick Lin
Larry M Mennemeier
Alexander D Peleg
David Bistry
Millind Mittal
Carole Dulong
Eiichi Kowashi
Benny Eitan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=24296415&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE19681660(C2) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE19681660T1 publication Critical patent/DE19681660T1/de
Application granted granted Critical
Publication of DE19681660C2 publication Critical patent/DE19681660C2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

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/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
    • G06F9/30038—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations using a mask
    • 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

HINTERGRUND DER ERFINDUNG Gebiet der Erfindung
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.
Hintergrundinformationen
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.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
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.
DETAILLIERTE BESCHREIBUNG
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:
Tabelle 1
Wirkung eines gepackten Datenbefehls/FP-Befehls auf das Tagwort
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.
Tabelle 2
Auswirkung der gepackten Datenbefehle auf die FPU
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
DE19681660T 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 Expired - Lifetime DE19681660C2 (de)

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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101211255B (zh) 1994-12-02 2012-07-04 英特尔公司 对复合操作数进行压缩操作的处理器、设备和计算系统
US7395298B2 (en) 1995-08-31 2008-07-01 Intel Corporation Method and apparatus for performing multiply-add operations on packed data
US6385634B1 (en) 1995-08-31 2002-05-07 Intel Corporation Method for performing multiply-add operations on packed data
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
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
US5940859A (en) * 1995-12-19 1999-08-17 Intel Corporation Emptying packed data state during execution of packed data instructions
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
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
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
US6230253B1 (en) * 1998-03-31 2001-05-08 Intel Corporation Executing partial-width packed data 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
AU2002307080A1 (en) * 2001-04-23 2002-11-05 Atmel Corporation Microprocessor for executing byte compiled java code
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
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
US8296550B2 (en) * 2005-08-29 2012-10-23 The Invention Science Fund I, Llc Hierarchical register file with operand capture ports
US9176741B2 (en) * 2005-08-29 2015-11-03 Invention Science Fund I, Llc Method and apparatus for segmented sequential storage
US9717896B2 (en) * 2007-12-18 2017-08-01 Gearbox, Llc Treatment indications informed by a priori implant information
US20090287120A1 (en) * 2007-12-18 2009-11-19 Searete Llc, A Limited Liability 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
US20090287109A1 (en) * 2008-05-14 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
US20090287101A1 (en) * 2008-05-13 2009-11-19 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Circulatory monitoring systems and methods
US8636670B2 (en) 2008-05-13 2014-01-28 The Invention Science Fund I, Llc Circulatory monitoring systems and methods
US20090292212A1 (en) * 2008-05-20 2009-11-26 Searete Llc, A Limited Corporation Of The State Of Delaware 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
US8130095B2 (en) * 2008-08-27 2012-03-06 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
US8125331B2 (en) * 2008-08-27 2012-02-28 The Invention Science Fund I, Llc 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
US8284046B2 (en) 2008-08-27 2012-10-09 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
US9411585B2 (en) 2011-09-16 2016-08-09 International Business Machines Corporation Multi-addressable register files and format conversions associated therewith
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
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
DE69429061T2 (de) 1993-10-29 2002-07-18 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
US5649225A (en) * 1994-06-01 1997-07-15 Advanced Micro Devices, Inc. Resynchronization of a superscalar processor
US5696955A (en) * 1994-06-01 1997-12-09 Advanced Micro Devices, Inc. Floating point stack and exchange instruction
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
EP0795155B1 (de) 1994-12-01 2003-03-19 Intel Corporation Ein mikroprozessor mit mulitplizierungsopeeration
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
US5940859A (en) 1995-12-19 1999-08-17 Intel Corporation Emptying packed data state during execution of packed data instructions
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
US5687336A (en) 1996-01-11 1997-11-11 Exponential Technology, Inc. Stack push/pop tracking and pairing in a pipelined processor

Patent Citations (2)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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
TW345649B (en) 1998-11-21
GB9811430D0 (en) 1998-07-22
GB2326494A (en) 1998-12-23
GB2326494B (en) 2000-08-23
DE19681660T1 (de) 1998-10-29
ZA9610677B (en) 1997-06-24
WO1997022924A1 (en) 1997-06-26
KR100286416B1 (ko) 2001-04-16
KR20000064489A (ko) 2000-11-06
AU1430597A (en) 1997-07-14
HK1016711A1 (en) 1999-11-05
US5701508A (en) 1997-12-23
US6170997B1 (en) 2001-01-09

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
DE112018000848T5 (de) Registerkontextwiederherstellung auf der Grundlage der Wiedergewinnung von Umbenennungsregistern
DE112006002237B4 (de) Verfahren zur selbstinitiierenden Synchronisierung in einem Computersystem
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
DE10296798B4 (de) SMM-Lader und -Ausführungsmechanismus für Komponentensoftware für mehrere Architekturen
DE69330889T2 (de) System und Verfahren zur Änderung der Namen von Registern
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
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

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