DE19983870B4

DE19983870B4 - Berechnung impliziter Datentypbits für Simd-Operationen

Info

Publication number: DE19983870B4
Application number: DE19983870T
Authority: DE
Inventors: Sivakumar Sunnyvale Makineni; Snnhyuk Campbell Kimn; Gautman B. Sunnyvale Doshi; Roger A. Beaverton Golliver
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1998-12-30
Filing date: 1999-12-08
Publication date: 2005-05-19
Anticipated expiration: 2019-12-09
Also published as: US6321327B1; AU4521200A; GB0114436D0; CN1335957A; WO2000041069A1; DE19983870T1; CN1165838C; GB2360110B; GB2360110A

Abstract

Es wird ein Verfahren zum Laden eines gepackten Gleitkommaoperanden in einen Registersatzeintrag, der ein oder mehrere zugeordnete implizite Bits aufweist, zur Verfügung gestellt. Der gepackte Gleitkommaoperand enthält mehrere Teiloperanden. Signifikanden- und Exponentenbits für jeden Teiloperanden werden in zugehörige Felder des Registereintrags kopiert, und die Exponentenbits werden überprüft, um zu bestimmen, ob der Teiloperand normiert ist. Ein dem Teiloperanden entsprechendes implizites Bit wird gesetzt, wenn der Teiloperand normiert ist.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen gepackter Gleitkommaoperanden mit jeweils zumindest zwei Teiloperanden an Gleitkommaausführungseinheiten, die wenigstens eine skalare Gleitkommaausführungseinheit und eine Vektorgleitkommaausführungseinheit umfassen, wobei die skalare Gleitkommaausführungseinheit an eine Verarbeitung von Operanden in einem skalaren Gleitkommaoperandenformat angepaßt ist und die Vektorgleitkommaausführungseinheit an eine Verarbeitung von Teiloperanden eines gepackten Operanden in dem Teiloperandenformat angepaßt ist, wobei der gepackte Gleitkommaoperand in einen Registersatzeintrag geladen wird, wobei der Registersatzeintrag so ausgebildet ist, daß er entweder eines gepackten Gleitkommaoperanden oder einen skalaren Gleitkommaoperanden speichern kann, sowie einen Prozessor zur Durchführung eines solchen Verfahrens.

Die Speicherung und Verarbeitung von Gleitkommaoperanden einschließlich der Erzeugung und Speicherung zusätzlicher Tags oder Bits in Zuordnung zu Gleitkommaoperanden ist beispielsweise aus WO 98/57254 oder dem Artikel "Floating Point Data Type Tag" in IBM Technical Disclosure Bulletin, Band 39, Nr. 7, Juli 1996, Seite 265 bekannt.

Prozessorentwickler suchen stets nach Wegen, die Leistung der Mikroprozessoren zu verbessern. Die parallele Verarbeitung mehrerer Operanden schafft einen Weg für einen Gewinn einer zusätzlichen Leistungsfähigkeit bei heutigen, in hohem Maße optimierten Prozessoren. Bei bestimmten üblichen mathematischen Berechnungen und Graphikoperationen werden die gleichen Operationen wiederholt an jeweils einer großen Anzahl von Operanden ausgeführt. Bei einer Matrixmultiplikation beispielsweise werden die Zeilenelemente einer ersten Matrix mit entsprechenden Spaltenelementen einer zweiten Matrix multipliziert und die sich ergebenden Produkte summiert (multipliziere-akkumuliere). Durch Bereitstellung einer geeigneten Einplanung (Scheduling) und von Ausführungsressourcen können Multipliziere-Akkumuliere-Operationen gleichzeitig an mehreren Sätzen von Zeilen-Spalten-Operanden implementiert werden. Diese Lösung ist als Vektorverarbeitung oder Einzel-Befehls-Mehrfach-Datenstrom(SIMD)-Verarbeitung im Unterschied zu skalarer oder Einzel-Befehls-Einzel-Datenstrom(SISD)-Verarbeitung bekannt.

Um SIMD-Operationen effizient zu implementieren, werden die Daten typischerweise an die Ausführungsressourcen in einem "gepackten" Datenformat zur Verfügung gestellt. Ein 64-Bit-Prozessor kann beispielsweise an einem gepackten Datenblock operieren, welcher zwei 32-Bit-Operanden enthält. Bei diesem Beispiel multipliziert ein Vektor-Multipliziere-Akkumuliere-Befehl V-FMA (f₁, f₂, f₃) jeweils ein Paar in einem Register f₁ gespeicherte 32-Bit-Operanden mit einem entsprechenden Paar von im Register f₂ gespeicherten 32-Bit-Einträgen und addiert die sich ergebenden Produkte mit einem Paar von im Register f₃ gespeicherten laufenden Summen (running sums). Mit anderen Worten, die Daten sind in den Registern f₁, f₂ und f₃ in einem gepackten Format gespeichert, das zwei Operanden aus jedem Registereintrag zur Verfügung stellt. Sofern der Prozessor ausreichende Ressourcen aufweist, kann er zwei oder mehr gepackte Datenblöcke, beispielsweise vier oder mehr 32-Bit-Operanden, gleichzeitig verarbeiten. Die 32-Bit-Operanden werden zu verschiedenen Ausführungseinheiten für eine parallele Verarbeitung gelenkt und nachfolgend gegebenenfalls wieder gepackt.

Selbst bei graphik-intensiven und wissenschaftlichen Programmen sind nicht sämtliche Operationen SIMD-Operationen. Ein großer Teil der von Mehrzweckprozessoren ausgeführten Software enthält Befehle, die skalare Operationen ausführen. Das heißt, jedes von einem Befehl spezifizierte Quellregister speichert einen Operanden und jedes von dem Befehl spezifizierte Zielregister empfängt einen Operanden. Bei dem obigen Beispiel könnte ein skalarer Gleitkomma-Mul tipliziere-Akkumuliere-Befehl S-FMA (f₁, f₂, f₃) einen in einem Register f₁ gespeicherten einzelnen 64-Bit-Operanden mit einem in dem Register f₂ gespeicherten entsprechenden 64-Bit-Operanden multiplizieren und das Produkt mit einer in dem Register f₃ gespeicherten laufenden Summe addieren. Jeder von dem S-FMA-Befehl verarbeitete Operand wird der FMAC-Einheit in einem ungepackten Format zur Verfügung gestellt.

Der Registersatz, der Quelloperanden an die Ausführungseinheiten zur Verfügung stellt und Ergebnisse aus diesen empfängt, verbraucht eine beträchtliche Menge der Chipfläche des Prozessors. Die verfügbare Chipfläche ist eine rare Ressource bei den meisten Prozessorchips. Aus diesem Grund enthalten Prozessoren typischerweise einen Registersatz für jeden Hauptdatentyp. Beispielsweise weist ein Prozessor typischerweise einen Gleitkommaregistersatz auf, der sowohl gepackte als auch nicht gepackte Gleitkommaoperanden speichert. Demzufolge werden gepackte und nicht gepackte Operanden so ausgebildet, daß sie in gleich große Registereinträge passen, und zwar trotz der Tatsache, daß ein gepackter Operand zwei oder mehr Teiloperanden enthält.

Die Bereitstellung von Ausführungsressourcen für gepackte und nicht gepackte Operanden erzeugt Leistungs/Kosten-Herausforderungen. Ein Weg zum Bereitstellen einer skalaren und Vektorverarbeitung hoher Leistung besteht darin, separate skalare und Vektorausführungseinheiten einzuschließen. Ein Vorteil dieser Lösung besteht darin, daß die Vektor- und Skalaren Ausführungseinheiten jeweils so optimiert werden können, daß sie Daten in ihrem entsprechenden Format, das heißt gepackt bzw. ungepackt, verarbeiten. Das Problem bei dieser Lösung besteht darin, daß die zusätzlichen Ausführungseinheiten Siliziumchipfläche verbrauchen, welche eine relativ kostbare Ressource ist.

Zusätzlich zur Bereitstellung geeigneter Ausführungsressourcen müssen Hochleistungsprozessoren Mechanismen zum effizienten Übertragen von sowohl gepackten als auch ungepackten Operandendaten enthalten. Diese Mechanismen umfassen solche, die Operandendaten aus der Speicherhierarchie des Prozessors, beispielsweise den Caches, zu dem Registersatz übertragen, und solche, die Operandendaten aus dem Registersatz zu den Ausführungsressourcen übertragen.

Aufgabe der Erfindung ist es, sowohl gepackte als auch skalare Gleitkommaoperanden zur Schonung von Chipflächen-Ressourcen mit einer geringen Anzahl von Verarbeitungseinheiten und Registern bei hoher Geschwindigkeit zu verarbeiten.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Patentanspruchs 1, sowie einen Prozessor mit den Merkmalen des Patentanspruchs 6 gelöst.

Es wird ein System geschaffen, das eine effiziente Verarbeitung eines Gleitkommaoperanden unterstützt, indem ein implizites Bit für den Operanden "auf dem Wege", das heißt dann, wenn der Operand in einen Registersatzeintrag geladen wird, gesetzt wird.

Gemäß der vorliegenden Erfindung wird ein Gleitkommaoperand zum Laden in einen Registersatzeintrag wiedergewonnen (gelesen). Ausgewählte Bits des Gleitkommaoperanden werden überprüft, und es wird ein dem Registersatzeintrag zugeordnetes implizites Bit gesetzt, wenn die ausgewählten Bits sich in einem ersten Zustand befinden.

Bei einem Ausführungsbeispiel der Erfindung ist der Gleitkommaoperand ein gepackter Operand, der zwei oder mehr Teiloperanden enthält, und der Registersatzeintrag enthält ein implizites Bit für jeden Teiloperanden. Das implizite Bit für einen Teiloperanden wird gesetzt, wenn die ausgewählten Bits anzeigen, daß der Teiloperand normiert ist.

Die vorliegende Erfindung ermöglicht somit, daß der Normiert/Nicht-normiert-Status eines Operanden bestimmt wird, wenn der Operand in den Registersatz geladen wird, und er über ein dem zugehörigen Registersatzeintrag zugeordnetes implizites Bit verfolgt wird. Dies beseitigt die Notwendigkeit für eine Status-Bestimmungslogik in dem Operandenliefermodul, welcher den Operanden aus dem Registersatz an die Ausführungseinheit überträgt. Da das Operandenliefermodul auf einem kritischen (Umgehungs)pfad für die Ausführungseinheit liegt, kann die Prozessorleistung signifikant verbessert werden.

Vorteilhafte und/oder bevorzugte Weiterbildungen der Erfindung sind in den Unteransprüchen gekennzeichnet.

Die vorliegende Erfindung kann unter Bezugnahme auf die folgenden Zeichnungen verstanden werden, in welchen gleiche Elemente durch gleiche Nummern angezeigt sind. Diese Zeichnungen werden zur Verfügung gestellt, um ausgewählte Ausführungsbeispiele der vorliegenden Erfindung zu veranschaulichen, und sollen nicht den Umfang der Erfindung einschränken.
1 ist eine Blockdarstellung eines Gleitkommaausführungssystems gemäß der vorliegenden Erfindung.
2A und 2B stellen die Bitfelder für nicht gepackte bzw. gepackte Operanden in einem Eintrag des in 1 gezeigten Registersatzes dar.
3 ist eine Blockdarstellung, die die Operation des Operandenliefermoduls an einem gepackten Operanden darstellt.
4 ist ein Schaltbild eines Ausführungsbeispiels des Operandenliefersystems, das in 1 gezeigt ist.
5 ist ein Schaltbild eines Ausführungsbeispiels des Ausgabekonvertierungsmoduls, das in 1 gezeigt ist.
Die folgende Diskussion führt zahlreiche spezielle Details aus, um ein besseres Verständnis der Erfindung zu erreichen. Fachleute, die den Vorteil dieser Offenbarung haben, werden jedoch erkennen, daß die Erfindung ohne diese speziellen Details ausgeführt werden kann. Darüber hinaus werden verschiedene gut bekannte Verfahren, Prozeduren, Komponenten und Schaltungen nicht im Detail beschrieben, um die Aufmerksamkeit auf die Merkmale der vorliegenden Erfindung zu lenken.
Prozessorarchitekturen spezifizieren typischerweise ein Format zum Speichern von Daten in chipeigenen Ressourcen, wie beispielsweise Registersätzen. Dieses Registersatzformat wird ausgewählt, um die verschiedenen von den Ausführungsressourcen des Prozessors behandelten Datentypen sowie irgendwelche Hilfsinformationen, die zum Verarbeiten der Daten verwendet werden, unterzubringen. Die unterzubringenden Datentypen können beispielsweise solche sein, die von dem IEEE 754-1985, dem IEEE-Standard für binäre Gleitkommaarithmetik, spezifiziert werden. Ein Registersatzformat unterstützt die effiziente Verarbeitung, indem Operandendaten in einem Format gespeichert werden, auf das einfach zugegriffen und das durch die Verarbeitungsressourcen verarbeitet werden kann.
Für eine skalare Verarbeitung wird jeder Operand als nicht gepackter Operand in dem Registersatzformat gespeichert. Hier bezieht sich "nicht gepackt" auf ein Datenformat, daß es nur einem Operanden gestattet, durch Daten in einem Registersatzeintrag repräsentiert zu werden. Beispielsweise könnte ein Prozessor einen nicht gepackten Operanden einfacher Genauigkeit, einen nicht gepackten Operanden doppelter Genauigkeit oder einen nicht gepackten Operanden doppelter erweiterter Genauigkeit pro Registersatzeintrag in dem Registersatzformat des Prozessors aufnehmen. Für eine Vektorverarbeitung werden mehrere Teiloperanden in einem gepackten Operanden zur Verfügung gestellt, der in einen einzigen Registersatzeintrag paßt. Das Aufnehmen gepackter und nicht gepackter Operanden in einem Registereintrag einer Größe bedeutet, daß die Operanden auf verschiedene Weise auf den Registereintrag abgebildet werden. Die verschiedenen Abbildungen können sich in den Ressourcen wiederspiegeln, die die Operanden beispielsweise aus einem Cache zu dem Registersatz übertragen, und solche Ressourcen, die Operanden aus dem Registersatz zu den Ausführungsressourcen übertragen.
Die verschiedenen Operandenformate für Vektor- und skalare Operationen können sich darüber hinaus in den Ausführungsressourcen selbst wiederspiegeln. Beispielsweise kann ein gepackter Operand, der zwei 32-Bit-Teiloperanden aufweist, unter Verwendung von zwei 32-Bit-Ausführungseinheiten verarbeitet werden. Ein nicht gepackter Operand in demselben System kann als Einzel-64-Bit-Operand durch einen 64-Bit-Ausführungseinheit verarbeitet werden. Bei diesem Beispiel werden drei verschiedene Ausführungseinheiten, zwei 32-Bit-Vektorausführungseinheiten und eine 64-Bit-Skalarausführungseinheit, für jede Ausführungspipeline zur Verfügung gestellt, aber es werden stets nur zwei Operanden parallel durch die Pipeline verarbeitet. Die zusätzliche Ausführungseinheit verbraucht wertvolle Siliziumchipfläche und Energie.
Eine Alternative zum Bereitstellen von zwei Vektorausführungseinheiten besteht darin, die Skalarausführungseinheit so zu modifizieren, daß sie sowohl skalare als auch Vektoroperanden verarbeitet. Diese Lösung beseitigt die Notwendigkeit für eine der Vektorausführungseinheiten. Jedoch kann das Modifizieren der Skalareinheit auf diese Weise ihre Leistung bei nicht gepackten Operanden verschlechtern.
Die vorliegende Erfindung schafft ein System, das Daten, die in gepackten und nicht gepackten Formaten zur Verfügung gestellt werden, effizient verarbeitet, ohne signifikant die Siliziumchipfläche des Prozessors zu erhöhen oder die Leistung des Prozessors bei nicht gepackten Daten zu verschlechtern. Ein Ladekonvertierungsmodul bestimmt implizite Bits für die Teiloperanden eines gepackten Operanden "auf dem Wege", beispielsweise dann, wenn der gepackte Operand in einen Eintrag des Registersatzes aus einem Speicherplatz, wie beispielsweise einem Cache, geladen wird. Die impliziten Bits werden dem Registersatzeintrag zugeordnet, und sie zeigen an, daß der zugehörige Teiloperand normiert, nicht normiert oder gleich Null (normierter Status) ist. Implizite Bits können darüber hinaus für nicht gepackte Operanden bestimmt werden, obwohl sie für eine nachfolgende Verarbeitung dieser Operanden nicht benötigt werden.
Wenn ein Befehl auf den Registersatzeintrag Bezug nimmt, konvertiert ein Operandenliefermechanismus einen Teiloperanden aus einem gepackten Operanden in ein Format, das für ei ne Verarbeitung durch eine Skalarausführungseinheit geeignet ist. Das Operandenliefersystem kann eine Operandenkonvertierung durch Bit-Steuerung oder Bit-Lenkung implementieren, um ein Belasten des Systems mit zusätzlichen Logikgattern zu vermeiden. Dies reduziert signifikant den Einfluß der Operandenkonvertierung auf die Leistung des Systems, während es die Leistung der Skalarausführungseinheit an nicht gepackten Daten bewahrt.
Bei einem Ausführungsbeispiel der vorliegenden Erfindung arbeitet die Skalarausführungseinheit in Verbindung mit einer Vektorausführungseinheit, um gepackte Operanden zu verarbeiten. Der konvertierte Operand und ein nicht konvertierter Teiloperand werden der Skalar- bzw. der Vektorausführungseinheit zur Verarbeitung zur Verfügung gestellt. Bei einem Ausführungsbeispiel der Erfindung umfaßt der Operandenliefermechanismus Bit-Steuerungs- oder Bit-Lenkungs-Leitbahnen (bit-steering traces) und Inverter, die einen der Teiloperanden in ein Skalarformat konvertieren, ohne die Ausführungsressourcen signifikant zu belasten. Dies wiederum bewahrt die Prozessorleistung bei Skalaroperationen.
Die skalare Ausführungseinheit kann ein Gleitkomma-Multipliziere-Akkumuliere-Modul (FMAC – Floating-Point Multiply Accumulate) sein, das zum Verarbeiten eines nicht gepackten Operanden in einem Registersatzformat (RFF – Register File Format) optimiert ist. Die Vektorausführungseinheit kann eine FMAC-Einheit sein, die zum Verarbeiten eines von einem gepackten Operanden in einem gepackten Datenformat (PDF – Packed Data Format) zur Verfügung gestellten Teiloperanden optimiert ist. Das Operandenliefermodul kann einen Multiplexer enthalten, der einen zusätzlichen Anschluß aufweist, um Bit-Umlenk-Leitbahnen (bit resteered traces) an die skalare Ausführungseinheit zu liefern, sowie einen Inverter zum Modifizieren ausgewählter Bits des Teiloperanden. zur Verarbeitung als nicht gepackter Operand.
1 ist eine Blockdarstellung eines Gleitkommasystems 100, das zum Implementieren der vorliegenden Erfindung geeignet ist. System 100 enthält einen Gleitkommaregistersatz 110, ein Operandenliefermodul 120, ein primäres FMAC 130, ein sekundäres FMAC 140, ein Ausgabekonvertierungsmodul 150 und ein Ladekonvertierungsmodul 160. Außerdem ist ein Cache 170 zum Bereitstellen von Operandendaten an den Registersatz 110 über das Ladekonvertierungsmodul 160 gezeigt. Der Cache 170 stellt eine Struktur in einem hierarchischen Speichersystem dar, die Daten zur Verarbeitung durch das Gleitkommasystem 100 und andere (nicht gezeigte) Prozessorressourcen speichert. Daten werden typischerweise in dem Speichersystem in den Datenformaten gespeichert, die von dem oben erörterten IEEE-Gleitkommastandard vorgeschrieben sind.
Bei dem offenbarten Ausführungsbeispiel des Systems 100 verarbeitet das primäre FMAC 130 nicht gepackte Operanden in einem ("nicht gepackten") Registersatzformat. Das sekundäre FMAC 140 verarbeitet Teiloperanden eines gepackten Operanden. Das Operandenliefermodul 120 koppelt Daten aus dem Registersatz 110 zu den FMACs 130 und 140 in den richtigen Formaten.
Bei dem offenbarten Ausführungsbeispiel des Systems 100 enthält der Registersatz 110 mehrere Registereinträge 112. Bei einem Ausführungsbeispiel weist jeder Eintrag 112 ein zugeordnetes implizites Bit 114 auf, welches gesetzt werden kann, um anzuzeigen, ob in dem zugehörigen Registereintrag 112 gespeicherte Daten normiert sind. Implizite Bits werden beispielsweise in dem IEEE-Standard 754 definiert. Ein implizites Bit kann mit einem Teiloperanden aus einem gepackten Operanden kombiniert werden, um den Operanden zur Verarbeitung zu charakterisieren. Beispielsweise kann ein implizites Bit gesetzt werden, um anzuzeigen, daß Daten in normierter Form vorliegen.
Bei skalaren Operationen stellt das Operandenliefermodul 120 einen nicht gepackten Gleitkommaoperanden aus dem Registersatz 110 an das primäre FMAC 130 zur Verfügung. Der nicht gepackte Operand wird in dem Registersatz 110 in einem Registersatzformat gespeichert. Bei Vektoroperationen ge winnt das Operandenliefermodul 120 einen gepackten Operanden aus dem Registersatz 110, konvertiert einen Teiloperanden in einen nicht gepackten Operanden und stellt ihn dem primären FMAC 130 zur Verfügung. Der zweite Teiloperand wird dem sekundären FMAC 140 zur Verfügung gestellt. Der primäre FMAC 130 wird somit von Vektor- und skalaren Operationen gemeinsam benutzt, während das sekundäre FMAC 140 die zusätzliche Ausführungsressource für Vektoroperationen zur Verfügung stellt.
Von den FMACs 130 und 140 erzeugte Ergebnisse werden zum Ausgabekonvertierungsmodul 150 für eine Rekombination zu einem gepackten Datenformat weitergekoppelt. Bei einem Ausführungsbeispiel der Erfindung koppelt eine Umgehung 160 Ausgabedaten aus dem primären FMAC 130 vor dem erneuten Packen zu dem Operandenliefermodul 120. Die herumgeleiteten Daten können einer zusätzlichen Verarbeitung durch das primäre FMAC 130 unterzogen werden, ohne daß sie durch das Konvertierungsmodul 150 zunächst neu gepackt und nachfolgend durch das Operandenliefermodul 120 entpackt werden. Diese Umgehungsschleife (bypass loop) entfernt die Eingangskonvertierung (von gepackte in nicht gepackte Daten) aus dem Umgehungspfad.
Das gezeigte System 100 weist eine einzige Gleitkommapipeline auf, aber die vorliegende Erfindung ist nicht auf Einzelpipelinesysteme eingeschränkt. Sie kann in einer oder in mehreren zusätzlichen Pipelines repliziert werden, um superskalare Gleitkomma-SIMD-Operationen zur Verfügung zu stellen. Das heißt, es können zwei oder mehr Vektorbefehle parallel verarbeitet werden. Allgemein ausgedrückt: Fachleute erkennen, daß die vorliegende Erfindung in Gleitkommasystemen implementiert werden kann, die von dem System 100 in ihrer Konfiguration abweichen.
2A zeigt ein Ausführungsbeispiel eines nicht gepackten Operanden 200 in einem Registersatzformat ("RFF-Operand), der für eine Verwendung bei der vorliegenden Erfindung geeignet ist. Der RFF-Operand 200 enthält ein Signifi kandenfeld 210, ein Exponentenfeld 220 und ein Vorzeichenfeld 230. Bei einem Ausführungsbeispiel der Erfindung weist das Signifikandenfeld 210 64 Bits, das Exponentenfeld 220 17 Bits und das Vorzeichenfeld 230 1 Bit auf.
2B zeigt ein Ausführungsbeispiel eines gepackten Operanden 250 in einem gepackten Datenformat ("PDF-Operand"), der für eine Verwendung bei der vorliegenden Erfindung geeignet ist. Das offenbarte Ausführungsbeispiel des PDF-Operanden 250 umfaßt einen ersten und einen zweiten Teiloperanden 260(a) bzw. 260(b). In der folgenden Diskussion wird der Index fortgelassen, solange er nicht erforderlich ist, um einen bestimmten Teiloperanden 260 zu unterscheiden. Ein Block ungenutzter Bits 270 ist ebenfalls in dem PDF-Operanden 250 gezeigt. Ungenutzte Bits 270 werden zu den Teiloperanden 260 hinzugefügt, um den Registersatzeintrag aufzufüllen. Jeder Teiloperand 260 enthält ein Mantissenfeld 262, ein Exponentenfeld 264 und ein Vorzeichenfeld 266. Bei einem Ausführungsbeispiel ist das Mantissenfeld 262 23 Bits breit, das Exponentenfeld 264 8 Bits breit und das Vorzeichenfeld 266 1 Bit breit. Bei dem offenbarten Ausführungsbeispiel ist jeder Teiloperand in einem Gleitkommaformat einfacher Genauigkeit, wie es beispielsweise in dem IEEE-Standard 754-1985 spezifiziert ist.
In den 2A und 2B sind außerdem implizite Bits 114 gezeigt, welche jedem Registersatzeintrag 112 (1) zugeordnet sind. Die impliziten Bits 114 können verwendet werden, um anzuzeigen, ob ein Teiloperand gleich Null oder nicht normiert ist. Bei einem Ausführungsbeispiel des FP-Registersatzes 110 können die impliziten Bits bestimmt werden, wenn die Daten in den Registereintrag 112 des Registersatzes 110 eingeschrieben werden, das heißt "auf dem Wege". Dies beseitigt das Erfordernis für eine zusätzliche Logik in dem Operandenliefermodul 120 zum Bestimmen des normierten/nicht-normierten Status eines Operanden, welche nur die Verarbeitung von Vektoroperanden verlangsamen würde. Beispielsweise würde das Bewerten des normierten/nicht normierten Status eines Teiloperanden bei der Lieferung zu dem FMAC 140 ein ODER-Gatter in einem kritischen Pfad des Operandenliefersystems 120 erfordern.
Bei Registersatzeinträgen 112, die nicht gepackte und gepackte Operanden gemäß den 2A und 2B speichern, werden implizite Bits 114, z. B. die Bits 82 und 83, wie folgt gesetzt, wenn die Daten in den Registersatz 110 eingeschrieben werden:
WENN (DATEN [62:55] = '0::8), DANN DATEN [83] = '0, SONST '1
WENN (DATEN [30:23] = '0::8), DANN DATEN [82] = '0, SONST '1.
Hier zeigen '1 und '0 eine binäre Eins bzw. eine binäre Null an.
Bei einem Ausführungsbeispiel des Systems 100 (1) kann das Ladekonvertierungsmodul 160 die obigen Operationen unter Verwendung eines Paars von 8-Eingangs-ODER-Gattern implementieren. Ein Ausführungsbeispiel des Ladekonvertierungsmoduls 160 enthält beispielsweise Leitbahnen (traces), die Exponenten-, Signifikanden- und Vorzeichenbits aus einem Eintrag des Cache 170 zu ihren entsprechenden Bitfeldern in einem Zieleintrag 112 (2) des Registersatzes 110 übertragen. Die Eingänge jedes ODER-Gatters sind mit einem der Exponentenbit-Leitbahnen (traces) eines der Teiloperanden gekoppelt, und der Ausgang des ODER-Gatters ist mit dem impliziten Bit, das den Teiloperanden zugeordnet ist, gekoppelt. Bei diesem Ausführungsbeispiel wird das implizite Bit auf Eins gesetzt, sofern eines der Exponentenbits des Teiloperanden ungleich Null ist.
Implizite Bits sind für das Operandenliefermodul 120 verfügbar, um Teiloperanden 260 in einem für die Verarbeitung geeigneten Format zur Verfügung zu stellen. Beispielsweise weist der Teiloperand 260 ein Mantissenfeld 262 auf, das 23 Bits aufnimmt. Ein 24-Bit-Signifikand kann gebildet werden, indem das zugeordnete implizite Bit zu der 23-Bit-Mantisse als am höchsten bewertetes Bit hinzugefügt wird. Bei dem offenbarten Ausführungsbeispiel ist diese Konvertierung bei RFF-Daten 200 nicht erforderlich. Jedoch wird die Logik vereinfacht, indem implizite Bits 114 für jeden in den Registersatz 110 geschriebenen Operanden bestimmt werden und diese ignoriert werden, wenn RFF-Daten 200 verarbeitet werden.
Bei einem Ausführungsbeispiel der Erfindung wird einer der Teiloperanden 260 in einen RFF-Operanden zur Verarbeitung durch das primäre FMAC 130 konvertiert und der andere Teiloperand wird dem sekundären FMAC 140 zur Verarbeitung zur Verfügung gestellt.
3 ist eine schematische Darstellung der von dem Operandenliefermodul 120 implementierten Operationen zum Bereitstellen geeignet formatierter Daten an die FMACs 130 und 140. Bei dem offenbarten Ausführungsbeispiel wird ein implizites Bit 114 mit Daten aus dem Teiloperanden 260(a) kombiniert, welcher in einen RFF-Operanden zur Verarbeitung durch das primäre FMAC 130 konvertiert wird. Ein Merkmal der vorliegenden Erfindung besteht darin, daß dieser Konvertierungsprozeß implementiert werden kann, ohne das primäre FMAC 130 zu belasten und folglich seine Leistung bei skalaren Operationen zu verschlechtern. Der Teiloperand 260(b) wird dem sekundären FMAC 140 zur Verarbeitung zur Verfügung gestellt, welche so optimiert sein kann, daß sie Operanden in dem Teiloperandenformat verarbeitet. Obwohl gezeigt ist, daß das FMAC 130 den oberen Teiloperanden (260(a)) des gepackten Operanden verarbeitet, ist dies nicht erforderlich. Allgemein kann ein beliebiger Teiloperand des gepackten Operanden ausgewählt werden, um zum FMAC 130 gelenkt zu werden.
Bei einem Ausführungsbeispiel der Erfindung führt das Operandenliefermodul 120 die Datenkonvertierung durch eine Bitsteuerung oder Bitlenkung des gepackten Operanden 250 in einen nicht gepackten Operanden 200 aus. Beispielsweise können die Daten aus dem Mantissenfeld 262(a) und dem impliziten Bit 114 (I1) in RFF-Signifikandendaten. (Signifikandenfeld 210) konvertiert werden. In ähnlicher Weise können Daten aus dem Exponentenfeld 264(a) in RFF-Exponentendaten (Exponentenfeld 220) konvertiert werden. Daten aus dem Vor zeichenfeld 266(a) können als RFF-Vorzeichenbits (Vorzeichenfeld 240) abgebildet werden. Die verschiedenen Konvertierungsschritte werden unten unter Verwendung der in Verbindung mit den 2A und 2B vorgesehenen beispielhaften Datenformate detaillierter beschrieben.
Signifikandenkonvertierung
Das Ausführungsbeispiel des Teiloperanden 260(a) umfaßt ein 23-Bit-Mantissenfeld 262(a). Bei einem Ausführungsbeispiel der Erfindung werden die Daten aus dem Mantissenfeld 262(a) in einen RFF-Signifikanden konvertiert, indem: (1) ein zugeordnetes implizites Bit 114 vor die MSB-Position einer 23-Bit-Mantisse aus dem Teilmantissenfeld 262 angehängt wird; und (2) binäre Nullen an das am geringsten bewertete Bit der Mantisse angehängt werden, um einen 64-Bit-RFF-Signifikanden zu bilden. Die Bit-Steuerung oder -lenkung für die Mantisse ist in Tabelle 1 zusammengefaßt, welche die aus dem Registereintrag 112 dem primären (1⁰) FMAC 130 eingegebenen Bits, die Funktion der Bits, die Quelle der Bits für skalare Befehle und die Quelle der Bits für Vektorbefehle anzeigt.
Tabelle 1
Wie oben angemerkt, werden die Operanden auf verschiedene Bits des Registereintrags 112 abgebildet, während diese Ope randen sich den gleichen Fußabdruck im Registersatz 110, das heißt den Registereintrag 112, teilen.
Bei den offenbarten Ausführungsbeispielen von RFF-Operand 200 und PDF-Operand 250 wird das implizite Bit durch Bit 63 bzw. Bit 83 spezifiziert. Um beide Datenformate aufnehmen zu können, kann das Operandenliefermodul 120 einen 2:1-Multiplexer benutzen, um das richtige Quellenbit zur Eingabe in das FMAC 130 auszuwählen. Das Einbringen eines zusätzlichen 2:1-Multiplexers in die Logikkette zwischen dem Registersatz 110 und dem FMAC 130 belastet das Operandenliefermodul 120 und verlangsamt die Lieferung der Daten an. das FMAC 130. Die Belastung verringert die Leistung sowohl für skalare als auch Vektoroperationen. Bei einem Ausführungsbeispiel der Erfindung wird die Bitsteuerung ausgeführt, indem ein zusätzlicher Anschluß an einem vorhandenen 3:1-Multiplexer (4) in dem Operandenliefermodul 120 zum Umleiten von Daten (4:1-Multiplexer der späten Umgehung) zur Verfügung gestellt wird. Dies beseitigt das Erfordernis, einen zusätzlichen Multiplexer dem Datenpfad zwischen dem Registersatz 110 und dem FMAC 130 hinzuzufügen.
Exponentenkonvertierung
Bei dem offenbarten Ausführungsbeispiel werden RFF- und PDF-Exponenten relativ zu verschiedenen Voreinstellungen (Biases) ausgedrückt. Die Differenz zwischen den Biases kann berücksichtigt werden, wenn der PDF-Exponent (Feld 264) in einen RFF-Exponenten (Feld 220) konvertiert wird. Bei einem Ausführungsbeispiel ist der RFF-Bias-Wert gleich FFFFh und der PDF-Bias-Wert ist 7Fh, das heißt der Exponenten-Bias für reelle Zahlen einfacher Genauigkeit in dem IEEE-Standard. Die Differenz zwischen diesen Werten ist FF80h.
Eine Lösung zur Exponentenkonvertierung addiert FF80h zu einem 8-Bit-Exponentenwert in dem PDF-Exponentenfeld 264, um den RFF-Exponenten zu gewinnen. Ein Problem bei dieser Lösung besteht darin, daß sie einen Addierer in dem Datenpfad zwischen dem Registersatz 110 und dem primären FMAC 130 benutzt. Die zusätzliche Gatterverzögerung in dem Operanden liefermodul 120 verschlechtert die Leistung des Systems sowohl für Vektor- als auch für Skalaroperationen. Eine alternative Lösung zum Einstellen des Exponenten-Bias beseitigt das Erfordernis eines Addierers.
Tabelle 2 faßt den zum Konvertieren eines PDF-Exponenten in einen RFF-Exponenten ausgeführten Bias-Einstellungsprozeß für den Fall zusammen, bei dem die Bias-Differenz FF80h ist. Hierbei sind E0 bis E7 die 8 Bits in dem PDF-Exponentenfeld 264(a) und 0 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 ist das binär ausgedrückte FF80h. Wie es in Tabelle 2 gezeigt ist, kann die Exponentenkonvertierung erreicht werden, indem das achte Exponentenbit in dem PDF-Exponentenfeld 264(a) invertiert wird (E7 → E7), es in den nächsten neun Bitpositionen des RFF-Exponenten (Feld 220) repliziert wird und das nicht invertierte achte Bit (E7) zu der am höchsten bewerteten Bitposition des RFF-Exponenten kopiert wird. Diese Operationen können mit einem Invertierer und geeignet geführten Leitbahnen (traces) ausgeführt werden. Es ist kein Addierer erforderlich und der negative Einfluß des Invertierers auf die Leistung des Operandenliefermoduls 120 und des primären FMAC 130 ist nicht signifikant.
Tabelle 2
Die in Tabelle 2 zusammengefaßte Lösung arbeitet nicht für nicht normierte Zahlen einfacher Genauigkeit. Nicht normierte Zahlen können durch den Wert des zugehörigen impliziten Bits 115 identifiziert und die Konvertierung kann unter Verwendung eines Software-Behandlers implementiert werden.
Die oben erörterte Exponentenbitlenkung ist in Tabelle 3 zusammengefaßt.
Tabelle 3
Hierbei zeigt "#" an, daß das Bit invertiert ist. Die Exponentenbits sind für das primäre FMAC 130 beginnend mit dem ersten Bit des Exponentenfeldes nummeriert.
4 stellt ein Ausführungsbeispiel des Operandenliefermoduls 120 dar, das zur Verwendung in einem Prozessor geeignet ist, der eine erste und eine zweite Gleitkommapipeline, pipe0 bzw. pipe1, aufweist. Die vorliegende Erfindung ist nicht auf eine spezielle Anzahl von in dem Prozessor benutzten pipelines eingeschränkt. Das offenbarte Ausführungsbeispiel des Operandenliefermoduls 120 enthält einen 4:1-Multiplexer für eine frühe Umgehung (EBPM – Early Bypass MUX) 410, einen 6:1-Multiplexer für eine mittlere Umgehung (MBPM – Middle Bypass MUX) 420 und einen 4:1-Multiplexer für eine späte Umgehung (LBPM – Late Bypass MUX) 430. Bei den oben beschriebenen beispielhaften Datenformaten konvertiert das Operandenliefermodul 120 einen 32-Bit-Teiloperanden 260(a) von einem gepackten oder PDF-Operanden 250 in einen nicht gepackten 82-Bit-Operanden oder RFF-Operanden 200.
Der EBPM 410 empfängt cache-gespeicherte Daten für pipe0 und pipe1 an den Eingängen A und B. Rückschreibdaten aus dem Backend von pipe0 und pipe1 können in das Operandenliefermodul 120 über die Eingänge C und D eingekoppelt werden. Ein Steuereingang des EBPM 410 wählt Daten, die an den MBPM 420 zur Verfügung gestellt werden sollen, aus einem der Eingänge A, B, C oder D aus. Der MBPM 420 empfängt Daten aus dem EBPM 410 am Eingang E. Umgehungsdaten aus einer Stufe der pipe0 und pipe1 werden an den Eingängen F bzw. G empfangen. Daten aus einem (nicht gezeigten) Ladekonvertierer für pipe0 und pipe1 werden an den Eingängen H bzw. I empfangen, und Daten aus dem Registersatz 110 werden an dem Eingang J empfangen. Ein Steuereingang des MBPM 420 wählt Daten, die an den LBPM 430 zur Verfügung gestellt werden sollen, aus einem der Eingänge E, F, G, H, I oder J aus.
Der LBPM 430 empfängt Umgehungsdaten von einer weiteren Stufe der pipe0, pipe1 an den Eingängen M bzw. N. Der Eingang K des LBPM 430 empfängt Daten aus dem MBPM 420 über den Bitsteuerungsblock 440, welcher die oben beschriebenen Konvertierungen für Vektoroperationen implementiert. Bei dem obigen Beispiel enthält der Bitsteuerungsblock 440 einen Invertierer und Bitsteuerungsleitbahnen zum Umformatieren der Daten aus einem oberen Teiloperanden 269(a) in RFF-Daten. Beispielsweise enthält der Bitsteuerungsblock eine Logik und Leitbahnen zum Konvertieren einer 23-Bit-PDF-Mantisse in einen 64-Bit-RFF-Signifikanden und zum Konvertieren eines 8-Bit-PDF-Exponenten in einen 17-Bit-RFF-Exponenten mit neu eingestelltem Bias. Bei skalaren Operationen empfängt der Eingang L des LBPM 430 Daten aus dem MBPM 420 ohne Eingriff einer Bitsteuerung oder Invertierung. Daten aus einem der Eingänge K oder L werden dem primären FMAC 130 in Abhängigkeit davon zur Verfügung gestellt, ob gepackte oder nicht gepackte Daten verarbeitet werden sollen.
Bei dem Ausführungsbeispiel gemäß 4 werden konvertierte (bit-gelenkte oder bit-gesteuerte) und nicht konvertierte Daten dem primären FMAC 130 zur Verfügung gestellt, indem der richtige Eingang K oder L ausgewählt wird. Dies ermöglicht es den Daten aus dem Registersatz 110 oder irgendeiner der relativ frühen Umgehungsstufen, am LBPM 430 konvertiert zu werden. Bei dem offenbarten Ausführungsbeispiel können die späten Umgehungsdaten an den Eingängen M und N konvertiert werden, indem jeder Eingang mit einem zugehörigen Bitsteuerungsblock 440 repliziert wird. Wenn jedoch umgelenkte Daten an den Eingängen M und N vor der spä ten Umgehung nicht gepackt werden, brauchen sie auch nicht entpackt zu werden. Die Verwendung eines zusätzlichen Anschlusses und des Bitsteuerungsblocks 440 an dem LBPM 430 kann vermieden werden.
Bei einem Ausführungsbeispiels des Operandenliefermoduls 120 können späte Umgehungsdaten dem LBPM 430 über die Umgehung 160 (1) zur Verfügung gestellt werden. Die Umgehung 160 greift die Ausgänge des primären und sekundären FMACs 130 bzw. 140 ab, bevor sie neu in beispielsweise das PDF-Format 250 gepackt werden. Bei diesem Ausführungsbeispiel ist keine zusätzliche Erweiterung des LBPM 430 oder seiner Eingänge für umgelenkte Daten erforderlich.
5 zeigt ein Ausführungsbeispiel des Ausgabekonvertierungsmoduls 150. Das offenbarte Ausführungsbeispiel des Ausgabekonvertierungsmoduls enthält einen primären Ausgangsmultiplexer 510 und einen Bitsteuerungsblock 520. Der primäre Ausgangsmultiplexer 510 enthält Eingänge zum Empfangen der Ergebnisse aus dem primären FMAC 430 und verschiedenen FPU-Ressourcen (FMISC) 154 sowie spezielle Ergebniscodierungen. Bei den Beispieldatenformaten stellt das FMAC 130 ein Ergebnis als nicht gepackten (RFF)-Operanden 200 (82 Bits) sowohl für skalare als auch Vektoroperationen zur Verfügung. In dem letztgenannten Fall kombiniert der Bitsteuerungsblock 520 den nicht gepackten Operanden aus dem primären FMAC 130 mit einem Teiloperanden aus dem sekundären FMAC 140, um einen gepackten Operanden zu bilden.
Die speziellen Codierungen, die dem primären Ausgangsmultiplexer 510 zur Verfügung gestellt werden, zeigen spezielle Ergebnisse, wie beispielsweise Null, unendlich oder eine maximale reelle Zahl (größter darstellbarer Gleitkommawert), in dem Registersatzformat an. Bei den offenbarten Ausführungsbeispielen können diese Codierungen für Vektoroperationen gegebenenfalls unter Verwendung der Bitsteuerungsoperationen, die oben beschrieben wurden, konvertiert werden. Sofern kompliziertere Konvertierungen für Null, unendlich und maximale Real-Ergebnisse erforderlich sind, kön nen sie in früheren Stufen des Operandenliefermoduls 120 implementiert werden, da die erforderlichen Informationen relativ früh in der Gleitkommaausführungspipeline verfügbar sind. Es wird keine zusätzliche Verzögerung in den kritischen Pfad eingebracht.
Bei Vektoroperationen werden die Ergebnisse des primären FMAC 130 und des sekundären FMAC 140 neu gepackt, um die Ergebnisse als PDF-Operanden zur Verfügung zu stellen. Bei dem offenbarten Ausführungsbeispiel empfangen die unteren 32 Bits des 82-Bit-Eintrags das Teiloperandenergebnis aus dem sekundären FMAC 140. Die nächsten höher bewerteten 32 Bits werden über Bitsteuerung durch das ungepackte Operandenergebnis aus dem primären FMAC 130 zur Verfügung gestellt. Die oberen 18 Bits empfangen implementierungsabhängige Konstanten, bei dem offenbarten Ausführungsbeispiel beispielsweise sind diese '1 & 1003Eh.
Der von dem primären FMAC 130 zur Verfügung gestellte nicht gepackte (RFF-)Exponent hat einen überschüssigen Bias von FF80h in Bezug auf das für Teiloperanden 260 in dem gepackten Operanden 250 benutzte IEEE-Format einfacher Genauigkeit. Der überschüssige Bias wird von dem nicht gepackten Operandenergebnis subtrahiert, wenn es in ein Teiloperandenergebnis zum Packen konvertiert wird. Bei dem Ausführungsbeispiel kann dies durch Addieren des Zweierkomplements von FF80h zu dem 17-Bit-RFF-Exponenten und Verwendung der unteren 8 Bits des Ergebnisses als Exponent für den Teiloperanden ausgeführt werden. Wie bereits zuvor kann die Konvertierung ohne Belasten der Gleitkommapipeline mit einem zusätzlichen Addierer unter Verwendung der Bitsteuerungsoperation, die in Tabelle 4 dargestellt ist, ausgeführt werden.
Tabelle 4
Wie es in Tabellel 4 gezeigt ist, können die Exponentenbits für den Teiloperanden aus dem nicht gepackten Operanden, der von dem primären FMAC 130 zur Verfügung gestellt wird, ohne Addition abgeleitet werden. Bei dem obigen Beispiel werden sie von den unteren acht Exponentenbits des nicht gepackten Operandenergebnisses, bei dem das achte Bit invertiert wird, zur Verfügung gestellt. Die oberen acht Bits, welche bei der Konvertierungsoperation ignoriert werden, sind in Tabelle 2 nicht gezeigt.
Tabelle 5 faßt die Bitsteuerungsoperationen zusammen, die ein nicht gepacktes Operandenergebnis aus dem primären FMAC 130 mit einem Teiloperandenergebnis aus dem sekundären FMAC 140 packen, um ein gepacktes Operandenergebnis für Vektoroperationen zur Verfügung zu stellen.
Tabelle 5
Hier bezieht sich "CO" auf den Teiloperanden (component Operand), "Ergebnisbits aus 1⁰-FMAC" bezieht sich auf das von dem primären FMAC 130 erzeugte gepackte Operandenergebnis und "Ergebnisbits aus 2⁰-FMAC" bezieht sich auf das von dem sekundären FMAC 130 erzeugte Teiloperandenergebnis.
Für bestimmte von dem FMAC ausgeführte Befehle werden zusätzliche Steuersignale dem FMAC zur Verfügung gestellt, um die Operation der Einheit zu modifizieren. Beispielsweise kann der FMAC verwendet werden, um Gleitkommaoperanden in Ganzzahloperanden zu konvertieren. Die Konvertierung kann bei sowohl Vektor- als auch skalaren Operanden angewendet werden. Die für die Vektor- und skalaren Fälle erforderliche Bitverschiebung unterscheidet sich, und es wird ein separates Steuersignal zur Verfügung gestellt, um die FMAC-Operation entsprechend einzustellen. Die oben erörterten Multipliziere-Akkumuliere-Operationen, beispielsweise die in Matrixmultiplikationen und Koordinatentransformationen enthaltenen, werden ohne derartige interne Modifikationen der FMAC-Einheiten verarbeitet.
Es wurde somit ein System zum Verarbeiten von SIMD- oder Vektoroperationen unter Verwendung einer Kombination skalarer und Vektorausführungseinheiten geschaffen. Die Menge zusätzlicher Ausführungshardware, die zu dem System hinzugefügt werden muß, ist verringert, während die Leistung der skalaren Ausführungshardware bewahrt wird. Das System benutzt einen Registersatz, der ein implizites Bit für jeden Teiloperanden eines gepackten Operanden aufweist. Eine Ladekonvertierungseinheit enthält eine Logik zum Testen jedes Teiloperanden hinsichtlich eines nicht normierten/Null-Status während der Ladeoperation und zum entsprechenden Setzen des zugehörigen impliziten Bits. Eine skalare und eine Vektorausführungseinheit werden für jede Pipeline in dem System zur Verfügung gestellt. Ein Operandenliefermodul liefert Daten aus einem Registersatz zu den skalaren und Vektorausführungseinheiten. Bei SIMD-Operationen gewinnt der Operandenliefermodul einen gepackten Operanden aus dem Registersatz, konvertiert einen Teiloperanden in einen nicht gepackten Operanden mit Hilfe einer Bitsteuerung oder Bitlenkung und stellt den nicht gepackten Operanden der skalaren Ausführungseinheit zur Verarbeitung zur Verfügung. Ein zweiter Teiloperand wird der Vektorausführungseinheit zur Verfügung gestellt. Die Bitlenkungslogik enthält Leitbahnlenkungen und Invertierer, welche einen minimalen Einfluß auf die Leistung des Systems sowohl bei skalaren als auch Vektoroperationen haben.

Claims

Verfahren zum Bereitstellen gepackter Gleitkommaoperanden (250) mit jeweils zumindest zwei Teiloperanden (260) an Gleitkommaausführungseinheiten, die wenigstens eine skalare Gleitkommaausführungseinheit (130) und eine Vektorgleitkommaausführungseinheit (140) umfassen, wobei die skalare Gleitkommaausführungseinheit (130) an eine Verarbeitung von Operanden in einem skalaren Gleitkommaoperandenformat angepaßt ist und die Vektorgleitkommaausführungseinheit (140) an eine Verarbeitung von Teiloperanden eines gepackten Operanden in dem Teiloperandenformat angepaßt ist, wobei a) der gepackte Gleitkommaoperand in einen Registersatzeintrag (112) geladen wird, wobei der Registersatzeintrag (112) so ausgebildet ist, daß er entweder einen gepackten Gleitkommaoperanden (250) oder einen skalaren Gleitkommaoperanden (200) speichern kann, wobei beim Laden für jeden Teiloperanden ein implizites Bit gesetzt wird, wenn sich ausgewählte Bits (264) des Teiloperanden in einem ersten Zustand befinden und die impliziten Bits (114) in Zuordnung zu dem Registersatzeintrag (112) gespeichert werden; und b) der gepackte Gleitkommaoperand bei Bedarf aus dem Registersatzeintrag an die Gleitkommaausführungseinheiten (130, 140) geliefert wird, indem: b1) beim Liefern wenigstens einer (260a) der Teiloperanden (260) mit seinem zugehörigen impliziten Bit in ein skalares Gleitkommaoperandenformat konvertiert und an die skalare Gleitkommaausführungseinheit (130) geliefert wird und b2) wenigstens ein weiterer (260b) der Teiloperanden (260) ohne Konvertierung an eine der Vektorgleitkommaausführungseinheiten (140) geliefert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Teiloperanden durch ein Operandenliefermodul (120) an die Gleitkommaausführungseinheiten (130, 140) geliefert werden.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß der wenigstens eine Teiloperand (260a), der in ein skalares Gleitkommaoperandenformat konvertiert wird, mit Hilfe einer Bitlenkung in dem Operandenliefermodul (120) konvertiert wird.
Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die dem Exponenten jedes Teiloperanden entsprechenden Bits getestet werden, indem bestimmt wird, ob der Exponent gleich Null ist.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß bestimmt wird, ob der Exponent gleich Null ist, indem eine logische ODER-Verknüpfung der Exponentenbits des jeweiligen Teiloperanden gebildet wird.
Prozessor zur Durchführung eines Verfahrens nach einem der Ansprüche 1-5, mit: einem Daten-Cache (170), einem Gleitkommaregistersatz (110) mit mehreren Einträgen (112), wobei ein Eintrag (112) jeweils so ausgebildet ist, daß er entweder einen gepackten Gleitkommaoperanden (250) mit wenigstens einem ersten und einem zweiten Teiloperanden oder einen skalaren Gleitkommaoperanden (200) speichern kann, wobei jeder Eintrag (112) ein erstes und ein zweites implizites Bit (114) aufweist, um im Falle des Speicherns eines gepackten Gleitkommaoperanden jeweils einen Zustand des ersten bzw. des zweiten Teiloperanden (260) anzuzeigen, einem Ladekonvertierer (160) zum Kopieren von Signifikanten- und Exponenten-Bits für den ersten und den zweiten Teiloperanden (260) eines gepackten Gleitkommaoperanden aus dem Daten-Cache (170) in einen der Registersatzeinträge (112), zum Testen der Exponentenbits des ersten und des zweiten Teiloperanden und zum entsprechenden Setzen des ersten bzw. zweiten impliziten Bits (114) derart, daß sie führende Bits des ersten und des zweiten Teiloperanden darstellen; wenigstens einer ersten und einer zweiten Gleitkommaausführungseinheit (130, 140), wobei wenigstens eine (130) der Gleitkommaausführungseinheiten an eine Verarbeitung von Operanden in einem skalaren Gleitkommaoperandenformat angepaßt ist und wenigstens eine weitere (140) der Gleitkommaausführungseinheiten an eine Verarbeitung der Teiloperanden des gepackten Gleitkommaoperanden in dem ursprünglichen Teiloperandenformat angepaßt ist, und einem Operandenliefermodul (120), das mit dem Registersatz (110) gekoppelt ist, um Teiloperanden eines gepackten Gleitkommaoperanden zu empfangen, und das wenigstens einen der Teiloperanden (260a) mit seinem zugehörigen impliziten Bit empfängt und in ein skalares Gleitkommaoperandenformat konvertiert und an die an eine Verarbeitung von Operanden in einem skalaren Gleitkommaoperandenformat angepaßte Gleitkommaausführungseinheit (130) liefert.
Prozessor nach Anspruch 6, dadurch gekennzeichnet, daß das Operandenliefermodul eine Bitlenkungsblock (440) zum Konvertieren eines an einem Eingang des Bitlenkungsblocks (440) empfangenen Teiloperanden mit impliziten Bit in einen am Ausgang ausgegebenen Operanden in einem skalaren Gleitkommaoperandenformat aufweist.
Prozessor nach Anspruch 7, dadurch gekennzeichnet, daß das Operandenliefermodul (120) einen Multiplexer (430) aufweist, der an einem Eingang mit dem Ausgang des Bitlenkungsblocks (440) gekoppelt ist, an einem weiteren Eingang einen Operanden in dem vom Registersatz ausgegebenen Format empfängt und an wenigstens einem weiteren Eingang Operanden aus einem Umgehungspfad vom Ausgang der Gleitkommaausführungseinheit empfängt.
Prozessor nach einem der Ansprüche 6 bis 8, dadurch gekennzeichnet, daß der Ladekonvertierer ODER-Gatter aufweist, die die Exponentenbits der Teiloperanden beim Laden in den Re gistersatz einer ODER-Verknüpfung unterziehen, um dabei für jeden Teiloperanden ein implizites Bit zu bestimmen.