DE19735348A1 - Einzelbefehl-Mehrdaten-Verarbeitung unter Verwendung von mehreren Bänken von Vektorregistern - Google Patents
Einzelbefehl-Mehrdaten-Verarbeitung unter Verwendung von mehreren Bänken von VektorregisternInfo
- Publication number
- DE19735348A1 DE19735348A1 DE19735348A DE19735348A DE19735348A1 DE 19735348 A1 DE19735348 A1 DE 19735348A1 DE 19735348 A DE19735348 A DE 19735348A DE 19735348 A DE19735348 A DE 19735348A DE 19735348 A1 DE19735348 A1 DE 19735348A1
- Authority
- DE
- Germany
- Prior art keywords
- register
- vector
- bank
- processor
- registers
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 239000013598 vector Substances 0.000 title claims abstract description 355
- 238000000034 method Methods 0.000 claims description 25
- 238000012545 processing Methods 0.000 claims description 19
- 230000015654 memory Effects 0.000 abstract description 21
- 239000000872 buffer Substances 0.000 description 26
- 238000012546 transfer Methods 0.000 description 23
- 238000010586 diagram Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 12
- 239000008186 active pharmaceutical agent Substances 0.000 description 9
- 238000006243 chemical reaction Methods 0.000 description 8
- 230000000295 complement effect Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 238000006073 displacement reaction Methods 0.000 description 4
- 238000002156 mixing Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 240000001987 Pyrus communis Species 0.000 description 2
- 238000007792 addition Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000003252 repetitive effect Effects 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000002405 diagnostic procedure Methods 0.000 description 1
- 230000008571 general function Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- NRBNGHCYDWUVLC-UHFFFAOYSA-N mtep Chemical compound S1C(C)=NC(C#CC=2C=NC=CC=2)=C1 NRBNGHCYDWUVLC-UHFFFAOYSA-N 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 238000009738 saturating Methods 0.000 description 1
- 238000005204 segregation Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000001356 surgical procedure Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
- G06F9/30025—Format conversion instructions, e.g. Floating-Point to Integer, decimal conversion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
- G06F15/76—Architectures of general purpose stored program computers
- G06F15/80—Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
- G06F15/8053—Vector processors
- G06F15/8076—Details on data register access
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30007—Arrangements for executing specific machine instructions to perform operations on data operands
- G06F9/30036—Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
- G06F9/30109—Register structure having multiple operands in a single register
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/30105—Register structure
- G06F9/30112—Register structure comprising data of variable length
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/3012—Organisation of register space, e.g. banked or distributed register file
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30098—Register arrangements
- G06F9/3012—Organisation of register space, e.g. banked or distributed register file
- G06F9/3013—Organisation of register space, e.g. banked or distributed register file according to data content, e.g. floating-point registers, address registers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30145—Instruction analysis, e.g. decoding, instruction word fields
- G06F9/3016—Decoding the operand specifier, e.g. specifier format
- G06F9/30167—Decoding the operand specifier, e.g. specifier format of immediate specifier, e.g. constants
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30181—Instruction operation extension or modification
- G06F9/30189—Instruction operation extension or modification according to execution mode, e.g. mode flag
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
ausreichenden 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-
Datenelemente 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-
Operationen 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-
Operationen 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-
Operationen 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 Lade-/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 Ziel- 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-
Logikeinheiten 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-
Steuerung 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-
Bibliotheken 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-
Verarbeitung ü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-
Prozessor 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-
Skalarregister, 32-Bit-Spezialanwendungsregister, zwei
Bänke von 288-Bit-Vektorregistern und zwei Doppelgrößen-
Vektorakkumulatorregister (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-
Vektorregisterzahl 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-
Registerzahlen 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.
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-
Vektorregister nicht benutzt. Ein 288-Bit-Vektorregister
kann zweiunddreißig 8-Bit- oder 9-Bit-Ganzzahl-
Datenelemente (ganzzahlige Datenelemente), sechzehn 16-Bit-
Ganzzahl-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. des 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-
Befehl 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-/Speicher
einheit 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-
Zwischenspeicher 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-
Zwischenspeicher 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-
Zwischenspeicher 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 jedes 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-/Speicheroperationen und den Logik-/Arithmetikoperationen
vorhanden. Vergleiche der Feldwerte im FIFO-
Zwischenspeicher 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-
Subsystem 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-
Operationen 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-
Datenbus 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-/Speichereinheit 250 oder durch Multiplexer 622 und 624
über einen Multiplizierer 620, eine Arithmetik-Logik-
Einheit 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-
Multiplizierer, der acht unabhängige 36×36-Bit-
Multiplizierer 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-
Multiplizierer, 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-
Datenelementgröße und 512 Bits bei anderen Datengrößen.
Die ALU 630 kann das resultierende 576-Bit- oder 512-Bit-
Ergebnis 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-
Einheit für Gleitkomma-Additionen und -Multiplikationen.
Ein weiterer Schaltungsaufbau implementiert Ganzzahl-
Verschiebungs-, 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-
Datenelemente 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-/Speichereinheit 250 die Operation bearbeitet.
Fig. 7 zeigt ein Ausführungsbeispiel der
Lade-/Speichereinheit 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-
Subsystem richten, während andere Aufrufe anhängig sind.
Folglich wird die Lade-/Speichereinheit 250 nicht
aufgehalten. Die Anzahl von Taktzyklen, die das Cache-
Subsystem 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-/Speichereinheit 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
Ziel- bzw. Bestimmungsregister Rd 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-
Direktwert 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.
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.
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.
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.
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.
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.
Die Felder im Format entsprechen folgender Vereinbarung:
Die erweiterten ARM-Befehle sind in alphabetischer
Reihenfolge beschrieben.
STC{cond} p15,cOpc, <Address<
CACHE{cond} Opc, <Address<
wobei cond = {eq, he, cs, cc, mi, pl, vs, vc, hi, Is, ge, It, 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.
CACHE{cond} Opc, <Address<
wobei cond = {eq, he, cs, cc, mi, pl, vs, vc, hi, Is, ge, It, 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.
Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft.
Der Opc<3 : 0< spezifiziert die folgenden Betriebsarten:
Es kann auf das ARM7-Datenblatt Bezug genommen werden, wie
der EA errechnet wird.
ARM7 Schutzverletzung.
CDP{cond} p7, 1, c0, c0, co
INTVP{cond}
wobei cond = {eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, ns}.
INTVP{cond}
wobei cond = {eq, ne, cs, cc, mi, pl, vs, vc, hi, ls, ge, lt, gt, le, al, ns}.
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.
Vektorprozessor nicht verfügbar.
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 = {0, . . . 15} und RNAME Bezug nimmt auf die durch die Architektur spezifizierte Registerart (d. h. PERO oder CSR).
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 = {0, . . . 15} und RNAME Bezug nimmt auf die durch die Architektur spezifizierte Registerart (d. h. PERO oder CSR).
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.
Schutzverletzung, wenn versucht wird, auf PERx während des
Benutzermodus zuzugreifen.
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({c0, . . . c15}, CRm = {c0, . . . c15} und RNAME Bezug nimmt auf die architekturmäßig spezifizierte Registerart (d. h. SP0 oder VCS).
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).
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.
Vektorprozessor nicht verfügbar.
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 = {0, . . . 15} und RNAME bezieht sich auf die architekturmäßige spezifizierte Registerart (d. h. PERO oder CSR).
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 = {0, . . . 15} und RNAME bezieht sich auf die architekturmäßige spezifizierte Registerart (d. h. PERO oder CSR).
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.
Schutzverletzung wenn versucht wird im Benutzermodus auf
PERx zuzugreifen.
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 = ({c0, . . . c15}, CRm = {c0, . . . c15} und RNAME Bezug nimmt auf die architekturmäßig spezifizierte Registerart (d. h. SP0 oder VCS).
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).
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.
Vektorprozessor nicht verfügbar.
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.
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.
Dieser Befehl wird nur ausgeführt, wenn Cond zutrifft.
Auf die durch den EA spezifizierte Cacheleitung wird in
den ARM7 Datencache vorgegriffen.
In bezug auf das ARM7-Datenblatt dahingehend wie der EA
berechnet wird.
Ausnahme: keine.
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}.
STARTVP{cond}
wobei cond = {eq, he, cs, cc, mi, pl, vs, vc, hi, Is, ge, it, gt, le, al, nv}.
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<. ARM 7 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.
Vektorprozessor nicht verfügbar.
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 = {r0, . . . r15}, ER = {0, . . . 15} und RNAME nimmt Bezug auf die architekturmäßig spezifizierte Registerbedeutung (d. h., UER1 oder VASYNC).
TESTSET{cond} Rd, RNAME
wobei cond = {eq, he, cs, cc, mi, pl, rs, re, hi, ls, ge, lt, gt, le, al, nv}, Rd = {r0, . . . r15}, ER = {0, . . . 15} und RNAME nimmt Bezug auf die architekturmäßig spezifizierte Registerbedeutung (d. h., UER1 oder VASYNC).
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-
Warteschleife implementiert werden kann.
Zur Zeit ist nur UER1 definiert, mit diesem Befehl zu
arbeiten.
Bits 19 : 17 und 7 : 5 sind reserviert.
Ausnahmen: keine
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
dem Multimedia-Signalprozessors verwendet. Sie sind in
Tabelle B.1 gezeigt.
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.
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.
Das Prozessor-Versionsregister identifiziert die spezielle
Version des einzelnen Prozessors aus der Multimedia-
Signalprozessor-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.
Das ARM7-Befehlsadressen-Unterbrechungspunkt-Register
unterstützt bei der Fehlersuche von ARM7-Programmen. Die
Registerdefinition ist in Tabelle B.5 gezeigt.
Das ARM7-Datenadreß-Unterbrechungspunkt-Register
unterstützt bei der Fehlersuche von ARM7-Programmen. Die
Registerdefinition ist in Tabelle B.6 gezeigt.
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.
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.9 zeigt die Zustände der erweiterten Register
beim Zurücksetzen beim Anschalten.
Der architekturgemäße Zustand des Vektorprozessors 120
umfaßt: 32 32-Bit-Skalarregister; 2 Gruppen von 32 288-Bit-
Vektorregistern; 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-
Architektur definiert fünf Elementformate, die in Tabelle C.1
dargestellt sind.
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-
Zielskalarregisters. 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.
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
über ihre Werte machen.
Das Vektor-Akkumulatorregister ist vorgesehen, um eine
Speicherung eines Zwischenergebnisses bereit zustellen, 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.
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.
Die Definition des Vektorsteuer- und Statusregisters VCSR ist
in Tabelle C.5 dargestellt.
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.
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.
Das Vektor-Datenadreßprogrammstop-Register VDABR hilft beim
Bereinigen von Vektorprogrammen. Die Registerdefinition ist
in Tabelle C.8 dargestellt.
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-
Modus 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.
Die Spezialregister werden durch den ARM7-Prozessor 110
initialisiert, bevor der Vektorprozessor einen Befehl
ausführen kann.
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.
Die Architektur entdeckt nicht Überträge von 8, 9, 16 oder
32-Bit-Operationen, die notwendig sind, um Überläufe ohne
Vorzeichen zu entdecken.
Tabelle D.1 zeigt die Datengrößen, die durch die Ladebefehle
unterstützt werden.
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.
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-
Datengröß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.
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 des Ä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 VRa in eine größere Größe, z. B.
int16, sind:
- 1. Vermischen der Elemente in VRa mit einem anderen Vektor VRb in zwei Vektoren VRc : VRd unter Benutzung des Bytes- Datentypes. Die Elemente in VRa werden in die unteren Bytes von int16-Datenelementen in ein Doppelgrößenregister VRc : VRd übertragen, und die Elemente von VRb, deren Werte irrelevant sind, werden in die oberen Bytes von VRc : VRd übertragen. Diese Operation überträgt effektiv eine Hälfte der Elemente. von VRa in VRc und die andere Hälfte in VRd, wobei die Größe jedes Elements von Byte auf Halbwort verdoppelt wird.
- 2. Verschiebe arithmetisch die Elemente in VRc : VRd 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 VRa 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 VRa mit dem anderen Vektor VRb in zwei Vektoren VRc : VRd. Die oberen Hälften in jedem Element in VRa und VRb werden in VRc übertragen und die unteren Hälften werden in VRd übertragen. Dies bewirkt das Sammeln der unteren Hälften aller Elemente in VRa in die untere Hälfte von VRd.
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-
Operationen. 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ä 29625 00070 552 001000280000000200012000285912951400040 0002019735348 00004 29506ttigungsmodus 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.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.
Der Befehlssatz für den Vektorprozessor umfaßt eine
Einteilung in elf Klassen, die in Tabelle E.1 dargestellt
sind.
Tabelle E.2 listet die Flußsteuerungsbefehle auf.
Die Logikklasse unterstützt die Booleschen Datentypen und
wird von der Elementenmaske beeinflußt. Tabelle E.3 listet
die Flußsteuerungsbefehle auf.
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.
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 er mit der Elementenmaske arbeitet. Tabelle
E.5 listet die Befehle der Arithmetik-Klasse auf.
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.
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-
Umwandlungsbefehle auf.
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.
Die Zwischen-Element-Verschiebungs-Befehlsklasse unterstützt
Byte-, Byte9-, Halbwort- und Wort-Datenformate. Tabelle E.9
listet die Befehle der Zwischen-Element-Verschiebungsklasse
auf.
Die Lade-/Speicher-Befehle unterstützen zusätzlich zu den
Byte-, Halbwort- und Wort-Datenformaten spezielle, mit dem
Byte 9 verbundene Datenformat-Operationen und werden nicht von
der Elementenmaske beeinflußt. Tabelle E.10 listet Befehle
der Lade-/Speicher-Klasse auf.
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.12 listet Befehle der Cache-Operations-Klasse auf,
die das Cache-Subsystem 130 steuern.
Um die Beschreibung des Befehlssatzes zu erleichtern, wird in
den gesamten Anhängen eine spezielle Terminologie verwendet.
Beispielsweise sind die Befehlsoperanden Zweierkomplement-
Ganzzahlen 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- Datenformate 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
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- Datenformate 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- Datentypen kann die Sättigung zu positiv Unendlich, positiv Null, negativ Null oder negativ Unendlich sein.
= 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- Datentypen kann die Sättigung zu positiv Unendlich, 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.
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.15 zeigt im VEC32-Modus unterstützte
Vektorladeoperationen (im TT-Feld als LT codiert), der
vorliegt, wenn das Bit VCSR<0< gelöscht ist.
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.
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.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.19 listet im VEC64-Modus unterstützte
Vektorspeicheroperationen auf (im TT-Feld als ST codiert),
der vorliegt, wenn das VCSR<0<-Bit gesetzt ist.
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 REAI-Format wird durch die Lade-, Speicher- und Cache-
Operationsbefehle verwendet. Tabelle E.20 zeigt die
Bedeutungen der Felder im 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.
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.
Die D : S : M-Codierungen haben die nachstehenden Bedeutungen,
wenn DS<1 : 0< 11 ist:
Das RRRR-Format stellt vier Registeroperanden bereit. Tabelle
E.24 zeigt die Felder im 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.
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.
Das CT-Format umfaßt die in Tabelle E.27 dargestellten
Felder.
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.
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.
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 REAI-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 Gleitkomma- 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.
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. UNBEKANNT2, Anwaltsunterlagen Nr. M- 4355, Titel: "Single-Instruction-Multiple-Data Processing 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"; und
U.S.-Anmeldung Nr. UNBEKANNT8, Anwaltsunterlagen Nr. M- 4370, Titel: "Single-Instruction-Multiple-Data Processing with Combined Scalar/Vector Operations".
U.S.-Anmeldung Nr. UNBEKANNT1, Anwaltsunterlagen Nr. M- 4354, Titel: "Multiprocessor Operation in a Multimedia Signal Processor";
U.S.-Anmeldung Nr. UNBEKANNT2, Anwaltsunterlagen Nr. M- 4355, Titel: "Single-Instruction-Multiple-Data Processing 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"; und
U.S.-Anmeldung Nr. UNBEKANNT8, Anwaltsunterlagen Nr. M- 4370, Titel: "Single-Instruction-Multiple-Data Processing with Combined Scalar/Vector Operations".
Claims (8)
1. Ein Vektorprozessor mit:
einer ersten Bank von Vektorregistern, wobei jedem Vektorregister in der ersten Bank eine Registerzahl zugeordnet ist, die sich von Registerzahlen unterscheidet, die anderen Vektorregistern in der ersten Bank zugeordnet sind,
einer zweiten Bank von Vektorregistern, wobei jedem Vektorregister in der zweiten Bank eine Registerzahl zugeordnet ist, die sich von Registerzahlen unterscheidet, die anderen Vektorregistern in der zweiten Bank zugeordnet sind, die aber die gleiche ist wie die Registerzahl, die dem entsprechenden Vektorregister in der ersten Bank zugeordnet ist,
einem Steuerregister, das ein Vorgabe-Bankfeld einschließt, und
einem Auswahlschaltungsaufbau für die erste und die zweite Bank der Vektorregister, wobei der Auswahlschaltungsaufbau in einem ersten Modus betrieben werden kann, um auf ein Vektorregister zuzugreifen, das durch eine Kombination einer Registerzahl von einem Befehl, der durch den Vektorprozessor ausgeführt wird, und einem Wert von dem Vorgabe-Bankfeld identifiziert wird.
einer ersten Bank von Vektorregistern, wobei jedem Vektorregister in der ersten Bank eine Registerzahl zugeordnet ist, die sich von Registerzahlen unterscheidet, die anderen Vektorregistern in der ersten Bank zugeordnet sind,
einer zweiten Bank von Vektorregistern, wobei jedem Vektorregister in der zweiten Bank eine Registerzahl zugeordnet ist, die sich von Registerzahlen unterscheidet, die anderen Vektorregistern in der zweiten Bank zugeordnet sind, die aber die gleiche ist wie die Registerzahl, die dem entsprechenden Vektorregister in der ersten Bank zugeordnet ist,
einem Steuerregister, das ein Vorgabe-Bankfeld einschließt, und
einem Auswahlschaltungsaufbau für die erste und die zweite Bank der Vektorregister, wobei der Auswahlschaltungsaufbau in einem ersten Modus betrieben werden kann, um auf ein Vektorregister zuzugreifen, das durch eine Kombination einer Registerzahl von einem Befehl, der durch den Vektorprozessor ausgeführt wird, und einem Wert von dem Vorgabe-Bankfeld identifiziert wird.
2. Vektorprozessor nach Anspruch 1, bei dem der
Auswahlschaltungsaufbau in einem zweiten Modus betrieben
werden kann, um auf ein erstes Vektorregister der ersten
Bank und auf ein zweites Vektorregister von der zweiten
Bank zuzugreifen, wobei sowohl das erste als auch das
zweite Register einer Registerzahl eines Befehls, der durch
den Vektorprozessor ausgeführt wird, zugeordnet ist und
wobei die Kombination des ersten und des zweiten Registers
für einen Vektorwert verwendet wird, der größer ist als
derjenige, der im ersten Vektorregister gespeichert werden
könnte.
3. Vektorprozessor nach Anspruch 2, bei dem der
Auswahlschaltungsaufbau in einem dritten Modus betrieben
werden kann, um auf ein Vektorregister zuzugreifen, das
durch eine Kombination einer Registerzahl und eines
Bankwerts von einem Befehl, der durch den Vektorprozessor
ausgeführt wird, identifiziert wird.
4. Vektorprozessor nach Anspruch 1, bei dem der
Auswahlschaltungsaufbau in einem zweiten Modus betrieben
werden kann, um auf ein Vektorregister zuzugreifen, das
durch eine Kombination einer Registerzahl und eines
Bankwerts von einem Befehl, der durch den Vektorprozessor
ausgeführt wird, identifiziert wird.
5. Vektorprozessor nach Anspruch 4, bei dem der
Auswahlschaltungsaufbau für Befehle, die logische
Operationen, die an Vektorgrößen durchgeführt werden,
darstellen, im ersten Modus betrieben wird und für
Lade-/Speicher-Operationen im zweiten Modus betrieben wird.
6. Ein Verfahren zum Betreiben eines Vektorprozessors,
das aufweist:
Zuordnen von Registerzahlen für Vektorregister in einer ersten Bank, wobei sich die für jedes Vektorregister in der ersten Bank zugeordnete Registerzahl von Registerzahlen unterscheidet, die anderen Vektorregistern in der ersten Bank zugeordnet sind,
Zuordnen von Registerzahlen für Vektorregister in einer zweiten Bank, wobei sich die für jedes Vektorregister in der zweiten Bank zugeordnete Registerzahl von Registerzahlen unterscheidet, die anderen Vektorregistern in der zweiten Bank zugeordnet sind, und wobei die für jedes Vektorregister in der zweiten Bank zugeordnete Registerzahl die gleiche ist, wie eine Registerzahl, die einem entsprechenden Vektorregister in der ersten Bank zugeordnet ist,
Bilden eines Befehls, der eine Registerzahl einschließt, und
Ausführen des Befehls, wobei das Ausführen des Befehls ein Zugreifen auf ein Vektorregister einschließt, welchem die Registerzahl zugeordnet ist, die im Befehl und in einer Bank, die durch ein Feld eines Steuerregisters des Vektorprozessors angezeigt wird, eingeschlossen ist.
Zuordnen von Registerzahlen für Vektorregister in einer ersten Bank, wobei sich die für jedes Vektorregister in der ersten Bank zugeordnete Registerzahl von Registerzahlen unterscheidet, die anderen Vektorregistern in der ersten Bank zugeordnet sind,
Zuordnen von Registerzahlen für Vektorregister in einer zweiten Bank, wobei sich die für jedes Vektorregister in der zweiten Bank zugeordnete Registerzahl von Registerzahlen unterscheidet, die anderen Vektorregistern in der zweiten Bank zugeordnet sind, und wobei die für jedes Vektorregister in der zweiten Bank zugeordnete Registerzahl die gleiche ist, wie eine Registerzahl, die einem entsprechenden Vektorregister in der ersten Bank zugeordnet ist,
Bilden eines Befehls, der eine Registerzahl einschließt, und
Ausführen des Befehls, wobei das Ausführen des Befehls ein Zugreifen auf ein Vektorregister einschließt, welchem die Registerzahl zugeordnet ist, die im Befehl und in einer Bank, die durch ein Feld eines Steuerregisters des Vektorprozessors angezeigt wird, eingeschlossen ist.
7. Verfahren nach Anspruch 6, das weiterhin aufweist:
Bilden eines zweiten Befehls, der eine Registerzahl einschließt, und
Ausführen des zweiten Befehls, wobei das Ausführen des zweiten Befehls das Zugreifen auf ein erstes Vektorregister, welchem die Registerzahl zugeordnet ist und welches in der ersten Bank ist, und Zugreifen auf ein zweites Vektorregister, welchem die Registerzahl zugeordnet ist und welches in der zweiten Bank ist, einschließt.
Bilden eines zweiten Befehls, der eine Registerzahl einschließt, und
Ausführen des zweiten Befehls, wobei das Ausführen des zweiten Befehls das Zugreifen auf ein erstes Vektorregister, welchem die Registerzahl zugeordnet ist und welches in der ersten Bank ist, und Zugreifen auf ein zweites Vektorregister, welchem die Registerzahl zugeordnet ist und welches in der zweiten Bank ist, einschließt.
8. Verfahren nach Anspruch 7, bei dem das Zugreifen auf
das erste und das zweite Vektorregister das Verarbeiten
eines einzelnen Vektors aufweist, der einen ersten Satz von
Datenelementen, die im ersten Vektorregister gespeichert
sind, und einen zweiten Satz von Datenelementen, die im
zweiten Vektorregister gespeichert sind, aufweist.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/697,086 US5838984A (en) | 1996-08-19 | 1996-08-19 | Single-instruction-multiple-data processing using multiple banks of vector registers |
US08/697,086 | 1996-08-19 |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19735348A1 true DE19735348A1 (de) | 1998-03-12 |
DE19735348B4 DE19735348B4 (de) | 2006-10-05 |
Family
ID=24799731
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19735348A Expired - Lifetime DE19735348B4 (de) | 1996-08-19 | 1997-08-14 | Vektorprozessor zur Einzelbefehl-Mehrdaten-Verarbeitung unter Verwendung von mehreren Bänken von Vektorregistern und zugehöriges Verfahren zum Betreiben desselben |
Country Status (7)
Country | Link |
---|---|
US (1) | US5838984A (de) |
JP (1) | JP3983857B2 (de) |
KR (1) | KR100236527B1 (de) |
CN (1) | CN1117316C (de) |
DE (1) | DE19735348B4 (de) |
FR (1) | FR2752965B1 (de) |
TW (1) | TW345650B (de) |
Families Citing this family (132)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6643765B1 (en) | 1995-08-16 | 2003-11-04 | Microunity Systems Engineering, Inc. | Programmable processor with group floating point operations |
US5961631A (en) * | 1997-07-16 | 1999-10-05 | Arm Limited | Data processing apparatus and method for pre-fetching an instruction in to an instruction cache |
US5864703A (en) * | 1997-10-09 | 1999-01-26 | Mips Technologies, Inc. | Method for providing extended precision in SIMD vector arithmetic operations |
US7197625B1 (en) * | 1997-10-09 | 2007-03-27 | Mips Technologies, Inc. | Alignment and ordering of vector elements for single instruction multiple data processing |
US6230259B1 (en) | 1997-10-31 | 2001-05-08 | Advanced Micro Devices, Inc. | Transparent extended state save |
US6157996A (en) * | 1997-11-13 | 2000-12-05 | Advanced Micro Devices, Inc. | Processor programably configurable to execute enhanced variable byte length instructions including predicated execution, three operand addressing, and increased register space |
US6334176B1 (en) * | 1998-04-17 | 2001-12-25 | Motorola, Inc. | Method and apparatus for generating an alignment control vector |
US6282634B1 (en) * | 1998-05-27 | 2001-08-28 | Arm Limited | Apparatus and method for processing data having a mixed vector/scalar register file |
US6862563B1 (en) | 1998-10-14 | 2005-03-01 | Arc International | Method and apparatus for managing the configuration and functionality of a semiconductor design |
US20060168431A1 (en) * | 1998-10-14 | 2006-07-27 | Peter Warnes | Method and apparatus for jump delay slot control in a pipelined processor |
US7308559B2 (en) * | 2000-02-29 | 2007-12-11 | International Business Machines Corporation | Digital signal processor with cascaded SIMD organization |
WO2001069411A2 (en) | 2000-03-10 | 2001-09-20 | Arc International Plc | Memory interface and method of interfacing between functional entities |
JP3940542B2 (ja) * | 2000-03-13 | 2007-07-04 | 株式会社ルネサステクノロジ | データプロセッサ及びデータ処理システム |
JP2001283413A (ja) * | 2000-03-29 | 2001-10-12 | Tdk Corp | スピンバルブ膜の製造方法 |
US6857061B1 (en) * | 2000-04-07 | 2005-02-15 | Nintendo Co., Ltd. | Method and apparatus for obtaining a scalar value directly from a vector register |
US6981132B2 (en) | 2000-08-09 | 2005-12-27 | Advanced Micro Devices, Inc. | Uniform register addressing using prefix byte |
US6877084B1 (en) | 2000-08-09 | 2005-04-05 | Advanced Micro Devices, Inc. | Central processing unit (CPU) accessing an extended register set in an extended register mode |
US7155601B2 (en) * | 2001-02-14 | 2006-12-26 | Intel Corporation | Multi-element operand sub-portion shuffle instruction execution |
US7162621B2 (en) | 2001-02-21 | 2007-01-09 | Mips Technologies, Inc. | Virtual instruction expansion based on template and parameter selector information specifying sign-extension or concentration |
US7599981B2 (en) * | 2001-02-21 | 2009-10-06 | Mips Technologies, Inc. | Binary polynomial multiplier |
US7711763B2 (en) | 2001-02-21 | 2010-05-04 | Mips Technologies, Inc. | Microprocessor instructions for performing polynomial arithmetic operations |
US7181484B2 (en) * | 2001-02-21 | 2007-02-20 | Mips Technologies, Inc. | Extended-precision accumulation of multiplier output |
US7039060B2 (en) * | 2001-03-07 | 2006-05-02 | Mips Tech Inc | System and method for extracting fields from packets having fields spread over more than one register |
US7127593B2 (en) * | 2001-06-11 | 2006-10-24 | Broadcom Corporation | Conditional execution with multiple destination stores |
US6986025B2 (en) * | 2001-06-11 | 2006-01-10 | Broadcom Corporation | Conditional execution per lane |
US7861071B2 (en) * | 2001-06-11 | 2010-12-28 | Broadcom Corporation | Conditional branch instruction capable of testing a plurality of indicators in a predicate register |
US7725521B2 (en) * | 2001-10-29 | 2010-05-25 | Intel Corporation | Method and apparatus for computing matrix transformations |
US7631025B2 (en) * | 2001-10-29 | 2009-12-08 | Intel Corporation | Method and apparatus for rearranging data between multiple registers |
US7685212B2 (en) * | 2001-10-29 | 2010-03-23 | Intel Corporation | Fast full search motion estimation with SIMD merge instruction |
US7739319B2 (en) * | 2001-10-29 | 2010-06-15 | Intel Corporation | Method and apparatus for parallel table lookup using SIMD instructions |
US7818356B2 (en) * | 2001-10-29 | 2010-10-19 | Intel Corporation | Bitstream buffer manipulation with a SIMD merge instruction |
US7624138B2 (en) | 2001-10-29 | 2009-11-24 | Intel Corporation | Method and apparatus for efficient integer transform |
US20040054877A1 (en) * | 2001-10-29 | 2004-03-18 | Macy William W. | Method and apparatus for shuffling data |
US20100274988A1 (en) * | 2002-02-04 | 2010-10-28 | Mimar Tibet | Flexible vector modes of operation for SIMD processor |
US20030231660A1 (en) * | 2002-06-14 | 2003-12-18 | Bapiraju Vinnakota | Bit-manipulation instructions for packet processing |
US7793084B1 (en) | 2002-07-22 | 2010-09-07 | Mimar Tibet | Efficient handling of vector high-level language conditional constructs in a SIMD processor |
US7392368B2 (en) * | 2002-08-09 | 2008-06-24 | Marvell International Ltd. | Cross multiply and add instruction and multiply and subtract instruction SIMD execution on real and imaginary components of a plurality of complex data elements |
WO2004015563A1 (en) * | 2002-08-09 | 2004-02-19 | Intel Corporation | Multimedia coprocessor control mechanism including alignment or broadcast instructions |
US6986023B2 (en) * | 2002-08-09 | 2006-01-10 | Intel Corporation | Conditional execution of coprocessor instruction based on main processor arithmetic flags |
GB2394571B (en) * | 2002-10-23 | 2005-08-10 | Motorola Inc | Arrangement system and method for vector permutation in single-instruction multiple-data microprocessors |
JP2004302647A (ja) * | 2003-03-28 | 2004-10-28 | Seiko Epson Corp | ベクトルプロセッサおよびレジスタのアドレス指定方法 |
US20040215924A1 (en) * | 2003-04-28 | 2004-10-28 | Collard Jean-Francois C. | Analyzing stored data |
US7610466B2 (en) * | 2003-09-05 | 2009-10-27 | Freescale Semiconductor, Inc. | Data processing system using independent memory and register operand size specifiers and method thereof |
US7315932B2 (en) | 2003-09-08 | 2008-01-01 | Moyer William C | Data processing system having instruction specifiers for SIMD register operands and method thereof |
US7275148B2 (en) * | 2003-09-08 | 2007-09-25 | Freescale Semiconductor, Inc. | Data processing system using multiple addressing modes for SIMD operations and method thereof |
GB2409068A (en) * | 2003-12-09 | 2005-06-15 | Advanced Risc Mach Ltd | Data element size control within parallel lanes of processing |
GB2409060B (en) * | 2003-12-09 | 2006-08-09 | Advanced Risc Mach Ltd | Moving data between registers of different register data stores |
GB2409064B (en) * | 2003-12-09 | 2006-09-13 | Advanced Risc Mach Ltd | A data processing apparatus and method for performing in parallel a data processing operation on data elements |
GB2409065B (en) * | 2003-12-09 | 2006-10-25 | Advanced Risc Mach Ltd | Multiplexing operations in SIMD processing |
GB2409067B (en) * | 2003-12-09 | 2006-12-13 | Advanced Risc Mach Ltd | Endianess compensation within a SIMD data processing system |
GB2411974C (en) * | 2003-12-09 | 2009-09-23 | Advanced Risc Mach Ltd | Data shift operations |
GB2409063B (en) * | 2003-12-09 | 2006-07-12 | Advanced Risc Mach Ltd | Vector by scalar operations |
GB2409061B (en) * | 2003-12-09 | 2006-09-13 | Advanced Risc Mach Ltd | Table lookup operation within a data processing system |
GB2411975B (en) * | 2003-12-09 | 2006-10-04 | Advanced Risc Mach Ltd | Data processing apparatus and method for performing arithmetic operations in SIMD data processing |
GB2409066B (en) * | 2003-12-09 | 2006-09-27 | Advanced Risc Mach Ltd | A data processing apparatus and method for moving data between registers and memory |
GB2409059B (en) * | 2003-12-09 | 2006-09-27 | Advanced Risc Mach Ltd | A data processing apparatus and method for moving data between registers and memory |
GB2409062C (en) * | 2003-12-09 | 2007-12-11 | Advanced Risc Mach Ltd | Aliasing data processing registers |
GB2411976B (en) * | 2003-12-09 | 2006-07-19 | Advanced Risc Mach Ltd | A data processing apparatus and method for moving data between registers and memory |
GB2411973B (en) * | 2003-12-09 | 2006-09-27 | Advanced Risc Mach Ltd | Constant generation in SMD processing |
GB2410097B (en) * | 2004-01-13 | 2006-11-01 | Advanced Risc Mach Ltd | A data processing apparatus and method for performing data processing operations on floating point data elements |
GB2411978B (en) * | 2004-03-10 | 2007-04-04 | Advanced Risc Mach Ltd | Inserting bits within a data word |
US7302627B1 (en) * | 2004-04-05 | 2007-11-27 | Mimar Tibet | Apparatus for efficient LFSR calculation in a SIMD processor |
US7873812B1 (en) | 2004-04-05 | 2011-01-18 | Tibet MIMAR | Method and system for efficient matrix multiplication in a SIMD processor architecture |
US7493481B1 (en) * | 2004-05-17 | 2009-02-17 | Netxen, Inc. | Direct hardware processing of internal data structure fields |
US9557994B2 (en) | 2004-07-13 | 2017-01-31 | Arm Limited | Data processing apparatus and method for performing N-way interleaving and de-interleaving operations where N is an odd plural number |
US20060070042A1 (en) * | 2004-09-24 | 2006-03-30 | Muratori Richard D | Automatic clocking in shared-memory co-simulation |
US20060179265A1 (en) * | 2005-02-08 | 2006-08-10 | Flood Rachel M | Systems and methods for executing x-form instructions |
US20060218377A1 (en) * | 2005-03-24 | 2006-09-28 | Stexar Corporation | Instruction with dual-use source providing both an operand value and a control value |
US7933405B2 (en) * | 2005-04-08 | 2011-04-26 | Icera Inc. | Data access and permute unit |
US20070038984A1 (en) * | 2005-08-12 | 2007-02-15 | Gschwind Michael K | Methods for generating code for an architecture encoding an extended register specification |
US7421566B2 (en) * | 2005-08-12 | 2008-09-02 | International Business Machines Corporation | Implementing instruction set architectures with non-contiguous register file specifiers |
US7734897B2 (en) * | 2005-12-21 | 2010-06-08 | Arm Limited | Allocation of memory access operations to memory access capable pipelines in a superscalar data processing apparatus and method having a plurality of execution threads |
US20070283129A1 (en) * | 2005-12-28 | 2007-12-06 | Stephan Jourdan | Vector length tracking mechanism |
US7565514B2 (en) * | 2006-04-28 | 2009-07-21 | Freescale Semiconductor, Inc. | Parallel condition code generation for SIMD operations |
US7958181B2 (en) | 2006-09-21 | 2011-06-07 | Intel Corporation | Method and apparatus for performing logical compare operations |
US9223751B2 (en) * | 2006-09-22 | 2015-12-29 | Intel Corporation | Performing rounding operations responsive to an instruction |
US8127113B1 (en) | 2006-12-01 | 2012-02-28 | Synopsys, Inc. | Generating hardware accelerators and processor offloads |
JPWO2008087779A1 (ja) * | 2007-01-19 | 2010-05-06 | 日本電気株式会社 | アレイ型プロセッサおよびデータ処理システム |
US20080229062A1 (en) * | 2007-03-12 | 2008-09-18 | Lorenzo Di Gregorio | Method of sharing registers in a processor and processor |
US8156307B2 (en) * | 2007-08-20 | 2012-04-10 | Convey Computer | Multi-processor system having at least one processor that comprises a dynamically reconfigurable instruction set |
US8122229B2 (en) * | 2007-09-12 | 2012-02-21 | Convey Computer | Dispatch mechanism for dispatching instructions from a host processor to a co-processor |
US8561037B2 (en) | 2007-08-29 | 2013-10-15 | Convey Computer | Compiler for generating an executable comprising instructions for a plurality of different instruction sets |
US8095735B2 (en) * | 2008-08-05 | 2012-01-10 | Convey Computer | Memory interleave for heterogeneous computing |
US9015399B2 (en) | 2007-08-20 | 2015-04-21 | Convey Computer | Multiple data channel memory module architecture |
US9710384B2 (en) * | 2008-01-04 | 2017-07-18 | Micron Technology, Inc. | Microprocessor architecture having alternative memory access paths |
CN101377735B (zh) * | 2007-08-28 | 2011-09-28 | 凌阳科技股份有限公司 | 于多模处理器中以串行位决定指令长度的装置及方法 |
US8078836B2 (en) | 2007-12-30 | 2011-12-13 | Intel Corporation | Vector shuffle instructions operating on multiple lanes each having a plurality of data elements using a common set of per-lane control bits |
US8205066B2 (en) * | 2008-10-31 | 2012-06-19 | Convey Computer | Dynamically configured coprocessor for different extended instruction set personality specific to application program with shared memory storing instructions invisibly dispatched from host processor |
US20100115233A1 (en) * | 2008-10-31 | 2010-05-06 | Convey Computer | Dynamically-selectable vector register partitioning |
US8423745B1 (en) | 2009-11-16 | 2013-04-16 | Convey Computer | Systems and methods for mapping a neighborhood of data to general registers of a processing element |
US8434074B2 (en) * | 2010-02-24 | 2013-04-30 | Intel Corporation | Register allocation with SIMD architecture using write masks |
KR20110103256A (ko) * | 2010-03-12 | 2011-09-20 | 삼성전자주식회사 | 다중 입출력 오퍼레이션 지원 프로세서 및 그 방법 |
US20120185670A1 (en) * | 2011-01-14 | 2012-07-19 | Toll Bret L | Scalar integer instructions capable of execution with three registers |
US9128701B2 (en) * | 2011-04-07 | 2015-09-08 | Via Technologies, Inc. | Generating constant for microinstructions from modified immediate field during instruction translation |
KR20120134549A (ko) | 2011-06-02 | 2012-12-12 | 삼성전자주식회사 | Simd 프로세서를 이용한 병렬 연산 처리 장치 및 방법 |
KR101877347B1 (ko) | 2011-09-26 | 2018-07-12 | 인텔 코포레이션 | 벡터 로드-op/저장-op에 스트라이드 기능을 제공하는 명령어 및 로직 |
KR101783312B1 (ko) * | 2011-11-15 | 2017-10-10 | 삼성전자주식회사 | 클러스터 간의 통신으로 인한 오버헤드를 최소화하는 장치 및 방법 |
WO2013085491A1 (en) * | 2011-12-06 | 2013-06-13 | Intel Corporation | System, apparatus and method for translating vector instructions |
CN104011645B (zh) * | 2011-12-22 | 2018-06-26 | 英特尔公司 | 用于产生其中在连续位置中的整数相差恒定整数跨度且最小整数从零偏移整数偏移量的整数序列的处理器、方法、系统和含有指令的介质 |
CN107102844B (zh) * | 2011-12-23 | 2021-06-08 | 英特尔公司 | 超级乘加(超级madd)指令 |
CN106775592B (zh) | 2011-12-23 | 2019-03-12 | 英特尔公司 | 处理器、用于计算系统的方法、机器可读介质和计算机系统 |
CN104081337B (zh) * | 2011-12-23 | 2017-11-07 | 英特尔公司 | 用于响应于单个指令来执行横向部分求和的系统、装置和方法 |
CN104025025B (zh) | 2011-12-28 | 2018-08-28 | 英特尔公司 | 用于对打包数据元素执行增量编码的系统、装置和方法 |
US9557998B2 (en) | 2011-12-28 | 2017-01-31 | Intel Corporation | Systems, apparatuses, and methods for performing delta decoding on packed data elements |
EP2798464B8 (de) * | 2011-12-30 | 2019-12-11 | Intel Corporation | Komprimierte drehprozessoren, verfahren, systeme und anweisungen |
US10289412B2 (en) * | 2012-02-09 | 2019-05-14 | Qualcomm Incorporated | Floating point constant generation instruction |
WO2013180712A1 (en) * | 2012-05-30 | 2013-12-05 | Intel Corporation | Vector and scalar based modular exponentiation |
US10430190B2 (en) | 2012-06-07 | 2019-10-01 | Micron Technology, Inc. | Systems and methods for selectively controlling multithreaded execution of executable code segments |
CN102819692A (zh) * | 2012-08-10 | 2012-12-12 | 上海交通大学 | 基于fpga的rna二级结构预测装置、系统及其实现方法 |
CN102930008B (zh) * | 2012-10-29 | 2015-10-07 | 无锡江南计算技术研究所 | 向量查表方法 |
US9639371B2 (en) | 2013-01-29 | 2017-05-02 | Advanced Micro Devices, Inc. | Solution to divergent branches in a SIMD core using hardware pointers |
CN104375803B (zh) * | 2013-08-13 | 2017-10-24 | 华为技术有限公司 | 一种数据处理的方法及装置 |
CN104461939A (zh) * | 2014-12-16 | 2015-03-25 | 清华大学 | 扩展处理器寄存器堆容量的方法 |
US10296489B2 (en) * | 2014-12-27 | 2019-05-21 | Intel Corporation | Method and apparatus for performing a vector bit shuffle |
US10296334B2 (en) * | 2014-12-27 | 2019-05-21 | Intel Corporation | Method and apparatus for performing a vector bit gather |
US10503502B2 (en) | 2015-09-25 | 2019-12-10 | Intel Corporation | Data element rearrangement, processors, methods, systems, and instructions |
GB2543303B (en) * | 2015-10-14 | 2017-12-27 | Advanced Risc Mach Ltd | Vector data transfer instruction |
US9733899B2 (en) * | 2015-11-12 | 2017-08-15 | Arm Limited | Lane position information for processing of vector |
US10152321B2 (en) * | 2015-12-18 | 2018-12-11 | Intel Corporation | Instructions and logic for blend and permute operation sequences |
US20170177350A1 (en) * | 2015-12-18 | 2017-06-22 | Intel Corporation | Instructions and Logic for Set-Multiple-Vector-Elements Operations |
CN111176608A (zh) * | 2016-04-26 | 2020-05-19 | 中科寒武纪科技股份有限公司 | 一种用于执行向量比较运算的装置和方法 |
CN107315568B (zh) | 2016-04-26 | 2020-08-07 | 中科寒武纪科技股份有限公司 | 一种用于执行向量逻辑运算的装置 |
CN108009976A (zh) * | 2016-10-27 | 2018-05-08 | 超威半导体公司 | 用于图形处理单元(gpu)计算的超级单指令多数据(超级simd) |
US10216479B2 (en) * | 2016-12-06 | 2019-02-26 | Arm Limited | Apparatus and method for performing arithmetic operations to accumulate floating-point numbers |
EP3747167B1 (de) | 2018-02-19 | 2022-08-31 | Huawei Technologies Co., Ltd. | Multi-cloud-vpc-routing und registrierung |
JP7296574B2 (ja) * | 2019-03-04 | 2023-06-23 | パナソニックIpマネジメント株式会社 | プロセッサ及びプロセッサの制御方法 |
US11132198B2 (en) * | 2019-08-29 | 2021-09-28 | International Business Machines Corporation | Instruction handling for accumulation of register results in a microprocessor |
CN110727412B (zh) * | 2019-09-14 | 2022-01-07 | 无锡江南计算技术研究所 | 一种基于掩码的混合浮点乘法低功耗控制方法及装置 |
US11551148B2 (en) * | 2020-04-29 | 2023-01-10 | Marvell Asia Pte Ltd | System and method for INT9 quantization |
CN112230995B (zh) * | 2020-10-13 | 2024-04-09 | 广东省新一代通信与网络创新研究院 | 一种指令的生成方法、装置以及电子设备 |
CN113064841B (zh) * | 2021-01-04 | 2023-06-06 | 统信软件技术有限公司 | 一种数据存储方法、处理方法、计算设备及可读存储介质 |
CN115794671B (zh) * | 2023-02-07 | 2023-04-14 | 成都申威科技有限责任公司 | 一种兼容向量数据的访存系统及方法 |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS59160267A (ja) * | 1983-03-02 | 1984-09-10 | Hitachi Ltd | ベクトル処理装置 |
US4791555A (en) * | 1983-10-24 | 1988-12-13 | International Business Machines Corporation | Vector processing unit |
JPH0648486B2 (ja) * | 1986-10-08 | 1994-06-22 | 日本電気株式会社 | ベクトルデ−タ処理装置 |
JP2679994B2 (ja) * | 1987-08-14 | 1997-11-19 | 株式会社日立製作所 | ベクトル処理装置 |
JP2941817B2 (ja) * | 1988-09-14 | 1999-08-30 | 株式会社日立製作所 | ベクトル処理装置 |
US5226142A (en) * | 1990-11-21 | 1993-07-06 | Ross Technology, Inc. | High performance register file with overlapping windows |
US5493687A (en) * | 1991-07-08 | 1996-02-20 | Seiko Epson Corporation | RISC microprocessor architecture implementing multiple typed register sets |
US5438669A (en) * | 1991-11-20 | 1995-08-01 | Hitachi, Ltd. | Data processor with improved loop handling utilizing improved register allocation |
JP2823767B2 (ja) * | 1992-02-03 | 1998-11-11 | 松下電器産業株式会社 | レジスタファイル |
JPH06274528A (ja) * | 1993-03-18 | 1994-09-30 | Fujitsu Ltd | ベクトル演算処理装置 |
JP2883784B2 (ja) * | 1993-04-27 | 1999-04-19 | 株式会社東芝 | マイクロコンピュータ |
US5669013A (en) * | 1993-10-05 | 1997-09-16 | Fujitsu Limited | System for transferring M elements X times and transferring N elements one time for an array that is X*M+N long responsive to vector type instructions |
WO1995032466A1 (en) * | 1994-05-19 | 1995-11-30 | Vlsi Technology, Inc. | Flexible register mapping scheme |
-
1996
- 1996-08-19 US US08/697,086 patent/US5838984A/en not_active Expired - Lifetime
-
1997
- 1997-04-07 KR KR1019970012770A patent/KR100236527B1/ko not_active IP Right Cessation
- 1997-08-14 DE DE19735348A patent/DE19735348B4/de not_active Expired - Lifetime
- 1997-08-18 FR FR9710436A patent/FR2752965B1/fr not_active Expired - Lifetime
- 1997-08-19 TW TW086111968A patent/TW345650B/zh not_active IP Right Cessation
- 1997-08-19 CN CN97117403A patent/CN1117316C/zh not_active Expired - Lifetime
- 1997-08-19 JP JP23766597A patent/JP3983857B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
KR19980018072A (ko) | 1998-06-05 |
US5838984A (en) | 1998-11-17 |
CN1174353A (zh) | 1998-02-25 |
CN1117316C (zh) | 2003-08-06 |
TW345650B (en) | 1998-11-21 |
KR100236527B1 (ko) | 1999-12-15 |
DE19735348B4 (de) | 2006-10-05 |
JPH10116268A (ja) | 1998-05-06 |
FR2752965B1 (fr) | 2004-09-24 |
JP3983857B2 (ja) | 2007-09-26 |
FR2752965A1 (fr) | 1998-03-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19735348B4 (de) | Vektorprozessor zur Einzelbefehl-Mehrdaten-Verarbeitung unter Verwendung von mehreren Bänken von Vektorregistern und zugehöriges Verfahren zum Betreiben desselben | |
DE19735350B4 (de) | Vektorprozessor zum Ausführen paralleler Operationen und Verfahren hierfür | |
DE69233412T2 (de) | Vorrichtung und Rechnerprogrammprodukt zur Ausführung von Verzweigungsbefehlen | |
DE102018005181B4 (de) | Prozessor für einen konfigurierbaren, räumlichen beschleuniger mit leistungs-, richtigkeits- und energiereduktionsmerkmalen | |
DE19914210B4 (de) | Verfahren und Prozessor für eine gestaffelte Ausführung einer Anweisung | |
DE60010907T2 (de) | Sram-steuerungvorrichtung für parallele prozessorarchitektur mit adressen- und befehlswarteschlange und arbiter | |
DE69627807T2 (de) | Datenprozessor zum gleichzeitigen Dataladen und Durchführung einer multiplizier-addier Operation | |
DE2903349C2 (de) | Prozessor und Verfahren zur Datenverarbeitung | |
DE102018006889A1 (de) | Prozessoren und Verfahren für bevorzugte Auslegung in einem räumlichen Array | |
DE102018005216A1 (de) | Prozessoren, Verfahren und Systeme für einen konfigurierbaren, räumlichen Beschleuniger mit Transaktions- und Wiederholungsmerkmalen | |
DE102018005172A1 (de) | Prozessoren, verfahren und systeme mit einem konfigurierbaren räumlichen beschleuniger | |
DE60011797T2 (de) | Ausführung von mehreren fäden in einem parallelprozessor | |
DE69933088T2 (de) | Vliw-verarbeiter verarbeitet befehle von verschiedenen breiten | |
DE102018126650A1 (de) | Einrichtung, verfahren und systeme für datenspeicherkonsistenz in einem konfigurierbaren räumlichen beschleuniger | |
DE69814268T2 (de) | Verfahren zur Anbindung eines Prozessors an einen Koprozessor | |
DE102018005169A1 (de) | Prozessoren und verfahren mit konfigurierbaren netzwerkbasierten datenflussoperatorschaltungen | |
DE102008005515A1 (de) | Virtuelle Architektur und virtueller Befehlssatz für die Berechnung paralleler Befehlsfolgen | |
DE60316151T2 (de) | Zugriff zum breiten speicher | |
DE69636861T2 (de) | Mikroprozessor mit Lade-/Speicheroperation zu/von mehreren Registern | |
DE102016006400A1 (de) | Hardware-prozessoren und verfahren für eng-gekoppelte heterogene datenverarbeitung | |
DE102015002215A1 (de) | Sortierbeschleunigungsprozessor, -Verfahren, -Systeme und -Befehle | |
DE69826404T2 (de) | Datenverarbeitungssystem mit mehreren Prozessoren, die eine Registerbank gemeinsam benutzen | |
DE102018125232A1 (de) | Einrichtung und Verfahren für komplexe Multiplikation und Akkumulation | |
DE112012003864T5 (de) | Mehrfach adressierbare Registerdateien und dazugehörige Formatumwandlungen | |
JPH0578863B2 (de) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
8110 | Request for examination paragraph 44 | ||
8364 | No opposition during term of opposition | ||
R071 | Expiry of right |