DE19735350A1 - Einzelbefehl-Mehrdaten-Verarbeitung bei einem Multimedia-Signalprozessor - Google Patents

Description

Diese Erfindung betrifft digitale Signalprozessoren, insbesondere Verfahren zur Parallelverarbeitung von mehreren Datenelementen pro Befehl für "Multimedia"- Funktionen, wie z. B. das Codieren und Decodieren von Video- und Audiodaten.

Programmierbare digitale Signalprozessoren (DSPs) für Multimedia-Anwendungen, wie z. B. Echtzeit-Video-Codieren und -Decodieren, erfordern eine beträchtliche Verarbeitungsleistung für die große Menge von Daten, die innerhalb einer begrenzten Zeit verarbeitet werden müssen. Einige Architekturen für digitale Signalprozessoren sind bekannt. Eine Universalarchitektur, wie sie bei den meisten Mikroprozessoren verwendet wird, erfordert typischerweise hohe Betriebsfrequenzen, um einen DSP mit einer aus reichenden Rechenleistung zum Echtzeit-Video-Codieren oder -Decodieren zur Verfügung zu stellen. Dies macht einen solchen DSP teuer.

Ein Prozessor für sehr lange Befehlswörter (VLIW-Prozessor) ist ein DSP mit sehr vielen Funktionseinheiten, von denen die meisten verschiedene, relativ einfache Aufgaben ausführen. Ein einziger Befehl für einen VLIW-DSP kann 128 Bytes oder länger sein und weist separate Teile auf, die die separaten Funktionseinheiten parallel ausführen. VLIW-DSPs weisen eine hohe Rechenleistung auf, weil viele Funktionseinheiten parallel arbeiten können. VLIW-DSPs sind ebenfalls relativ günstig, weil jede Funktionseinheit relativ klein und einfach ist. Ein Problem der VLIW-DSPs besteht in einer Ineffizienz bei der Handhabung einer Eingangs-/Ausgangs-Steuerung, bei einer Kommunikation mit einem Hauptcomputer und bei anderen Funktionen, die sich selbst nicht für eine parallele Ausführung auf den Funktionseinheiten des VLIW-DSP′s eignen. Zusätzlich unterscheidet sich die VLIW-Software von der herkömmlichen Software und ist schwierig zu entwickeln, weil die Programmierwerkzeuge und die Programmierer, die mit den VLIW-Softwarearchitekturen vertraut sind, selten sind.

Es ist daher Aufgabe der Erfindung einen digitalen Signalprozessor zu vernünftigen Kosten mit einer hohen Rechenleistung und einer vertrauten Programmierumgebung für Multimedia-Anwendungen und ein Verfahren hierfür vorzusehen.

Die vorstehende Aufgabe wird durch den Prozessor nach Anspruch 1 bzw. das Verfahren nach Anspruch 6 gelöst.

Vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen angegeben.

Gemäß einem Aspekt der Erfindung schließt ein digitaler Multimedia-Signalprozessor (Multimedia-DSP) einen Vektorprozessor ein, der Vektordaten (z. B. mehrere Datenelemente pro Operand) verarbeitet, um eine hohe Rechenleistung vorzusehen. Der Prozessor verwendet eine Einzelbefehl-Mehrdaten-Architektur mit einem Befehlssatz vom RISC-Typ (vom Typ für einen Rechner mit einem reduzierten Befehlssatz). Programmierer können sich einfach in die Programmierumgebung des Vektorprozessors einarbeiten, weil sie ähnlich wie die Programmumgebungen von Universal-Prozessoren sind, mit denen die meisten Programmierer vertraut sind.

Der DSP schließt einen Satz von Universal-Vektorregistern ein. Jedes Vektorregister weist eine festgelegte Größe auf, ist aber in einzelne Datenelemente einer vom Nutzer wählbaren Größe unterteilt. Folglich hängt die Anzahl von den in einem Vektorregister gespeicherten Datenelementen von der gewählten Größe für die Elemente ab. Z. B. kann ein 32-Byte-Register in zweiunddreißig 8-Bit-Datenelemente, sechzehn 16-Bit-Datenelemente oder acht 32-Bit-Da­ tenelemente unterteilt sein. Die Wahl der Datengröße und des Datentyps wird durch einen Befehl getroffen, der Daten, die mit dem Vektorregister assoziiert sind, bearbeitet und ein Ausführungsdatenweg für den Befehl führt eine Anzahl von parallelen Operationen durch, die von der durch einen Befehl angezeigten Datengröße abhängen.

Befehle für den Vektorprozessor können als Operanden Vektorregister oder Skalarregister aufweisen und mehrere Datenelemente von Vektorregistern parallel verarbeiten, so daß die Rechenleistung hoch ist. Ein exemplarischer Befehlssatz für einen Vektorprozessor gemäß der Erfindung schließt ein: Coprozessor-Schnittstellen-Operationen; Flußsteuerungsoperationen; Lade-/Speicher-Operationen und Logik-/Arithmetik-Operationen. Die Logik-/Arithmetik-Ope­ rationen schließen Operationen ein, die Datenelemente von einem Vektorregister mit entsprechenden Datenelementen von einem oder mehreren anderen Vektorregistern kombinieren, um die Datenelemente eines resultierenden Datenvektors zu erzeugen. Andere Logik-/Arithmetik-Ope­ rationen mischen verschiedene Datenelemente von einem oder mehreren Vektorregistern oder kombinieren Datenelemente von einem Vektorregister mit skalaren Größen.

Eine Erweiterung der Vektorprozessorarchitektur fügt Skalarregister hinzu, von denen jedes ein skalares Datenelement enthält. Die Kombination von Skalar- und Vektorregistern ermöglicht die Erweiterung des Befehlssatz des Vektorprozessors, so daß dieser Operationen einschließt, die auf parallele Weise jedes Datenelement eines Vektors mit einem skalaren Wert kombinieren. Z. B. multipliziert ein Befehl die Datenelemente eines Vektors mit einem skalaren Wert. Die Skalarregister sehen ebenfalls einen Ort zum Speichern eines einzigen Datenelements vor, das aus einem Vektorregister extrahiert bzw. abgefragt oder darin gespeichert werden soll. Die Skalarregister sind ebenfalls zum Leiten von Informationen zwischen dem Vektorprozessor und einem Coprozessor mit einer Architektur, die nur Skalarregister vorsieht, und für Berechnungen von effektiven Adressen für Lade-/Speicher-Ope­ rationen geeignet.

Gemäß einem anderen Aspekt der Erfindung sind Vektorregister im Vektorprozessor in Bänken bzw. Gruppen organisiert. Jede Bank kann als die "aktuelle" Bank ausgewählt werden, während die andere Bank die "alternative" Bank ist. Ein Bit der "aktuellen Bank" in einem Steuerregister des Vektorprozessors zeigt die aktuelle Bank an. Um die zur Identifizierung eines Vektorregisters notwendige Anzahl von Bits zu verringern, sehen einige Befehle nur eine Registerzahl vor, um ein Vektorregister in der aktuellen Bank zu identifizieren. Lade-/Speicher-Befehle weisen ein zusätzliches Bit auf, um ein Vektorregister von einer der beiden Bänke zu identifizieren. Folglich können, während in der aktuellen Bank Daten verarbeitet werden, Lade-/Speicher-Befehle Daten in die alternative Bank holen. Dies ermöglicht die Software-Pipeline-Verarbeitung für Bildverarbeitungs- und für Graphikverfahren und verringert die Prozessorverzögerungen wenn Daten abgerufen werden, weil Logik-/Arithmetik-Operationen außerhalb der Reihenfolge ausgeführt werden können, wobei Lese-/Speicher-Operationen auf die alternative Registerbank zugreifen. Bei anderen Befehlen ermöglicht die alternative Bank die Verwendung von Doppelgrößen-Vektorregistern, die ein Vektorregister von der aktuellen Bank und ein entsprechendes Vektorregister von der alternativen Bank einschließen. Solche Doppelgrößen-Register können anhand der Befehlssyntax identifiziert werden. Ein Steuerbit im Vektorprozessor kann eingestellt werden, so daß die Vorgabe-Vektorgröße entweder ein oder zwei Vektorregister ist. Die alternative Bank ermöglicht ebenfalls die Verwendung von weniger explizit identifizierten Operanden in der Syntax von komplexen Befehlen, wie z. B. Mischen, Entmischen, Sättigen und bedingte Übertragung, die zwei Quellregister und zwei Zielregister bzw. Bestimmungsregister aufweisen.

Der Vektorprozessor implementiert weiterhin neue Befehle, wie z. B. Quadrupel-Mittelwert, Mischen, Entmischen, paarweises Maximum mit Austauschen und Sättigen. Diese Befehle führen Operationen aus, die bei Multimedia Funktionen, wie Videocodieren und -decodieren, üblich sind und ersetzen zwei oder mehr Befehle, die andere Befehlssätze erfordern würden, um die gleiche Funktion zu implementieren. Demgemäß verbessert der Befehlssatz des Vektorprozessors die Effizienz und die Geschwindigkeit der Programme bei Multimedia-Anwendungen.

Die Erfindung wird nachstehend anhand der Figuren näher erläutert. Es zeigen:

Fig. 1 ein Blockdiagramm eines Multimedia-Prozessors gemäß einem Ausführungsbeispiel der Erfindung,

Fig. 2 ein Blockdiagramm eines Vektorprozessors für den Multimedia-Prozessor von Fig. 1,

Fig. 3 ein Blockdiagramm einer Befehlsabrufeinheit für den Vektorprozessor von Fig. 2,

Fig. 4 ein Blockdiagramm einer Befehlsabrufeinheit für den Vektorprozessor von Fig. 2,

Fig. 5A, 5B und 5C die Stufen der Ausführungs-Pipeline bei einem Register-Register-Befehl, einem Ladebefehl und einem Speicherbefehl für den Vektorprozessor von Fig. 2,

Fig. 6A ein Blockdiagramm für einen Ausführungsdatenweg für den Vektorprozessor von Fig. 2,

Fig. 6B ein Blockdiagramm für ein Registerfile für den Ausführungsdatenweg von Fig. 6A,

Fig. 6C ein Blockdiagramm für Parallelverarbeitungs-Lo­ gikeinheiten für den Ausführungsdatenweg von Fig. 6A,

Fig. 7 ein Blockdiagramm für eine Lade-/Speichereinheit für den Vektorprozessor von Fig. 2 und

Fig. 8 Formate für einen Befehlssatz eines Vektorprozessors gemäß einem Ausführungsbeispiel der Erfindung.

Die Verwendung der gleichen Bezugszeichen bei verschiedenen Figuren zeigt ähnliche oder identische Einrichtungen an.

Fig. 1 zeigt ein Blockdiagramm eines Ausführungsbeispiels eines Multimedia-Signalprozessors 100 (MSP) gemäß einem Ausführungsbeispiel der Erfindung. Der Multimedia-Prozessor 100 schließt einen Verarbeitungskern 105 ein, der einen Universalprozessor 110 und einen Vektorprozessor 120 aufweist. Der Verarbeitungskern 105 ist mit dem Rest des Multimedia-Prozessors 100 über ein Cache-Subsystem 130 verbunden, welches statische Speicher mit wahlfreiem Zugriff 160 und 190 (SRAMs), einen Festwertspeicher 170 (ROM) und eine Cache-Steuerung 180 enthält. Die Cache-Steu­ erung 180 kann den SRAM 160 als einen Befehlscache 162 und einen Datencache 164 für den Prozessor 110 und den SRAM 190 als einen Befehlscache 192 und einen Datencache 194 für den Vektorprozessor 120 konfigurieren.

Der chipintegrierte ROM 170 enthält Daten und Befehle für die Prozessoren 110 und 120 und kann ebenfalls als ein Cache konfiguriert werden. Bei einem exemplarischen Ausführungsbeispiel enthält der ROM 170: Rücksetz- und Initialisierungsprozeduren, Selbsttest-Diagnoseprozeduren, Unterbrechungs- und Ausnahmebedingungsroutinen und Subroutinen für eine "Soundblaster"-Emulation, Subroutinen für eine V.34-Modem-Signalverarbeitung, universelle Telefonfunktionen, 1-Dim- und 3-Dim-Graphiksubroutinen-Bi­ bliotheken und Subroutinen-Bibliotheken für Audio- und Videostandards, wie z. B. MPEG-1, MPEG-2, H.261, H.263, G.728 und G.723.

Das Cache-Subsystem 130 verbindet die Prozessoren 110 und 120 mit zwei Systembussen 140 und 150 und arbeitet sowohl als ein Cache als auch eine Schaltstation für die Prozessoren 110 und 120 sowie die Einrichtungen, die an die Busse 140 und 150 gekoppelt sind. Der Systembus 150 arbeitet bei einer höheren Taktfrequenz als der Bus 140 und ist mit einer Speichersteuereinheit 158, einer lokalen Busschnittstelle 156, einer DMA-Steuereinheit 154 und einer Einrichtungsschnittstelle 152 verbunden, die in dieser Reihenfolge Schnittstellen für einen externen lokalen Speicher, einen lokalen Bus eines Hauptcomputers, direkte Speicherzugriffe und verschiedene Analog-Digital-Wandler sowie Digital-Analog-Wandler vorsehen. Verbunden mit dem Bus 140 sind ein Systemzeitgeber 142, eine UART 144 (eine Anpassungsschaltung zur Umsetzung von paralleler zu serieller Datenübertragung), ein Bitstrom-Prozessor 146 und eine Unterbrechungs-Steuereinheit 148. Die hierin mit eingeschlossenen Patentanmeldungen in Anhang G mit den Titeln "Multiprocessor Operation in a Multimedia Signal Processor" und "Methods and Apparatus for Processing Video Data" beschreiben die Arbeitsweise des Cache-Subsystems 130 und exemplarischer Einrichtungen, auf die die Prozessoren 110 und 120 über das Cache-Subsystem 130 und die Busse 140 und 150 zugreifen, detaillierter.

Die Prozessoren 110 und 120 führen separate Teilprozesse eines Programms aus und sind für eine effizientere Ausführung von ihnen zugeordneten, besonderen Aufgaben strukturell verschieden voneinander. Der Prozessor 110 ist primär für Steuerfunktionen zuständig, wie die Ausführung eines Echtzeit-Betriebssystems und ähnlichen Funktionen, die keine große Zahl von sich wiederholenden Berechnungen benötigen. Demzufolge erfordert der Prozessor 110 keine hohe Rechenleistung und kann unter Verwendung einer herkömmlichen Universal-Prozessorarchitektur implementiert werden. Der Vektorprozessor 120 führt überwiegend das "Zahlenfressen" aus, das sich wiederholende Operationen an Datenblöcken einschließt, die bei der Multimedia-Ver­ arbeitung üblich sind. Für eine hohe Rechenleistung und ein relativ einfaches Programmieren weist der Vektorprozessor 120 eine SIMD-Architektur (eine Einzelbefehl-Mehrdaten-Verarbeitungs-Architektur) auf und bei dem beispielhaften Ausführungsbeispiel sind die meisten Datenwege im Vektorprozessor 120 entweder 288 oder 576 Bits breit, um die Vektordatenverarbeitung zu unterstützen. Zusätzlich schließt der Befehlssatz für den Vektorprozessor 120 Befehle ein, die für Multimediaprobleme besonders geeignet sind.

Bei dem exemplarischen Ausführungsbeispiel ist der Prozessor 110 ein 32-Bit-RISC-Prozessor, der bei 40 MHz arbeitet und mit der Architektur eines ARM7-Prozessors in Übereinstimmung ist, wobei er einen Registersatz einschließt, wie er im ARM7-Standard definiert ist. Eine Architektur und ein Befehlssatz für einen ARM7-RISC-Prozes­ sor ist im "ARM7DM-Data Sheet", Dokument Nummer: ARM DDI 0010G, das von Advance RISC Machines Ltd. erhältlich ist, beschrieben. Das ARM7DM-Datenblatt soll hierdurch durch Bezugnahme in seiner Gesamtheit eingeschlossen werden. Der Anhang A beschreibt die Erweiterung des ARM7-Befehlssatzes beim exemplarischen Ausführungsbeispiel.

Der Vektorprozessor 120 verarbeitet sowohl Vektorgrößen als auch Skalargrößen. Beim exemplarischen Ausführungsbeispiel besteht der Vektordatenprozessor 120 aus einer Pipeline­ verarbeitenden RISC-Maschine, die bei 80 MHz arbeitet. Die Register des Vektorprozessors 120 schließen 32-Bit-Ska­ larregister, 32-Bit-Spezialanwendungsregister, zwei Bänke von 288-Bit-Vektorregistern und zwei Doppelgrößen-Vek­ torakkumulatorregister (von z. B. 576 Bit) ein. Der Anhang C beschreibt den Registersatz für das exemplarische Ausführungsbeispiel des Vektorprozessors 120. Beim exemplarischen Ausführungsbeispiel schließt der Prozessor 120 zweiunddreißig Skalarregister ein, die in den Befehlen durch 5-Bit-Registerzahlen im Bereich von 0 bis 31 identifiziert werden. Es sind ebenfalls vierundsechzig 288-Bit-Vektorregister vorhanden, die in zwei Bänken zu 32 Vektorregistern organisiert sind. Jedes Vektorregister kann durch eine 1-Bit-Bankzahl (0 oder 1) und eine 5-Bit-Vek­ torregisterzahl im Bereich von 0 bis 31 identifiziert werden. Die meisten Befehle greifen nur auf Vektorregister in einer aktuellen Bank zu, wie dies durch ein Vorgabe- Bank-Bit CBANK, das in einem Steuerregister VCSR des Vektorprozessors 120 gespeichert ist, angezeigt wird. Ein zweites Steuerbit VEC64 zeigt an, ob die Vorgabe-Re­ gisterzahlen ein Doppelgrößen-Vektorregister identifizieren, das ein Register von jeder Bank einschließt. Die Syntax der Befehle unterscheidet zwischen Registerzahlen, die ein Vektorregister identifizieren, und Registerzahlen, die ein Skalarregister identifizieren.

Jedes Vektorregister kann in Datenelemente programmierbarer Größe partitioniert bzw. unterteilt werden. Die Tabelle 1 zeigt die Datentypen, die für Datenelemente innerhalb eines 288-Bit-Vektorregisters unterstützt werden.

Tabelle 1

Der Anhang D bietet weitere Beschreibungen der Datengrößen und Datentypen, die durch das exemplarische Ausführungsbeispiel der Erfindung unterstützt werden.

Bei einem int9-Datentyp werden 9-Bit-Bytes hintereinander in ein 288-Bit-Vektorregister gepackt, aber bei den anderen Datentypen wird jedes neunte Bit in einem 288-Bit-Vek­ torregister nicht benutzt. Ein 288-Bit-Vektorregister kann zweiunddreißig 8-Bit- oder 9-Bit-Ganzzahl-Da­ tenelemente (ganzzahlige Datenelemente), sechzehn 16-Bit-Ganz­ zahl-Datenelemente oder acht 32-Bit-Ganzzahl- oder 32-Bit-Gleitkomma-Elemente halten bzw. zwischenspeichern. Zusätzlich können zwei Vektorregister miteinander kombiniert werden, um Datenelemente in einen Doppelgrößenvektor zu packen. Wenn beim exemplarischen Ausführungsbeispiel der Erfindung ein Steuerbit VEC64 in einem Steuer- und Statusregister VCSR eingestellt wird, wird der Vektorprozessor 120 in einen Modus VEC64 gesetzt, in dem die Doppelgröße (576 Bits) die Vorgabegröße der Vektorregister ist.

Der Multimedia-Prozessor 100 weist ebenfalls einen Satz von 32-Bit-erweiterten Registern 115 auf, auf die sowohl durch den Prozessor 110 als auch durch den Prozessor 120 zugegriffen werden kann. Der Anhang B beschreibt den Satz der erweiterten Register und deren Funktion beim exemplarischen Ausführungsbeispiel der Erfindung. Unter bestimmten Umständen kann der Prozessor 110 auf die erweiterten Register und die Skalar- und Spezialanwendungsregister des Vektorprozessors 120 zugreifen. Zwei spezielle "Nutzer"-erweiterte Register weisen zwei Leseanschlüsse auf, um zu ermöglichen, daß die Prozessoren 110 und 120 gleichzeitig die Register lesen. Auf andere erweiterte Register kann nicht gleichzeitig zugegriffen werden.

Der Vektorprozessor 120 weist zwei alternative Zustände VP_RUN und VP_IDLE auf, die anzeigen, ob der Vektorprozessor 120 läuft oder im Leerlauf ist. Wenn der Vektorprozessor 120 im Zustand VP_IDLE ist, kann der Prozessor 110 aus Skalar- oder Spezialanwendungsregistern des Vektorprozessors 120 lesen oder diese beschreiben, aber während der Vektorprozessor 120 im Zustand VP_RUN ist, sind die Ergebnisse des Prozessors 110 beim Lesen oder Beschreiben eines Registers des Vektorprozessors 120 undefiniert.

Die Erweiterung des ARM7-Befehlssatzes für den Prozessor 110 schließt Befehle ein, die auf die erweiterten Register und die Skalar- oder Spezialanwendungsregister des Vektorprozessors 120 zugreifen. Ein Befehl MFER bzw. MFEP überträgt Daten von einem erweiterten Register bzw. von einem Skalar- oder Spezialanwendungsregister im Vektorprozessor 120 zu einem Universalregister im Prozessor 110. Ein Befehl MTER bzw. MTEP überträgt Daten von einem Universalregister im Prozessor 110 zu einem erweiterten Register bzw. einem Skalar- oder Spezialanwendungsregister im Vektorprozessor 120. Ein TESTSET-Befehl liest sowohl ein erweitertes Register und setzt auch das Bit 30 des erweiterten Registers auf 1. Der Befehl TESTSET ermöglicht eine Nutzer/Erzeuger-Synchronisierung, indem Bit 30 eingestellt wird, um dem Prozessor 120 zu signalisieren, daß der Prozessor 110 ein erzeugtes Ergebnis gelesen (oder benutzt) hat. Andere Befehle für den Prozessor 110, wie STARTVP und INTVP, steuern den Betriebszustand des Vektorprozessors 120.

Der Prozessor 110 funktioniert als ein Hauptprozessor, um den Betrieb des Vektorprozessors 120 zu steuern. Die Verwendung einer asymmetrischen Aufteilung der Steuerung zwischen den Prozessoren 110 und 120 vereinfacht das Problem der Synchronisierung der Prozessoren 110 und 120. Der Prozessor 110 initialisiert den Vektorprozessor 120, indem eine Befehlsadresse in einen Programmzähler für den Vektorprozessor 120 geschrieben wird, während der Vektorprozessor 120 im Zustand VP_IDLE ist. Der Prozessor 110 führt dann einen STARTVP-Befehl aus, der den Vektorprozessor 120 in den Zustand VP_RUN wechseln läßt. Im Zustand VP_RUN ruft der Vektorprozessor 120 über ein Cache-Subsystem 130 Befehle ab und führt diese Befehle parallel zum Prozessor 110 aus, der in seinem eigenen Programm fortfährt. Nachdem er gestartet wurde, führt der Vektorprozessor 120 die Ausführung fort, bis er auf eine Ausnahme trifft, einen VCJOIN- oder VCINT-Befehl ausführt, wobei eine entsprechende Bedingung erfüllt wird, oder durch den Prozessor 110 unterbrochen wird. Der Vektorprozessor 120 kann die Ergebnisse der Programmausführung an den Prozessor 110 übergeben, indem die Ergebnisse in ein erweitertes Register geschrieben werden, indem die Ergebnisse in den gemeinsamen Adreßraum der Prozessoren 110 und 120 geschrieben werden, oder indem das Ergebnis in einem Skalar- oder Spezialanwendungsregister belassen wird, auf das der Prozessor 110 zugreift, wenn der Vektorprozessor 120 wieder in den Zustand VP_IDLE tritt.

Der Vektorprozessor 120 handhabt bzw. bearbeitet seine eigenen Ausnahmen nicht. Nach der Ausführung eines Befehls, der eine Ausnahme hervorruft, tritt der Vektorprozessor 120 in den Zustand VP_IDLE und signalisiert dem Prozessor 110 über eine direkte Leitung eine Unterbrechungsanfrage. Der Vektorprozessor 120 bleibt im Zustand VP_IDLE bis der Prozessor 110 einen weiteren STARTVP-Befehl ausführt. Der Prozessor 110 ist verantwortlich für das Lesen eines Registers VISRC des Vektorprozessors 120, um die Art der Ausnahme festzustellen, wobei die Ausnahme möglicherweise durch Wiederinitialisierung des Vektorprozessors 120 bearbeitet und dann, falls gewünscht, der Vektorprozessor 120 angewiesen wird, die Ausführung wieder aufzunehmen.

Ein durch den Prozessor 110 ausgeführter INTVP-Befehl unterbricht den Vektorprozessor 120, was bewirkt, daß der Vektorprozessor 120 in den Leerlaufzustand VP_IDLE tritt. Ein Befehl INTVP kann z. B. bei einem Multitaskingsystem verwendet werden, um den Vektorprozessor von der Ausführung einer Aufgabe, wie z. B. das Videodecodieren, zu einer anderen Aufgabe, wie z. B. einer Soundkarten-Emulation, umzuschalten.

Die Vektorprozessorbefehle VCINT und VCJOIN sind Ablaufsteuerungsbefehle, die, falls eine durch den Befehl angezeigte Bedingung erfüllt wird, die Ausführung durch den Vektorprozessor 120 anhalten, den Vektorprozessor 120 in den Zustand VP_IDLE versetzen und eine Unterbrechungsanfrage an den Prozessor 110 ausgeben, bis solche Anfragen abgedeckt bzw. erfüllt sind. Ein Programmzähler (Spezialanwendungs-Register VPC) des Vektorprozessors 120 zeigt die Befehlsadresse nach dem VCINT- oder VCJOIN-Befehl an. Der Prozessor 110 kann ein Unterbrechungsquellenregister VISRC des Vektorprozessors 120 prüfen, um festzustellen, ob ein VCINT- oder VCJOIN-Be­ fehl die Unterbrechungsanfrage verursacht hat. Da der Vektorprozessor 120 breite Datenbusse aufweist und beim Einsparen und Wiederherstellen seiner Register effizienter ist, sollte die Software, die durch den Vektorprozessor 120 ausgeführt wird, während des Kontextschaltens Register sparen und wiederherstellen. Die eingeschlossene Patentanmeldung in Anhang G mit dem Titel "Efficient Context Saving and Restoring in Multiprocessors" beschreibt ein exemplarisches System zum Kontextschalten.

Fig. 2 zeigt die primären Funktionsblöcke des exemplarischen Ausführungsbeispiels des Vektorprozessors 120. Der Vektorprozessor 120 schließt eine Befehlsabrufeinheit 210 (IFU), einen Decodierer 220, eine Ablaufsteuereinheit 230, einen Ausführungsdatenweg 240 und eine Lade-/Speichereinheit 250 (LSU) ein. Die IFU 210 ruft Befehle und Prozeßablaufsteuerbefehle, wie Verzweigungen, ab. Der Befehlsdecodierer 220 decodiert in der Reihenfolge entsprechend der Ankunft von der IFU 210 einen Befehl pro Zyklus und schreibt die vom Befehl decodierten Feldwerte in einen FIFO (FIFO-Speicher) in der Ablaufsteuereinheit 230. Die Ablaufsteuereinheit 230 wählt die Feldwerte aus, die an die Ausführungssteuerregister ausgegeben werden, wie dies für die Ausführung von Stufen von Operationen erforderlich ist. Die Ausgabeauswahl hängt von der Abhängigkeit der Operanden und der Verfügbarkeit von Verarbeitungsresourcen, wie dem Ausführungsdatenweg 240 oder der Lade-/Spei­ chereinheit 250, ab. Der Ausführungsdatenweg 240 führt Logik-/Arithmetikbefehle aus, die Vektordaten oder Skalardaten verarbeiten. Die Lade-/Speichereinheit 250 führt Lade-/Speicherbefehle aus, die auf den Adreßraum des Vektorprozessors 120 zugreifen.

Fig. 3 zeigt ein Blockdiagramm eines Ausführungsbeispiels der IFU 210, die einen Befehlszwischenspeicher enthält, der in einen Hauptbefehlszwischenspeicher 310 und einen Sekundärbefehlszwischenspeicher 312 unterteilt ist. Der Hauptzwischenspeicher 310 enthält acht aufeinanderfolgende Befehle, einschließlich dem Befehl, der dem aktuellen Programmzählerstand entspricht. Der Sekundärzwischenspeicher 312 enthält die acht Befehle, die unmittelbar auf die Befehle im Zwischenspeicher 310 folgen. Die IFU 210 schließt ebenfalls einen Verzweigungsziel-Zwi­ schenspeicher 314 ein, der acht aufeinanderfolgende Befehle enthält, einschließlich dem Ziel des nächsten Ablaufsteuerungsbefehls im Zwischenspeicher 310 oder 312. Beim exemplarischen Ausführungsbeispiel verwendet der Vektorprozessor 120 einen RISC-Typ-Befehlssatz, bei dem jeder Befehl 32 Bits lang ist, und die Zwischenspeicher 310, 312 und 314 sind 8×32-Bit-Zwischenspeicher und sind über einen 256-Bit-Befehlsbus mit dem Cache-Subsystem 130 verbunden. In einem einzigen Taktzyklus kann die IFU 210 acht Befehle vom Cache-Subsystem 130 in irgendeinen der Zwischenspeicher 310, 312 oder 314 laden. Das Register 340, 342 bzw. 344 zeigt eine Basisadresse für den im Zwischenspeicher 310, 312 bzw. 314 geladenen Befehl.

Ein Multiplexer 332 (MUX) wählt den aktuellen Befehl aus dem Hauptbefehlszwischenspeicher 310. Falls der aktuelle Befehl kein Ablaufsteuerbefehl ist und ein Befehl, der in einem Befehlsregister 330 gespeichert ist, zu einer Decodierungsstufe der Ausführung vorrückt, wird der aktuelle Befehl im Befehlsregister 330 gespeichert und der Programmzählerstand wird inkrementiert. Nachdem das Inkrementieren des Programmzählerstandes den letzten Befehl im Zwischenspeicher 310 gewählt hat, wird der nächste Satz von acht Befehlen in den Zwischenspeicher 310 geladen.

Falls der Zwischenspeicher 312 die gewünschten acht Befehle enthält, werden die Inhalte des Zwischenspeichers 312 und des Registers 342 unmittelbar in den Zwischenspeicher 310 und das Register 340 übertragen und acht weitere Befehle werden vorab vom Cache-System 130 in den Sekundärzwischenspeicher 312 abgerufen. Aus der Basisadresse im Register 342 und einem durch einen Multiplexer 352 ausgewählten Offset stellt ein Addierer 350 die Adresse des nächsten Satzes von Befehlen fest. Während oder nachdem die Adresse vom Register 342 zum Register 340 übertragen wird, wird die resultierende Adresse vom Addierer 350 im Register 342 gespeichert. Mit der Anfrage nach acht Befehlen wird die berechnete Adresse ebenfalls zum Cache-Subsystem 130 gesendet. Falls eine vorherige Anfrage an das Cache-Steuersystem 130 noch nicht die nächsten acht Befehle an den Zwischenspeicher 312 vorgesehen hat, wenn diese vom Zwischenspeicher 310 benötigt werden, werden die zuvor angeforderten Befehle unmittelbar im Zwischenspeicher 310 gespeichert, wenn diese vom Cache-Subsystem 130 erhalten werden.

Falls der aktuelle Befehl ein Ablaufsteuerbefehl ist, bearbeitet die IFU 210 den Befehl durch Auswerten einer Bedingung für den Ablaufsteuerbefehl und Aktualisieren des Programmzählerstandes, der auf den Ablaufsteuerbefehl folgt. Die IFU 210 wird angehalten, falls die Bedingung unbestimmt ist, weil ein vorheriger Befehl, der die Bedingung ändern kann, nicht abgeschlossen wurde. Falls nicht verzweigt wird, wird der Programmzähler inkrementiert und der nächste Befehl wird wie oben beschrieben ausgewählt. Falls verzweigt wird und ein Verzweigungsziel-Zwi­ schenspeicher 314 das Ziel der Verzweigung enthält, werden die Inhalte des Zwischenspeichers 314 und des Registers 344 zum Zwischenspeicher 310 und zum Register 340 übertragen, so daß die IFU 210 das Bereitstellen von Befehlen an den Decodierer 220 fortsetzen kann, ohne auf Befehle vom Cache-Subsystem 130 zu warten.

Um vorab Befehle für den Verzweigungsziel-Zwischenspeicher 314 abzurufen, tastet ein Eingabesammler 320 die Zwischenspeicher 310 und 312 ab, um den nächsten Ablaufsteuerbefehl, der auf den aktuellen Programmzählerstand folgt, zu lokalisieren. Falls im Zwischenspeicher 310 oder 312 ein Ablaufsteuerbefehl gefunden wird, bestimmt der Eingabesammler 320 aus der Basisadresse des Zwischenspeichers 310 oder 312, der den Befehl enthält, den Offset zu einem ausgerichteten Satz von acht Befehlen, die die Zieladresse des Ablaufsteuerbefehls einschließen. Die Multiplexer 352 und 354 liefern den Offset aus dem Ablaufsteuerbefehl und die Basisadresse vom Register 340 oder 342 an den Addierer 350, der eine neue Basisadresse für den Zwischenspeicher 314 erzeugt. Die neue Basisadresse wird an das Cache-Subsystem 130 geliefert, welches anschließend für den Verzweigungsziel-Zwi­ schenspeicher 314 die acht Befehle liefert.

Zusätzlich zum Programmzählerstand kann die IFU 210 bei der Bearbeitung von Ablaufsteuerbefehlen, wie den "Dekrement- und bedingte Verzweigungs-" Befehlen VD1CBR, VD2CBR und VD3CBR und dem "wechsle Steuerregister-" Befehl VCHGCR, Registerwerte ändern. Wenn die IFU 210 einen Befehl vorfindet, der kein Ablaufsteuerbefehl ist, so wird dieser Befehl zum Befehlsregister 330 und von dort zum Decodierer 220 weitergeleitet.

Der Decodierer 220 decodiert einen Befehl, indem Steuerwerte in die Felder eines FIFO-Zwischenspeichers 410 in der Ablaufsteuereinheit 230 geschrieben werden, wie dies in Fig. 4 dargestellt ist. Der FIFO-Zwischenspeicher 410 enthält vier Zeilen von Flipflops, von denen jede fünf Felder mit Informationen zum Steuern der Ausführung eines Befehls enthalten kann. Die Zeilen 0 bis 3 speichern nacheinander Informationen für die ältesten bis neuesten Befehle und die Information im FIFO-Zwischenspeicher 410 wird hinab zu niedrigeren Zeilen verschoben, wenn eine ältere Information entfernt wird, nachdem Befehle abgeschlossen sind. Die Ablaufsteuereinheit 230 gibt einen Befehl an eine Ausführungsstufe aus, indem die notwendigen Felder des Befehls ausgewählt werden, wobei der Befehl in eine Steuerleitung 420, die die Ausführungsregister 421 bis 427 einschließt, eingeladen werden soll. Die meisten Befehle können für eine Ausgabe und Ausführung außerhalb der Reihenfolge bereitgestellt werden. Insbesondere die Reihenfolge der Logik-/Arithmetikoperationen bezüglich der Lade-/Speicheroperationen ist willkürlich, außer es sind Operandenabhängigkeiten zwischen den Lade-/Spei­ cheroperationen und den Logik-/Arithmetikoperationen vorhanden. Vergleiche der Feldwerte im FIFO-Zwi­ schenspeicher 410 zeigen, ob irgendwelche Operandenabhängigkeiten vorhanden sind.

Fig. 5A erläutert eine Sechsstufen-Ausführungs-Pipeline für einen Befehl, der ohne Zugriff auf den Adreßraum des Vektorprozessors 120 eine Register-Register-Operation ausführt. Bei einer Befehlsabrufstufe 511 ruft die IFU 210 einen Befehl wie oben beschrieben ab. Die Abrufstufe benötigt einen Taktzyklus, außer die IFU 210 wird durch eine Pipeline-Verzögerung, eine unaufgelöste Verzweigungsbedingung oder eine Verzögerung im Cache-Sub­ system 130, das die vorab abgerufenen Befehle zur Verfügung stellt, aufgehalten. Bei einer Decodiererstufe 512 decodiert der Decodierer 220 den Befehl von der IFU 210 und schreibt Informationen für den Befehl in die Ablaufsteuereinheit 230. Die Decodiererstufe 512 benötigt ebenfalls einen Taktzyklus, außer in der FIFO 410 stehen keine Zeilen für eine neue Operation zur Verfügung. Während des ersten Zyklus im FIFO 410 kann die Operation an die Steuerleitung 420 ausgegeben werden, aber sie kann durch die Ausgabe von älteren Operationen verzögert werden.

Der Ausführungsdatenweg 240 führt Register-Register-Ope­ rationen durch und liefert Daten und Adressen für Lade-/Speicher-Operationen. Fig. 6A zeigt ein Blockdiagramm eines Ausführungsbeispiels des Ausführungsdatenwegs 240 und wird in Verbindung mit Ausführungsstufen 514, 515 und 516 beschrieben. Das Ausführungsregister 421 liefert Signale, die zwei Register in einem Registerfile 610 identifizieren, die während einer Lesestufe 514 in einem Taktzyklus gelesen werden. Das Registerfile 610 schließt 32 Skalarregister und 64 Vektorregister ein. Fig. 6B ist ein Blockdiagramm des Registerfiles 610. Das Registerfile 610 weist zwei Leseanschlüsse und zwei Schreibanschlüsse auf, um bei jedem Taktzyklus bis zu zwei Lesevorgänge und zwei Schreibvorgänge aufzunehmen. Jeder Anschluß schließt eine Auswahlschaltung 612, 614, 616 oder 618 und einen 288-Bit-Da­ tenbus 613, 615, 617 oder 619 ein. Die Auswahlschaltungen, wie die Schaltungen 612, 614, 616 und 618 sind dem Fachmann gut bekannt und verwenden ein Adreßsignal WRADDR1, WRADDR2, RDADDR1 oder RDADDR2, das der Decodierer 220 aus einer 5-Bit-Registerzahl ableitet, die typischerweise aus einem Befehl, einem Bank-Bit von dem Befehl oder von einem Steuerstatusregister VCSR und der Befehlssyntax, die anzeigt, ob die Register Vektorregister oder Skalarregister sind, extrahiert wird. Gelesene Daten können wahlweise durch den Multiplexer 656 zur Lade-/Spei­ chereinheit 250 oder durch Multiplexer 622 und 624 über einen Multiplizierer 620, eine Arithmetik-Logik-Ein­ heit 630 oder einen Akkumulator 640 geleitet werden. Die meisten Operationen lesen zwei Register und die Lesestufe 514 ist in einem Zyklus abgeschlossen. Jedoch erfordern manche Befehle, wie ein Multiplizier- und Addierbefehl VMAD und Befehle, die Doppelgrößenvektoren bearbeiten, Daten von mehr als zwei Registern, so daß die Lesestufe 514 länger als ein Taktzyklus ist.

Während einer Ausführungsstufe 515 bearbeiten der Multiplizierer 620, die Arithmetik-Logik-Einheit 630 und der Akkumulator 640 Daten, die zuvor vom Registerfile 610 gelesen wurden. Die Ausführungsstufe 515 kann die Lesestufe 514 überlappen, falls mehrere Zyklen zum Lesen der notwendigen Daten erforderlich sind. Die Dauer der Ausführungsstufe 515 hängt vom Typ der Datenelemente (ganzzahlig oder Gleitkomma) und der Menge (Anzahl der Lesezyklen) der bearbeiteten Daten ab. Signale von den Ausführungsregistern 422, 423 und 425 steuern die Eingangsdaten an die Arithmetik-Logik-Einheit 630, den Akkumulator 640 und den Multiplizierer 620 für die ersten Operationen, die während der Ausführungsstufe durchgeführt werden. Die Signale von den Ausführungsregistern 432, 433 und 435 steuern zweite bzw. nachfolgende Operationen, die während der Ausführungsstufe 515 ausgeführt werden.

Fig. 6C zeigt ein Blockdiagramm eines Ausführungsbeispiels des Multiplizierers 620 und der Arithmetik-Logik-Einheit 630 (ALU). Der Multiplizierer 620 ist ein Ganzzahl-Mul­ tiplizierer, der acht unabhängige 36×36-Bit-Mul­ tiplizierer 626 enthält. Jeder Multiplizierer 626 enthält vier 9×9-Bit-Multiplizierer, die über einen Steuerschaltungsaufbau miteinander verbunden sind. Bei einer Datenelementgröße von 8-Bit und 9-Bit trennen Steuersignale von der Ablaufsteuereinheit 230 die vier 9×9-Bit-Multiplizierer voneinander, so daß jeder Multiplizierer 626 vier Multiplikationen ausführt und der Multiplizierer 620 zweiunddreißig unabhängige Multiplikationen während eines Zyklus ausführt. Bei 16-Bit-Datenelementen verbindet der Steuerschaltungsaufbau Paare von 9×9-Bit-Mul­ tiplizierer, damit sie zusammenarbeiten, und der Multiplizierer 620 führt 16 Parallelmultiplikationen aus. Bei einem 32-Bit-Ganzzahl-Datenelementtyp führen acht Multiplizierer 626 acht Parallelmultiplikationen pro Taktzyklus durch. Die Ergebnisse einer Multiplikation liefern ein 576-Bit-Ergebnis bei einer 9-Bit-Da­ tenelementgröße und 512 Bits bei anderen Datengrößen.

Die ALU 630 kann das resultierende 576-Bit- oder 512-Bit-Er­ gebnis vom Multiplizierer 620 in zwei Taktzyklen bearbeiten. Die ALU 630 enthält acht unabhängige 36-Bit-ALUs 636. Jede ALU 636 enthält eine 32×32-Bit-Gleitkomma-Ein­ heit für Gleitkomma-Additionen und -Multiplikationen. Ein weiterer Schaltungsaufbau implementiert Ganzzahl-Ver­ schiebungs-; Arithmetik- und Logikfunktionen. Für eine Ganzzahl-Verarbeitung enthält jede ALU 636 vier Einheiten, die zu einer unabhängigen 8-Bit- und 9-Bit-Verarbeitung in der Lage sind und die für 16-Bit- und 32-Bit-Ganzzahl-Da­ tenelemente in Sätzen von zwei oder vier verbunden werden können.

Der Akkumulator 640 akkumuliert die Ergebnisse und schließt zwei 576-Bit-Register für eine höhere Genauigkeit bei Zwischenergebnissen ein.

Während der Schreibstufe 516 werden Ergebnisse von der Ausführungsstufe im Registerfile 610 gespeichert. Während eines einzigen Taktzyklus können zwei Register beschrieben werden und die Eingangsmultiplexer 602 und 605 wählen zwei zu schreibende Datenwerte aus. Die Dauer der Schreibstufe 516 für eine Operation hängt von der Menge der Daten, die als Ergebnis der Operation geschrieben werden müssen, und der Konkurrenz von der LSU 250 ab, die einen Ladebefehl durch Schreiben auf das Registerfile 610 abschließen kann. Signale von den Ausführungsregistern 426 und 427 wählen das Register aus, auf das die Daten von der Logikeinheit 630, dem Akkumulator 640 und dem Multiplizierer 620 geschrieben werden.

Fig. 5B zeigt eine Ausführungs-Pipeline 520 für die Ausführung eines Ladebefehls. Die Befehlsabrufstufe 511, die Decodiererstufe 512 und die Ausgabestufe 513 für die Ausführungs-Pipeline 520 sind die gleichen wie die bei der Register-Register-Operation beschriebenen. Die Lesestufe 514 ist ebenfalls die gleiche wie oben beschrieben, mit der Ausnahme, daß der Ausführungsdatenweg 240 Daten vom Registerfile 610 verwendet, um eine Adresse für einen Aufruf an das Cache-Subsystem 130 zu bestimmen. Bei der Adreßstufe 525 wählen die Multiplexer 652, 654 und 656 die Adresse aus, die der Lade-/Speichereinheit 250 für die Ausführungsstufen 526 und 527 zugeführt wird. Während der Stufen 526 und 527 bleibt die Information für die Ladeoperation im FIFO 410, während die Lade-/Spei­ chereinheit 250 die Operation bearbeitet.

Fig. 7 zeigt ein Ausführungsbeispiel der Lade-/Spei­ chereinheit 250. Während der Stufe 526 wird aus der in der Stufe 525 bestimmten Adresse ein Aufruf für Daten an das Cache-Subsystem 130 gerichtet. Das exemplarische Ausführungsbeispiel verwendet transaktionsbasierte Cache-Aufrufe, wo mehrere Einrichtungen, einschließlich den Prozessoren 110 und 120, über das Cache-Subsystem 130 auf den lokalen Adreßraum zugreifen können. Nach einem Aufruf an das Cache-Subsystem 130 könnten die angeforderten Daten während einiger Zyklen nicht zur Verfügung stehen, aber die Lade-/Speichereinheit 250 kann Aufrufe an das Cache-Sub­ system richten, während andere Aufrufe anhängig sind. Folglich wird die Lade-/Speichereinheit 250 nicht aufgehalten. Die Anzahl von Taktzyklen, die das Cache-Sub­ system 130 benötigt, um die angeforderten Daten zur Verfügung zu stellen, hängt davon ab, ob ein Treffer oder ein Fehlschuß im Datencache 194 vorliegt, d. h., ob die entsprechenden Daten vorhanden sind oder nicht.

Bei der Treiberstufe 527 legt das Cache-Subsystem 130 ein Datensignal für die Lade-/Speichereinheit 250 an. Das Cache-Subsystem 130 kann Daten von 256 Bits (32 Bytes) pro Zyklus an die Lade-/Speichereinheit 250 liefern. Ein Byte-Ausrichter 710 richtet jedes der 32 Bytes in einer entsprechenden 9-Bit-Speicherstelle aus, um einen 288-Bit-Wert vorzusehen. Das 288-Bit-Format ist geeignet für Multimedia-Anwendungen, wie das MPEG-Codieren und -Decodieren, das manchmal 9-Bit-Datenelemente verwendet. Der 288-Bit-Wert wird in einen Lesedaten-Zwischenspeicher 720 geschrieben. Bei der Schreibstufe 528 überträgt die Ablaufsteuerung 230 das Feld 4 vom FIFO-Zwischenspeicher 410 zum Ausführungsregister 426 oder 427, um die 288-Bit-Menge vom Datenzwischenspeicher 720 zum Registerfile 610 zu schreiben.

Fig. 5C zeigt eine Ausführungs-Pipeline 530 für eine Ausführung eines Speicherbefehls. Die Befehlsabrufstufe 511, die Decodiererstufe 512 und die Ausgabestufe 513 für die Ausführungs-Pipeline 530 sind die gleichen wie oben beschrieben. Die Lesestufe 514 ist ebenfalls die gleiche wie oben beschrieben, mit der Ausnahme, daß die Lesestufe zu speichernde Daten und Daten für Adreßberechnungen liest. Zu speichernde Daten werden in einen Schreibdatenzwischenspeicher 730 in der Lade-/Spei­ chereinheit 250 geschrieben. Multiplexer 740 wandeln die in einem 9-Bit-Bytes-Format vorgesehenen Daten in ein herkömmliches Format von 8-Bit-Bytes um. Die umgewandelten Daten vom Zwischenspeicher 730 und die zugehörige Adresse von der Adreßberechnungsstufe 525 werden während einer SRAM-Stufe 536 parallel zum Cache-Subsystem 130 gesendet.

Beim exemplarischen Ausführungsbeispiel des Vektorprozessors 120 ist jeder Befehl 32 Bits lang und weist eines der neun in Fig. 8 gezeigten Formate auf, die mit REAR, REAI, RRRM5, RRRR, RI, CT, RRRM9, RRRM9* und RRRM9** bezeichnet sind. Der Anhang E beschreibt den Befehlssatz für den Vektorprozessor 120.

Einige Lade-, Speicher- und Cache-Operationen, die Skalarregister benutzen, wenn sie eine effektive Adresse bestimmen, weisen das REAR-Format auf. REAR-Format-Befehle werden durch die Bits 29-31, die 000b sind, identifiziert und weisen drei Operanden auf, die durch zwei Registerzahlen SRb und SRi für Skalarregister und eine Registerzahl Rn eines Registers, das in Abhängigkeit von einem Bit D ein Skalar- oder Vektorregister sein kann, identifiziert werden. Ein Bankbit B identifiziert entweder eine Bank für das Register Rn oder zeigt an, ob das Vektorregister Rn ein Doppelgrößen-Vektorregister ist, falls die Vorgabe-Vektorregistergröße von doppelter Größe ist. Ein Operationscodefeld Opc identifiziert die an den Operanden ausgeführte Operation und ein Feld TT zeigt einen Übertragungstyp, wie Laden oder Speichern, an. Ein typischer REAR-Formatbefehl ist der Befehl VL, der das Register Rn von einer Adresse lädt, die durch Addieren der Inhalte der Skalarregister SRb und SRi bestimmt wird. Falls ein Bit A gesetzt ist, wird die berechnete Adresse in dem Skalarregister SRb gespeichert.

Die REAI-Formatbefehle sind die gleichen wie die REAR-Befehle, mit der Ausnahme daß ein 8-Bit-Direktwert von einem Feld IMM anstelle der Inhalte des Skalarregisters SRi verwendet wird. REAR- und REAI-Formate weisen kein Datenelement-Größenfeld auf.

Das RRRM5-Format ist für Befehle mit zwei Quelloperanden und einem Zieloperanden. Diese Befehle weisen entweder drei Registeroperanden oder zwei Registeroperanden und einen 5-Bit-Direktwert auf. Ein Codieren der Felder D, S und M, wie dies im Anhang E gezeigt ist, legt fest, ob der erste Quelloperand Ra ein Skalar- oder Vektorregister ist, ob der zweite Quelloperand Rb/IM5 ein Skalarregister, ein Vektorregister oder ein 5-Bit-Direktwert ist und ob das Zielregister Rd (bzw. Bestimmungsregister) ein Skalar- oder Vektorregister ist.

Das RRRR-Format ist für Befehle mit vier Registeroperanden. Die Registerzahlen Ra und Rb zeigen Quellregister an. Die Registerzahl Rd zeigt ein Zielregister an und die Registerzahl Rc zeigt in Abhängigkeit vom Feld Opc entweder ein Quellregister oder ein Zielregister an. Alle Operanden sind Vektorregister, außer Bit S ist gesetzt, um anzuzeigen, daß das Register Rb ein Skalarregister ist. Ein Feld DS zeigt die Datenelementgröße für die Vektorregister an. Das Feld Opc wählt den Datentyp für 32-Bit-Datenelemente.

Der RI-Formatbefehl lädt einen Direktwert in ein Register. Das Feld IMM enthält einen Direktwert von bis zu 18 Bits. Die Registerzahl Rd zeigt das Zielregister an, welches in Abhängigkeit vom Bit D entweder ein Vektorregister in der aktuellen Bank oder ein Skalarregister ist. Das Feld DS bzw. F zeigt die Größe bzw. den Typ eines Datenelements an. Für 32-Bit-Ganzzahl-Datenelemente wird der 18-Bit-Di­ rektwert um ein Vorzeichen erweitert, bevor er in das Register Rd geladen wird. Bei Gleitkomma-Datenelementen zeigt das Bit 18 das Vorzeichen, die Bits 17 bis 10 den Exponenten und die Bits 9 bis 0 die Mantisse eines 32-Bit-Gleitkomma-Werts an.

Das CT-Format ist für Ablaufsteuerbefehle und schließt ein Operationscodefeld Opc, ein Bedingungsfeld Cond und einen 23-Bit-Direktwert IMM ein. Es wird verzweigt, wenn eine durch das Bedingungsfeld angezeigte Bedingung wahr ist. Mögliche Bedingungscodes sind "immer", "weniger als", "gleich", "weniger als oder gleich", "größer als", "ungleich", "größer als oder gleich" und "Überlauf". Bits GT, EQ, LT und SO im Status- und Steuerregister VCSR werden verwendet, um die Bedingungen zu prüfen.

Das Format RRRM9 ist entweder für drei Registeroperanden oder zwei Registeroperanden und einen 9-Bit-Direktwert vorgesehen. Eine Kombination von Bits D, S und M zeigt an, welche der Operanden Vektorregister, Skalarregister oder 9-Bit-Direktwerte sind. Ein Feld DS zeigt eine Datenelementgröße an. Die RRRM9*- und RRRM9**-Formate sind Spezialfälle des RRRM9-Formats und werden durch das Operationscodefeld Opc unterschieden. Das RRRM9*-Format ersetzt eine Quellregisterzahl Ra durch einen Bedingungscode Cond und ein ID-Feld. Das RRRM9**-Format ersetzt die höchstwertigen Bits des Direktwerts durch einen Bedingungscode Cond und ein Bit K. Eine weitere Beschreibung von RRRM9* und RRRM9** befindet sich im Anhang E in Hinblick auf einen "bedingten Übertragungsbefehl" VCMOV, einen "Befehl mit einer bedingten Übertragung mit Elementmaske" VCMOVM und einen "Befehl Vergleiche und Setze Maske" VCMPV.

ANHANG A

Bei der beispielhaften Ausführung ist der Prozessor 110 ein Prozessor allgemeiner Funktion, der dem Standard für einen ARM7-Prozessor genügt. Für die Beschreibung der Register in dem ARM7 kann auf das ARM-Architekturdokument oder das ARM7-Datenblatt (Dokumentennummer ARM DDI 0020C, herausgegeben im Dez. 1994) Bezug genommen werden.

Um mit dem Vektorprozessor 120 in Wechselwirkung zu treten, führt der Prozessor 110 folgendes aus: Starten und Stoppen des Vektorprozessors; Testen des Vektorprozessorzustandes, einschließlich der Synchronisation; Datenübertragung von einem skalaren/spezialanwendungsbezogenen Register im Vektorprozessor 120 in ein allgemeines Register im Prozessor 110; und Datenübertragung von einem allgemeinen Register in ein skalares/spezialanwendungsbezogenes Register im Vektorprozessor. Es gibt keine direkten Mittel zum Übertragen zwischen einem allgemeinen Register und einem Vektorregister des Vektorprozessors. Solche Übertragungen erfordern Speicher als ein Zwischenmedium.

Tabelle A.1 beschreibt die Ausführung des Befehlssatzes des ARM7 für Vektorprozessor-Wechselwirkungen.

Tabelle A.1

Ausführungen des Befehlssatzes des ARM7

Die Tabelle A.2 listet ARM7-Ausnahmen auf, die vor der Ausführung eines falschen Befehls entdeckt und berichtet werden. Die Ausnahmevektoradresse ist in hexadezimaler Schreibweise angegeben.

Tabelle A.2

ARM7-Ausnahmen

Das Folgende beschreibt die Syntax der Erweiterung des ARM7-Befehlsatzes. Bezüglich einer Nomenklaturbeschreibung und des Befehlsformates kann auf ein ARM-Architekturdokument oder das ARM7-Datenblatt (Dokumentennummer ARM DDI 0020C, herausgegeben im Dez. 1994) Bezug genommen werden.

Die ARM-Architektur stellt drei Befehlsformate für die Coprozessorschnittstelle zur Verfügung:

• 1. Coprozessor-Datenbefehle (CDP)
• 2. Coprozessor-Datenübertragungen (LDC, STC)
• 3. Coprozessor-Registerübertragungen (MRC, MCR)

Die MSP-Architekturerweiterung benutzt alle drei Formate.

Das Coprozessor-Datenbefehlsformat (CDP) wird für Befehle benutzt, die keine Rückmeldung an den ARM7 benötigen.

CDP-Format

Die Felder im CDP-Format unterliegen folgenden Vereinbarungen:

Das Coprozessor-Datenübertragungsformat (LDC, STC) wird benutzt, um eine Untermenge der Register des Vektorprozessors direkt in den Speicher zu laden oder zu speichern. Der ARM7-Prozessor ist verantwortlich für das Bereitstellen der Wortadresse, und der Vektorprozessor liefert oder akzeptiert die Daten und steuert die Zahl der zu übertragenden Worte. Für weitere Einzelheiten kann auf das ARM7-Datenblatt Bezug genommen werden.

LDC, STC-Format

Die Felder in dem Format unterliegen folgenden Vereinbarungen:

Das Coprozessorregister-Übertragungsformat (MRC, MCR) wird benutzt, um Informationen direkt zwischen dem ARM7 und dem Vektorprozessor zu melden. Dieses Format wird benutzt, um zwischen einem ARM7-Register und einem skalaren oder spezialanwendungsbezogenen Register des Vektorprozessors zu verschieben.

MRC, MCR-Format

Die Felder im Format entsprechen folgender Vereinbarung:

ERWEITERTE ARM-BEFEHLSBESCHREIBUNG

Die erweiterten ARM-Befehle sind in alphabetischer Reihenfolge beschrieben.

CACHE Cache-Betrieb

Format

Assembler Syntax

STC{cond} p15, cOpc, <Address<
CACHE{cond} Opc, <Address<
Wobei cond = {eq, he, cs, cc, mi, pl, vs, vc, hi, Is, ge, lt, gt, le, ai, nv} und Opc = {0, 1, 3}. Da das CRn-Feld des LDC/STC-Formats benutzt wird, den Opc zu spezifizieren, ist zu beachten, daß der dezimalen Darstellung des Befehlscodes der Buchstabe "c" (d. h. daß c0 anstatt 0 zu benutzen ist) in der ersten Syntax voranzustellen ist. Bezüglich der Adressenart Syntax kann auf das ARM7-Datenblatt Bezug genommen werden.

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft. Der Opc<3 : 0< spezifiziert die folgenden Betriebsarten:

Operation

Es kann auf das ARM7-Datenblatt Bezug genommen werden, wie der EA errechnet wird.

Ausnahme

ARM7 Schutzverletzung.

INTVP Interrupt-Vektorprozessor

Format

Assembler Syntax

CDP{cond} p}, 1, c0, c0, co
INTVP{cond}
wobei cond = {eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, ns}.

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutreffend ist. Dieser Befehl signalisiert dem Vektorprozessor anzuhalten. ARM7 fährt mit der Ausführung des nächsten Befehls fort, ohne zu warten, daß der Vektorprozessor anhält.

Eine MFER Besetzt-Warteschleife sollte benutzt werden, um zu beobachten, ob der Vektorprozessor nach der Ausführung dieses Befehls anhält. Dieser Befehl hat keinen Effekt, wenn der Vektorprozessor schon im VP_IDLE-Zustand ist.

Bits 19 : 12, 7 : 15 und 3 : 0 sind reserviert.

Ausnahme

Vektorprozessor nicht verfügbar.

MFER Übertrage vom erweiterten Register

Format

Assembler Syntax

MRC{cond} p7, 2, Rd, cP, cER, 0
MFER{cond} Rd, RNAME
wobei cond = {eq, he, cs, cc, mi, pl, rs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd = (r0, . . . r15},
P = {0, 1], ER = f0, . . ., 15} und RNAME Bezug nimmt auf die durch die Architektur spezifizierte Registerart (d. h. PERO oder CSR).

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft. Das ARM7-Register Rd wird von dem mit P:ER<3 : 0< spezifizierten erweiterten Register ER übertragen, wie in der unten stehenden Tabelle gezeigt wird. Es wird Bezug genommen auf den Abschnitt 1.2 für die Beschreibungen des erweiterten Registers.

Ausnahmen

Schutzverletzung, wenn versucht wird, auf PERx während des Benutzermodus zuzugreifen.

MFVP Übertragung vom Vektorprozessor

Format

Assembler Syntax

MRC{cond} p7.1.Rd.Crn.CRm0
MFVP{cond} Rd.RNAME
wobei cond = {eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd = {r0, . . ., r15},
CRn{c0, . . ., c15}, CRm = {c0, . . ., c15} und RNAME Bezug nimmt auf die architekturmäßig spezifizierte Registerart (d. h. SP0 oder VCS).

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft.

Das ARM7-Register Rd wird von dem skalaren/spezialanwendungsbezogenen Register CRn<1 : 0<:CRm<3 : 0< des Vektorprozessors übertragen. Es wird Bezug genommen auf den Abschnitt 3.2.3 bezüglich der Registerzahlzuordnung des Vektorprozessors für Registerübertragungen.

Bits 7.5 wie auch CRn<3 : 2< sind reserviert.

Die Vektorprozessor-Registerkarte ist nachstehend gezeigt. Es wird Bezug genommen auf Tabelle 15 für die Spezialanwendungsbezogenen Register (SP0-SP15) des Vektorprozessors.

SR0 wird immer als 32 Bits von Nullen gelesen; und Schreiben dort hinein wird ignoriert.

Ausnahme

Vektorprozessor nicht verfügbar.

MTER Übertragen zum erweiterten Register

Format

Assembler Syntax

MRC{cond} p7, 2, Rd, cP, cER, 0
MFER{cond} Rd, RNAME
wobei cond = {eq, he, cs, cc, mi, pl, rs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd = fr0, . . ., r15),
P = {0, 1} ER = {0, . . ., 15} und RNAME bezieht sich auf die architekturmäßige spezifizierte Registerart (d. h. PERO oder CSR).

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft. Das ARM7-Register Rd wird von dem mit P:ER<3 : 0< spezifizierten Register ER übertragen, wie in der Tabelle unten gezeigt wird.

Ausnahme

Schutzverletzung wenn versucht wird im Benutzermodus auf PERx zuzugreifen.

MFVP Übertrage zum Vektorprozessor

Format

Assembler Syntax

MRC{cond} p7.1.Rd.Crn.CRm.0
MFVP{cond} Rd.RNAME
wobei cond = {eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, nv}, Rd = {r0, . . ., r15},
CRn = {fc0, . . ., c15}, CRm = {c0, . . ., c15} und RNAME Bezug nimmt auf die architekturmäßig spezifizierte Registerart (d. h. SP0 oder VCS).

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft.

Das ARM7-Register Rd wird vom skalaren/spezialanwendungsbezogenen Register CRn<1 : 0<:CRm<3 : 0< übertragen.

Bits 7 : 5 wie auch Bits CRn<3 : 2< sind reserviert.

Die Vektorprozessor-Registerkarte ist wie unten angegeben.

Ausnahme

Vektorprozessor nicht verfügbar.

PFTCH Vorgriff

Format

Assembler Syntax

LDC{cond} p15, 2, <Adresse<
PFTCH{cond} <Adresse<
wobei cond = {eq, he, cs, cc, mi, pl, rs, vc, hi, Is, ge, lt, gt, le, al, nv}. Nimmt Bezug auf das ARM7-Datenblatt für die Adreßarten-Syntax.

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft.

Auf die durch den EA spezifizierte Cacheleitung wird in den ARM7 Datencache vorgegriffen.

Betrieb

In Bezug auf das ARM7-Datenblatt dahingehend wie der EA berechnet wird.

Ausnahme: keine.

STARTVP Start Vektorprozessor

Format

Assembler Syntax

CDP{cond} p7, 0, cO, cO, cO
STARTVP {cond}
wobei cond = {eq, he, cs, cc, mi, pl, vs, vc, hi, Is, ge, it, gt, le, al, nv}.

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft. Dieser Befehl signalisiert dem Vektorprozessor, die Ausführung zu beginnen und löscht automatisch VISRC<vjp< und VISRC<vip<. ARM7 fährt mit der Ausführung des nächsten Befehls fort, ohne auf den Beginn der Ausführung des Vektorprozessors zu warten.

Der Zustand des Vektorprozessors muß in den gewünschten Zustand initialisiert sein, bevor dieser Befehl ausgeführt wird. Dieser Befehl hat keinen Effekt, wenn der Vektorprozessor schon im VP_RUN-Zustand ist.

Bits 19 : 12, 7 : 5 und 3 : 0 sind reserviert.

Ausnahme

Vektorprozessor nicht verfügbar.

TESTSET Test und Setze

Format

Assembler Syntax

MRC{cond} p7, 0, Rd, cO, cER, 0
TESTSET{cond} Rd, RNAME
wobei cond = {eq, he, cs, cc, mi, pl, rs, re, hi, ls, ge, lt, gt, le, al, nv}, Rd = fr0, . . ., r15}, ER = {0, . . ., 15} und RNAME nimmt Bezug auf die architekturmäßig spezifizierte Registerbedeutung (d. h., UER1 oder VASYNC).

Beschreibung

Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft. Dieser Befehl führt die Inhalte von UERx auf RD zurück und setzt UERx<30< auf 1. Wenn das ARM7-Register 15 als Zielregister spezifiziert ist, wird UERx<30< als das Z Bit von CPSR zurückgegeben, so daß eine kurze Besetzt-War­ teschleife implementiert werden kann.

Zur Zeit ist nur UER1 definiert, mit diesem Befehl zu arbeiten.

Bits 19 : 17 und 7 : 5 sind reserviert.

Ausnahmen: keine

ANHANG B

Die Architektur des Multimediaprozessors 100 definiert erweiterte Register, auf die der Prozessor 110 mit den Befehlen MFER und MTER zugreift. Die erweiterten Register schließen privilegierte erweiterte Register und benutzer­ erweiterte Register ein. Die privilegierten erweiterten Register werden in erster Linie zur Steuerung des Betriebs des Multimedia-Signalprozessors verwendet. Sie sind in Tabelle B.1 gezeigt.

Tabelle B.1

Privilegierte erweiterte Register

Das Steuerregister steuert den Betrieb vom MSP 100. Alle Bits in CTR werden beim Zurücksetzen gelöscht. Die Registerdefinition ist in Tabelle B.2 gezeigt.

Tabelle B.2

CTR Definition

Das Statusregister zeigt den Status von MSP 100 an. Alle Bits im Feld STR werden beim Zurücksetzen gelöscht. Die Registerdefinition ist in Tabelle B.3 gezeigt.

Tabelle B.3

STR Definition

Das Prozessor-Versionsregister identifiziert die spezielle Version des einzelnen Prozessors aus der Multimedia-Signal­ prozessor-Familie von Prozessoren.

Das Vektorprozessor-Interrupt-Maskenregister VIMSK steuert das Berichten von Vektorprozessor-Ausnahmen an dem Prozessor 110. Jedes Bit in VIMSK, ermöglicht der Ausnahme, den ARM7 zu unterbrechen, wenn es zusammen mit dem entsprechenden Bit des VISRC-Registers gesetzt ist. Es hat keine Wirkung darauf, wie die Vektorprozessor-Ausnahme erkannt wird, sondern bewirkt nur, ob die Ausnahme den ARM7 unterbrechen soll. Alle Bits in VIMSK werden beim Zurücksetzen gelöscht. Die Registerdefinition ist in Tabelle B.4 gezeigt.

Tabelle B.4

VIMSK Definition

Das ARM7-Befehlsadressen-Unterbrechungspunkt-Register unterstützt bei der Fehlersuche von ARM7-Programmen. Die Registerdefinition ist in Tabelle B.5 gezeigt.

Tabelle B.5

AIABR Definition

Das ARM7-Datenadreß-Unterbrechungspunkt-Register unterstützt bei der Fehlersuche von ARM7-Programmen. Die Registerdefinition ist in Tabelle B.6 gezeigt.

Tabelle B.6

ADABR Definition

Das Notizblock-Register konfiguriert die Adresse und die Größe des Notizblockes, welcher unter Benutzung von SRAM im Cacheuntersystem 130 gebildet wird. Die Registerdefinition ist in Tabelle B.7 gezeigt.

Tabelle B.7

SPREG Definition

Die benutzer-erweiterten Register werden meistens benutzt zur Synchronisation der Prozessoren 110 und 120. Die benutzer-erweiterten Register sind derzeitig so definiert, daß sie nur ein Bit haben, welches Bit 30 ist, und Befehle wie "MFER R15, UERx", z. B., geben den Bitwert in das Z-Zeichen (Flag) zurück. Die Bits UERx<31< und UERx<29 : 0< werden immer als Nullen gelesen. Die benutzer-erweiterten Register sind in Tabelle B.8 beschrieben.

Tabelle B.8

Benutzer-erweiterte Register

Tabelle B.9 zeigt die Zustände der erweiterten Register beim Zurücksetzen beim Anschalten.

Tabelle B.9

Erweiterter Registerzustand beim Anschalten

ANHANG C

Der architekturgemäße Zustand des Vektorprozessors 120 umfaßt: 32 32-Bit-Skalarregister; 2 Gruppen von 32 288-Bit-Vek­ torregistern; ein Paar 576-Bit-Vektor-Akkumulatorregister; und eine Gruppe von 32-Bit-Spezialregistern. Die Skalar-, Vektor- und Akkumulatorregister sind zur Universalprogrammierung vorgesehen und unterstützen viele unterschiedliche Datentypen.

Die nachstehenden Bezeichnungen werden in diesem und den folgenden Abschnitten verwendet: VR bezeichnet ein Vektorregister; VRi bezeichnet das i-te Vektorregister (Nullpunktverschiebung); VR[i] bezeichnet das i-te Datenelement in einem Vektorregister VR; VR<a:b< bezeichnet Bits a bis b in einem Vektorregister VR; und VR[i]<a:b< bezeichnet Bits a bis b des i-ten Datenelements in einem Vektorregister VR.

Eine Vektorarchitektur weist eine zusätzliche Dimension von Datentypen und -formaten für die Mehrfachelemente innerhalb eines Vektorregisters auf. Da ein Vektorregister eine feste Größe hat, hängt die Anzahl der Datenelemente, die es enthalten kann, vom Format der Elemente ab. Die MSP-Ar­ chitektur definiert fünf Elementformate, die in Tabelle C.1 dargestellt sind.

Tabelle C.1

Datenelementformate

Die MSP-Architektur interpretiert Vektordaten entsprechend dem in einem Befehl festgelegten Datentyp und -format. Gegenwärtig werden die Zweierkomplement-Formate (ganze Zahl) für die Byte-, Byte9-, Halbwort- und Wort-Elementformate bei den meisten arithmetischen Befehlen unterstützt. Außerdem wird das IEEE 754 Format mit einfacher Genauigkeit mit dem Wort-Elementformat hinsichtlich der meisten arithmetischen Befehle unterstützt.

Ein Programmierer hat die Freiheit, die Daten in einer beliebigen gewünschten Weise zu interpretieren, solange die Befehlsfolge ein sinnvolles Ergebnis ergibt. Der Programmierer hat zum Beispiel die Freiheit, das Byte9-Format zu verwenden, um vorzeichenlose Zahlen mit 8 Bits zu speichern, und er hat ebenso die Freiheit, vorzeichenlose Zahlen mit 8 Bits in den Byte-Format-Datenelementen zu speichern und mit ihnen zu arbeiten unter Verwendung der bereitgestellten arithmetischen Zweierkomplement-Befehle, solange das Programm mit "falschen" Überlaufergebnissen umgehen kann.

Es gibt 32 Skalarregister, die als SR0 bis SR31 bezeichnet werden. Die Skalarregister sind 32 Bits breit und können ein Datenelement eines beliebigen der definierten Formate enthalten. Das Skalarregister SR0 ist insofern speziell, daß das Register SR0 sich immer als 32 Bits aus Nullen liest und ein Schreibvorgang in das Register SR0 ignoriert wird. Die Byte-, Byte9- und Halbwort-Datentypen werden in den niedrigstwertigen Bits der Skalarregister gespeichert, wobei die höchstwertigen Bits nicht definierte Werte aufweisen.

Da die Register keine Datentypanzeiger besitzen, müssen die Programmierer den Datentyp hinsichtlich der bei jedem Befehl verwendeten Register kennen. Dies unterscheidet sich von anderen Architekturen, bei denen von einem 32-Bit-Register angenommen wird, daß es einen 32-Bit-Wert enthält. Die MSP-Architektur legt fest, daß ein Ergebnis eines Datentyps A nur die Bits, die für den Datentyp A definiert sind, korrekt modifiziert. Zum Beispiel modifiziert das Ergebnis einer Byte 9-Addition nur die niedrigeren 9 Bits des 32-Bit-Ziel­ skalarregisters. Die Werte der höheren 23 Bits sind nicht definiert, wenn sie nicht durch einen Befehl anders festgelegt werden.

Die 64 Vektorregister sind in 2 Gruppen eingeteilt, jede mit 32 Registern. Die Gruppe 0 enthält die ersten 32 Register und die Gruppe 1 enthält die zweiten 32 Register. Die zwei Gruppen werden derart verwendet, daß eine Gruppe als aktuelle Gruppe festgelegt ist und die andere als alternative Gruppe festgelegt ist. Alle Vektorbefehle verwenden die Register in der aktuellen Gruppe durch Vorgabe, mit Ausnahme der Lade-/Speicher- und Registerübertragungs-Befehle, die auf die Vektorregister in der alternativen Gruppe zugreifen können. Das CBANK-Bit im Vektorsteuer- und Statusregister VCSR wird verwendet, um die Gruppe 0 oder die Gruppe 1 als aktuelle Gruppe festzulegen. (Die andere Gruppe wird zur alternativen Gruppe.) Die Vektorregister in der aktuellen Gruppe werden als VR0 bis VR31 und die in der alternativen Gruppe als VRA0 bis VRA31 bezeichnet.

Alternativ können die zwei Gruppen geplant gemischt werden, um 32 Doppelgrößen-Vektorregister mit jeweils 576 Bits bereitzustellen. Das VEC64-Bit im Steuerregister VCSR legt diesen Modus fest. Im VEC64-Modus gibt es keine aktuelle und alternative Gruppe, und eine Vektorregisternummer kennzeichnet ein entsprechendes Paar von 288-Bit-Vektorregistern der zwei Gruppen. Das heißt,

VRi<575 : 0< = VR₁i<287 : 0<:VR₀i<287 : 0<

wobei VR₀i und-VR₁i die Vektorregister mit der Registernummer VRi in der Gruppe 1 bzw. in der Gruppe 0 bezeichnen. Die Vektorregister doppelter Größe werden als VR0 bis VR31 bezeichnet.

Die Vektorregister können für die Mehrfachelemente der Byte-, Byte9-, Halbwort oder Wortformate ausgelegt sein, wie in Tabelle C.2 dargestellt.

Tabelle C.2

Anzahl der Elemente pro Vektorregister

Das Mischen von Elementformaten innerhalb eines Vektorregisters wird nicht unterstützt. Mit Ausnahme des Byte9-Elementformats werden nur 256 der 288 Bits verwendet. Insbesondere wird jedes neunte Bit nicht verwendet. Die nicht verwendeten 32 Bits in den Byte-, Halbwort- und Wortformaten sind reserviert, und Programmierer sollten keinerlei Annahmen aber ihre Werte machen.

Das Vektor-Akkumulatorregister ist vorgesehen, um eine Speicherung eines Zwischenergebnisses bereitzustellen, das einen höheren Genauigkeitsgrad hat als das Ergebnis in einem Zielregister. Das Vektor-Akkumulatorregister besteht aus vier 288-Bit-Registern, die als VAC1H, VAC1L, VAC0H und VAC0L bezeichnet werden. Das VAC0H:VAC0L-Paar wird durch die drei Standardbefehle verwendet. Das VAC1H:VAC1L-Paar wird nur im VEC64-Modus verwendet, um die 64 Byte9-Vektoroperationen zu emulieren. Selbst wenn die Gruppe 1 als aktuelle Gruppe im VEC32-Modus festgelegt ist, wird das VAC0H:VAC0L-Paar verwendet.

Um mit derselben Anzahl an Elementen wie in den Quellvektorregistern ein Ergebnis mit erweiterter Genauigkeit zu erzeugen, werden Elemente mit erweiterter Genauigkeit in einem Paar von Registern gespeichert, wie in Tabelle C.3 dargestellt.

Tabelle C.3

Vektorakkumulator-Format

Das VAC1H:VAC1L-Paar wird nur im VEC64-Modus verwendet, wo die Anzahl der Elemente ebenso viel wie 64, 32 oder 16 für das Byte9 (und Byte), Halbwort bzw. Wort sein kann.

Es gibt 33 Spezialregister, die direkt aus dem Speicher geladen oder direkt im Speicher abgespeichert werden können oder nicht. Sechzehn Spezialregister, bezeichnet als RASR0 bis RASR15, bilden einen internen Rückkehradreßstapelspeicher und werden durch die Subroutinenaufruf- und Rückkehrbefehle verwendet. Siebzehn weitere 32-Bit-Spezialregister sind in Tabelle C.4 dargestellt.

Tabelle C.4

Spezialregister

Die Definition des Vektorsteuer- und Statusregisters VCSR ist in Tabelle C.5 dargestellt.

Tabelle C.5

VCSR-Definition

Das Vektorprogrammzählregister VPC ist die Adresse des als nächstes vom Vektorprozessor 120 auszuführenden Befehls. Der ARM7-Prozessor 110 sollte das Register VPC laden, bevor er den STARTVP-Befehl ausgibt, um die Operation des Vektorprozessors 120 zu starten.

Der Vektorausnahmebedingungs-Programmzähler VEPC gibt die Adresse des Befehls an, der höchstwahrscheinlich die aktuellste Ausnahmebedingung verursacht hat. MSP 100 unterstützt keine präzisen Ausnahmebedingungen, deshalb der Begriff "höchstwahrscheinlich".

Das Vektorunterbrechungs-Quellregister VISRC gibt die Unterbrechungsquellen für den ARM7-Prozessor 110 an. Die/Das geeignete(n) Bit(s) wird/werden durch die Hardware nach dem Erkennen der Ausnahmebedingung(en) gesetzt. Die Software muß das Register VISRC löschen, bevor der Vektorprozessor 120 die Ausführung wieder aufnehmen kann. Ein beliebiges im Register VISRC gesetztes Bit veranlaßt den Vektorprozessor 120, den Zustand VP_IDLE einzugeben. Wenn das entsprechende Unterbrechungs-Freigabebit in VIMSK gesetzt wird, wird dem Prozessor 110 eine Unterbrechung signalisiert. Tabelle C.6 definiert den Inhalt des Registers VISRC.

Tabelle C.6

VISRC-Definition

Das Vektorunterbrechungs-Befehlsregister VIINS wird mit dem VCINT- oder VCJOIN-Befehl aktualisiert, wenn der VCINT- oder VCJOIN-Befehl zur Unterbrechung des ARM7-Prozessors 110 ausgeführt wird.

Die Vektorzählregister VCR1, VCR2 und VCR3 sind für den Befehl Dekrement und Abzweigung VD1CBR, VD2CBR und VD3CBR und werden mit der Zählung der auszuführenden Schleifen initialisiert. Wenn der Befehl VD1CBR ausgeführt wird, wird das Register VCR1 um 1 vermindert. Wenn der Zählwert nicht Null ist und die in dem Befehl festgelegte Bedingung mit VFLAG übereinstimmt, dann wird die Abzweigung genommen. Wenn nicht, wird die Abzweigung nicht genommen. Das Register VCR1 wird in beiden Fällen um 1 vermindert. Die Register VCR2 und VCR3 werden auf die gleiche Weise verwendet.

Das Vektor-Globalmaskenregister VGMR0 gibt die zu beeinflussenden Elemente des Zielvektorregisters im VEC32-Modus und die Elemente innerhalb VR<287 : 0< im VEC64-Modus an. Jedes Bit in VGMR0 steuert die Aktualisierung von 9 Bits im Zielvektorregister. Insbesondere steuert VGMR0<i< die Aktualisierung von VRd<9i+8 : 9i< im VEC32-Modus und von VR₀d<9i+8 : 9i< im VEC64-Modus. Man bemerke, daß VR₀d das Zielregister in der Gruppe 0 im VEC64-Modus bezeichnet und daß sich VRd auf das Zielregister in der aktuellen Gruppe bezieht, die im VEC32-Modus entweder die Gruppe 0 oder die Gruppe 1 sein kann. Das Vektor-Globalmaskenregister VGMR0 wird bei der Ausführung aller Befehle mit Ausnahme des VCMOVM-Befehls verwendet.

Das Vektor-Globalmaskenregister VGMR1 gibt die Elemente innerhalb VR<575 : 288< an, die im VEC64-Modus beeinflußt werden. Jedes Bit im Register VGMR1 steuert die Aktualisierung von 9 Bits im Zielvektorregister in der Gruppe 1. Insbesondere steuert VGMR1<i< die Aktualisierung von VR₁d<9i+8 : 9i<. Das Register VGMR1 wird im VEC32-Modus nicht verwendet, aber es beeinflußt im VEC64-Modus die Ausführung aller Befehle mit Ausnahme des VCMOVM-Befehls.

Das Vektorüberlaufregister VOR0 gibt die Elemente im VEC32-Modus und die Elemente innerhalb VR<287 : 0< im VEC64-Modus an, die Überlaufergebnisse nach einer arithmetischen Vektoroperation enthalten. Dieses Register wird nicht durch eine arithmetische Skalaroperation modifiziert. Wenn das Bit VOR0<i< gesetzt wird, gibt es an, daß das i-te Element der Byte- oder Byte9-, das (i idiv 2)-te Element der Halbwort- oder das (i idiv 4)-te Element der Wortdatentyp-Operation ein Überlaufergebnis enthält. Zum Beispiel würden das Bit 1 und das Bit 3 gesetzt werden, um den Überlauf des ersten Halbwort- bzw. Wortelements anzuzeigen. Diese Abbildung der Bits in VOR0 unterscheidet sich von der Abbildung der Bits in VGMR0 oder VGMR1.

Das Vektorüberlaufregister VOR1 wird verwendet, um die Elemente innerhalb VR<575 : 288< im VEC64-Modus anzuzeigen, die Überlaufergebnisse nach einer arithmetischen Vektoroperation enthalten. Das Register VOR1 wird im VEC32-Modus nicht verwendet und auch nicht durch eine arithmetische Skalaroperation modifiziert. Wenn das Bit VOR1<i< gesetzt wird, gibt es an, daß das i-te Element der Byte- oder Byte9-, das (i idiv 2)-te Element der Halbwort- oder das (i idiv 4)-te Element der Wortdatentyp-Operation ein Überlaufergebnis enthält. Zum Beispiel würden das Bit 1 und das Bit 3 gesetzt werden, um den Überlauf des ersten Halbwort- bzw. Wortelements in VR<575 : 288< anzuzeigen. Die Abbildung der Bits in VOR1 unterscheidet sich von der Abbildung der Bits in VGMR0 oder VGMR1.

Das Vektor-Befehlsadreßprogrammstop-Register VIABR hilft beim Bereinigen von Vektorprogrammen. Die Registerdefinition ist in Tabelle C.7 dargestellt.

Tabelle C.7

VIABR-Definition

Das Vektor-Datenadreßprogrammstop-Register VDABR hilft beim Bereinigen von Vektorprogrammen. Die Registerdefinition ist in Tabelle C.8 dargestellt.

Tabelle C.8

VDABR-Definition

Das Vektor-Übertragungsmaskenregister VMMR0 wird durch den VCMOVM-Befehl jederzeit verwendet sowie, wenn VCSR<SMM< = 1 für alle Befehle gilt. Das Register VMMR0 gibt die zu beeinflussenden Elemente des Zielvektorregisters im VEC32-Mo­ dus und die Elemente innerhalb VR<287 : 0< im VEC64-Modus an. Jedes Bit in VMMR0 steuert die Aktualisierung von 9 Bits im Zielvektorregister. Insbesondere steuert VMMR0<i< die Aktualisierung von VRd<9i+8 : 9i< im VEC32-Modus und von VR₀d<9i+8 : 9i< im VEC64-Modus. VR0d bezeichnet das Zielregister in der Gruppe 0 im VEC64-Modus und VRd bezieht sich auf das Zielregister in der aktuellen Gruppe, die im VEC32-Modus entweder die Gruppe 0 oder die Gruppe 1 sein kann.

Das Vektor-Übertragungsmaskenregister VMMR1 wird durch den VCMOVM-Befehl jederzeit verwendet sowie, wenn VCSR<SMM< = 1 für alle Befehle gilt. Das Register VMMR1 gibt die Elemente innerhalb VR<575 : 288< an, die im VEC64-Modus beeinflußt werden sollen. Jedes Bit in VMMR1 steuert die Aktualisierung von 9 Bits im Zielvektorregister in der Gruppe 1. Insbesondere steuert VGMR1<i< die Aktualisierung von VR1d<9i+8 : 9i<. Das Register VGMR1 wird im VEC32-Modus nicht verwendet.

Das Vektor- und ARM7-Synchronisationsregister VASYNC stellt eine Erzeuger-/Verbraucher-Synchronisationsart zwischen den Prozessen 110 und 120 bereit. Gegenwärtig ist nur das Bit 30 definiert. Ein ARM7-Prozeß kann auf das Register VASYNC unter Verwendung der Befehle MFER, MTER und TESTSET zugreifen, während sich der Vektorprozessor 120 im Zustand VP_RUN oder im Zustand VP_IDLE befindet. Das Register VASYNC ist für einen ARM7-Prozeß durch die TVP- oder MFVP-Befehle nicht zugänglich, da diese Befehle außerhalb der ersten 16 Spezialregister des Vektorprozessors nicht zugreifen können. Ein Vektorprozeß kann auf das Register VASYNC durch einen VMOV-Befehl zugreifen.

Tabelle C.9 zeigt den Zustand des Vektorprozessors nach einer Rücksetzung durch Netzeinschaltung.

Tabelle C.9

Vektorprozessor-Zustand nach Rücksetzung durch Netzeinschaltung

Die Spezialregister werden durch den ARM7-Prozessor 110 initialisiert, bevor der Vektorprozessor einen Befehl ausführen kann.

ANHANG D

Jeder Befehl impliziert oder spezifiziert den Datentyp der Quellen- und Zieloperanden. Einige Befehle haben eine Semantik, die gleichzeitig auf mehr als einen Datentyp verweisen. Einige Befehle haben eine Semantik, die einen Datentyp für die Quelle nehmen und einen unterschiedlichen Datentyp für das Ergebnis produzieren. Dieser Anhang beschreibt die Datentypen, unterstützt durch eine beispielhafte Ausführung. Tabelle 1 in der Anwendung beschreibt die Datentypen int8, int9, int16, int32 und Gleitkomma, die unterstützt werden. Ganzzahlformate ohne Vorzeichen werden nicht unterstützt und somit muß ein Ganzzahlenwert ohne Vorzeichen zuerst in ein Zweier­ komplement-Format konvertiert werden, bevor es benutzt wird. Der Programmierer ist frei, arithmetische Befehle mit Ganzzahlen ohne Vorzeichen oder anderen Formaten seiner Wahl zu benutzen, solange Überläufe in geeigneter Weise behandelt werden. Die Architektur definiert Überläufe nur von Zweierkomplement-Ganzzahlen- und 32-Bit-Gleitkomma-Datentypen.

Tabelle D.1 zeigt die Datengrößen, die durch die Ladebefehle unterstützt werden.

Tabelle D.1

Datengrößen unterstützt durch die Ladebefehle

Die Architektur spezifiziert die Speicheradressen-Ausrichtung auf die Datentypgrenzen. Das bedeutet, daß für Bytes keine Ausrichtung erforderlich ist. Für ein Halbwort ist die Ausrichtungsanforderung die Halbwortgrenze. Für ein Wort ist die Ausrichtungsanforderung die Wortgrenze.

Tabelle D.2 zeigt die bei den Speicherbefehlen unterstützten Datengrößen.

Tabelle D.2

Datengrößen unterstützt von den Speicherbefehlen

Da mehr als ein Stammtyp in einem Register aufgezeichnet wird, sei es ein Skalar oder Vektor, können Bits im Zielregister sein, die kein definiertes Ergebnis für einige Datentypen haben. Tatsächlich sind, außer für die byte9-Da­ tengrößenoperationen bei einem Vektorzielregister und für die Wortdatengrößenoperation bei einem skalaren Zielregister, Bits im Zielregister, deren Werte durch die Operation nicht definiert sind. Für diese Bits spezifiziert die Architektur, daß deren Werte undefiniert sind. Tabelle D.3 zeigt für jede Datengröße die undefinierten Bits.

Tabelle D.3

Undefinierte Bits für die Datengrößen

Die Programmierer müssen sich der Datentypen der Quell- und Zielregister oder des Speichers bei Programmieren bewußt sein. Eine Datentypumwandlung von einer Elementgröße zu einer anderen macht Ergebnisse in unterschiedlicher Zahl von Elementen möglich, die in einem Vektorregister gespeichert werden. Zum Beispiel erfordert die Umwandlung eines Vektorregisters vom Halbwort- zum Wortdatentyp zwei Vektorregister zum Speichern derselben Anzahl an umgewandelten Elementen. Umgekehrt erzeugt die Umwandlung vom Wortdatentyp, die ein benutzer-definiertes Format im Vektorregister haben kann, zum Halbwortformat die gleiche Zahl von Elementen in einer Hälfte eines Vektorregisters und die verbleibenden Bits in der anderen Hälfte. In beiden Fällen erzeugt die Datentypumwandlung architekturgemäß etwas mit der Anordnung der konvertierten Elemente, was im Format unterschiedlich von den Quellelementen ist.

Grundsätzlich erzeugt die MSP-Architektur keine Operationen, die implizit die Zahl der Elemente im Ergebnis ändern. Die Architektur zeigt, daß der Programmierer sich der Konsequenzen dem Änderns der Zahl der Elemente im Zielregister bewußt sein muß. Die Architektur stellt nur Operationen zur Verfügung, die von einem Datentyp zu einem anderen Datentyp derselben Größe umwandeln und erfordert, daß der Programmierer bezüglich der Unterschiede in den Datengrößen anpaßt beim Umwandeln von einem Datentyp zu einem anderen mit unterschiedlicher Größe.

Spezielle Befehle wie VSHFLL und VUNSHFLL, wie in Anhang E beschrieben, vereinfachen die Umwandlung von einem Vektor einer ersten Datengröße in einen zweiten Vektor mit einer zweiten Datengröße. Die Grundschritte beim Umwandeln von Zweierkomplement-Datentypen von einer kleineren Elementgröße, z. B. int8, in einem Vektor VR_a in eine größere Größe, z. B. int16, sind.

• 1. Vermischen der Elemente in VR_a mit einem anderen Vektor VR_b in zwei Vektoren VR_c:VR_d unter Benutzung des Bytes-Da­ tentypes. Die Elemente in VR_a werden in die unteren Bytes von int16-Datenelementen in ein Doppelgrößenregister VR_c:VR_d übertragen, und die Elemente von VR_b, deren Werte irrelevant sind, werden in die oberen Bytes von VR_c:VR_d übertragen. Diese Operation überträgt effektiv eine Hälfte der Elemente von VR_a in VR_c und die andere Hälfte in VR_d, wobei die Größe jedes Elements von Byte auf Halbwort verdoppelt wird.
• 2. Verschiebe arithmetisch die Elemente in VR_c:VR_d um 8 Bits, um deren Vorzeichen zu erweitern.

Die Grundschritte beim Konvertieren vom Datentyp im Zweierkomplement von einer größeren Elementgröße, z. B. int16, im Vektor VR_a in eine kleinere Größe, z. B. int8, sind:

• 1. Überprüfen zur Sicherstellung, daß jedes Element im int16-Datentyp in Bytegröße darstellbar ist. Wenn notwendig, auffüllen der Elemente an beiden Enden, um sie an die kleinere Größe anzupassen.
• 2. Entmischen der Elemente in VR_a mit dem anderen Vektor VR_b in zwei Vektoren VR_c:VR_d. Die oberen Hälften in jedem Element in VR_a und VR_b werden in VR_c übertragen und die unteren Hälften werden in VR_d übertragen. Dies bewirkt das Sammeln der unteren Hälften aller Elemente in VR_a in die untere Hälfte von VR_d.

Spezielle Befehle werden für folgende Datentyp-Umwandlungen zur Verfügung gestellt: int32 in Gleitkomma einfacher Genauigkeit; Gleitkomma einfacher Genauigkeit in Festkomma, (X, Y Schreibweise); Gleitkomma einfacher Genauigkeit in int32; int8 in int9; int9 in int16; und int16 in int9.

Um Flexibilität bei der Vektorprogrammierung zur Verfügung zu stellen, benutzen die meisten Befehle eine Elementmaske, um nur mit ausgewählten Elementen innerhalb eines Vektors zu operieren. Die Vektorglobalmaskenregister VGMR0 und VGMR1 identifizieren die Elemente, die im Zielregister und im Vektor Akkumulator durch den Vektorbefehl geändert werden. Für Byte- und Byte9-Datengrößenoperationen identifizieren jede der 32 Bits im VGMR0 (oder VGMR1), ein Element, mit dem gearbeitet wird. Bit VGMR0 <i< zeigt wenn gesetzt an, daß das Element i mit Bytegröße betroffen ist, wobei i von 0 bis 31 sein kann. Für Operationen mit Halbwortdatengröße identifiziert jedes Paar von 32 Bits in VGMR0 (oder VGMR1) ein Element, mit dem gearbeitet wird. Bits VGMR0<2i:2i+1< zeigen, wenn gesetzt, an, daß das Element i betroffen ist, wobei i von 0 bis 15 sein kann. Wenn nur ein Bit eines Paares in VGMR0 gesetzt ist für eine Halbwort-Datengrößen-Operation, werden nur die Bits in dem entsprechenden Byte geändert. Für Wortdatengrößen-Operationen identifiziert jeder Satz von vier Bits in VGMR0 (oder VGMR1) ein Element, mit dem gearbeitet wird. Bits VGMR0<4i:4i+3< zeigen, wenn gesetzt, an, daß das Element i betroffen ist, wobei i von 0 bis 7 geht. Wenn nicht alle Bits in einem Satz von vier in VGMR0 gesetzt sind für eine Operation in Datenwortgröße, werden nur die Bits in dem entsprechenden Byte geändert.

VGMR0 und VGMR1 können durch einen Vergleich eines Vektorregisters mit einem Vektor- oder Skalarregister oder mit einem direkten Wert unter Benutzung des VCMPV-Befehls gesetzt werden. Dieser Befehl setzt die Maske entsprechend der spezifizierten Datengröße in geeigneter Weise. Da ein Skalarregister so definiert ist, daß es nur ein Datenelement beinhaltet, werden die skalaren Befehle (das sind die, bei denen die Zielregister Skalare sind) durch die Elementmaske nicht beeinflußt.

Zur Flexibilität bei der Vektorprogrammierung unterstützen die meisten MSP-Befehle drei von Vektor- und Skalaroperationen. Diese sind:

• 1. Vektor = Vektor op Vektor
• 2. Vektor = Vektor op Skalar
• 3. Skalar = Skalar op Skalar

Für den Fall 2, bei dem ein Skalarregister als B-Operand spezifiziert ist, wird das einzige Element in dem Skalarregister so oft wie nötig vervielfacht, um mit der Zahl von Elementen im Vektor A Operanden zusammenzupassen. Die vervielfachten Elemente haben denselben Wert wie das Element im spezifizierten skalaren Operanden. Der skalare Operand kann vom Skalarregister sein oder aus dem Befehl stammen, in Form eines Direktoperanden. Im Falle eines Direktoperanden wird die geeignete Vorzeichenerweiterung angewendet, wenn der spezifizierte Datentyp eine größere Datengröße benutzt, als in der Direktfeldgröße zur Verfügung steht.

In vielen Multimediaanwendungen muß der Genauigkeit der Quelle, des Zwischen- und des Endergebnisses spezielle Aufmerksamkeit geschenkt werden. Zusätzlich erzeugen die Ganzzahl-Multiplikationsbefehle Zwischenergebnisse mit "doppelter Genauigkeit", die in zwei Vektorregistern gespeichert werden können.

Die MSP-Architektur unterstützt derzeitig Zweierkomplemente von Ganzzahlformaten für 8, 9, 16 und 32 Bitelemente und das IEEE 754-Format einfacher Genauigkeit für 32-Bit-Elemente. Ein Überlauf ist für ein Ergebnis definiert, das jenseits des größten positiven oder größten negativen Wertes liegt, der für den spezifizierten Datentyp darstellbar ist. Wenn sich ein Überlauf ereignet, stellt der in das Zielregister geschriebene Wert keine gültige Zahl dar. Ein Unterlauf ist nur definiert für Gleitkommaoperationen.

Wenn nicht anders bemerkt, benutzen alle Gleitkommaoperationen eine von vier Rundungsarten, spezifiziert in den Bits VCSR<RMODE<. Einige Befehle benutzen das, was als "Rundung weg von Null" (gerades Runden) bekannt ist. Diese Befehle werden ausdrücklich benannt.

Sättigung ist eine wichtige Funktion in vielen Multimediaanwendungen. Die MSP-Architektur unterstützt Sättigung in allen vier Ganzzahl- und den Gleitkomma-Ope­ rationen. Bit ISAT in Register VCSR spezifiziert den Ganzzahl-Sättigungsmodus. Der Gleitkommasättigungsmodus, der auch als schneller IEEE-Modus bekannt ist, ist mit den FAST-Bit im VCSR spezifiziert. Wenn der Sättigungsmodus zugelassen ist, wird ein Ergebnis, das jenseits des größten positiven oder größten negativen Wertes ist, entsprechend auf den größten positiven oder größten negativen Wert gesetzt. Ein Überlauf kann in diesem Fall sich nicht ereignen, und ein Überlaufbit kann nicht gesetzt werden.

Tabelle D.4 listet die Genauigkeitsausnahmen auf, die vor der Ausführung des fehlerhaften Befehls erkannt und berichtet werden. Die Ausnahme-Vektoradresse ist in hexadezimaler Notation angegeben.

Tabelle D.4

Genauigkeitsausnahmen

Tabelle D.5 listet Ungenauigkeitsausnahmen auf, die nach der Ausführung einer gewissen Zahl von Befehlen entdeckt und berichtet werden, die später im Programmablauf vorliegen als der fehlerhafte Befehl.

Tabelle D.5

Ungenauigkeitsausnahme

ANHANG E

Der Befehlssatz für den Vektorprozessor umfaßt eine Einteilung in elf Klassen, die in Tabelle E.1 dargestellt sind

Tabelle E.1

Zusammenfassung der Vektorbefehlsklassen

Tabelle E.2 listet die Flußsteuerungsbefehle auf.

Tabelle E.2

Flußsteuerungsbefehle

Die Logikklasse unterstützt die Booleschen Datentypen und wird von der Elementenmaske beeinflußt. Tabelle E.3 listet die Flußsteuerungsbefehle auf.

Tabelle E.3

Logikbefehle

Die Befehle der Verschiebungs-/Rotations-Klasse arbeiten mit den int8-, int9-, int16- und int32-Datentypen (kein Gleitkomma-Datentyp) und werden von der Elementenmaske beeinflußt. Tabelle E.4 listet die Befehle der Verschiebungs-/Rotations-Klasse auf.

Tabelle E.4

Klasse der Verschiebung & Rotation

Die Befehle der Arithmetik-Klasse unterstützen im allgemeinen die int8-, int9-, int16-, int32- und Gleitkomma-Datentypen und werden von der Elementenmaske beeinflußt. Hinsichtlich spezieller Beschränkungen auf nicht-unterstützte Datentypen, siehe die nachstehende ausführliche Beschreibung jedes Befehls. Der VCMPV-Befehl wird nicht von der Elementenmaske beeinflußt, da 25709 00070 552 001000280000000200012000285912559800040 0002019735350 00004 25590er mit der Elementenmaske arbeitet. Tabelle E.5 listet die Befehle der Arithmetik-Klasse auf.

Tabelle E.5

Arithmetik-Klasse

Die MPEG-Befehle sind eine Klasse von Befehlen, die sich besonders für die MPEG-Codierung und -Decodierung eignen, jedoch auch auf verschiedene Arten verwendet werden können. Die MPEG-Befehle unterstützen die int8-, int9-, int16- und int32-Datentypen und werden von der Elementenmaske beeinflußt. Tabelle E.6 listet die MPEG-Befehle auf.

Tabelle E.6

MPEG-Klasse

Jeder Datentyp-Umwandlungsbefehl unterstützt spezielle Datentypen und wird nicht von der Elementenmaske beeinflußt, da die Architektur mehr als einen Datentyp in einem Register nicht unterstützt. Tabelle E.7 listet die Datentyp-Um­ wandlungsbefehle auf.

Tabelle E.7

Datentyp-Umwandlungstabelle

Die Zwischen-Element-Arithmetik-Befehlsklasse unterstützt die int8-, int9-, int16-, int32- und Gleitkomma-Datentypen. Tabelle E.8 listet Befehle der Zwischen-Element-Arithmetik-Klasse auf.

Tabelle E.8

Zwischen-Element-Arithmetik-Klasse

Die Zwischen-Element-Verschiebungs-Befehlsklasse unterstützt Byte-, Byte9-, Halbwort- und Wort-Datenformate. Tabelle E.9 listet die Befehle der Zwischen-Element-Verschiebungsklasse auf.

Tabelle E.9

Zwischen-Element-Verschiebungsklasse

Die Lade-/Speicher-Befehle unterstützen zusätzlich zu den Byte-, Halbwort- und Wort-Datenformaten spezielle, mit dem Byte9 verbundene Datenformat-Operationen und werden nicht von der Elementenmaske beeinflußt. Tabelle E.10 listet Befehle der Lade-/Speicher-Klasse auf.

Tabelle E.10

Lade-/Speicher-Klasse

Die meisten Registerübertragungsbefehle unterstützen die int8-, int9-, int16-, int32- und Gleitkomma-Datentypen und werden nicht von der Elementenmaske beeinflußt. Nur der VCMOVM-Befehl wird von der Elementenmaske beeinflußt. Tabelle E.11 listet die Befehle der Registerübertragungs-Klasse auf:

Tabelle E.11

Registerübertragungsklasse

Tabelle E.12 listet Befehle der Cache-Operations-Klasse auf, die das Cache-Subsystem 130 steuern.

Tabelle E.12

Cache-Operations-Klasse

NOMENKLATUR DER BEFEHLSBESCHREIBUNG

Um die Beschreibung des Befehlssatzes zu erleichtern, wird in den gesamten Anhängen eine spezielle Terminologie verwendet.

Beispielsweise sind die Befehlsoperanden Zweierkomplement-Ganz­ zahlen mit Vorzeichen der Byte-, Byte9-, Halbwort- oder Wortformate, sofern nicht anders ausgewiesen. Der verwendete Begriff "Register" bedeutet ein Universalregister (Skalar- oder Vektorregister). Andere Registerarten werden explizit beschrieben. Bei der Syntax der Assemblersprache kennzeichnen die Suffixe b, b9, h und w sowohl die Datenformate (Byte, Byte9, Halbwort und Wort) als auch die ganzzahligen Datentypen (int8, int9, int16 und int32). Des weiteren sind die Terminologie und Symbole, die zur Beschreibung der Befehlsoperanden, Operationen und der Syntax der Assemblersprache verwendet werden, wie folgt.

Rd Zielregister (Vektor-, Skalar- oder Spezialregister)
Ra, Rb Quellregister a und b (Vektor-, Skalar- oder Spezialregister)
Rc Quell- oder Zielregister c (Vektor- oder Skalarregister)
Rs Speicherdaten-Quellregister (Vektor- oder Skalarregister)
S 32-Bit-Skalar- oder -Spezialregister
VR Vektorregister der aktuellen Gruppe
VRA Vektorregister der alternativen Gruppe
VR₀ Vektorregister der Gruppe 0
VR₁ Vektorregister der Gruppe 1
VRd Zielvektorregister (Standard ist die aktuelle Gruppe, außer wenn VRA angegeben ist)
VRa, VRb Quellvektorregister a und b
VRc Quell- oder Zielvektorregister c
VRs Vektorspeicherdaten-Quellregister
VAC0H Vektor-Akkumulatorregister 0 oberer Bereich
VAC0L Vektor-Akkumulatorregister 0 unterer Bereich
VAC1H Vektor-Akkumulatorregister 1 oberer Bereich
VAC1L Vektor-Akkumulatorregister 1 unterer Bereich
SRd Zielskalarregister
SRa, SRb Quellskalarregister a und b
SRb+ Aktualisierung des Bezugsregisters mit der effektiven Adresse
SRs Skalarspeicherdaten-Quellregister
SP Spezialregister
VR[i] i-tes Element im Vektorregister VR
VR[i] <a:b< Bits a bis b des i-ten Elements im Vektorregister VR
VR[i] <msb< das höchstwertige Bit des i-ten Elements im Vektorregister VR
EA Effektive Adresse für Speicherzugriff
MEM Speicher
BYTE[EA] Ein durch EA adressiertes Byte im Speicher
HALF[EA] Das durch EA adressierte Halbwort im Speicher. Die Bits <15 : 8< werden durch EA+1 adressiert.
WORD[EA] Ein durch EA adressiertes Wort im Speicher. Die Bits <31 : 24< werden durch EA+3 adressiert.
NumElem gibt die Anzahl der Elemente für einen gegebenen Datentyp an. Es ist 32, 16 oder 8 für die Byte- und Byte9-, Halbwort- bzw. Wort-Da­ tenformate im VEC32-Modus. Es ist 64, 32 oder 16 für die Byte- und Byte9-, Halbwort- bzw. Wort-Datenformate im VEC64-Modus. Für Skalaroperationen ist NumElem 0.
EMASK[i] gibt die Elementenmaske für das i-te Element an. Es stellt 1, 2 oder 4 Bits in VGMR0/1, ∼ VGMR0/1, VMMR0/1 oder VMMR0/1 für die Byte- und Byte9-, Halbwort- bzw. Wort-Datenformate dar. Für Skalaroperationen wird angenommen, daß die Elementenmaske gesetzt ist, selbst wenn EMASK[i] = 0.
NMASK[i] gibt die Elementenmaske für das i-te Element an. Es stellt 1, 2 oder 4 Bits in VMMR0 oder VMMR1 für die Byte- und Byte9-, Halbwort- bzw. Wort-Datenformate dar.
VCSR Vektorsteuer- und Statusregister
VCSR<x< bezeichnet ein Bit oder Bits in VCSR. Das "x" ist ein Feldname.
VPC Vektorprozessor-Programmzähler
VECSIZE Die Vektorregistergröße ist 32 im VEC32- und 64 im VEC64-Modus.
SPAD Arbeitspuffer
Die Konstrukte der C-Programmierung werden verwendet, um die Flußsteuerung der Operationen zu beschreiben. Ausnahmen sind nachstehend angegeben:
= Zuweisung
: Verkettung
{x || y} gibt eine Auswahl aus x oder y an (kein logisches oder)
sex Vorzeichenerweiterung für festgelegtes Datenformat
sex_dp Vorzeichenerweiterung für doppelte Genauigkeit von festgelegtem Datenformat
sign » Vorzeichen-erweiterte (arithmetische) Verschiebung nach rechts
zex Null-Erweiterung für festgelegtes Datenformat
zero » Null-erweiterte (logische) Verschiebung nach rechts
« Verschiebung nach links (Einfüllen von Nullen)
trnc7 Abschneiden der führenden 7 Bits (eines Halbworts)
trnc1 Abschneiden des führenden 1 Bits (eines Byte9) Modulo-Operator
|Ausdruck| Absolutwert des Ausdrucks
/ Division (für Gleitkomma-Datentyp, verwendet einen der vier IEEE-Rundungsmodi)
// Division (verwendet den Rundungsmodus "von Null weg runden")
Sättigung() Sättigung zum negativsten oder positivsten Wert anstatt Erzeugung eines Überlaufs, für ganzzahlige Datentypen. Für Gleitkomma-Da­ tentypen kann die Sättigung zu positiv Uneridlich, positiv Null, negativ Null oder negativ Unendlich sein.

Allgemeine Befehlsformate sind in Fig. 8 dargestellt und werden nachstehend beschrieben.

Das REAR-Format wird durch die Lade-, Speicher- und Cache-Operationsbefehle verwendet und die Felder im REAR-Format haben die nachstehenden Bedeutungen, wie in Tabelle E.13 angegeben.

Tabelle E.13

REAR-Format

Die Bits 17 : 15 sind reserviert und sollten Nullen sein, um die Verträglichkeit mit zukünftigen Erweiterungen in der Architektur zu gewährleisten. Bestimmte Codierungen der B:D- und TT-Felder sind nicht definiert.

Programmierer sollten diese Codierungen nicht verwenden, da die Architektur nicht das erwartete Ergebnis angibt, wenn eine solche Codierung verwendet wird. Tabelle E.14 zeigt sowohl im VEC32- als auch im VEC64-Modus unterstützte Skalarladeoperationen (im TT-Feld als LT codiert)

Tabelle E.14

REAR-Ladeoperationen im VEC32- und VEC64-Modus

Tabelle E.15 zeigt im VEC32-Modus unterstützte Vektorladeoperationen (im TT-Feld als LT codiert), der vorliegt, wenn das Bit VCSR<0< gelöscht ist.

Tabelle E.15

REAR-Ladeoperationen im VEC32-Modus

Das B-Bit wird verwendet, um die aktuelle oder alternative Gruppe anzuzeigen.

Tabelle E.16 zeigt im VEC64-Modus unterstützte Vektorladeoperationen (im TT-Feld als LT codiert), der vorliegt, wenn das VCSR<0<-Bit gesetzt ist.

Tabelle E.16

REAR-Ladeoperationen im VEC32-Modus

Das Bit B wird verwendet, um die 64-Byte-Vektoroperation anzuzeigen, da das Konzept der aktuellen und alternativen Gruppe im VEC64-Modus nicht existiert.

Tabelle E.17 listet sowohl im VEC32- als auch im VEC64-Modus unterstützte Skalarspeicheroperationen auf (im TT-Feld als ST codiert).

Tabelle E.17

REAR-Skalarspeicheroperationen

Tabelle E.18 listet die im VEC32-Modus unterstützten Vektorspeicheroperationen auf (im TT-Feld als ST codiert), der vorliegt, wenn das VCSR<0<-Bit gelöscht ist.

Tabelle E.18

REAR-Vektorspeicheroperationen im VEC32-Modus

Tabelle E.19 listet im VEC64-Modus unterstützte Vektorspeicheroperationen auf (im TT-Feld als ST codiert), der vorliegt, wenn das VCSR<0<-Bit gesetzt ist.

Tabelle E.19

REAR-Vektorspeicheroperationen im VEC32-Modus

Das Bit B wird verwendet, um die 64-Byte-Vektoroperation anzuzeigen, da das Konzept der aktuellen und alternativen Gruppe im VEC64-Modus nicht existiert.

Das REAl-Format wird durch die Lade-, Speicher- und Cache-Operationsbefehle verwendet. Tabelle E.20 zeigt die Bedeutungen der Felder im REAI-Format.

Tabelle E.20

REAI-Format

Die REAR- und REAI-Formate verwenden identische Codierungen für die Übertragungsarten. Vgl. das REAR-Format für weitere Einzelheiten zur Codierung.

Das RRRM5-Format stellt drei Register oder zwei Register und einen 5-Bit-Direktoperanden bereit. Tabelle E.21 definiert das Feld für das RRRM5-Format.

Tabelle E.21

RRRM5-Format

Die Bits 19 : 15 sind reserviert und müssen Nullen sein, um die Verträglichkeit mit zukünftigen Erweiterungen in der Architektur zu gewährleisten.

Alle Vektorregister-Operanden beziehen sich auf die aktuelle Gruppe (die entweder die Gruppe 0 oder die Gruppe 1 sein kann), sofern nicht anders festgelegt. Tabelle E.22 listet die D:S:M-Codierungen auf, wenn DS<1:0< 00, 01 oder 10 ist.

ATabelle E.22

RRRM5 D:S:M-Codierungen für DS ungleich 11

Die D:S:M-Codierungen haben die nachstehenden Bedeutungen, wenn DS<1 : 0< 11 ist:

Tabelle E.23

RRRM5 D:S:M-Codierungen für DS gleich 11

Das RRRR-Format stellt vier Registeroperanden bereit. Tabelle E.24 zeigt die Felder im RRRR-Format.

Tabelle E.24

RRRR-Format

Alle Vektorregister-Operanden beziehen sich auf die aktuelle Gruppe (die entweder die Gruppe 0 oder die Gruppe 1 sein kann), sofern nicht anders festgelegt.

Das RI-Format wird nur durch den Befehl unmittelbares Laden verwendet. Tabelle E.25 gibt die Felder im RI-Format an.

Tabelle E.25

RI-Format

Bestimmte Codierungen des F:DS<1 : 0<-Feldes sind nicht definiert. Programmierer sollten diese Codierungen nicht verwenden, da die Architektur nicht das erwartete Ergebnis angibt, wenn eine solche Codierung verwendet wird. Der in Rd geladene Wert hängt vom Datentyp ab, wie in Tabelle E.26 dargestellt.

Tabelle E.26

RI-Format geladener Werte

Das CT-Format umfaßt die in Tabelle E.27 dargestellten Felder.

Tabelle E.27

CT-Format

Die Verzweigungsbedingungen verwenden das Feld VCSR[GT:EQ:LT]. Die Überlaufbedingung verwendet das Bit VCSR[SO], das vor den GT-, EQ- und LT-Bits Vorrang hat, wenn es gesetzt ist. VCCS und VCBARR interpretieren das Feld Cond<2 : 0< anders als vorstehend beschrieben. Vgl. deren ausführliche Befehlsbeschreibung.

Das RRRM9-Format gibt drei Register oder zwei Register und einen 9-Bit-Direktoperanden an. Tabelle E.28 gibt die Felder des RRRM9-Formats an.

Tabelle E.28

RRRM9-Format

Die Bits 19 : 15 sind reserviert, wenn die D:S:M-Codierung keinen Direktoperanden festlegt, und müssen Nullen sein, um eine zukünftige Verträglichkeit zu gewährleisten.

Alle Vektorregister-Operanden beziehen sich auf die aktuelle Gruppe (die entweder die Gruppe 0 oder die Gruppe 1 sein kann), sofern nicht anders festgelegt. Die D:S:M-Codierungen sind identisch mit jenen, die in den Tabellen E.22 und E.23 für das RRRM5-Format dargestellt sind, ausgenommen, daß unmittelbare Werte, die aus dem unmittelbaren Feld extrahiert sind, von der DS<1 : 0<-Codierung abhängen, wie in Tabelle E.29 gezeigt.

Tabelle E.29

Unmittelbare Werte im RRRM9-Format

Das unmittelbare Format ist nicht verfügbar mit dem Gleitkomma-Datentyp.

Nachstehend erscheinen die MSP-Vektorbefehle in alphabetischer Reihenfolge. Anmerkung:

• 1. Ein Befehl wird von der Elementenmaske beeinflußt, sofern nicht anders ausgewiesen. Die CT-Format-Befehle werden nicht von der Elementenmaske beeinflußt. Die REAR- und REAl-Format-Befehle, die aus den Lade-, Speicher- und Cache-Befehlen bestehen, werden ebenfalls nicht von der Elementenmaske beeinflußt.
• 2. Der 9-Bit-Direktoperand ist nicht verfügbar mit dem Gleitkomma-Datentyp.
• 3. In der Operationsbeschreibung ist nur die Vektorform gegeben. Für eine Skalaroperation nehme man an, daß nur eines, nämlich das 0. Element definiert ist.
• 4. Für die RRRM5- und RRRM9-Formate werden die nachstehenden Codierungen für die ganzzahligen Datentypen verwendet (b, b9, h, w):
• 5. Für die RRRM5- und RRRM9-Formate werden die nachstehenden Codierungen für den Gleitkomma-Datentyp verwendet:
• 6. Für alle Befehle, die einen Überlauf verursachen können, werden maximale oder minimale Grenzen der Sättigung auf int8, int9, int16, int32 angewendet, wenn das Bit VCSR<ISAT< gesetzt ist. Entsprechend wird ein Gleitkom­ ma-Ergebnis auf -Unendlich, -Null, +Null oder +Unendlich gesättigt, wenn das Bit VCSR<FSAT< gesetzt ist.
• 7. Syntaktisch kann .n anstelle von .b9 verwendet werden, um das Byte9-Datenformat zu kennzeichnen.
• 8. Das Gleitkomma-Ergebnis, das zum Zielregister oder zum Vektorakkumulator zurückgegeben wird, ist für alle Befehle vom Format IEEE 754 mit einfacher Genauigkeit.

Das Gleitkomma-Ergebnis wird in den unteren Bereich des Akkumulators geschrieben und der obere Bereich wird nicht modifiziert.

ANHANG G Querverweise auf Anmeldungen, die mit der vorliegenden Anmeldung in Zusammenhang stehen

Diese Patentunterlagen beziehen sich auch auf die folgenden eingereichten Patentanmeldungen, die hiermit durch Bezugnahme eingeschlossen werden sollen:
U.S.-Anmeldung Nr. UNBEKANNT1, Anwaltsunterlagen Nr. M-4354, Titel: "Multiprocessor Operation in a Multimedia Signal Processor";
U.S.-Anmeldung Nr. UNBEKANNT3, Anwaltsunterlagen Nr. M-4365, Titel: "Efficient Context Saving and Restoring in Multiprocessors";
U.S.-Anmeldung Nr. UNBEKANNT4, Anwaltsunterlagen Nr. M-4366, Titel: "System and Method for Handling Software Interrupts with Argument Passing";
U.S.-Anmeldung Nr. UNBEKANNT5, Anwaltsunterlagen Nr. M-4367, Titel: "System and Method for Handling Interrupts and Exception Events in an Asymmetric Multiprocessor Architecture;
U.S.-Anmeldung Nr. UNBEKANNT6, Anwaltsunterlagen Nr. M-4368, Titel: "Methods and Apparatus for Processing Video Data";
U.S.-Anmeldung Nr. UNBEKANNT7, Anwaltsunterlagen Nr. M-4369, Titel: "Single-Instruction-Multiple-Data Processing Using Multiple Banks of Vector Registers"; und
U.S.-Anmeldung Nr. UNBEKANNT8, Anwaltsunterlagen Nr. M-4370, Titel: "Single-Instruction-Multiple-Data Processing with Combined Scalar/Vector Operations".

Claims (6)

1. Ein Vektorprozessor, der aufweist:
ein Registerfile, das Vektorregister aufweist,
einen Decodierer, der während des Decodierens eines Befehls ein ausgewähltes Vektorregister vom Registerfile identifiziert und eine Größe für Datenelemente, die während der Ausführung des Befehls bearbeitet werden sollen, identifiziert, und
einen Verarbeitungsschaltungsaufbau, der an das Vektorregister gekoppelt ist, wobei der Verarbeitungsschaltungsaufbau beim Ausführen des Befehls eine Anzahl von parallelen Operationen an Daten von dem ausgewählten Vektorregister durchführt, wobei die Anzahl von parallelen Operationen durch die Größe für die Datenelemente gesteuert wird.

2. Vektorprozessor nach Anspruch 1, bei dem jedes Vektorregister eine festgelegte Größe aufweist.

3. Vektorprozessor nach Anspruch 1, bei dem mögliche Größen, die der Decodierer identifizieren kann, 8 Bits, 9 Bits, 16 Bits und 32 Bits sind.

4. Vektorprozessor nach Anspruch 1, bei dem der Decodierer während des Decodierens eines Befehls einen Typ für Datenelemente, die während der Ausführung des Befehls verarbeitet werden sollen, identifiziert.

5. Vektorprozessor nach Anspruch 4, bei dem mögliche Typen, die der Decodierer identifizieren kann, Ganzzahl-Da­ tentypen und Fließkomma-Datentypen einschließen.

6. Ein Verfahren zum Betreiben eines Vektorprozessors, das aufweist:
Speichern von Daten in einem Vektorregister,
Bilden eines Befehls, der eine Registerzahl, die das
Vektorregister identifiziert, und ein Größenfeld, das eine Größe für Datenelemente im Vektorregister identifiziert, einschließt, und
Ausführen des Befehls durch Ausführen einer Anzahl von parallelen Operationen, wobei jede der Operationen einem Datenelement im Vektorregister entspricht und wobei das Größenfeld die Anzahl von parallel ausgeführten Operationen steuert.