DE69520707T2 - Vektorverarbeitungseinheit mit rekonfigurierbarem Datenpuffer - Google Patents

Vektorverarbeitungseinheit mit rekonfigurierbarem Datenpuffer

Info

Publication number
DE69520707T2
DE69520707T2 DE69520707T DE69520707T DE69520707T2 DE 69520707 T2 DE69520707 T2 DE 69520707T2 DE 69520707 T DE69520707 T DE 69520707T DE 69520707 T DE69520707 T DE 69520707T DE 69520707 T2 DE69520707 T2 DE 69520707T2
Authority
DE
Germany
Prior art keywords
data
buffers
vector
memory
load
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
DE69520707T
Other languages
English (en)
Other versions
DE69520707D1 (de
Inventor
Makoto Omata
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NEC Corp
Original Assignee
NEC Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by NEC Corp filed Critical NEC Corp
Publication of DE69520707D1 publication Critical patent/DE69520707D1/de
Application granted granted Critical
Publication of DE69520707T2 publication Critical patent/DE69520707T2/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00Digital computers in general; Data processing equipment in general
    • G06F15/76Architectures of general purpose stored program computers
    • G06F15/80Architectures of general purpose stored program computers comprising an array of processing units with common control, e.g. single instruction multiple data processors
    • G06F15/8053Vector processors
    • G06F15/8076Details on data register access
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/30007Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/30036Instructions to perform operations on packed data, e.g. vector, tile or matrix operations
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30003Arrangements for executing specific machine instructions
    • G06F9/3004Arrangements for executing specific machine instructions to perform operations on memory
    • G06F9/30043LOAD or STORE instructions; Clear instruction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/30098Register arrangements
    • G06F9/30105Register structure
    • G06F9/30112Register structure comprising data of variable length
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/30Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3824Operand accessing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Computing Systems (AREA)
  • Complex Calculations (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Description

    HINTERGRUND DER ERFINDUNG Gebiet der Erfindung
  • Die vorliegende Erfindung bezieht sich auf eine Vektorverarbeitungseinheit und insbesondere auf eine Vektorverarbeitungseinheit mit einem Datenpuffer zwischen einem Speicher und einem Vektorprozessor.
  • Beschreibung des Standes der Technik
  • In einer Vektorverarbeitungseinheit mit gemeinsam genutztem Speicher tendiert der physikalische Abstand zum Speicher dazu, länger zu werden, wenn die Größe des Systems mit Blick auf den Zusammenbau größer wird. Deshalb erfordert der Speicherzugriff viel Zeit.
  • Die Vektorverarbeitungseinheit erreicht durch die gleichzeitige, kontinuierliche arithmetische Verarbeitung einer großen Menge von Daten eine arithmetische Hochgeschwindigkeitsverarbeitung. Das heißt, nachdem eine Gruppe von Operanden aus dem Speicher in ein Vektorregister geladen ist, wird die arithmetische Verarbeitung ausgeführt, indem der arithmetische Operand aus dem Vektorregister einem Prozessor zugeführt wird. Dann wird das Ergebnis abermals in dem Vektorregister gespeichert, dessen Inhalte wiederum im Speicher gespeichert werden.
  • In Fig. 10 ist ein Beispiel des Betriebs in einer herkömmlichen Vektorverarbeitungseinheit gezeigt, in der die Vektorverarbeitung durch das Übertragen der Daten zwischen dem Speicher und dem Vektorregister ausgeführt wird, ohne irgendeinen Puffer vorzusehen. In dem Beispiel wird die Vektorverarbeitung unter Verwendung der Daten aus dem Speicher mit zwei Vektorladebefehlen VLD ausgeführt, wobei dann das Ergebnis der Verarbeitung mit einem Vektorspeicherbefehl VST in den Speicher geschrieben wird. Deshalb ergibt sich infolge des Speicherzugriffs eine Leerlaufzeit. Wenn die Leerlaufzeit für den Speicherzugriff länger wird, wird die Leerlaufzeit in der Verarbeitungseinheit ebenfalls länger, so daß der Wirkungsgrad der Verwendung des Prozessors verschlechtert wird.
  • Weil in der Vektorverarbeitungseinheit mehrere Vektorprozessoren vorgesehen sind, besteht außerdem die Möglichkeit des Konflikts um den Speicherzugriff in jedem Vektorprozessor. Deshalb ist es nicht notwendigerweise garantiert, daß die Daten mit einer minimalen Zugriffszeit zurückgeschickt werden, so daß tendenziell mehr und mehr Leerlaufzeit auftritt.
  • Um dieses Problem zu lösen, sieht die herkömmliche Vektorverarbeitungseinheit einen Puffer zwischen dem Vektorregister und dem Speicher zum Trennen des Speicherzugriffs von der Vektorverarbeitung vor. Dies verbessert die Vektorverarbeitungseinheit, indem ihr erlaubt wird, die Daten im voraus zu laden, so daß die folgende Vektorverarbeitung nach dem Speichern der Daten kontinuierlich und unabhängig davon ausgeführt werden kann, ob der Speicherzugriff ausgeführt ist oder nicht.
  • In Fig. 11 umfaßt die herkömmliche Vektorverarbeitungseinheit 1800 einen Vektorprozessor 1700 mit einer Kreuzschiene 1710, den Vektorregistern 1720, 1721 und einem Prozessor 1730; die Ladedatenpuffer 1100 mit einer Ladedatenpuffer-Speicherschaltung 1200 und einer Ladedatenpuffer-Leseschaltung 1300 zum Speichern der Vektordaten, die an den Vektorprozessor 1700 zu senden sind; und die Speicherdatenpuffer 1400 mit einer Speicherdatenpuffer- Speicherschaltung 1500 und einer Speicherdatenpuffer-Leseschaltung 1600 zum Speichern des Ergebnisses der Verarbeitung durch den Vektorprozessor 1700.
  • Dann wird die Anzahl der Wörter von jedem der Ladedatenpuffer 1110 und 1120 für die maximale Anzahl von Elementen von einem Vektorbefehl bestimmt. Obwohl hier durch die Puffer 1110 und 1120 die Anzahl der Ladedatenpuffer zwei beträgt, wird sie außerdem durch das Schätzen der Anzahl der Ladebefehle bestimmt, für die die Daten nicht zurückgeschickt werden, obwohl der Befehl ausgegeben wird.
  • Außerdem wird die Anzahl der Wörter von jedem der Speicherdatenpuffer 1410 und 1420 auch für die maximale Anzahl von Elementen von einem Vektorbefehl bestimmt. Dann wird die Anzahl durch das Schätzen der Anzahl der Speicherbefehle bestimmt, die von der Ausgabe eines Speicherbefehls zum Speichern in einem Speicher 1900 ausgeführt werden können.
  • Wie in Fig. 12 gezeigt ist, beträgt, wenn die Vektorlänge in Fig. 12 (A) 8 beträgt, die Anzahl der Vektorladebefehle VLD 4, deren Ausgabe begonnen werden kann, bis die Vektorverarbeitung ausgeführt werden kann. Falls außerdem in Fig. 12 (B) die Vektorlänge 4 beträgt, beträgt die Anzahl der Vektorladebefehle VLD 7, deren Ausgabe begonnen werden kann, bis die Vektorverarbeitung ausgeführt werden kann. Obwohl vier Ladedatenpuffer ausreichend sein können, falls die Vektorlänge 8 beträgt, sind deshalb sieben Ladedatenpuffer erforderlich, falls die Vektorlänge 4 beträgt.
  • Als nächstes wird die Ausführung der Befehle und das Ergebnis der Verarbeitung durch die Verwendung eines Beispiels einer Befehlsfolge beschrieben. Hier wird für den Zweck der Beschreibung angenommen, daß die Anzahl der Ladedatenpuffer bzw. Speicherdatenpuffer zwei beträgt, wobei jeder eine Kapazität von 8 Bytes · 64 Wörter besitzt, daß es einen 8-Byte-Ladebefehl VLD, einen Ladebefehl VLDU für die höherwertigen 4 Bytes, einen Ladebefehl VLDL für die niederwertigen 4 Bytes, einen 8-Byte-Speicherbefehl VST, einen Speicherbefehl VSTU für die höherwertigen 4 Bytes, einen Speicherbefehl VSTL für die niederwertigen 4 Bytes, eine Festkommaaddition VADD und eine Gleitkommaaddition VFAD gibt, wobei die maximale Anzahl der Vektorelemente, die diese Befehle besitzen können, 64 beträgt. Die Vektorregister werden außerdem als V0 und V1 bezeichnet.
  • Hier wird angenommen, daß die in Fig. 9 gezeigte Befehlsfolge unter der Annahme ausgeführt wird, daß die Vektorlänge 16 beträgt.
  • In Fig. 13 werden die Vektorladebefehle aus den Befehlen (1) und (2) zuerst den Ladedatenpuffern 1110 bzw. 1120 zugewiesen, wenn die Befehlsfolge in der herkömmlichen Vektorverarbeitungseinheit unter Verwendung von zwei Ladedatenpuffern verarbeitet wird. Dann werden die Ladedatenpuffer 1110 und 1120 außerdem für die Vektorladebefehle aus den Befehlen (5) und (6) verwendet. Ähnlich werden die Vektorspeicherbefehle aus den Befehlen (4) und (8) den Speicherdatenpuffern 1410 bzw. 1420 zugewiesen.
  • Weil es nur zwei Ladedatenpuffer gibt, kann in diesem Fall der Befehl (5) nicht ausgegeben werden, bis der Ladedatenpuffer V0, der von dem Befehl (1) verwendet wird, freigegeben wird. Folglich tritt die in Fig. 13 gezeigte Verzögerungszeit a auf.
  • Weil die Ladedatenpuffer 1110, 1120 und die Speicherdatenpuffer 1410, 1420 mit einer festen Größe konfiguriert sind, gibt es in Fig. 14 eine Möglichkeit, daß eine Anzahl verschwendeter Bereiche in den Ladedatenpuffern 1110, 1120 und in den Speicherdatenpuffern 1410, 1420 verursacht wird, falls der Vektor kurz ist.
  • Als ein Beispiel einer derartigen herkömmlichen Vektorverarbeitungseinheit beschreibt die europäische Patentanmeldung Nr. 445.802-A2 eine Vektorverarbeitungseinheit mit einem Speicherpuffer.
  • Weil die herkömmliche Vektorverarbeitungseinheit die feste Anzahl und Kapazität der Datenpuffer besitzt, besitzt sie den Nachteil, daß abhängig von einer Programmkonfiguration der Wirkungsgrad der Verwendung verschlechtert ist, wie oben beschrieben ist. Das heißt, wenn die Vektorlänge lang ist, gibt es eine geringe Auswirkung auf die Leistung, selbst wenn die Anzahl der Datenpuffer relativ klein ist. Falls jedoch die Vektorlänge kurz ist, kann der Vektorprozessor nicht effizient verwendet werden, ohne eine große Anzahl Datenpuffer vorzusehen. Weil andererseits die Vektorlänge von einem Programm abhängt, sollte für einen Fall, in dem die Vektorlänge kurz ist, eine relativ große Anzahl von Datenpuffern vorgesehen sein, um die Leistung der herkömmlichen Vektorverarbeitungseinheit ungeachtet der Vektorlänge vollständig zu gewinnen, was das Problem verursacht, daß die Menge der Hardware vergrößert wird.
  • Aus EP-A-0165539 ist ein Vektorverarbeitungssystem mit einer Vektorverarbeitungseinheit, einem Hauptspeicher und einem Pufferspeicher bekannt, der zwischen die Vektorverarbeitungseinheit und den Hauptspeicher geschaltet ist. Der Pufferspeicher enthält ein oder mehrere virtuelle Vektorregister, die unter der Steuerung des Anwenders in Register-zu-Register-Vektoroperationen betreibbar sind. Ein Anwenderbefehl spezifiziert die Länge eines zu verarbeitenden Vektoroperanden, den Typ der auszuführenden Operation und welche Register verwendet werden.
  • Aus dem "IBM Technical Disclosure Bulletin", Dezember 1985, Bd. 8, Nr. 7, S. 2928-2934 ist eine Systemarchitektur für die effiziente Pipelineausführung eines listengesteuerten, sich wiederholenden Prozesses und einer Mehrzwecksimulation bekannt. Die Pipeline ist im wesentlichen ein Vektorprozessor, wobei der Adressenraum der Datenpuffer am häufigsten als derjenige der virtuellen Vektorregister behandelt wird. Diese können so definiert sein, daß sie eine Vielzahl von Längen und Formaten besitzen. Die Existenz der virtuellen Vektorregister ist ein zweckmäßiges Architekturmerkmal für die Unterstützung des "dynamischen Bindens" von RR-Makros, um DO-LOOP-spezifische Supermakros während des AP-Ausführungsdienstes zu bilden.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist eine Aufgabe der vorliegenden Erfindung, die obigen Probleme zu lösen und die Datenpuffer effizient zu verwenden.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, selbst für eine kurze Vektorlänge kein Warten auf die Datenpuffer zu verursachen, so daß die Leistung des Vektorprozessors vollständig gewonnen wird.
  • Die vorliegende Erfindung schafft eine Vektorverarbeitungseinheit, wie sie im Anspruch 1 definiert ist.
  • In einer bevorzugten Ausführungsform der vorliegenden Erfindung ist die Vektorverarbeitungseinheit gemäß der vorliegenden Erfindung eine Vektorverarbeitungseinheit mit einem Vektorprozessor, wobei sie einen Datenpuffer zwischen dem Vektorprozessor und einem Speicher besitzt, wobei der Datenpuffer für die Anzahl der Wörter, die gespeichert werden können, und die Anzahl der Teilungen der Puffer variabel angeordnet ist. Außerdem kann der Datenpuffer für die Datenbreite pro Wort variabel angeordnet sein.
  • KURZBESCHREIBUNG DER ZEICHNUNG
  • Ein Aspekt der vorliegenden Erfindung wird deutlicher, wenn er in bezug auf die folgende Zeichnung beschrieben wird, worin:
  • Fig. 1 eine Darstellung ist, die eine Konfiguration einer Vektorverarbeitungseinheit gemäß der vorliegenden Erfindung zeigt;
  • Fig. 2 eine Konfiguration des Ladedatenpuffers in der vorliegenden Erfindung ist;
  • Fig. 3 eine Darstellung ist, die die Anzahl der Speicherelemente des Ladedatenpuffers in der vorliegenden Erfindung zeigt;
  • Fig. 4 eine Konfiguration der Ladedaten-Speicherschaltung in der vorliegenden Erfindung ist;
  • Fig. 5 eine Darstellung ist, die zeigt, wie eine Datenpufferadresse in der vorliegenden Erfindung zu erzeugen ist;
  • Fig. 6 eine Konfiguration der Ladedaten-Leseschaltung in der vorliegenden Erfindung ist;
  • Fig. 7 eine Darstellung ist, die den Betrieb der Vektorverarbeitung in der vorliegenden Erfindung zeigt;
  • Fig. 8 eine Darstellung ist, die zeigt, wie der Ladedatenpuffer und der Speicherdatenpuffer der vorliegenden Erfindung zu verwenden sind;
  • Fig. 9 ein Beispiel der Befehlsfolge ist, die zum Schreiben der vorliegenden Erfindung und des Standes der Technik verwendet wird;
  • Fig. 10 eine Darstellung ist, die den Betrieb der Vektorverarbeitung in einer herkömmlichen Vektorverarbeitungseinheit ohne Datenpuffer zeigt;
  • Fig. 11 eine Konfiguration der herkömmlichen Vektorverarbeitungseinheit mit Datenpuffer ist;
  • Fig. 12 eine Darstellung ist, die den Betrieb der Vektorverarbeitung in einer idealen Vektorverarbeitungseinheit mit einer Anzahl von Datenpuffern zeigt;
  • Fig. 13 eine Darstellung ist, die den Betrieb der Vektorverarbeitung in einer herkömmlichen Vektorverarbeitungseinheit mit Datenpuffer zeigt; und
  • Fig. 14 eine Darstellung ist, die zeigt, wie der Ladedatenpuffer und der Speicherdatenpuffer in der herkömmlichen Vektorverarbeitungseinheit zu verwenden sind.
  • AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Eine Ausführungsform der vorliegenden Erfindung wird unter Bezugnahme auf die Zeichnung ausführlich erklärt.
  • In Fig. 1 umfaßt in einer bevorzugten Ausführungsform der vorliegenden Erfindung eine Vektorverarbeitungseinheit 800 einen Vektorprozessor 700, der mit einem Speicher 900 verbunden ist und Vektorverarbeitung ausführt, die Ladedatenpuffer 100, die die an den Vektorprozessor 700 zu liefernden Vektordaten speichern, und die Speicherdatenpuffer 400, die die Ergebnisse der Verarbeitung durch den Vektorprozessor 700 speichern. Es sind außerdem eine Ladedatenpuffer-Speicherschaltung 200 und eine Ladedaten- Leseschaltung 300 zum Speichern und Lesen der Vektordaten in bzw. aus den Ladedatenpuffern 100 vorgesehen. Ähnlich sind eine Speicherdatenpuffer-Speicherschaltung 500 und eine Speicherdatenpuffer-Leseschaltung 600 zum Speichern und Lesen der Vektordaten in bzw. aus den Speicherdatenpuffern 400 vorgesehen. Außerdem umfaßt der Vektorprozessor 700 die Vektorregister 720 und 721 zum Halten der Vektordaten, einen Prozessor 730 und eine Kreuzschiene 710 zum Übertragen des Ergebnisses der Verarbeitung zu den Vektorregistern.
  • Für die Einfachheit der Beschreibung wird angenommen, daß die Ausführungsform jeweils zwei Ladedatenpuffer und Speicherdatenpuffer besitzt, wobei jeder Datenpuffer eine Kapazität von 8 Bytes · 64 Wörter besitzt. Außerdem wird angenommen, daß die einem Datenpuffer zugewiesene Anzahl der Puffer maximal vier beträgt. Außerdem wird angenommen, daß der Typ der Befehle den 8-Byte-Ladebefehl VLD, den Ladebefehl VLDU für die höherwertigen 4 Bytes, den Ladebefehl VLDL für die niederwertigen 4 Bytes, den 8-Byte-Speicherbefehl VST, den Speicherbefehl VSTU für die höherwertigen 4 Bytes, den Speicherbefehl VSTL für die niederwertigen 4 Bytes, die Festkommaaddition VADD und die Gleitkommaaddition VFAD umfaßt. Es wird angenommen, daß jeder dieser Befehle bis zu 64 als die Vektorlänge spezifizieren kann. Es gibt außerdem zwei Vektorregister, V0 und V1.
  • In Fig. 2 ist der Ladedatenpuffer 110 zu angeordnet, daß er 64 Wörter aus 8-Byte-Daten speichern kann, wobei er in vier virtuelle Puffer #0 bis #3 unterteilt ist. Demzufolge entsprechen die Adressen 0 bis 15 des Ladedatenpuffers dem virtuellen Puffer #0, die Adressen 16 bis 31 des Ladedatenpuffers dem virtuellen Puffer #1, die Adressen 32 bis 47 des Ladedatenpuffers dem virtuellen Puffer #2 und die Adressen 48 bis 63 des Ladedatenpuffers dem virtuellen Puffer #3.
  • In Fig. 3 umfaßt ein in Ladedatenpuffer 110 verfügbarer Bereich die Adressen 0 bis 63, wenn der virtuelle Puffer #0 spezifiziert ist, die Adressen 16 bis 63, wenn der virtuelle Puffer #1 spezifiziert ist, die Adressen 32 bis 63, wenn der virtuelle Puffer #2 spezifiziert ist, und die Adressen 48 bis 63, wenn der virtuelle Puffer #3 spezifiziert ist. Das heißt, die Nummer des virtuellen Puffers bedeutet die Startadresse im Ladedatenpuffer. Falls es Vektordaten A und B gibt, die jeweils eine Vektorlänge von 32 aufweisen, ist es deshalb z. B. möglich, die Vektordaten A dem virtuellen Puffer #0 und die Vektordaten B dem virtuellen Puffer #2 zuzuweisen.
  • Der Ladedatenpuffer 120 besitzt die gleiche Anordnung wie der Ladedatenpuffer 110, mit der Ausnahme, daß die Nummern für die virtuellen Puffer #4 bis #7 sind.
  • Der Speicherdatenpuffer 410 besitzt ebenfalls eine Anordnung, die dem Ladedatenpuffer 110 ähnlich ist. Außerdem besitzt der Speicherdatenpuffer 420 die gleiche Anordnung wie der Speicherdatenpuffer 410, mit der Ausnahme, daß die Nummern für die virtuellen Puffer #4 bis #7 sind.
  • Sowohl die Ladedatenpuffer 110 und 120 als auch die Speicherdatenpuffer 410 und 420 werden wie folgt adressiert. Weil die Ladedatenpuffer 101 128 Wörter als Ganzes besitzen, ist eine Wortadresse durch sieben Bits dargestellt. Demzufolge ist es möglich, entweder den Ladedatenpuffer 110 oder den Ladedatenpuffer 120 mit seinem höchstwertigen Bit zu identifizieren. Außerdem stellen die anderen sechs Bits eine Wortadresse in einem Datenpuffer dar. Die höherwertigen zwei Bits der sechs Bits werden verwendet, um den virtuellen Puffer zu identifizieren. Das heißt, für den Ladedatenpuffer 110 identifizieren sie irgendeine aus #0 bis #3, während sie für den Ladedatenpuffer 120 irgendeine aus #4 bis #7 identifizieren. Dann entsprechen die niederwertigen vier Bits der Wortadresse der Elementnummer jeder der 16 Daten in jedem virtuellen Puffer. Dies trifft auf die Speicherdatenpuffer 410 und 420 zu.
  • Wenn der 8-Byte-Ladebefehl VLD ausgeführt wird, können in dem wie oben angeordneten Datenpuffer acht Puffer von #0 bis #7 verwendet werden, falls 1 ≤ VL ≤ 16 gilt, während nur zwei Puffer #0 und #4 verwendet werden können, falls die Vektorlänge VL 49 ≤ VL ≤ 64 beträgt.
  • Wenn z. B. der VLD bei VL = 16 ausgeführt wird, wobei der Puffer #0 verwendet wird, wird das Ergebnis bei den Adressen 0 bis 15 des Ladedatenpuffers 110 gespeichert, wobei die Adressen 16 bis 63 nicht verwendet werden. Falls der folgende VLD abermals VL = 16 ist, und dann der Puffer #1 verwendet wird, wird das Ergebnis bei den Adressen 16 bis 31 des Ladedatenpuffers 110 gespeichert.
  • In Fig. 4 umfaßt wie Ladedatenpuffer-Speicherschaltung 200 eine Ladedaten-Schreibsteuerschaltung 210, die ein Schreibpuffernummern-Register 211, das die virtuelle Puffernummer eines Ladedatenpuffers hält, ein Elementnummernregister 212, das die Elementnummern im virtuellen Puffer des Ladedatenpuffers hält, ein Schreibbefehlstyp- Register 213, das den Typ des Befehls hält, eine Schreibselektor-Steuerschaltung 216, die die Schreibselektoren 225 und 226 in einer Ladedaten-Komprimierungsschaltung 220 steuert, eine Adressengeneratorschaltung 215, die eine Adresse des Ladedatenpuffers erzeugt, und ein Schreibadressenregister 214, das die erzeugten Adressen hält, enthält. Außerdem umfaßt die Ladedatenpuffer-Speicherschaltung 210 die Ladedaten-Komprimierungsschaltung 220, die die Datenempfangsregister 221 und 222, wie die Daten von dem Speicher empfangen, die Schreibregister 223 und 224, die die Daten in die Ladedatenpuffer 100 schreiben, und einen oberen Schreibselektor 225 und einen unteren Schreibselektor 226, die die Daten in den Datenempfangsregistern 221 und 222 in den Schreibregistern 223 und 224 halten, enthält.
  • Die Ladedatenpuffer-Speicherschaltung 200 teilt die von dem Speicher 900 empfangenen 8-Byte-Ladedaten in die höherwertigen 4 Bytes und die niederwertigen 4 Bytes und hält sie in den Datenempfangsregistern 221 und 222 in der Ladedaten-Komprimierungsschaltung 220. Dann bestimmt sie den Typ des Befehls, der die Daten lädt, durch Decodieren des Schreibbefehlstyp-Register 213.
  • Falls der Typ des Befehls ein 8-Byte-Ladebefehl VLD ist, steuert die Schreibselektor-Steuerschaltung 216 den oberen Schreibselektor 225 und den unteren Schreibselektor 226, so daß sie die empfangenen 8-Byte-Daten in den Schreibregistern 223 und 224 wie sie sind halten. Dann werden die Daten in den Schreibregistern 223 und 224 bei einer von der Schreibadressen-Generatorschaltung 215 anhand der Schreibpuffernummer 211 und der Datenelementnummer 212 erzeugten Schreibadresse in den Ladedatenpuffern 100 gespeichert.
  • Falls der Typ des Befehls der Ladebefehl VLDU für die höherwertigen 4 Bytes ist, weil nur die höherwertigen 4 Bytes in dem Empfangsregister 221 gültige Daten sind, werden die Schreibselektoren 225 und 226 umgeschaltet, um die Daten von dem Empfangsregister 221 zu empfangen. Die Daten aus dem Empfangsregister 221 werden im Schreibregister 223 gehalten, falls das Datenelementnummern-Register 212 eine gerade Zahl anzeigt, während sie im Schreibregister 224 gehalten werden, falls das Datenelementnummern- Register 212 eine ungerade Zahl anzeigt. Wenn in beide Schreibregister 223 und 224 Daten gefüllt sind, werden folglich die Daten in den Schreibregistern 223 und 224 bei der von der Schreibadressen-Generatorschaltung 215 anhand der Schreibpuffernummer 211 und der Datenelementnummer 212 erzeugten Schreibadresse in den Ladedatenpuffern 100 gespeichert.
  • Falls ähnlich der Typ des Befehls der Ladebefehl VLDL für die niederwertigen 4 Bytes ist, weil nur die niederwertigen 4 Bytes in dem Empfangsregister 222 gültig sind, werden die Schreibselektoren 225 und 226 umgeschaltet, um die Daten von dem Empfangsregister 222 zu empfangen. Dann werden die Daten aus dem Empfangsregister 222 in dem Schreibregister 223 gehalten, falls das Datenelementnummern-Register 212 eine gerade Zahl anzeigt, während sie in dem Schreibregister 224 gehalten werden, falls das Datenelementnummern-Register 212 eine ungerade Zahl anzeigt. Wenn in beide Schreibregister 223 und 224 Daten gefüllt sind, werden folglich die Daten in den Schreibregistern 223 und 224 bei der von der Schreibadressen-Generatorschaltung 215 anhand der Schreibpuffernummer 211 und der Datenelementnummer 212 erzeugten Schreibadresse in den Ladedatenpuffern 100 gespeichert.
  • In Fig. 5 erzeugt die Schreibadressen-Generatorschaltung 215 eine Schreibadresse für die Ladedatenpuffer 100 in der folgenden Weise. In Fig. 5 (A) werden, falls der Typ des Befehls der 8-Byte-Ladebefehl VLD ist, die niederwertigen zwei Bits des Schreibpuffernummern-Registers 211 um die höherwertigen zwei Bits des Elementnummernregisters 212 addiert, so daß sie überlappend sind. Das heißt, die Adresse des Ladedatenpuffers wird durch Addieren der in dem Schreibpuffernummern-Register 211 als eine Startadresse gehaltenen Puffernummer zu der in dem Elementnummernregister 212 gehaltenen Elementnummer erhalten.
  • In Fig. 5 (B) werden, falls der Typ des Befehls der 4-Byte-Ladebefehl VLDU oder VLDL ist, das niedrigstwertige Bit des Schreibpuffernummern-Registers 211 und das höherwertigste Bit des Elementnummernregisters 212 addiert, so daß sie überlappend sind. Das heißt, die Adresse des Ladedatenpuffers wird durch das Addieren der in dem Schreibpuffernummern-Register 211 als eine Startadresse gehaltenen Puffernummer zu der in dem Elementnummernregister 212 gehaltenen Elementnummer, dividiert durch 2, erhalten.
  • In Fig. 6 umfaßt die Ladedatenpuffer-Leseschaltung 300 eine Ladedaten-Lesesteuerschaltung 310, die ein Lesepuffernummern-Register 311, das die virtuelle Puffernummer des Ladedatenpuffers hält, einen Elementnummernzähler 312, der die Elementnummern im virtuellen Puffer des Ladedatenpuffers zählt, ein Lesebefehlstyp-Register 313, das den Typ der Befehle hält, eine Synchronisierselektor- Steuerschaltung 316, die ein Signal zum Steuern der Synchronisierselektoren 325 und 324 in einer Ladedaten-Expandierschaltung 320 erzeugt, eine Adressengeneratorschaltung 315, die eine Leseadresse des Ladedatenpuffers erzeugt, und ein Selektorsteuerregister 314, das das Steuersignal von der Synchronisierselektorschaltung 316 hält, enthält. Außerdem umfaßt die Ladedatenpuffer-Speicherschaltung 200 die Ladedaten-Expandierschaltung 320, die die Leseregister 321 und 322, die die Daten von dem Ladedatenpuffer empfangen, die Synchronisierregister 323 und 324, die die Daten zu dem Vektorprozessor 700 übertragen, und die Synchronisierselektoren 325 und 326, die die Daten der Leseregister 321 und 322 in den Synchronisierregister 323 und 324 halten, enthält.
  • Die Ladedatenpuffer-Leseschaltung 300 erzeugt durch die Leseadressen-Generatorschaltung 315 anhand der Lesepuffernummer 311 und des Leseelementnummern-Zählers 312 eine Leseadresse. Die erzeugte Leseadresse wird für das Lesen aus den Ladedatenpuffern 100 verwendet. Die ausgelesenen Daten werden in die Leseregister 321 und 322 gesetzt. Außerdem wird der Elementnummernzähler 312 jedesmal inkrementiert, wenn Daten an den Vektorprozessor 700 gesendet werden.
  • Der Typ des Befehls, der sich auf die Lesedaten bezieht, wird durch das Decodieren des Lesebefehlstyps-Registers 313 mit einem Decodierer in der Synchronisierselektor- Steuerschaltung 316 bestimmt.
  • Falls der Typ des Befehls der 8-Byte-Ladebefehl VLD ist, steuert die Schreibselektor-Steuerschaltung 316 die Synchronisierselektoren 325 und 326, um die Daten der Leseregister 321 und 322 in die Synchronisierregister 323 und 324 wie sie sind zu setzen. Die in den Synchronisierregistern 323 und 324 gesetzten Daten werden zu dem Vektorprozessor 700 gesendet. Derartige Operationen werden von jedem Maschinenzyklus wiederholt, bis alle Elemente gelesen sind.
  • Falls der Typ des Befehls der 4-Byte-Ladebefehl VLDU oder der Ladebefehl VLDL für die niederwertigen 4 Bytes ist, gibt es über zwei Maschinenzyklen die gleichen Daten in den Leseregistern 321 und 322. Dies ist so, weil in einem Maschinenzyklus nur einmal Daten zu dem Vektorprozessor 700 gesendet werden können. Der Synchronisierselektor 325 oder 326 schaltet alternativ das Leseregister 321 oder 322 durch das Steuersignal um, das in dem Selektorsteuerregister 314 gehalten wird. Dies veranlaßt das Synchronisierregister 323, die in dem Leseregister 321 oder 322 gehaltenen Daten in das Synchronisierregister 323 oder 324 zu setzen.
  • Das heißt, die in dem Leseregister 321 gehaltenen Daten werden gewählt, falls die von dem Leseelementnummern-Zähler 312 angezeigte Elementnummer der Lesedaten eine gerade Zahl ist, während die in dem Leseregister 322 gehaltenen Daten gewählt werden, falls die Nummer eine ungerade Zahl ist. Falls der Typ des Befehls der Ladebefehl VLDU für die höherwertigen 4 Bytes ist, werden dann die gewählten Daten in das Synchronisierregister 323 gesetzt. Falls der Typ des Befehls der Ladebefehl VLDL für die niederwertigen 4 Bytes ist, werden die gewählten Daten in das Synchronisierregister 324 gesetzt. Die in das Synchronisierregister 323 gesetzten Daten werden zu dem Vektorprozessor 700 gesendet.
  • Das Verfahren zum Erzeugen der Leseadressen durch die Leseadressen-Generatorschaltung 315 ist zu dem von der Schreibadressen-Generatorschaltung 215 ähnlich, das in Fig. 5 beschrieben ist. Das heißt, falls der Typ des Befehls der 8-Byte-Ladebefehl VLD ist, wird die Leseadresse durch das Verfahren nach Fig. 5 (A) erzeugt, während, falls er ein 4-Byte-Ladebefehl VLDU oder VLDL ist, die Leseadresse durch das Verfahren nach Fig. 5 (B) erzeugt wird.
  • Obwohl die obige Beschreibung an der Ladedatenpuffer- Speicherschaltung 200 und der Ladedaten-Leseschaltung 300 für die Ladedatenpuffer 100 ausgeführt ist, besitzen die Speicherdatenpuffer-Speicherschaltung 500 bzw. die Speicherdaten-Leseschaltung 600 für die Speicherdatenpuffer 400 eine ähnliche Konfiguration.
  • Als nächstes wird ein Beispiel der Verarbeitung in der Ausführungsform der Vektorverarbeitungseinheit der vorliegenden Erfindung beschrieben.
  • Wird die Befehlsfolge nach Fig. 9, die oben als ein Beispiel beschrieben ist, genommen, wenn die Vektorlänge 16 beträgt, werden sie in der Ausführungsform ausgeführt, wie sie in Fig. 7 gezeigt ist. Die Vektorladebefehle aus den Befehlen (1), (2), (5) und (6) werden den virtuellen Puffern #0, #1, #2 bzw. #3 des Ladedatenpuffers zugewiesen. Ähnlich werden die Vektorspeicherbefehle aus den Befehlen (4) und (8) den virtuellen Puffern #0 bzw. #1 des Speicherdatenpuffers zugewiesen.
  • In Fig. 7 werden zuerst die Vektorladebefehle aus den Befehlen (1) und (2) den virtuellen Puffern #0 bzw. #1 des Ladedatenpuffers 110 zugewiesen. Die Vektorladebefehle aus den Befehlen (5) und (6) werden den virtuellen Puffern #2 bzw. #3 des Ladedatenpuffers 110 zugewiesen. Andererseits werden die Vektorspeicherbefehle aus den Befehlen (4) und (8) den virtuellen Puffern #0 und #1 des Speicherdatenpuffers 410 zugewiesen.
  • Wenn der Ablaufplan nach Fig. 7 mit demjenigen einer herkömmlichen Vektorverarbeitungseinheit verglichen wird, die in Fig. 13 gezeigt ist, ermöglicht es die Ausführungsform, den Zugriff ohne irgendein Intervall auszuführen, ohne den Zustand des Vektorregisters zu kennen, weil die vier virtuellen Puffer #0, #1, #2 und #3 in dem Ladedatenpuffer 110 bereitgestellt sind. Demzufolge ergibt sich kein Warten auf leeren Raum in dem Puffer wie im Stand der Technik, so daß die Leistung verbessert werden kann.
  • In der obigen Verarbeitung werden der Ladedatenpuffer 110 bzw. der Speicherdatenpuffer 410 so verwendet, wie in Fig. 8 gezeigt ist. Gemäß der vorliegenden Erfindung kann der Datenpuffer mit fester Kapazität effizient verwendet werden, weil alle Daten komprimiert und in dem Ladedatenpuffer 110 und dem Speicherdatenpuffer 410 gespeichert werden.
  • Wie oben beschrieben ist, kann gemäß der vorliegenden Erfindung durch die Verwendung des Ladedatenpuffers bzw. Speicherdatenpuffers, die zwischen dem Vektorregister und dem Speicher als mehrere virtuelle Puffer bereitgestellt sind, der Datenpuffer effizient verwendet werden, selbst wenn die Vektorlänge kurz ist. Weil außerdem die vorliegende Erfindung eine Funktion zum Komprimieren der Daten, wenn sie in dem Datenpuffer gespeichert werden, und zum Expandieren der Daten, wenn sie gelesen werden, besitzt, kann der Datenpuffer effizient verwendet werden, selbst wenn die Datenbreite schmal ist.

Claims (5)

1. Vektorverarbeitungseinheit, mit:
einem Vektorprozessor (700) mit Vektorregistern (720, 721);
einem Speicher (900); und
einer Datenpuffereinrichtung (100, 400), die Ladedatenpuffer (100) enthält, die sich zwischen dem Speicher (900) und dem Vektorprozessor (700) befinden, um vom Speicher (900) geladene Daten zu speichern,
dadurch gekennzeichnet, daß die Ladedatenpuffer (100) in mehrere virtuelle Ladepuffer (110, 120) unterteilbar sind, die durch Kennummern identifiziert werden, die den virtuellen Ladepuffern (110, 120) zugewiesen sind,
und daß sie eine Einrichtung (210) zum Erzeugen einer Adresse zum Schreiben in die virtuellen Ladepuffer (110, 120) sowie eine Einrichtung (310) zum Erzeugen einer Adresse zum Lesen aus den virtuellen Ladepuffern (110, 120) anhand der den virtuellen Ladepuffern zugewiesenen Kennummern umfaßt.
2. Vektorverarbeitungseinheit nach Anspruch 1,
dadurch gekennzeichnet, daß
der Ladedatenpuffer umfaßt:
eine Einrichtung (220) zum Komprimieren und Speichern von aus dem Speicher in die virtuellen Ladepuffer geladenen Daten; und
eine Einrichtung (320) zum Expandieren der in den virtuellen Ladepuffern gespeicherten Daten.
3. Vektorverarbeitungseinheit nach Anspruch 1, dadurch gekennzeichnet, daß der Datenpuffer ferner einen Speicherdatenpuffer (400-600) zum Speichern von im Speicher zu speichernden Daten umfaßt, wobei der Speicherdatenpuffer mehrere virtuelle Speicherpuffer besitzt und durch Identifizierungsnummern identifiziert wird, die den virtuellen Speicherpuffern zugewiesen sind.
4. Vektorverarbeitungseinheit nach Anspruch 3, dadurch gekennzeichnet, daß
der Speicherdatenpuffer umfaßt:
eine Einrichtung (510) zum Erzeugen einer Adresse zum Speichern in die virtuellen Speicherpuffer anhand der Kennummern, die den virtuellen Speicherpuffern zugewiesen sind; und
eine Einrichtung (610) zum Erzeugen einer Adresse zum Lesen aus den virtuellen Speicherpuffern anhand der Kennummern, die den virtuellen Speicherpuffern zugewiesen sind.
5. Vektorverarbeitungseinheit nach Anspruch 4, dadurch gekennzeichnet, daß:
der Speicherdatenpuffer umfaßt:
eine Einrichtung (520) zum Komprimieren und Speichern von aus dem Speicher in die virtuellen Speicherpuffer geladenen Daten; und
eine Einrichtung (620) zum Expandieren der in den virtuellen Speicherpuffern gespeicherten Daten.
DE69520707T 1994-05-31 1995-05-31 Vektorverarbeitungseinheit mit rekonfigurierbarem Datenpuffer Expired - Fee Related DE69520707T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP6117784A JP2752902B2 (ja) 1994-05-31 1994-05-31 ベクトル処理装置

Publications (2)

Publication Number Publication Date
DE69520707D1 DE69520707D1 (de) 2001-05-23
DE69520707T2 true DE69520707T2 (de) 2001-11-29

Family

ID=14720236

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69520707T Expired - Fee Related DE69520707T2 (de) 1994-05-31 1995-05-31 Vektorverarbeitungseinheit mit rekonfigurierbarem Datenpuffer

Country Status (5)

Country Link
EP (1) EP0686922B1 (de)
JP (1) JP2752902B2 (de)
AU (1) AU691593B2 (de)
CA (1) CA2150518C (de)
DE (1) DE69520707T2 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4789269B2 (ja) * 2008-04-10 2011-10-12 エヌイーシーコンピュータテクノ株式会社 ベクトル処理装置及びベクトル処理方法
JP5708303B2 (ja) * 2011-06-29 2015-04-30 富士通株式会社 画像処理装置、画像処理方法および画像処理プログラム
US10061581B2 (en) * 2014-01-31 2018-08-28 Qualcomm Incorporated On-the-fly conversion during load/store operations in a vector processor

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS57121746A (en) * 1981-01-22 1982-07-29 Nec Corp Information processing device
JPH0670785B2 (ja) * 1984-05-21 1994-09-07 株式会社日立製作所 ポインタ動的制御によるバツフアメモリ拡張方法
US4771380A (en) * 1984-06-22 1988-09-13 International Business Machines Corp. Virtual vector registers for vector processing system
US4888679A (en) * 1988-01-11 1989-12-19 Digital Equipment Corporation Method and apparatus using a cache and main memory for both vector processing and scalar processing by prefetching cache blocks including vector data elements
JPH02254563A (ja) * 1989-03-29 1990-10-15 Koufu Nippon Denki Kk ベクトルデータ処理方式
JP2622008B2 (ja) * 1990-03-08 1997-06-18 甲府日本電気株式会社 情報処理装置
JPH04557A (ja) * 1990-04-17 1992-01-06 Mitsubishi Electric Corp ベクトルプロセッサ

Also Published As

Publication number Publication date
CA2150518A1 (en) 1995-12-01
JP2752902B2 (ja) 1998-05-18
AU2040195A (en) 1995-12-07
AU691593B2 (en) 1998-05-21
DE69520707D1 (de) 2001-05-23
EP0686922A1 (de) 1995-12-13
EP0686922B1 (de) 2001-04-18
CA2150518C (en) 2002-01-01
JPH07325805A (ja) 1995-12-12

Similar Documents

Publication Publication Date Title
DE69114333T2 (de) Rechner mit der Fähigkeit mehrere Befehle gleichzeitig auszuführen.
DE3781694T2 (de) Virtuelle prozessortechniken in einem feldmultiprozessor.
DE3750143T2 (de) Vektorprozessor mit Verdichtungs-/Erweiterungsmöglichkeit von Vektordaten.
DE69329630T2 (de) Vorrichtung zur Vektorverarbeitung
DE69636861T2 (de) Mikroprozessor mit Lade-/Speicheroperation zu/von mehreren Registern
DE4137515C2 (de) Integrierte Halbleiterschaltungsvorrichtung
DE3724317C2 (de)
DE69625256T2 (de) Mikrorechner
DE69325774T2 (de) Programmierbare Externspeichersteuerungseinrichtung
DE69017178T2 (de) Datenverarbeitungssystem mit Vorrichtung zur Befehlskennzeichnung.
DE68920419T2 (de) Verfahren und Anordnung für eine leistungsfähige DRAM-Steuerung.
DE69418146T2 (de) Temporärer Registersatz für einen superpipeline-superskalaren Prozessor
DE69031524T2 (de) Verfahren und Vorrichtung zur Datenübertragung zwischen Prozessorelementen
DE69327504T2 (de) Datenprozessor mit Operationseinheiten, die gemeinsam Gruppen von Registerspeichern benutzen
DE19526008A1 (de) Vertikal partitionierter, primärer Befehls-Cache-Speicher
DE69330923T2 (de) Verschachteltes Speichersystem
DE69714532T2 (de) Synchrone Halbleiterspeichervorrichtung mit Makrobefehlsspeichern und Ausführungsverfahren dafür
DE69032172T2 (de) Anordnung und Verfahren zur Verarbeitung von Grafikdaten
DE68925840T2 (de) Speicherzugriffssteuerungsvorrichtung, die aus einer verringerten Anzahl von LSI-Schaltungen bestehen kann
DE3852432T2 (de) Befehlssteuerungsvorrichtung für ein Computersystem.
DE2548720A1 (de) Mikroprogramm-steuerwerk
DE3501903A1 (de) Im pipelinebetrieb arbeitende datenverarbeitungseinrichtung
DE68928507T2 (de) Vektordatenverarbeitungsvorrichtung
DE69132367T2 (de) Inhaltsadressierbarer Speicher
DE69520707T2 (de) Vektorverarbeitungseinheit mit rekonfigurierbarem Datenpuffer

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8339 Ceased/non-payment of the annual fee