DE112013005236T5 - Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle - Google Patents

Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle Download PDF

Info

Publication number
DE112013005236T5
DE112013005236T5 DE112013005236.9T DE112013005236T DE112013005236T5 DE 112013005236 T5 DE112013005236 T5 DE 112013005236T5 DE 112013005236 T DE112013005236 T DE 112013005236T DE 112013005236 T5 DE112013005236 T5 DE 112013005236T5
Authority
DE
Germany
Prior art keywords
vector
elements
instruction
field
command
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.)
Withdrawn
Application number
DE112013005236.9T
Other languages
English (en)
Inventor
Liu Yang
Bin Robin WANG
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112013005236T5 publication Critical patent/DE112013005236T5/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • 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/30007Arrangements for executing specific machine instructions to perform operations on data operands
    • G06F9/3001Arithmetic instructions
    • 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/3001Arithmetic instructions
    • G06F9/30014Arithmetic instructions with variable precision
    • 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/30018Bit or string instructions
    • 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/30145Instruction analysis, e.g. decoding, instruction word fields
    • 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/34Addressing or accessing the instruction operand or the result ; Formation of operand address; Addressing modes
    • G06F9/355Indexed addressing
    • G06F9/3555Indexed addressing using scaling, e.g. multiplication of index
    • 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/3867Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • 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/3885Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units
    • G06F9/3893Concurrent instruction execution, e.g. pipeline or look ahead using a plurality of independent parallel functional units controlled in tandem, e.g. multiplier-accumulator
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Mathematical Physics (AREA)
  • Computational Mathematics (AREA)
  • Mathematical Analysis (AREA)
  • Mathematical Optimization (AREA)
  • Pure & Applied Mathematics (AREA)
  • Complex Calculations (AREA)
  • Advance Control (AREA)

Abstract

Es wird ein Verfahren beschrieben, das eine Bildintegralberechnung durch das Erzeugen eines zweiten Vektors und das Erzeugen eines dritten Vektors ausführt. Der zweite Vektor wird durch das Ausführen eines ersten Befehls, der abwechselnde Elemente eines ersten Vektors zu jeweiligen benachbarten Elementen des ersten Vektors addiert und die resultierenden Summationen in dem zweiten Vektor darstellt, erzeugt. Der erste Befehl leitet außerdem die jeweiligen benachbarten Elemente zu dem zweiten Vektor durch. Der dritte Vektor wird durch das Ausführen eines zweiten Befehls, der die Elemente einer Seite des zweiten Vektors zu einem Element einer anderen Seite des zweiten Vektors addiert und die andere Seite des zweiten Vektors durchleitet, erzeugt.

Description

  • Gebiet der Erfindung
  • Das Gebiet der Erfindung betrifft Computerverarbeitungssysteme und spezifischer Integralbild-Berechnungsbefehle.
  • Hintergrund
  • 1 zeigt eine graphische Darstellung auf hoher Ebene eines Verarbeitungskerns 100, der mit einer Logikschaltungsanordnung auf einem Halbleiterchip implementiert ist. Der Verarbeitungskern enthält eine Pipeline 101. Die Pipeline besteht aus mehreren Stufen, wobei jede dafür ausgelegt ist, einen spezifischen Schritt in dem Mehrschrittprozess auszuführen, der erforderlich ist, um einen Programmcodebefehl vollständig auszuführen. Diese enthalten typischerweise wenigstens Folgendes: 1) Befehlsholen- und -decodieren; 2) Datenholen; 3) Ausführung; 4) Zurückschreiben. Die Ausführungsstufe führt eine spezifische Operation, die durch einen Befehl identifiziert wird, der in einer früheren Stufe(n) (z. B. in dem obigen Schritt 1)) geholt und decodiert worden ist, an den Daten, die durch denselben Befehl identifiziert werden und in einer weiteren früheren Stufe geholt worden sind (z. B. in dem obigen Schritt 2)), aus. Die Daten, auf die eingewirkt wird, werden typischerweise von einem Speicherplatz 102 eines (universellen) Registers geholt. Die neuen Daten, die beim Abschluss der Operation erzeugt werden, werden außerdem typischerweise in den Speicherplatz des Registers ”zurückgeschrieben” (z. B. in der obigen Stufe 4)).
  • Die Logikschaltungsanordnung, die der Ausführungsstufe zugeordnet ist, besteht typischerweise aus mehreren ”Ausführungseinheiten” oder ”Funktionseinheiten” 103_1 bis 103_N, wobei jede dafür ausgelegt ist, ihre eigene eindeutige Teilmenge der Operationen auszuführen (eine erste Funktionseinheit führt z. B. die mathematischen Operationen an ganzen Zahlen aus, eine zweite Funktionseinheit führt die Gleitkommabefehle aus, eine dritte Funktionseinheit führt die Lade-/Speicheroperationen aus einem/in einen ”Cache”/Speicher aus usw.). Die Sammlung aller durch alle Funktionseinheiten ausgeführten Operationen entspricht dem ”Befehlssatz”, der durch den Verarbeitungskern 100 unterstützt wird.
  • In dem Gebiet der Computerwissenschaft sind zwei Typen von Prozessorarchitekturen weithin erkannt: ”Skalar” und ”Vektor”. Ein Skalarprozessor ist dafür ausgelegt, Befehle auszuführen, die Operationen an einem einzigen Datensatz ausführen, wohingegen ein Vektorprozessor dafür ausgelegt ist, Befehle auszuführen, die Operationen an mehreren Datensätzen ausführen. Die 2A und 2B stellen ein Vergleichsbeispiel dar, das den grundlegenden Unterschied zwischen einem Skalarprozessor und einem Vektorprozessor demonstriert.
  • 2A zeigt ein Beispiel eines skalaren UND-Befehls, bei dem ein einziger Operandensatz, A und B, miteinander UND-verknüpft wird, um ein einzelnes (oder ”skalares”) Ergebnis C zu erzeugen (d. h., AB = C). Im Gegensatz zeigt 2B ein Beispiel eines Vektor-UND-Befehls, bei dem zwei Operandensätze, A/B und D/E, jeweils UND-verknüpft werden, um ein Vektorergebnis C, F zu erzeugen (d. h., A.UND.B = C und D.UND.E = F). Als eine Sache der Terminologie ist ein ”Vektor” ein Datenelement, das mehrere ”Elemente” aufweist. Ein Vektor V = Q, R, S, T, U weist z. B. fünf verschiedene Elemente auf: Q, R, S, T und U. Die ”Größe” des beispielhaften Vektors V ist fünf (weil er fünf Elemente aufweist).
  • 1 zeigt außerdem das Vorhandensein eines Vektorregisterplatzes 107, der anders als ein universeller Registerplatz 102 ist. Spezifisch wird der universelle Registerplatz 102 nominell verwendet, um Skalarwerte zu speichern. Wenn irgendeine der Ausführungseinheiten als solche Skalaroperationen ausführt, verwendet sie nominell Operanden, die von dem universellen Registerspeicherplatz 102 abgerufen werden, (wobei sie die Ergebnisse zurück in den universellen Registerspeicherplatz 102 schreibt). Wenn im Gegensatz irgendeine der Ausführungseinheiten Vektoroperationen ausführt, verwendet sie nominell Operanden, die von dem Vektorregisterplatz 107 abgerufen werden (wobei sie die Ergebnisse zurück in den Vektorregisterplatz 107 schreibt). Verschiedene Bereiche des Speichers können gleichermaßen für die Speicherung von Skalarwerten und Vektorwerten zugewiesen sein.
  • Es wird außerdem das Vorhandensein einer Maskierungslogik 104_1 bis 104_N und 105_1 bis 105_N an den jeweiligen Eingängen in die und Ausgängen aus den Funktionseinheiten 103_1 bis 103_N angegeben. In verschiedenen Implementierungen ist für die Vektoroperationen nur eine dieser Schichten tatsächlich implementiert – obwohl dies keine strenge Anforderung ist (es ist denkbar, dass die Ausführungseinheiten, die nur Skalar- und keine Vektoroperationen ausführen, keine Maskierungsschicht aufweisen müssen, obwohl dies in 1 nicht dargestellt ist). Für irgendeinen Vektorbefehl, der die Maskierung verwendet, können die Eingangsmaskierungslogik 104_1 bis 104_N und/oder die Ausgangsmaskierungslogik 105_1 bis 105_N verwendet werden, um zu steuern, auf welche Elemente für den Vektorbefehl effektiv eingewirkt wird. Hier wird ein Maskierungsvektor aus einem Maskierungsregisterplatz 106 (z. B. zusammen mit den Eingangsoperandenvektoren, die aus dem Vektorregisterspeicherplatz 107 gelesen werden) gelesen, wobei er wenigstens einer der Schichten der Maskierungslogik 104, 105 dargestellt wird.
  • Während des Verlaufs des Ausführens des Vektorprogrammcodes muss nicht jeder Vektorbefehl ein volles Datenwort erfordern. Die Eingangsvektoren für einige Befehle können z. B. nur aus 8 Elementen bestehen, die Eingangsvektoren für andere Befehle können aus 16 Elementen bestehen, die Eingangsvektoren für andere Befehle können aus 32 Elementen bestehen usw. Die Maskierungsschichten 104/105 werden deshalb verwendet, um einen Satz von Elementen eines vollen Vektordatenworts zu identifizieren, der für einen speziellen Befehl zutrifft, um über die Befehle verschiedene Vektorgrößen zu verursachen. Typischerweise wird für jeden Vektorbefehl ein in dem Maskenregisterplatz 106 gehaltenes spezifisches Maskenmuster durch den Befehl ausgerufen, von dem Maskenregisterplatz geholt und einer oder beiden der Maskenschichten 104/105 bereitgestellt, um den richtigen Satz von Elementen für die spezielle Vektoroperationen ”freizugeben”.
  • 3a zeigt eine ”Integralbild”-Berechnung. Eine Integralbild-Berechnung summiert alle Bildpunktwerte über eine Bildfläche 301 (wie sie z. B. durch eine rechteckige Fläche mit den Eckkoordinaten (0, 0) und (x', y') definiert ist). Das Summieren der Bildpunktwerte über die Bildfläche 301 entspricht im Wesentlichen der Berechnung eines diskreten Integrals, wobei die Bildpunktwerte der diskreten Funktion entsprechen, die über die Fläche integriert wird.
  • Eine Technik ist, alle Werte entlang einer ersten Dimension der Fläche 301 für jeden diskreten Ort entlang der zweiten Dimension zu summieren. Wie z. B. in 3a beobachtet wird, werden alle Bildpunktwerte entlang der x-Achse innerhalb der Fläche 301 für einen speziellen Ort auf der y-Achse innerhalb der Fläche 301 summiert 302. Das Ausführen dieser Operation für jeden y-Achsen-Ort innerhalb der Fläche 301 liefert einen Summationswert für jeden y-Achsen-Ort. Diese Summationswerte werden dann (im Wesentlichen über die zweite (y-)Achse) summiert, um einen endgültigen Summationswert für die gesamte Fläche 301 zu erzeugen.
  • Ein Problem ist der Wirkungsgrad, mit dem ein Integralbild bestimmt wird – insbesondere, wenn mehrere Flächen mit überlappenden Bildpunktwerten berechnet werden. Gegenwärtig werden Skalar- im Gegensatz zu Vektorfolgen verwendet. 3b zeigt ein Beispiel eines Skalarbefehlsausführungsablaufs, der verwendet wird, um Summationen für verschiedene Breiten der Fläche zu berechnen. Ein Ergebnis 311 entspricht z. B. einer Breite der Fläche von zwei, während ein Ergebnis 312 einer Breite der Fläche von vier entspricht. Hier führt die streng serielle und skalare Art der ADD-Operationen dazu, dass drei Maschinenzyklen notwendig sind, um die Summationen für nur vier verschiedene Breiten zu berechnen. Anders gesagt, wie in 3b beobachtet wird, ein nächstes Vorrücken bei der Breitensummation muss auf die vorhergehende(n) Addition(en) über die kleinere(n) Breite(n) warten.
  • Um mit den Ineffizienzen umzugehen, die der Berechnung eines Bildintegrals zugeordnet sind, haben alternative Vorgehensweisen Programmcodefolgen verwendet, die Algorithmen verwenden, die die tatsächliche Berechnung ”approximieren”. Die Approximationen können unzureichend sein, wenn Genauigkeit gewünscht ist.
  • Die Figuren
  • Die vorliegende Erfindung wird beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen veranschaulicht, in denen gleiche Bezugszeichen ähnliche Elemente angeben und worin:
  • 1 eine Befehlsausführungspipeline zeigt;
  • 2A, 2B die Vektorverarbeitung betreffen;
  • 3A, 3B eine Integralbildberechnung betreffen;
  • 4 die Operationen von zwei Befehlen für die Integralbildberechnung zeigt;
  • 5A einen Funktionseinheitslogikentwurf zum Implementieren der Befehle nach 4 zeigt;
  • 5B einen Ablaufplan für die Befehle nach 4 zeigt;
  • 5C jeweilige Ablaufpläne für zwei verschiedene Befehle zeigt;
  • 6A ein Blockdiagramm ist, das ein generisches vektorfreundliches Befehlsformat und dessen Befehlsschablonen der Klasse A gemäß den Ausführungsformen der Erfindung veranschaulicht;
  • 6B ein Blockdiagramm ist, das ein generisches vektorfreundliches Befehlsformat und dessen Befehlsschablonen der Klasse B gemäß den Ausführungsformen der Erfindung veranschaulicht;
  • 7A–C ein Blockdiagramm sind, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß den Ausführungsformen der Erfindung veranschaulicht;
  • 8 ein Blockschaltplan einer Registerarchitektur gemäß einer Ausführungsform der Erfindung ist;
  • 9A ein Blockschaltplan eines einzelnen CPU-Kerns zusammen mit seiner Verbindung mit dem Verbindungsnetz auf dem Die und mit seiner lokalen Teilmenge des ”Caches” der Ebene 2 (L2-”Caches”) gemäß den Ausführungsformen der Erfindung ist;
  • 9B eine Explosionsansicht eines Teils des CPU-Kerns in 9A gemäß den Ausführungsformen der Erfindung ist;
  • 10 ein Blockschaltplan ist, der eine beispielhafte Nicht-in-der-Reihenfolge-Architektur gemäß den Ausführungsformen der Erfindung veranschaulicht;
  • 11 ein Blockschaltplan eines Systems gemäß einer Ausführungsform der Erfindung ist;
  • 12 ein Blockschaltplan eines zweiten Systems gemäß einer Ausführungsform der Erfindung ist;
  • 13 ein Blockschaltplan eines dritten Systems gemäß einer Ausführungsform der Erfindung ist;
  • 14 ein Blockschaltplan eines SoC gemäß einer Ausführungsform der Erfindung ist;
  • 15 ein Blockschaltplan eines Einzelkernprozessors und eines Mehrkernprozessors mit integriertem Speicher-Controller und integrierter Graphik gemäß den Ausführungsformen der Erfindung ist; und
  • 16 ein Blockschaltplan ist, der die Verwendung eines Software-Befehlsumsetzers, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz umzusetzen, gemäß den Ausführungsformen der Erfindung gegenüberstellt.
  • Ausführliche Beschreibung
  • 4 zeigt einen programmatischen Ablauf für zwei neue Befehle 401, 402, der eine Vektorvorgehensweise verwendet, um die Ineffizienz des Vertrauens auf streng serielle, Skalar-ADD-Befehle zu verbessern. Wie in 4 beobachtet wird, führen beide Befehle 401, 402 parallele ADD-Operationen an bestimmten Eingangsvektorelementen aus, wobei sie bestimmte Eingangsvektorelemente durchleiten. Die Kombination, welche Vektorelemente addiert werden und welche Vektorelemente durchgelassen werden, ist wie zwischen den beiden Befehlen verschieden.
  • Spezifischer addiert der erste Befehl 401 jedes zweite Element zu seinem ganz rechten Nachbar, wobei er jeden derartigen ganz rechten Nachbarn durchleitet. Das heißt, die Elemente 410, 411 des Eingangsvektors 409 werden zu ihren jeweiligen ganz rechten Nachbarn 412, 413 addiert, um die Ergebniselemente 414, 415 zu erzeugen, wobei die ganz rechten Nachbarn 412, 413 außerdem zu dem Ergebnis 416 durchgeleitet werden, um ein Ergebnis zu erzeugen, das die Summationsterme 414, 415 aufweist, die mit den Durchleitungstermen 412, 413 verschachtelt sind. Im Gegensatz addiert der zweite Befehl 402 das gleiche Eingangselement 414 (höchster Ordnung) von dem rechten Satz 417 (niedrigster Ordnung) der Elemente seines Eingangsvektors 416 zu jedem Element des linken Satzes 419 (höchster Ordnung) der Elemente des Eingangsvektors, während er den rechten Satz 417 der Eingangselemente durchleitet.
  • Wie in 4 beobachtet wird, enthält das Ergebnis 420 des zweiten Befehls 402 als solches die Summationsterme auf seiner linken Seite 421, aber die Durchleitungsterme auf seiner rechten Seite 422. Das Ergebnis 420 der beiden Befehle, wobei der zweite Befehl 402 auf das Ergebnis des ersten Befehls 401 wirkt, erzeugt Summationen (z. B. entlang derselben Achse, wie z. B. der x-Achse) für Bildflächen mit verschiedenen Breiten, die (für die oben erörterte spezielle Ausführungsform) mit zunehmender Bildgröße von rechts nach links orientiert sind. Die Durchschnittsfachleute erkennen, dass die Orientierung links gegen rechts eine Sache der Wahl des Entwicklers ist und in alternativen Ausführungsformen leicht umgekehrt werden kann.
  • Folglich wird durch das Vergleichen der Befehlsfolge nach 3b mit der Befehlsfolge nach 4 bemerkt, dass ein ganzer Maschinenzyklus aus der Berechnung eliminiert worden ist.
  • 5a zeigt einen Logikentwurf für eine Funktionseinheit, die beide der Befehle implementieren kann, die oben bezüglich 4 erörtert worden sind. Wie in 5a beobachtet wird, werden die Elemente eines Eingangsvektors 501 zu einer Addierer-Multiplexierer-Bank 502 und zu einer Durchleitungs-Multiplexierer-Bank 503 geleitet. Die Ausgangsknoten der Addierer-Multiplexierer-Bank 502 werden zu den Eingangsknoten einer Addiererbank 504 geleitet. Die Steuereingänge der Durchleitungs-Multiplexierer-Bank 503 bestimmen, ob das entsprechende Element für den Ergebnisvektor 505 ein Durchleitungsterm von dem Eingangsvektor 501 oder ein Addiererterm von der Addiererbank 504 sein soll. Die Steuereingaben der Addierer-Multiplexierer-Bank 502 bestimmen, welche Eingangsvektorelemente für einen speziellen Elementort des Ausgangsvektors 505 addiert werden.
  • Die Addierer der Addiererbank 504 addieren die ihnen dargestellten Eingangsterme und leiten die entsprechenden Summationsterme zu der Durchleitungs-Multiplexierer-Bank 503. Hier kann z. B. der in einem ROM 506 gespeicherte Mikrocode den verschiedenen Multiplexierern die geeigneten Steuereingaben für den speziellen Befehl, der auszuführen ist, bereitstellen. Die beiden Befehle können mit verschiedenen Opcodes oder mit denselben Opcodes, die verschiedene unmittelbare Operanden aufweisen, die vorschreiben, welcher spezifische Befehl ausgeführt werden soll, spezifiziert werden. Falls der Mikrocode nicht verwendet wird, könnten die geeigneten Steuersignale z. B. durch eine festverdrahtete Decodiererschaltungsanordnung erzeugt werden, die den Opcode/unmittelbaren Operanden in passende Multiplexierer-Steuereingangswerte decodiert. Es sei angegeben, dass der Eingangsvektorblock 501 und der Ausgangsvektorblock 505 einem Registerplatz der Vektorregister, die der Befehlsausführungspipeline zugeordnet sind (z. B. an die Befehlsausführungspipeline gekoppelt sind), oder spezifischen Registern innerhalb einer Befehlsausführungspipeline entsprechen können.
  • Es sei angegeben, dass allgemeiner die Addierer- und Durchleitungs-Multiplexierer-Bänke als ein Typ der Ausführungsform für die Addiererauswahlschaltungsanordnung bzw. die Durchleitungsauswahlschaltungsanordnung betrachtet werden können.
  • Die in 5a beobachteten spezifischen Verdrahtungswege sind für die Leichtigkeit der Veranschaulichung mit den in 4 beobachteten spezifischen Operationen ”arrangiert”. Abermals sind die Durchschnittsfachleute imstande, die Ergebnisse anders zu orientieren und/oder zu gestalten und/oder die inneren Operationen anders zu orientieren und/oder zu gestalten. 5b zeigt einen generischeren Funktionseinheitsentwurf, der für irgendeinen Addierer irgendwelche zwei Eingangsvektorelemente addieren und irgendein Eingangsvektorelement durchleiten kann.
  • 5c zeigt jeweilige Ablaufpläne 550, 560 für die beiden verschiedenen Befehle. Für den ersten Befehl 550 werden die für die Addition gewählten Eingangsvektorelemente und die für das Durchleiten gewählten Eingangsvektorelemente in einer abwechselnden Weise 551 ausgewählt. Die für die Addition gewählten Eingangsvektorelemente werden zu einem benachbarten Vektorelement addiert, das außerdem für das Durchleiten 552 gewählt worden ist. Das Ergebnis wird als die Summationsterme von der Addition, die mit den Durchleitungstermen in einer abwechselnden Weise verschachtelt sind, dargestellt. Für den zweiten Befehl 560 wird ein Eingangselement von einer ersten Seite des Eingangsvektors für die Addition zu (z. B. allen) Eingangselementen auf der anderen Seite des Eingangsvektors 561 gewählt. Die Elemente der ersten Seite werden zu dem Ergebnis 562 durchgeleitet, während die Summationsterme von der Addition, die die Terme der anderen Seite umfassen, zu dem Ergebnis 563 geleitet werden.
  • Es sei angegeben, dass die oben erörterten Befehlsfolgen in maschinenlesbaren Medien als Programmcode für die Ausführung durch einen Computer implementiert sein können, der eine Befehlsausführungspipeline aufweist, die die Befehle ausführt. Die Befehlsfolge des Programmcodes kann durch einen Kompilierer erzeugt werden, der dafür ausgelegt ist, einen Objektcode z. B. aus einer Programmablaufbeschreibung auf höherer Ebene zu erzeugen.
  • Das generische vektorfreundliche Befehlsformat
  • Die oben ausführlich beschriebenen Ausführungsformen des Befehls (der Befehle) können in einem ”generischen vektorfreundlichen Befehlsformat” verkörpert sein, das im Folgenden ausführlich beschrieben wird. In anderen Ausführungsformen wird ein derartiges Format nicht verwendet und wird ein anderes Befehlsformat verwendet, wobei jedoch die Beschreibung im Folgenden der Schreibmaskenregister, der verschiedenen Datentransformationen (”Swizzle”, Rundsenden usw.), der Adressierung usw. im Allgemeinen auf die Beschreibung der Ausführungsformen des obigen Befehls (der obigen Befehle) anwendbar ist.
  • Außerdem werden im Folgenden beispielhafte Systeme, Architekturen und Pipelines ausführlich beschrieben. Die Ausführungsformen des obigen Befehls (der obigen Befehle) können durch derartige Systeme, Architekturen und Pipelines ausgeführt werden, sind aber nicht auf jene, die ausführlich beschrieben sind, eingeschränkt.
  • Ein vektorfreundliches Befehlsformat ist ein Befehlsformat, das für Vektorbefehle geeignet ist (es gibt z. B. bestimmte Felder, die für Vektoroperationen spezifisch sind). Während Ausführungsformen beschrieben sind, in denen sowohl Vektor- als auch Skalaroperationen durch das vektorfreundliche Befehlsformat unterstützt werden, verwenden in alternativen Ausführungsformen nur Vektoroperationen das vektorfreundliche Befehlsformat.
  • Das beispielhafte generische vektorfreundliche Befehlsformat – die Fig. 6A–B
  • Die 6A–B sind Blockdiagramme, die ein generisches vektorfreundliches Befehlsformat und dessen Befehlsschablonen gemäß den Ausführungsformen der Erfindung veranschaulichen. 6A ist ein Blockdiagramm, das ein generisches vektorfreundliches Befehlsformat und dessen Befehlsschablonen der Klasse A gemäß den Ausführungsformen der Erfindung veranschaulicht; während 6B ein Blockdiagramm ist, das ein generisches vektorfreundliches Befehlsformat und dessen Befehlsschablonen der Klasse B gemäß den Ausführungsformen der Erfindung veranschaulicht. Spezifisch ein generisches vektorfreundliches Befehlsformat 600, für das die Befehlsschablonen der Klasse A und der Klasse B definiert sind, wobei beide von diesen Befehlsschablonen ohne Speicherzugriff 605 und Befehlsschablonen mit Speicherzugriff 620 enthalten. Der Begriff generisch im Kontext des vektorfreundlichen Befehlsformats bezieht sich auf das Befehlsformat, das nicht an irgendeinen spezifischen Befehlssatz gebunden ist. Während die Ausführungsformen beschrieben werden, in denen die Befehle in dem vektorfreundlichen Befehlsformat auf Vektoren wirken, die von irgendwelchen Registern (Befehlsschablonen ohne Speicherzugriff 605) oder Registern/dem Speicher (Befehlsschablonen mit Speicherzugriff 620) bezogen werden, können alternative Ausführungsformen der Erfindung nur eines von diesen unterstützen. Während außerdem die Ausführungsformen der Erfindung beschrieben werden, in denen es Lade- und Speicherbefehle in dem Vektorbefehlsformat gibt, weisen alternative Ausführungsformen stattdessen oder zusätzlich Befehle in einem anderen Befehlsformat auf, die Vektoren in und aus Registern (z. B. aus dem Speicher in Register, aus Registern in den Speicher, zwischen Registern) bewegen. Während ferner die Ausführungsformen der Erfindung beschrieben werden, die zwei Klassen von Befehlsschablonen unterstützen, können alternative Ausführungsformen nur eine von diesen oder mehr als zwei unterstützen.
  • Währenddessen werden die Ausführungsformen der Erfindung beschrieben, in denen das vektorfreundliche Befehlsformat das Folgende unterstützt: eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-) oder 64-Bit-(8-Byte-)Datenelementbreiten (oder -größen), (wobei folglich ein 64-Byte-Vektor entweder aus 16 Elementen in Doppelwortgröße oder alternativ 8 Elementen in Vierfachwortgröße besteht); eine 64-Byte-Vektoroperandenlänge (oder -größe) mit 16-Bit-(2-Byte-) oder 8-Bit-(1-Byte-)Datenelementbreiten (oder -größen); eine 32-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-), 64-Bit-(8-Byte-), 16-Bit-(2-Byte-) oder 8-Bit-(1-Byte-)Datenelementbreiten (oder -größen); und eine 16-Byte-Vektoroperandenlänge (oder -größe) mit 32-Bit-(4-Byte-), 64-Bit-(8-Byte-), 16-Bit-(2-Byte-) oder 8-Bit-(1-Byte-)Datenelementbreiten (oder -größen); alternative Ausführungsformen können mehr, weniger und/oder andere Vektoroperandengrößen (z. B. 656-Byte-Vektoroperanden) mit mehr, weniger oder anderen Datenelementbreiten (z. B. 128-Bit-(16-Byte-)Datenelementbreiten) unterstützen.
  • Die Befehlsschablonen der Klasse A in 6A enthalten Folgendes: 1) innerhalb der Befehlsschablonen ohne Speicherzugriff 605 ist eine Befehlsschablone einer Operation 610 des Typs der Steuerung des vollen Rundens ohne Speicherzugriff und eine Befehlsschablone einer Operation 615 des Datentransformationstyps ohne Speicherzugriff gezeigt; und 2) innerhalb der Befehlsschablonen mit Speicherzugriff 620 ist eine zeitliche Befehlsschablone 625 mit Speicherzugriff und eine nicht zeitliche Befehlsschablone 630 mit Speicherzugriff gezeigt. Die Befehlsschablonen der Klasse B in 6B enthalten Folgendes: 1) innerhalb der Befehlsschablonen ohne Speicherzugriff 605 ist eine Befehlsschablone einer Operation 612 des Typs der Steuerung eines teilweisen Rundens mit Schreibmaskensteuerung und ohne Speicherzugriff und eine Befehlsschablone einer Operation 617 des vsize-Typs mit Schreibmaskensteuerung und ohne Speicherzugriff gezeigt; und 2) innerhalb der Befehlsschablonen mit Speicherzugriff 620 ist eine Befehlsschablone mit Schreibmaskensteuerung 627 und Speicherzugriff gezeigt.
  • Das Format
  • Das generische vektorfreundliche Befehlsformat 600 enthält die folgenden Felder, die im Folgenden in der in den 6A–B veranschaulichten Reihenfolge aufgelistet sind. Im Zusammenhang mit den obigen Erörterungen kann in einer Ausführungsform unter Bezugnahme auf die Formateinzelheiten, die im Folgenden in den 6A–B und 7A–C bereitgestellt sind, entweder ein Befehlstyp 605 ohne Speicherzugriff oder ein Befehlstyp 620 mit Speicherzugriff verwendet werden. Die Adressen für den Eingangsvektoroperanden und das Ziel können in einem im Folgenden beschriebenen Registeradressenfeld 644 identifiziert werden.
  • Das Formatfeld 640 – ein spezifischer Wert (ein Befehlsformat-Identifiziererwert) in diesem Feld identifiziert eindeutig das vektorfreundliche Befehlsformat und folglich die Vorkommen von Befehlen in dem vektorfreundlichen Befehlsformat in den Befehlsströmen. Folglich unterscheidet der Inhalt des Formatfeldes 640 die Vorkommen der Befehle in dem ersten Befehlsformat von den Vorkommen der Befehle in anderen Befehlsformaten, wobei er deshalb die Einführung des vektorfreundlichen Befehlsformats in einen Befehlssatz ermöglicht, der andere Befehlsformate aufweist. Dieses Feld ist als solches in dem Sinn optional, dass es für einen Befehlssatz, der nur das generische vektorfreundliche Befehlsformat aufweist, nicht erforderlich ist.
  • Das Basisoperationsfeld 642 – sein Inhalt unterscheidet die verschiedenen Basisoperationen. Wie hier später beschrieben wird, kann das Basisoperationsfeld 642 ein Opcode-Feld enthalten und/oder Teil eines Opcode-Feldes sein.
  • Das Registerindexfeld 644 – sein Inhalt spezifiziert direkt oder durch Adressenerzeugung die Orte der Quell- und Zieloperanden, ob sie sich in Registern oder im Speicher befinden. Diese enthalten eine ausreichende Anzahl von Bits, um N Register aus einer P × Q-Registerdatei (z. B. einer 32 × 1012-Registerdatei) auszuwählen. Während in einer Ausführungsform N bis zu drei Quellen und ein Zielregister sein kann, können alternative Ausführungsformen mehr oder weniger Quellen und Zielregister unterstützen (sie können z. B. bis zu zwei Quellen unterstützen, wobei eine dieser Quellen außerdem als das Ziel wirkt, sie können bis zu drei Quellen unterstützen, wobei eine dieser Quelle außerdem als das Ziel wirkt, und sie können bis zu zwei Quellen und ein Ziel unterstützen). Während in einer Ausführungsform P = 32 gilt, können alternative Ausführungsformen mehr oder weniger Register (z. B. 16) unterstützen. Während in einer Ausführungsform Q = 1012 Bits gilt, können alternative Ausführungsformen mehr oder weniger Bits (z. B. 128, 1024) unterstützen.
  • Das Modifiziererfeld 646 – sein Inhalt unterscheidet die Vorkommen der Befehle in dem generischen Vektorbefehlsformat, die den Vektorzugriff spezifizieren, von jenen, die dies nicht ausführen; d. h., zwischen den Befehlsschablonen ohne Speicherzugriff 605 und den Befehlsschablonen 620 mit Speicherzugriff. Die Operationen mit Speicherzugriff lesen und/oder schreiben in die Speicherhierarchie (wobei sie in einigen Fällen die Quell- und/oder Zieladressen unter Verwendung der Werte in den Registern spezifizieren), während die Operationen ohne Speicherzugriff dies nicht tun (z. B. die Quelle und die Ziele Register sind). Während in einer Ausführungsform dieses Feld außerdem zwischen drei verschiedenen Weisen unterscheidet, um die Speicheradressenberechnungen auszuführen, können alternative Ausführungsformen mehr, weniger oder andere Weisen unterstützen, um die Speicheradressenberechnungen auszuführen.
  • Das Vergrößerungsoperationsfeld 650 – sein Inhalt unterscheidet, welche von einer Vielfalt verschiedener Operationen zusätzlich zu der Basisoperation auszuführen ist. Dieses Feld ist kontextspezifisch. In einer Ausführungsform der Erfindung ist dieses Feld in ein Klassenfeld 668, ein Alphafeld 652 und ein Betafeld 654 unterteilt. Das Vergrößerungsoperationsfeld ermöglicht, dass gemeinsame Gruppen von Operationen anstatt in 2, 3 oder 4 Befehlen in einem einzigen Befehl ausgeführt werden. Im Folgenden befinden sich einige Beispiele der Befehle (deren Nomenklatur hier später ausführlicher beschrieben wird), die das Vergrößerungsfeld 650 verwenden, um die Anzahl der erforderlichen Befehle zu verringern.
    frühere Befehlsfolgen Befehlsfolgen gemäß einer Ausführungsform der Erfindung
    vaddps ymm0, ymm1, ymm2 vaddps zmm0, zmm1, zmm2
    vpshufd ymm2, ymm2, 0x55 vaddps ymm0, ymm1, ymm2 vaddps zmm0, zmm1, zmm2 {bbbb}
    vpmovsxbd ymm2, [rax] vcvtdq2ps ymm2, ymm2 vaddps ymm0, ymm1, ymm2 vaddps zmm0, zmm1, [rax] {sint8}
    vpmovsxbd ymm3, [rax] vcvtdq2ps ymm3, ymm3 vaddps ymm4, ymm2, ymm3 vblendvps ymm1, ymm5, ymm1, ymm4 vaddps zmm1 {k5}, zmm2, [rax] {sint8}
    vmaskmovps ymm1, ymm7, [rbx] vbroadcastss ymm0, [rax] vaddps ymm2, ymm0, ymm1 vblendvps ymm2, ymm2, ymm1, ymm7 vmovaps zmm1 {k7}, [rbx] vaddps zmm2 {k7} {z}, zmm1, [rax] {1toN}
  • Wobei [rax] der Basiszeiger ist, der für die Adressenerzeugung zu verwenden ist, und wobei {} eine Umsetzungsoperation angibt, die durch das Datenmanipulationsfeld (das hier später ausführlicher beschrieben wird) spezifiziert ist.
  • Das Maßstabsfeld 660 – sein Inhalt ermöglicht das Skalieren des Inhalts des Indexfeldes für die Speicheradressenerzeugung (z. B. für die Adressenerzeugung, die 2Maßstab·Index + Basis verwendet).
  • Das Verschiebungsfeld 662A – sein Inhalt wird als ein Teil der Speicheradressenerzeugung verwendet (z. B. für die Adressenerzeugung, die 2Maßstab·Index + Basis + Verschiebung verwendet).
  • Das Verschiebungsfaktorfeld 662B (es sei angegeben, dass die Nebeneinanderstellung des Verschiebungsfeldes 662A direkt über das Verschiebungsfaktorfeld 662B angibt, dass das eine oder das andere verwendet wird) – sein Inhalt wird als Teil der Adressenerzeugung verwendet; es spezifiziert einen Verschiebungsfaktor, der mit der Größe eines Speicherzugriffs (N) zu skalieren ist – wobei N die Anzahl der Bytes in dem Speicherzugriff ist (z. B. für die Adressenerzeugung, die 2Maßstab·Index + Basis + skalierte Verschiebung verwendet). Redundante Bits niedriger Ordnung werden ignoriert, wobei folglich der Inhalt des Verschiebungsfaktorfeldes mit der Gesamtgröße (N) der Speicheroperanden multipliziert wird, um die endgültige Verschiebung zu erzeugen, die beim Berechnen einer effektiven Adresse zu verwenden ist. Der Wert von N wird durch die Prozessor-Hardware zur Laufzeit basierend auf dem vollen Opcode-Feld 674 (das hier später beschrieben wird) und dem Datenmanipulationsfeld 654C bestimmt, wie hier später beschrieben wird. Das Verschiebungsfeld 662A und das Verschiebungsfaktorfeld 662B sind in dem Sinn optional, dass sie für die Befehlsschablonen ohne Speicherzugriff 605 nicht verwendet werden und/oder verschiedene Ausführungsformen nur eines oder keines der beiden implementieren können.
  • Das Datenelementbreitenfeld 664 – sein Inhalt unterscheidet, welche von einer Anzahl von Datenelementbreiten verwendet werden soll (in einigen Ausführungsformen für alle Befehle; in anderen Ausführungsformen für nur einige der Befehle). Dieses Feld ist in dem Sinn optional, dass es nicht erforderlich ist, falls nur eine Datenelementbreite unterstützt wird und/oder die Datenelementbreiten unter Verwendung irgendeines Aspekts der Opcodes unterstützt werden.
  • Das Schreibmaskenfeld 670 – sein Inhalt steuert auf einer Grundlage pro Datenelementposition, ob die Datenelementposition in dem Zielvektoroperanden das Ergebnis der Basisoperation und der Vergrößerungsoperation widerspiegelt. Die Befehlsschablonen der Klasse A unterstützen die Verschmelzungs-Schreibmaskierung, während die Befehlsschablonen der Klasse B sowohl die Verschmelzungs- als auch die Nullsetzungs-Schreibmaskierung unterstützen. Beim Verschmelzen ermöglichen die Vektormasken, dass irgendein Satz von Elementen in dem Ziel während der Ausführung irgendeiner Operation (die durch die Basisoperation und die Vergrößerungsoperation spezifiziert ist) vor Aktualisierungen geschützt ist; in einer anderen Ausführungsformen wird der alte Wert jedes Elements des Ziels, wo das entsprechende Maskenbit eine 0 aufweist, beibehalten. Im Gegensatz ermöglichen die Vektormasken bei der Nullsetzung, dass während der Ausführung irgendeiner Operation (die durch die Basisoperation und die Vergrößerungsoperation spezifiziert ist) irgendein Satz von Elementen in dem Ziel null gesetzt wird; in einer Ausführungsform wird ein Element des Ziels auf 0 gesetzt, wenn das entsprechende Maskenbit einen 0-Wert aufweist. Eine Teilmenge dieser Funktionalität ist die Fähigkeit, die Vektorlänge der Operation, die ausgeführt wird, (d. h., die Spanne der Elemente, die modifiziert werden, vom ersten bis zum letzten) zu steuern; es ist jedoch nicht notwendig, dass die Elemente, die modifiziert werden, aufeinanderfolgend sind. Folglich ermöglicht das Schreibmaskenfeld 670 teilweise Vektoroperationen, einschließlich Ladeoperationen, Speicheroperationen, arithmetischer Operationen, logischer Operationen usw. Diese Maskierung kann außerdem für die Fehlerunterdrückung verwendet werden (d. h., durch das Maskieren der Datenelementpositionen des Ziels, um den Empfang des Ergebnisses irgendeiner Operation zu verhindern, die einen Fehler verursachen kann/verursacht – z. B. angenommen, dass ein Vektor in einem Speicher eine Seitengrenze kreuzt und dass die erste Seite, aber nicht die zweite Seite einen Seitenfehler verursachen würde, wobei der Seitenfehler ignoriert werden kann, falls alle Datenelemente des Vektors, die auf der ersten Seite liegen, durch die Schreibmaske maskiert werden). Ferner ermöglichen die Schreibmasken ”Vektorisierungsschleifen”, die bestimmte Typen von bedingten Anweisungen enthalten. Während die Ausführungsformen der Erfindung beschrieben werden, in denen der Inhalt des Schreibmaskenfeldes 670 eines aus einer Anzahl von Schreibmaskenregistern auswählt, das die zu verwendende Schreibmaske enthält, (wobei folglich der Inhalt des Schreibmaskenfeldes 670 indirekt identifiziert, dass die Maskierung auszuführen ist), ermöglichen alternative Ausführungsformen stattdessen oder zusätzlich, dass der Inhalt des Schreibmaskenfeldes 670 direkt die Maskierung spezifiziert, die auszuführen ist. Ferner erlaubt das Nullsetzen Leistungsverbesserungen, wenn: 1) die Registerumbenennung bei Befehlen verwendet wird, deren Zieloperand nicht außerdem eine Quelle ist (außerdem Nicht-dreifach-Befehle genannt), weil während der Registerumbenennungs-Pipelinestufe das Ziel nicht länger eine implizite Quelle ist (es müssen keine Datenelemente von dem aktuellen Zielregister in das umbenannte Zielregister kopiert werden oder irgendwie zusammen mit der Operation übertragen werden, weil jedes Datenelement, das nicht das Ergebnis der Operation ist, (irgendein maskiertes Datenelement) nullgesetzt wird); und 2) während der Rückschreibstufe, weil Nullen geschrieben werden.
  • Das unmittelbare Feld 672 – sein Inhalt ermöglicht die Spezifikation eines unmittelbaren Wertes. Dieses Feld ist in dem Sinn optional, dass es in einer Implementierung des generischen vektorfreundlichen Formats nicht vorhanden ist, die keinen unmittelbaren Wert unterstützt, und dass es in Befehlen nicht vorhanden ist, die keinen unmittelbaren Wert verwenden.
  • Die Auswahl der Klasse der Befehlsschablone
  • Das Klassenfeld 668 – sein Inhalt unterscheidet zwischen verschiedenen Klassen von Befehlen. In den 2A–B wählen die Inhalte dieses Feldes zwischen den Befehlen der Klasse A und der Klasse B aus. In den 6A–B werden die Vierecke mit abgerundeten Ecken verwendet, um einen spezifischen Wert anzugeben, der in einem Feld vorhanden ist (z. B. Klasse A 668A bzw. Klasse B 668B für das Klassenfeld 668 in den 6A–B).
  • Die Befehlsschablonen ohne Speicherzugriff der Klasse A
  • In dem Fall der Befehlsschablonen ohne Speicherzugriff 605 der Klasse A wird das Alphafeld 652 als ein RS-Feld 652A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Vergrößerungsoperationstypen ausgeführt werden soll (z. B. das Runden 652A.1 und die Datentransformation 652A.2 sind für die Befehlsschablonen der Operation 610 des Rundungstyps ohne Speicherzugriff bzw. der Operation 615 des Datentransformationstyps ohne Speicherzugriff spezifiziert), während das Betafeld 654 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In 6 werden die Blöcke mit abgerundeten Ecken verwendet, um einen spezifischen Wert anzugeben, der vorhanden ist (z. B. kein Speicherzugriff 646A in dem Modifiziererfeld 646; das Runden 652A.1 und die Datentransformation 652A.2 für das Alphafeld 652/rs-Feld 652A). In den Befehlsschablonen ohne Speicherzugriff 605 sind das Maßstabsfeld 660, das Verschiebungsfeld 662A und das Verschiebungsmaßstabsfeld 662B nicht vorhanden.
  • Die Befehlsschablonen ohne Speicherzugriff – die Operation des Typs der Steuerung des vollen Rundens
  • In der Befehlsschablone der Operation 610 des Typs der Steuerung der vollen Rundens ohne Speicherzugriff wird das Betafeld 654 als ein Rundungssteuerfeld 654A interpretiert, dessen Inhalt(e) ein statisches Runden bereitstellen. Während in den beschriebenen Ausführungsformen der Erfindung das Rundungssteuerfeld 654A ein Feld 656 zum Unterdrücken aller Gleitkomma-Ausnahmen (SAE) und ein Rundungsoperations-Steuerfeld 658 enthält, können alternative Ausführungsformen das Codieren dieser beiden Konzepte in dasselbe Feld unterstützen oder können nur das eine oder das andere dieser Konzepte/Felder aufweisen (können z. B. nur das Rundungsoperations-Steuerfeld 658 aufweisen).
  • Das SAE-Feld 656 – sein Inhalt unterscheidet, ob die Ausnahmeereignismeldung zu sperren ist oder nicht; wenn der Inhalt des SAE-Feldes 656 angibt, dass die Unterdrückung freigegeben ist, meldet ein gegebener Befehl keine Art eines Gleitkommaausnahmemerkers und startet keine Gleitkommaausnahmebehandlungseinrichtung.
  • Das Rundungsoperations-Steuerfeld 658 – sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen auszuführen ist (z. B. Aufrunden, Abrunden, Runden zur Null und Runden zum Nächsten). Folglich ermöglicht das Rundungsoperations-Steuerfeld 658 das Ändern des Rundungsmodus auf einer Grundlage pro Befehl, wobei es folglich besonders nützlich ist, wenn dies erforderlich ist. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi enthält, setzt der Inhalt des Rundungsoperations-Steuerfelds 650 diesen Registerwert außer Kraft (es ist vorteilhaft, imstande zu sein, den Rundungsmodus wählen zu können, ohne ein Sichern-Modifizieren-Wiederherstellen an einem derartigen Steuerregister ausführen zu müssen).
  • Die Befehlsschablonen ohne Speicherzugriff – die Operation des Datentransformationstyps
  • In der Befehlsschablone der Operation 615 des Datentransformationstyps ohne Speicherzugriff wird das Betafeld 654 als ein Datentransformationsfeld 654B interpretiert, dessen Inhalt unterscheidet, welche von einer Anzahl von Datentransformationen ausgeführt werden soll (z. B. keine Datentransformation, ”Swizzle”, Rundsenden).
  • Die Befehlsschablonen mit Speicherzugriff der Klasse A
  • In dem Fall einer Befehlsschablone mit Speicherzugriff 620 der Klasse A wird das Alphafeld 652 als ein Räumungshinweisfeld 652B interpretiert, dessen Inhalt unterscheidet, welcher der Räumungshinweise verwendet werden soll (in 6A sind zeitlich 652B.1 und nicht zeitlich 652B.2 für die zeitliche Befehlsschablone 625 mit Speicherzugriff bzw. die nicht zeitliche Befehlsschablone 630 mit Speicherzugriff spezifiziert), während das Betafeld 654 als ein Datenmanipulationsfeld 654C interpretiert wird, dessen Inhalt unterscheidet, welche von einer Anzahl von Datenmanipulationsoperationen (die außerdem als Grundelemente bekannt sind) ausgeführt werden soll (z. B. keine Manipulation; Rundsenden; Aufwärtsumsetzung einer Quelle; und Abwärtsumsetzung eines Ziels). Die Befehlsschablonen mit Speicherzugriff 620 enthalten das Maßstabsfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsmaßstabsfeld 662B.
  • Die Vektorspeicherbefehle führen Vektorladeoperationen aus dem und Vektorspeicheroperationen in den Speicher mit Umsetzungsunterstützung aus. Wie bei regulären Vektorbefehlen übertragen die Vektorspeicherbefehle Daten von dem/zu dem Speicher in einer datenelementweisen Weise, wobei die Elemente, die tatsächlich übertragen werden, durch die Inhalte der Vektormaske vorgeschrieben sind, die als die Schreibmaske ausgewählt ist. In 6A werden die Vierecke mit abgerundeten Ecken verwendet, um einen spezifischen Wert anzugeben, der in einem Feld vorhanden ist (z. B. Speicherzugriff 646B für das Modifiziererfeld 646; zeitlich 652B.1 und nicht zeitlich 652B.2 für das Alphafeld 652/das Räumungshinweisfeld 652B).
  • Befehlsschablonen mit Speicherzugriff – zeitlich
  • Die zeitlichen Daten sind Daten, die wahrscheinlich bald genug erneut verwendet werden, um von der ”Cache”-Speicherung zu profitieren. Dies ist jedoch ein Hinweis, wobei verschiedene Prozessoren ihn in verschiedener Weise implementieren können, einschließlich des völligen Ignorierens des Hinweises.
  • Befehlsschablonen mit Speicherzugriff – nicht zeitlich
  • Die nicht zeitlichen Daten sind Daten, bei denen es unwahrscheinlich ist, dass sie bald genug erneut verwendet werden, um von der ”Cache”-Speicherung im ”Cache” der 1. Ebene zu profitieren, wobei ihnen die Priorität für die Räumung gegeben werden sollte. Dies ist jedoch ein Hinweis, wobei verschiedene Prozessoren ihn in verschiedener Weise implementieren können, einschließlich des völligen Ignorierens des Hinweises.
  • Die Befehlsschablonen der Klasse B
  • In dem Fall der Befehlsschablonen der Klasse B wird das Alphafeld 652 als ein Schreibmaskensteuerfeld (Z-Feld) 652C interpretiert, dessen Inhalt unterscheidet, ob die durch das Schreibmaskenfeld 670 gesteuerte Schreibmaskierung eine Verschmelzung oder eine Nullsetzung sein sollte.
  • Die Befehlsschablonen ohne Speicherzugriff der Klasse B
  • In dem Fall der Befehlsschablonen ohne Speicherzugriff 605 der Klasse B wird ein Teil des Betafeldes 654 als ein RL-Feld 657A interpretiert, dessen Inhalt unterscheidet, welcher der verschiedenen Vergrößerungsoperationstypen ausgeführt werden soll (z. B. das Runden 657A.1 und die Vektorlänge (VSIZE) 657A.2 sind jeweils für die Befehlsschablone der Operation 612 des Typs der Steuerung eines teilweisen Rundens mit Schreibmaskensteuerung und ohne Speicherzugriff bzw. die Befehlsschablone der Operation 617 des VSIZE-Typs mit Schreibmaskensteuerung und ohne Speicherzugriff spezifiziert), während der Rest des Betafeldes 654 unterscheidet, welche der Operationen des spezifizierten Typs ausgeführt werden soll. In 6 werden die Blöcke mit abgerundeten Ecken verwendet, um einen spezifischen Wert anzugeben, der vorhanden ist (z. B. kein Speicherzugriff 646A in dem Modifiziererfeld 646; das Runden 657A.1 und VSIZE 657A.2 für das RL-Feld 657A). In den Befehlsschablonen ohne Speicherzugriff 605 sind das Maßstabsfeld 660, das Verschiebungsfeld 662A und das Verschiebungsmaßstabsfeld 662B nicht vorhanden.
  • Befehlsschablonen ohne Speicherzugriff – die Schreibmaskensteuerung, die Operation des Typs der Steuerung des teilweisen Rundens
  • In der Befehlsschablone der Operation 610 des Typs der Steuerung des teilweisen Rundens mit Schreibmaskensteuerung und ohne Speicherzugriff wird der Rest des Betafeldes 654 als ein Rundungsoperationsfeld 659A interpretiert, wobei die Ausnahmeereignismeldung gesperrt ist (ein gegebener Befehl meldet keine Art eines Gleitkommaausnahmemerkers und startet keine Gleitkommaausnahmebehandlungseinrichtung).
  • Das Rundungsoperations-Steuerfeld 659A – genau wie das Rundungsoperations-Steuerfeld 658, sein Inhalt unterscheidet, welche aus einer Gruppe von Rundungsoperationen auszuführen ist (z. B. Aufrunden, Abrunden, Runden zur Null und Runden zum Nächsten). Folglich ermöglicht das Rundungsoperations-Steuerfeld 659A das Ändern des Rundungsmodus auf einer Grundlage pro Befehl, wobei es folglich besonders nützlich ist, wenn dies erforderlich ist. In einer Ausführungsform der Erfindung, in der ein Prozessor ein Steuerregister zum Spezifizieren der Rundungsmodi enthält, setzt der Inhalt des Rundungsoperations-Steuerfeldes 650 diesen Registerwert außer Kraft (es ist vorteilhaft, imstande zu sein, den Rundungsmodus wählen zu können, ohne ein Sichern-Modifizieren-Wiederherstellen an einem derartigen Steuerregister ausführen zu müssen).
  • Befehlsschablonen ohne Speicherzugriff – die Operation des VSIZE-Typs mit Schreibmaskensteuerung
  • In der Befehlsschablone der Operation 617 des VSIZE-Typs mit Schreibmaskensteuerung und ohne Speicherzugriff wird der Rest des Betafeldes 654 als ein Vektorlängenfeld 659B interpretiert, dessen Inhalt unterscheidet, mit welcher von einer Anzahl von Datenvektorlängen gearbeitet werden soll (z. B. 128, 856 oder 1012 Byte).
  • Die Befehlsschablonen mit Speicherzugriff der Klasse B
  • In dem Fall einer Befehlsschablone mit Speicherzugriff 620 der Klasse A wird ein Teil des Betafeldes 654 als ein Rundsendefeld 657B interpretiert, dessen Inhalt unterscheidet, ob eine Datenmanipulationsoperation des Rundsendetyps ausgeführt werden soll, während der Rest des Betafeldes 654 als das Vektorlängenfeld 659B interpretiert wird. Die Befehlsschablonen mit Speicherzugriff 620 enthalten das Maßstabsfeld 660 und optional das Verschiebungsfeld 662A oder das Verschiebungsmaßstabsfeld 662B.
  • Zusätzliche Kommentare hinsichtlich der Felder
  • Bezüglich des generischen vektorfreundlichen Befehlsformats 600 ist gezeigt, dass ein volles Opcode-Feld 674 das Formatfeld 640, das Basisoperationsfeld 642 und das Datenelementbreitenfeld 664 enthält. Während eine Ausführungsform gezeigt ist, in der das volle Opcode-Feld 674 alle diese Felder enthält, enthält das volle Opcode-Feld 674 in den Ausführungsformen, die nicht alle von ihnen unterstützen, weniger als alle dieser Felder. Das volle Opcode-Feld 674 stellt den Operationscode bereit.
  • Das Vergrößerungsoperationsfeld 650, das Datenelementbreitenfeld 664 und das Schreibmaskenfeld 670 ermöglichen, dass diese Merkmale in dem generischen vektorfreundlichen Befehlsformat auf einer Grundlage pro Befehl spezifiziert werden.
  • Die Kombination des Schreibmaskenfeldes und des Datenelementbreitenfeldes erzeugt insofern typisierte Befehle, als sie es ermöglicht, dass die Maske basierend auf verschiedenen Datenelementbreiten angewendet wird.
  • Das Befehlsformat erfordert eine relativ kleine Anzahl von Bits, weil es basierend auf den Inhalten der anderen Felder verschiedene Datenfelder für verschiedene Zwecke wiederverwendet. Eine Perspektive ist z. B., dass der Inhalt des Modifiziererfeldes zwischen den Befehlsschablonen ohne Speicherzugriff 605 nach den 6A–B und den Befehlsschablonen mit Speicherzugriff 6250 in den 6A–B auswählt; während der Inhalt des Klassenfeldes 668 innerhalb jener Befehlsschablonen ohne Speicherzugriff 605 zwischen den Befehlsschablonen 610/615 nach 6A und 612/617 nach 6B auswählt; und während der Inhalt des Klassenfeldes 668 innerhalb jener Befehlsschablonen mit Speicherzugriff 620 zwischen den Befehlsschablonen 625/830 nach 6A und 627 nach 6B auswählt. Aus einer weiteren Perspektive wählt der Inhalt des Klassenfeldes 668 zwischen den Befehlsschablonen der Klasse A und der Klasse B der 6A bzw. B; während der Inhalt des Modifiziererfeldes innerhalb jener Befehlsschablonen der Klasse A zwischen den Befehlsschablonen 605 und 620 nach 6A wählt; und während der Inhalt des Modifiziererfeldes innerhalb jener Befehlsschablonen der Klasse B zwischen den Befehlsschablonen 605 und 620 nach 6B wählt. In dem Fall, dass der Inhalt des Klassenfeldes eine Befehlsschablone der Klasse A angibt, wählt der Inhalt des Modifiziererfeldes 646 die Interpretation des Alphafeldes 652 (zwischen dem rs-Feld 652A und dem EH-Feld 652B). In einer in Beziehung stehenden Weise wählen die Inhalte des Modifiziererfeldes 646 und des Klassenfeldes 668, ob das Alphafeld als das rs-Feld 652A, das EH-Feld 652B oder das Schreibmaskensteuerfeld (Z-Feld) 652C interpretiert wird. In dem Fall, in dem das Klassen- und das Modifiziererfeld eine Operation ohne Speicherzugriff der Klasse A angeben, ändert sich die Interpretation des Betafeldes des Vergrößerungsfeldes basierend auf dem Inhalt des rs-Feldes; während in dem Fall, in dem das Klassen- und das Modifiziererfeld eine Operation ohne Speicherzugriff der Klasse B angeben, die Interpretation des Betafeldes von den Inhalten des RL-Feldes abhängt. In dem Fall, in dem das Klassen- und das Modifiziererfeld eine Operation mit Speicherzugriff der Klasse A angeben, ändert sich die Interpretation des Betafeldes des Vergrößerungsfeldes basierend auf dem Inhalt des Basisoperationsfeldes; während in dem Fall, in dem das Klassen- und das Modifiziererfeld eine Operation mit Speicherzugriff der Klasse B angeben, sich die Interpretation des Rundsendefeldes 657B des Betafeldes des Vergrößerungsfeldes basierend auf den Inhalten des Basisoperationsfeldes ändert. Folglich erlaubt die Kombination aus dem Basisoperationsfeld, dem Modifiziererfeld und dem Vergrößerungsoperationsfeld, dass eine noch breitere Vielfalt von Vergrößerungsoperationen spezifiziert wird.
  • Die verschiedenen Befehlsschablonen, die innerhalb der Klasse A und der Klasse B gefunden werden, sind in verschiedenen Situationen vorteilhaft. Die Klasse A ist nützlich, wenn aus Leistungsgründen eine Nullsetzungs-Schreibmaskierung oder kleinere Vektorlängen erwünscht sind. Die Nullsetzung erlaubt z. B. das Vermeiden von falschen Abhängigkeiten, wenn eine Umbenennung verwendet wird, weil nicht länger mit dem Ziel künstlich verschmolzen werden muss; als ein weiteres Beispiel erleichtert die Vektorlängensteuerung die Speichern-Laden-Weiterleitungs-Probleme, wenn mit der Vektormaske kürzere Vektorgrößen emuliert werden. Die Klasse B ist nützlich, wenn es erwünscht ist: 1) Gleitkommaausnahmen zu erlauben (d. h., wenn die Inhalte des SAE-Feldes nein angeben), während gleichzeitig die Rundungsmodussteuerungen verwendet werden; 2) imstande zu sein, die Aufwärtsumsetzung, das ”Swizzling”, das Auslagern und/oder die Abwärtsumsetzung zu verwenden; 3) auf den Graphikdatentyp zu wirken. Die Aufwärtsumsetzung, das ”Swizzling”, das Auslagern, die Abwärtsumsetzung und der Graphikdatentyp verringern z. B. die Anzahl der Befehle, die erforderlich ist, wenn mit Quellen in einem verschiedenen Format gearbeitet wird; als ein weiteres Beispiel stellt die Fähigkeit, Ausnahmen zu erlauben, eine volle IEEE-Konformität mit gerichteten Rundungsmodi bereit.
  • Ein beispielhaftes spezifisches vektorfreundliches Befehlsformat
  • Die 7A–C sind ein Blockdiagramm, das ein beispielhaftes spezifisches vektorfreundliches Befehlsformat gemäß den Ausführungsformen der Erfindung veranschaulicht. Die 7A–C zeigen ein spezifisches vektorfreundliches Befehlsformat 700, das in dem Sinn spezifisch ist, dass es sowohl den Ort, die Größe, die Interpretation und die Reihenfolge der Felder als auch die Werte für einige dieser Felder spezifiziert. Das spezifische vektorfreundliche Befehlsformat 700 kann verwendet werden, um den x86-Befehlssatz zu erweitern, wobei folglich einige der Felder ähnlich zu jenen oder die gleichen wie jene sind, die in dem vorhandenen x86-Befehlssatz und dessen Erweiterung (z. B. AVX) verwendet werden. Dieses Format bleibt mit dem Präfixcodierungsfeld, dem wirklichen Opcode-Byte-Feld, dem MOD-R/M-Feld, dem SIB-Feld, dem Verschiebungsfeld und den unmittelbaren Feldern des vorhandenen x86-Befehlssatzes mit Erweiterungen konsistent. Die Felder nach 6, in die die Felder nach den 7A–C abbilden, sind veranschaulicht.
  • Es sollte erkannt werden, dass, obwohl die Ausführungsformen der Erfindung unter Bezugnahme auf das spezifische vektorfreundliche Befehlsformat 700 im Kontext des generischen vektorfreundlichen Befehlsformats 600 für Veranschaulichungszwecke beschrieben werden, die Erfindung nicht auf das spezifische vektorfreundliche Befehlsformat 700 eingeschränkt ist, mit Ausnahme, wo es beansprucht ist. Das generische vektorfreundliche Befehlsformat 600 betrachtet z. B. verschiedene mögliche Größen für die verschiedenen Felder, während gezeigt ist, dass das spezifische vektorfreundliche Befehlsformat 700 Felder mit spezifischen Größen aufweist. Während als ein spezifisches Beispiel das Datenelementbreitenfeld 664 in dem spezifischen vektorfreundlichen Befehlsformat 700 als ein Ein-Bit-Feld veranschaulicht ist, ist die Erfindung nicht in dieser Weise eingeschränkt (d. h., das generische vektorfreundliche Befehlsformat 600 betrachtet andere Größen des Datenelementbreitenfelds 664).
  • Das Format – die Fig. 7A–C
  • Das generische vektorfreundliche Befehlsformat 600 enthält die folgenden Felder, die im Folgenden in der in den 7A–C veranschaulichten Reihenfolge aufgelistet sind.
  • Das EVEX-Präfix (die Bytes 0-3)
  • Das EVEX-Präfix 702 – ist in einer Vier-Byte-Form codiert.
  • Das Formatfeld 640 (das EVEX-Byte 0, die Bits [7:0]) – das erste Byte (das EVEX-Byte 0) ist das Formatfeld 640, wobei es 0x62 enthält (den eindeutigen Wert, der zum Unterscheiden des vektorfreundlichen Befehlsformats in einer Ausführungsform der Erfindung verwendet wird).
  • Die zweiten-vierten Bytes (die EVEX-Bytes 1-3) enthalten eine Anzahl von Bitfeldern, die eine spezifische Fähigkeit bereitstellen.
  • Das REX-Feld 705 (das EVEX-Byte 1, die Bits [7-5]) – besteht aus einem EVEX.R-Bitfeld (dem EVEX-Byte 1, dem Bit [7] – R), einem EVEX.X-Bitfeld (dem EVEX-Byte 1, dem Bit [6] – X) und dem 657BEX-Byte 1, dem Bit [5] – B). Das EVEX.R-, das EVEX.X- und das EVEX.B-Bitfeld stellen die gleiche Funktionalität wie die entsprechenden VEX-Bitfelder bereit, wobei sie unter Verwendung der Form des 1er-Komplements codiert sind, d. h., ZMM0 ist als 1111B codiert, ZMM15 ist als 0000B codiert. Andere Felder der Befehle codieren die unteren drei Bits der Registerindizes, wie es in der Technik bekannt ist (rrr, xxx und bbb), so dass Rrrr, Xxxx und Bbbb durch das Addieren von EVEX.R, EVEX.X und EVEX.B gebildet werden können.
  • Das REX'-Feld 710 – dies ist der erste Teil des REX'-Feldes 710 und ist das EVEX.R'-Bitfeld (das EVEX-Byte 1, das Bit [4] – R'), das verwendet wird, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Register-Satzes zu codieren. In einer Ausführungsform der Erfindung ist dieses Bit zusammen mit anderen, wie im Folgenden angegeben wird, in einem bitinvertierten Format gespeichert, um es (in dem wohlbekannten x86-32-Bit-Modus) von dem BOUND-Befehl zu unterscheiden, dessen wirkliches Opcode-Byte 62 ist, das aber in dem (im Folgenden beschriebenen) MOD-R/M-Feld den Wert von 11 in dem MOD-Feld nicht akzeptiert; alternative Ausführungsformen der Erfindung speichern dieses und die anderen im Folgenden angegebenen Bits nicht in dem invertierten Format. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, R'Rrrr wird durch das Kombinieren von EVEX.R', EVEX.R und den anderen RRR von anderen Feldern gebildet.
  • Das Opcode-Abbildungsfeld 715 (das EVEX-Byte 1, die Bits [3:0] – mmmm) – sein Inhalt codiert ein impliziertes führendes Opcode-Byte (0F, 0F 38 oder 0F 3).
  • Das Datenelementbreitenfeld 664 (das EVEX-Byte 2, das Bit [7] – W) – ist durch die Schreibweise EVEX.W dargestellt. EVEX.W wird verwendet, um die Granularität (die Größe) des Datentyps zu definieren (entweder 32-Bit-Datenelemente oder 64-Bit-Datenelemente).
  • Das EVEX.vvvv 720 (das EVEX-Byte 2, die Bits [6:3]-vvvv) – die Rolle des EVEX.vvvv kann das Folgende enthalten: 1) das EVEX.vvvv codiert den ersten Quellregisteroperanden, ist in einer invertieren Form (Form des 1er-Komplements) spezifiziert und ist für Befehle mit 2 oder mehr Quelloperanden gültig; 2) das EVEX.vvvv codiert den Zielregisteroperanden und ist in der Form des 1er-Komplemens für bestimmte Vektorverschiebungen spezifiziert; oder 3) EVEX.vvvv codiert keinen Operanden, das Feld ist reserviert und sollte 1111b enthalten. Folglich codiert das EVEX.vvvv-Feld 720 die 4 Bits niedriger Ordnung des ersten Quellregister-Spezifikationselements, das in invertierter Form (der Form des 1er-Komplements) gespeichert ist. In Abhängigkeit von dem Befehl wird ein zusätzliches anderes EVEX-Bitfeld verwendet, um die Größe des Spezifikationselements auf 32 Register zu erweitern.
  • Das EVEX.U-668-Klassenfeld (das EVEX-Byte 2, das Bit [2]-U) – Falls EVEX.U = 0 gilt, gibt es die Klasse A oder EVEX.U0 an; falls EVEX.U = 1 gilt, gibt es die Klasse B oder EVEX.U1 an.
  • Das Präfixcodierungsfeld 725 (das EVEX-Byte 2, die Bits [1:0]-pp) – stellt zusätzliche Bits für das Basisoperationsfeld bereit. Zusätzlich zum Bereitstellen von Unterstützung für die Alt-SSE-Befehle in dem EVEX-Präfixformat weist dies außerdem den Vorteil des Verdichtens des SIMD-Präfixes auf (anstatt ein Byte zu erfordern, um das SIMD-Präfix auszudrücken, erfordert das EVEX-Präfix nur 2 Bits). Um die Alt-SSE-Befehle, die das SIMD-Präfix verwenden (66H, F2H, F3H), sowohl im Altformat als auch im EVEX-Präfixformat zu unterstützen, sind in einer Ausführungsform diese Alt-SIMD-Präfixe in dem SIMD-Präfixcodierungsfeld codiert; wobei sie zur Laufzeit in den Alt-SIMD-Präfix expandiert werden, bevor sie dem PLA des Decodierers bereitgestellt werden (so kann der PLA sowohl das Alt- als auch das EVEX-Format dieser Altbefehle ohne Modifikation ausführen). Obwohl neuere Befehle den Inhalt des EVEX-Präfixcodierungsfeldes als eine Opcode-Erweiterung direkt verwenden könnten, erweitern bestimmte Ausführungsformen in einer ähnlichen Weise für die Konsistenz, wobei sie es aber ermöglichen, dass durch diese Alt-SIMD-Präfixe verschiedene Bedeutungen spezifiziert werden. Eine alternative Ausführungsform kann den PLA neu entwerfen, um die 2-Bit-SIMD-Präfixcodierungen zu unterstützen, und erfordert folglich die Erweiterung nicht.
  • Das Alphafeld 652 (das EVEX-Byte 3, das Bit [7]-EH; außerdem als EVEX.EH, EVEX.rs, EVEX.RL, EVEX.Schreibmaskensteuerung und EVEX.N bekannt; außerdem mit α veranschaulicht) – wie vorher beschrieben worden ist, ist dieses Feld kontextspezifisch. Eine zusätzliche Beschreibung ist später hier bereitgestellt.
  • Das Betafeld 654 (das EVEX-Byte 3, die Bits [6:4]-SSS, außerdem als EVEX.s2-0, EVEX.r2-0, EVEX.rr1, EVEX. LL0, EVEX.LLB bekannt; außerdem mit βββ veranschaulicht) – wie vorher beschrieben worden ist, ist dieses Feld kontextspezifisch. Eine zusätzliche Beschreibung ist später hier bereitgestellt.
  • Das REX'-Feld 710 – dies ist der Rest des REX'-Feldes und ist das EVEX.V'-Bitfeld (das EVEX-Byte 3, das Bit [3] – V'), das verwendet werden kann, um entweder die oberen 16 oder die unteren 16 des erweiterten 32-Register-Satzes zu codieren. Dieses Bit ist in einem bitinvertierten Format gespeichert. Ein Wert von 1 wird verwendet, um die unteren 16 Register zu codieren. Mit anderen Worten, V'VVVV wird durch das Kombinieren von EVEX.V', EVEX.vvvv gebildet.
  • Das Schreibmaskenfeld 670 (das EVEX-Byte 3, die Bits [2:0]-kkk) – sein Inhalt spezifiziert den Index eines Registers in den Schreibmaskenregistern, wie vorher beschrieben worden ist. In einer Ausführungsform der Erfindung weist der spezifische Wert EVEX.kkk = 000 ein spezifisches Verhalten auf, das impliziert, dass für den speziellen Befehl keine Schreibmaske verwendet wird (dies kann in verschiedenen Weisen einschließlich der Verwendung einer Schreibmaske, die mit allen festverdrahtet ist, oder Hardware, die die Maskierungs-Hardware umgeht, implementiert sein).
  • Das wirkliche Opcode-Feld 730 (das Byte 4)
  • Dies ist außerdem als das Opcode-Byte bekannt. Ein Teil des Opcodes ist in diesem Feld spezifiziert.
  • Das MOD-R/M-Feld 740 (das Byte 5)
  • Das Modifiziererfeld 646 (MODR/M.MOD, die Bits [7-6] – das MOD-Feld 742) – Wie vorher beschrieben worden ist, unterscheidet der Inhalt des MOD-Feldes 742 zwischen Operationen mit Speicherzugriff und ohne Speicherzugriff. Dieses Feld wird später hier weiter beschrieben.
  • Das MODR/M.reg-Feld 744, die Bits [5-3] – die Rolle des ModR/M.reg-Feldes kann in zwei Situationen zusammengefasst werden: das ModR/M.reg codiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden oder das ModR/M.reg wird als eine Opcode-Erweiterung behandelt und nicht verwendet, um irgendeinen Befehlsoperanden zu codieren.
  • Das MODR/M.r/m-Feld 746, die Bits [2-0] – Die Rolle des ModR/M.r/m-Feldes kann das Folgende enthalten: das ModR/M.r/m codiert den Befehlsoperanden, der auf eine Speicheradresse verweist, oder das ModR/M.r/m codiert entweder den Zielregisteroperanden oder einen Quellregisteroperanden.
  • Das Maßstab-, Index-, Basis-(SIB-)Byte (das Byte 6)
  • Das Maßstabfeld 660 (SIB.SS, die Bits [7-6]) – Wie vorher beschrieben worden ist, wird der Inhalt des Maßstabfeldes 660 für die Speicheradressenerzeugung verwendet. Dieses Feld wird später hier weiter beschrieben.
  • Das SIB.xxx 754 (die Bits [5-3]) und das SIB.bbb 756 (die Bits [2-0]) – auf die Inhalte dieser Felder ist vorher bezüglich der Registerindizes Xxxx und Bbbb verwiesen worden.
  • Das (die) Verschiebungsbyte(s) (das Byte 7 oder die Bytes 7-10)
  • Das Verschiebungsfeld 662A (die Bytes 7-10) – wenn das MOD-Feld 742 10 enthält, sind die Bytes 7-10 das Verschiebungsfeld 662A, wobei es gleich wie die Alt-32-Bit-Verschiebung (disp32) arbeitet und auf Byte-Granularität arbeitet.
  • Das Verschiebungsfaktorfeld 662B (das Byte 7) – wenn das MOD-Feld 742 01 enthält, ist das Byte 7 das Verschiebungsfaktorfeld 662B. Der Ort dieses Feldes ist der gleiche wie der der 8-Bit-Verschiebung (disp8) des Alt-x86-Befehlssatzes, die auf Byte-Granularität arbeitet. Weil die disp8 vorzeichenerweitert ist, kann sie nur zwischen -128- und 127-Byte-Versätzen adressieren; hinsichtlich von 64-Byte-”Cache”-Zeilen verwendet die disp8 8 Bits, die auf nur vier wirklich nützliche Werte –128, –64, 0 und 64 gesetzt werden können; weil oft ein größerer Bereich benötigt wird, wird die disp32 verwendet; die disp32 erfordert jedoch 4 Bytes. Im Gegensatz zu der disp8 und der disp32 ist das Verschiebungsfaktorfeld 662B eine Neuinterpretation der disp8; wenn das Verschiebungsfaktorfeld 662B verwendet wird, ist die tatsächliche Verschiebung durch den Inhalt des Verschiebungsfaktorfeldes multipliziert mit der Größe des Speicheroperandenzugriffs (N) bestimmt. Dieser Typ der Verschiebung wird als disp8·N bezeichnet. Dies verringert die durchschnittliche Befehlslänge (ein einziges Byte wird für die Verschiebung verwendet, aber mit einem viel größeren Bereich). Eine derartige komprimierte Verschiebung basiert auf der Annahme, dass die effektive Verschiebung ein Vielfaches der Granularität des Speicherzugriffs ist, wobei folglich die redundanten Bits niedriger Ordnung des Adressenversatzes nicht codiert werden müssen. Mit anderen Worten, das Verschiebungsfaktorfeld 662B ersetzt die 8-Bit-Verschiebung des Alt-x86-Befehlssatzes. Folglich ist das Verschiebungsfaktorfeld 662B in der gleichen Weise wie eine 8-Bit-Verschiebung des x86-Befehlssatzes codiert (daher keine Änderungen der ModRM/SIB-Codierungsregeln), mit der einzigen Ausnahme, dass die disp8 zu disp8·N überladen wird. Mit anderen Worten, es gibt keine Änderungen der Codierungsregeln oder der Codierungslängen, sondern nur in der Interpretation des Verschiebungswertes durch die Hardware (die die Verschiebung mit der Größe des Speicheroperanden skalieren muss, um einen byteweisen Adressenversatz zu erhalten).
  • Der unmittelbare Wert
  • Das unmittelbare Feld 672 arbeitet, wie vorher beschrieben worden ist.
  • Eine beispielhafte Registerarchitektur – Fig. 8
  • 8 ist ein Blockschaltplan einer Registerarchitektur 800 gemäß einer Ausführungsform der Erfindung. Die Registerdateien und die Register der Registerarchitektur sind im Folgenden aufgelistet:
    Die Vektorregisterdatei 810 – in der veranschaulichten Ausführungsform gibt es 32 Vektorregister, die 812 Bits breit sind; diese Register werden als zmm0 bis zmm31 bezeichnet. Die 656 Bits niedrigerer Ordnung der unteren 16 zmm-Register sind den Registern ymm0-16 überlagert. Die 128 Bits niedrigerer Ordnung der unteren 16 zmm-Register (die 128 Bits niedrigerer Ordnung der ymm-Register) sind den Registern xmm0-15 überlagert. Das spezifische vektorfreundliche Befehlsformat 700 wirkt auf diese überlagerte Registerdatei so, wie in den Tabellen im Folgenden veranschaulicht ist.
    einstellbare Vektorlänge Klasse Operationen Register
    Befehlsschablonen, die das Vektorlängenfeld 659B nicht enthalten A (Fig. 6A; U = 0) 810, 615, 625, 630 zmm-Register (die Vektorlänge ist 64 Byte)
    B (Fig. 6B; U = 1) 812 zmm-Register (die Vektorlänge ist 64 Byte)
    Befehlsschablonen, die das Vektorlängenfeld 659B enthalten B (Fig. 6B; U = 1) 817, 627 zmm-, ymm- oder xmm-Register (die Vektorlänge ist 64 Byte, 32 Byte oder 16 Byte) in Abhängigkeit vom Vektorlängenfeld 659B
  • Mit anderen Worten, das Vektorlängenfeld 659B wählt zwischen einer maximalen Länge und einer oder mehreren anderen kürzeren Längen, wobei jede derartige kürzere Länge die Hälfte der Länge der vorhergehenden Länge ist; wobei die Befehlsschablonen ohne das Vektorlängenfeld 659B auf die maximale Vektorlänge wirken. Ferner arbeiten in einer Ausführungsform die Befehlsschablonen der Klasse B des spezifischen vektorfreundlichen Befehlsformats 700 auf gepackte oder skalare Gleitkommadaten mit einfacher/doppelter Genauigkeit und gepackte oder skalare ganzzahlige Daten. Die Skalaroperationen sind Operationen, die an der Datenelementposition niedrigster Ordnung in einem zmm/ymm/xmm-Register ausgeführt werden; die Datenelementpositionen höherer Ordnung werden entweder als die gleichen gelassen, wie sie vor dem Befehl gewesen sind, oder in Abhängigkeit von der Ausführungsform auf null gesetzt.
  • Die Schreibmaskenregister 815 – in der veranschaulichten Ausführungsform gibt es 8 Schreibmaskenregister (k0 bis k7), jedes mit einer Größe von 64 Bits. Wie vorher beschrieben worden ist, kann in einer Ausführungsform der Erfindung das Vektormaskenregister k0 nicht als eine Schreibmaske verwendet werden; wenn die Codierung, die normalerweise k0 angeben würde, für eine Schreibmaske verwendet wird, wählt sie eine festverdrahtete Schreibmaske von 0xFFFF, was die Schreibmaskierung für diesen Befehl effektiv sperrt.
  • Das Multimediaerweiterungs-Steuerstatusregister (MXCSR) 820 – in der veranschaulichten Ausführungsform stellt dieses 32-Bit-Register Status- und Steuerbits bereit, die bei Gleitkommaoperationen verwendet werden.
  • Die Universalregister 825 – in der veranschaulichten Ausführungsform gibt es sechzehn 64-Bit-Universalregister, die zusammen mit den vorhandenen x86-Adressierungsmodi verwendet werden, um die Speicheroperanden zu adressieren. Auf diese Register wird durch die Namen RAX, RBX, RCX, RDX, RBP, RSI, RDI, RSP und R8 bis R15 verwiesen.
  • Das erweiterte Merkerregister (das EFLAGS-Register) 830 – in der veranschaulichten Ausführungsform wird dieses 32-Bit-Register verwendet, um die Ergebnisse vieler Befehle aufzuzeichnen.
  • Das Gleitkomma-Steuerwortregister (FCW-Register) 835 und das Gleitkomma-Statuswortregister (FSW-Register) 840 – in der veranschaulichten Ausführungsform werden diese Register durch die x87-Befehlssatzerweiterungen verwendet, um die Rundungsmodi, die Ausnahmemasken und die Merker im Fall des FCW festzulegen und die Ausnahmen im Fall des FSW zu verfolgen.
  • Die skalare Gleitkomma-Stapelregisterdatei (der x87-Stapel) 845, auf die die gepackte ganzzahlige flache MMX-Registerdatei 850 abgebildet ist – in der veranschaulichten Ausführungsform ist der x87-Stapel ein Acht-Elemente-Stapel, der verwendet wird, um skalare Gleitkommaoperationen an 32/64/80-Bit-Gleitkommadaten unter Verwendung der x87-Befehlssatzerweiterung auszuführen; während die MMX-Register verwendet werden, um sowohl Operationen an gepackten ganzzahligen 64-Bit-Daten auszuführen als auch die Operanden für einige Operationen, die zwischen den MMX- und den XMM-Registern ausgeführt werden, zu halten.
  • Die Segmentregister 855 – in der veranschaulichten Ausführungsform gibt es sechs 16-Bit-Register, die verwendet werden, um die für die Erzeugung segmentierter Adressen verwendeten Daten zu speichern.
  • Das RIP-Register 865 – in der veranschaulichten Ausführungsform speichert dieses 64-Bit-Register den Befehlszeiger.
  • Alternative Ausführungsformen der Erfindung können breitere oder schmalere Register verwenden. Außerdem können alternative Ausführungsformen der Erfindung mehr, weniger oder andere Registerdateien und Register verwenden.
  • Eine bespielhafte In-der-Reihenfolge-Prozessorarchitektur – die Fig. 9A–Fig. 9B
  • Die 9A–B veranschaulichen einen Blockschaltplan einer beispielhaften In-der-Reihenfolge-Prozessorarchitektur. Diese beispielhaften Ausführungsformen sind um mehrere Instantiierungen eines In-der-Reihenfolge-CPU-Kerns entworfen, der mit einem Breitvektorprozessor (VPU) vergrößert ist. Die Kerne kommunizieren durch ein Verbindungsnetz mit hoher Bandbreite in Abhängigkeit von der e13t-Anwendung mit irgendeiner Logik mit fester Funktion, Speicher-E/A-Schnittstellen und anderer notwendiger E/A-Logik. Eine Implementierung dieser Ausführungsform ist z. B. eine selbstständige GPU, die typischerweise einen PCIe-Bus enthalten würde.
  • 9A ist ein Blockschaltplan eines einzelnen CPU-Kerns zusammen mit seiner Verbindung zu einem Verbindungsnetz 902 auf dem Die und mit seiner lokalen Teilmenge des ”Caches” 904 der Ebene 2 (L2-”Caches”) gemäß den Ausführungsformen der Erfindung. Ein Befehlsdecodierer 900 unterstützt den x86-Befehlssatz mit einer Erweiterung, die das spezifische Vektorbefehlsformat 700 enthält. Während in einer Ausführungsform der Erfindung (um den Entwurf zu vereinfachen) eine Skalareinheit 908 und eine Vektoreinheit 910 separate Registersätze (die Skalarregister 912 bzw. die Vektorregister 914) verwenden und die zwischen ihnen übertragenen Daten in den Speicher geschrieben und dann von einem ”Cache” 906 der Ebene 1 (L1-”Cache”) zurück eingelesen werden, können alternative Ausführungsformen der Erfindung eine andere Vorgehensweise verwenden (z. B. einen einzigen Registersatz verwenden oder einen Kommunikationsweg enthalten, der es ermöglicht, dass die Daten zwischen den beiden Registerdateien übertragen werden, ohne geschrieben und zurückgelesen zu werden).
  • Der L1-”Cache” 906 ermöglicht Zugriffe mit niedriger Latenzzeit auf den ”Cache”-Speicher in den Skalar- und Vektoreinheiten. Zusammen mit den Lade-op-Befehlen in dem vektorfreundlichen Befehlsformat bedeutet dies, dass der L1-”Cache” 906 etwas wie eine erweiterte Registerdatei behandelt werden kann. Dies verbessert die Leistung vieler Algorithmen signifikant, insbesondere mit dem Räumungshinweisfeld 652B.
  • Die lokale Teilmenge des L2-”Caches” 904 ist ein Teil eines globalen L2-”Caches”, der in separate lokale Teilmengen, eine pro CPU-Kern, unterteilt ist. Jede CPU weist einen direkten Zugriffsweg auf ihre eigene lokale Teilmenge des L2-”Caches” 904 auf. Die durch einen CPU-Kern gelesenen Daten werden in seiner L2-”Cache”-Teilmenge 904 gespeichert, wobei parallel mit anderen CPUs, die auf ihre eigenen lokalen L2-”Cache”-Teilmengen zugreifen, schnell auf sie zugegriffen werden kann. Die durch einen CPU-Kern geschriebenen Daten sind in seiner eigenen L2-”Cache”-Teilmenge 904 gespeichert und werden bei Bedarf von anderen Teilmengen geleert. Das Ringnetz stellt die Kohärenz für die gemeinsam benutzten Daten sicher.
  • 9B ist eine Explosionsansicht eines Teils des CPU-Kerns in 9A gemäß den Ausführungsformen der Erfindung. 9B enthält sowohl einen L1-Daten-”Cache” 906A, der Teil des L1-”Caches” 904 ist, als auch mehr Einzelheiten hinsichtlich der Vektoreinheit 910 und der Vektorregister 914. Spezifisch ist die Vektoreinheit 910 eine 16 breite Vektorverarbeitungseinheit (VPU) (siehe die 16 breite ALU 928), die ganzzahlige Befehle, Gleitkommabefehle mit einfacher Genauigkeit und Gleitkommabefehle mit doppelter Genauigkeit ausführt. Die VPU unterstützt das ”Swizzling” der Registereingaben mit der ”Swizzle”-Einheit 920, die numerische Umsetzung mit den numerischen Umsetzungseinheiten 922A–B und die Replikation mit der Replikationseinheit 924 am Speichereingang. Die Schreibmaskenregister 926 ermöglichen das Aussagen der resultierenden Vektorschreibvorgänge.
  • Die Registerdaten können in verschiedenen Weisen ”geswizzelt” werden, z. B. um die Matrizenmultiplikation zu unterstützen. Die Daten von dem Speicher können über die VPU-Stränge repliziert werden. Dies ist sowohl bei der parallelen Graphik- als auch der parallelen Nicht-Graphik-Datenverarbeitung eine gemeinsame Operation, die den ”Cache”-Wirkungsgrad signifikant erhöht.
  • Das Ringnetz ist bidirektional, um es den Agenten, wie z. B. den CPU-Kernen, den L2-”Caches” und anderen Logikblöcken, zu ermöglichen, innerhalb des Chips miteinander zu kommunizieren. Jeder Ringdatenweg ist pro Richtung 812 Bits breit.
  • Eine beispielhafte Nicht-in-der-Reihenfolge-Architektur – Fig. 10
  • 10 ist ein Blockschaltplan, der eine beispielhafte Nicht-in-der-Reihenfolge-Architektur gemäß den Ausführungsformen der Erfindung veranschaulicht, und kann als eine spezifischere Beschreibung einer Pipeline, wie z. B. der Pipeline, die oben in 1 erörtert worden ist, betrachtet werden. Spezifisch veranschaulicht 10 eine wohlbekannte beispielhafte Nicht-in-der-Reihenfolge-Architektur, die modifiziert worden ist, um das vektorfreundliche Befehlsformat und dessen Ausführung aufzunehmen. In 10 bezeichnen die Pfeile eine Kopplung zwischen zwei oder mehr Einheiten und gibt die Richtung des Pfeils eine Richtung des Datenflusses zwischen diesen Einheiten an. 10 enthält eine ”Front-End”-Einheit 1005, die an eine Ausführungsmaschineneinheit 1010 und eine Speichereinheit 1015 gekoppelt ist; die Ausführungsmaschineneinheit 1010 ist ferner an die Speichereinheit 1015 gekoppelt.
  • Die ”Front-End”-Einheit 1005 enthält eine Verzweigungsvorhersageeinheit 1020 der Ebene 1 (L1), die an eine Verzweigungsvorhersageeinheit 1022 der Ebene 2 (L2) gekoppelt ist. Die L1- und die L2-Verzweigungsvorhersageeinheit 1020 und 1022 sind an eine L1-Befehls-”Cache”-Einheit 1024 gekoppelt. Die L1-Befehls-”Cache”-Einheit 1024 ist an einen Befehlsübersetzungspuffer (TLB) 1026 gekoppelt, der ferner an eine Befehlshol- und -vorcodierungseinheit 1028 gekoppelt ist. Die Befehlshol- und -vorcodierungseinheit 1028 ist an eine Befehlswarteschlangeneinheit 1030 gekoppelt, die ferner an eine Decodiereinheit 1032 gekoppelt ist. Die Decodiereinheit 1032 umfasst eine komplexe Decodiereinheit 1034 und drei einfache Decodiereinheiten 1036, 1038 und 1040. Die Decodiereinheit 1032 enthält eine Mikrocode-ROM-Einheit 1042. Die Decodiereinheit 1032 kann arbeiten, wie vorher oben in dem Decodiererstufenabschnitt beschrieben worden ist. Die L1-Befehls-”Cache”-Einheit 1024 ist ferner an eine L2-”Cache”-Einheit 1048 in der Speichereinheit 1015 gekoppelt. Die Befehls-TLB-Einheit 1026 ist ferner an eine TLB-Einheit 1046 der zweiten Ebene in der Speichereinheit 1015 gekoppelt. Die Decodiereinheit 1032, die Mikrocode-ROM-Einheit 1042 und eine Schleifenstromdetektoreinheit 1044 sind jede an eine Umbenennungs-/Zuweisungseinheit 1056 in der Ausführungsmaschineneinheit 1010 gekoppelt.
  • Die Ausführungsmaschineneinheit 1010 enthält eine Umbenennungs-/Zuweisungseinheit 1056, die an eine Ausbuchungseinheit 1074 und eine vereinheitlichte Scheduler-Einheit 1058 gekoppelt ist. Die Ausbuchungseinheit 1074 ist ferner an die Ausführungseinheiten 1060 gekoppelt und enthält eine Umordnungspuffereinheit 1078. Die vereinheitlichte Scheduler-Einheit 1058 ist ferner an eine Einheit 1076 der physikalischen Registerdateien gekoppelt, die an die Ausführungseinheiten 1060 gekoppelt ist. Die Einheit 1076 der physikalischen Registerdateien umfasst eine Vektorregistereinheit 1077A, eine Schreibmaskenregistereinheit 1077B und eine Skalarregistereinheit 1077C; diese Registereinheiten können die Vektorregister 810, die Vektormaskenregister 815 und die Universalregister 825 bereitstellen; wobei die Einheit 1076 der physikalischen Registerdateien zusätzliche Registerdateien enthalten kann, die nicht gezeigt sind (z. B. die skalare Gleitkomma-Stapelregisterdatei 845, die auf die gepackte MMX-Ganzzahl-Flachregisterdatei 850 abgebildet ist). Die Ausführungseinheiten 1060 enthalten drei gemischte Skalar- und Vektoreinheiten 1062, 1064 und 1072; eine Ladeeinheit 1066; eine Speicheradresseneinheit 1068; und eine Speicherdateneinheit 1070. Die Ladeeinheit 1066, die Speicheradresseneinheit 1068 und die Speicherdateneinheit 1070 sind jede ferner an die Daten-TLB-Einheit 1052 in der Speichereinheit 1015 gekoppelt.
  • Die Speichereinheit 1015 enthält die TLB-Einheit 1046 der zweiten Ebene, die an die Daten-TLB-Einheit 1052 gekoppelt ist. Die Daten-TLB-Einheit 1052 ist an eine L1-Daten-”Cache”-Einheit 1054 gekoppelt. Die L1-Daten-”Cache”-Einheit 1054 ist ferner an eine L2-”Cache”-Einheit 1048 gekoppelt. In einigen Ausführungsformen ist die L2-”Cache”-Einheit 1048 ferner an L3- und höhere ”Cache”-Einheiten 1050 innerhalb und/oder außerhalb der Speichereinheit 1015 gekoppelt.
  • Beispielhaft kann die beispielhafte Nicht-in-der-Reihenfolge-Architektur die Prozesspipeline 8200 wie folgt implementieren: 1) die Befehlshol- und -vorcodierungseinheit 1028 führt die Hol- und Längendecodierungsstufen aus; 2) die Decodiereinheit 1032 führt die Decodierstufe aus; 3) die Umbenennungs-/Zuweisungseinheit 1056 führt die Zuweisungsstufe und die Umbenennungsstufe aus; 4) der vereinheitlichte Scheduler 1058 führt die Planungsstufe aus; 5) die Einheit 1076 der physikalischen Registerdateien, die Umordnungspuffereinheit 1078 und die Speichereinheit 1015 führen die Registerlese-/Speicherlesestufe aus; die Ausführungseinheiten 1060 führen die Ausführungs-/Datentransformationsstufe aus; 6) die Speichereinheit 1015 und die Umordnungspuffereinheit 1078 führen die Rückschreib-/Speicherschreibstufe 1960 aus; 7) die Ausbuchungseinheit 1074 führt die ROB-Lesestufe aus; 8) verschiedene Einheiten können an der Ausnahmebehandlungsstufe beteiligt sein; und 9) die Ausbuchungseinheit 1074 und die Einheit 1076 der physikalischen Registerdateien führen den Festschreibungsstufe aus.
  • Beispielhafte Einzelkern- und Mehrkernprozessoren – Fig. 15
  • 15 ist ein Blockschaltplan eines Einzelkernprozessors und eines Mehrkernprozessors 1500 mit einem integrierten Speicher-Controller und einer integrierten Graphik gemäß den Ausführungsformen der Erfindung. Die Kästen mit durchgezogenen Linien in 15 veranschaulichen einen Prozessor 1500 mit einem einzigen Kern 1502A, einem Systemagenten 1510 und einem Satz von einer oder mehreren Bus-Controller-Einheiten 1516, während die optionale Ergänzung der Kästen mit gestrichelten Linien einen alternativen Prozessor 1500 mit mehreren Kernen 1502A–N, einen Satz von einer oder mehreren integrierten Speicher-Controller-Einheit(en) 1514 in der Systemagenteneinheit 1510 und eine integrierte Graphiklogik 1508 veranschaulicht.
  • Die Speicherhierarchie enthält eine oder mehrere Ebenen des ”Caches” innerhalb der Kerne, einen Satz oder ein oder mehrere gemeinsam benutzte ”Cache”-Einheiten 1506 und einen (nicht gezeigten) äußeren Speicher, die an den Satz der integrierten Speicher-Controller-Einheiten 1514 gekoppelt sind. Der Satz der gemeinsam benutzten ”Cache”-Einheiten 1506 kann einen oder mehrere ”Caches” der mittleren Ebene, wie z. B. der Ebene 2 (L2), der Ebene 3 (L3), der Ebene 4 (L4) oder anderer Ebenen des ”Caches”, einen ”Cache” der letzten Ebene (LLC) und/oder Kombinationen daraus enthalten. Während in einer Ausführungsform eine ringbasierte Verbindungseinheit 1512 die integrierte Graphiklogik 1508, den Satz der gemeinsam benutzten ”Cache”-Einheiten 1506 und die Systemagenteneinheit 1510 verbindet, können alternative Ausführungsformen irgendeine Anzahl wohlbekannter Techniken zum Verbinden derartiger Einheiten verwenden.
  • In einigen Ausführungsformen sind einer oder mehrere der Kerne 1502A–N zum ”Multithreading” imstande. Der Systemagent 1510 enthält jene Komponenten, die die Kerne 1502A–N koordinieren und betreiben. Die Systemagenteneinheit 1510 kann z. B. eine Leistungssteuereinheit (PCU) und eine Anzeigeeinheit enthalten. Die PCU kann eine Logik und die Komponenten, die zum Regeln des Leistungszustands der Kerne 1502A–N und der integrierten Graphiklogik 1508 erforderlich ist, sein oder enthalten. Die Anzeigeeinheit dient zum Ansteuern einer oder mehrerer extern angeschlossener Anzeigen.
  • Die Kerne 1502A–N können hinsichtlich der Architektur und/oder des Befehlssatzes homogen oder heterogen sein. Einige der Kerne 1502A–N können z. B. in der Reihenfolge sein (wie z. B. der, der in den 9A und 9B gezeigt ist), während andere nicht in der Reihenfolge sein können (wie z. B. der, der in 10 gezeigt ist). Als ein weiteres Beispiel können zwei oder mehr der Kerne 1502A–N zur Ausführung desselben Befehlssatzes imstande sein, während andere zum Ausführen nur einer Teilmenge dieses Befehlssatzes oder eines anderen Befehlssatzes imstande sein können. Wenigstens einer der Kerne kann das hier beschriebene vektorfreundliche Befehlsformat ausführen.
  • Der Prozessor kann ein Universalprozessor, wie z. B. ein CoreTM i3-, i5-, i7-, 2 Duo- und Quad-, XeonTM- oder ItaniumTM-Prozessor, sein, die von der Intel Corporation, Santa Clara, Kalifornien, verfügbar sind. Alternativ kann der Prozessor von einem anderen Unternehmen sein. Der Prozessor kann ein Spezialprozessor sein, wie z. B. ein Netz- oder ein Kommunikationsprozessor, eine Kompressionsmaschine, ein Graphikprozessor, ein Coprozessor, ein eingebetteter Prozessor oder dergleichen. Der Prozessor kann in einem oder mehreren Chips implementiert sein. Der Prozessor 1500 kann Teil von einem oder mehreren Substraten sein und/oder kann in einem oder mehreren Substraten unter Verwendung irgendeiner Anzahl von Prozesstechniken, wie z. B. BiCMOS, CMOS oder NMOS, implementiert sein.
  • Beispielhafte Computersysteme und Prozessoren – die Fig. 11–Fig. 13
  • Die 1113 sind beispielhafte Systeme, die geeignet sind, um den Prozessor 1500 zu enthalten, während 88 ein beispielhaftes System auf einem Chip (SoC) ist, das einen oder mehrere der Kerne 1502 enthalten kann. Andere Systementwürfe und -konfigurationen, die in der Technik für Laptops, Desktops, Handheld-PCs, persönliche digitale Assistenten, Entwicklungs-Arbeitsplatzrechner, Server, Netzvorrichtungen, Netz-”Hubs”, ”Switches”, eingebettete Prozessoren, digitale Signalprozessoren (DSPs), Graphikvorrichtungen, Videospielvorrichtungen, ”Set-Top-Boxes”, Mikrocontroller, Zellentelephone, tragbare Medienspieler, Handheld-Vorrichtungen und verschiedene andere elektronische Vorrichtungen bekannt sind, sind außerdem geeignet. Im Allgemeinen ist eine riesige Vielfalt von Systemen oder elektronischen Vorrichtungen, die einen Prozessor und/oder eine andere Ausführungslogik, wie sie hier offenbart sind, aufnehmen können, allgemein geeignet.
  • In 11 ist ein Blockschaltplan eines Systems 1100 gemäß einer Ausführungsform der Erfindung gezeigt. Das System 1100 kann einen oder mehrere Prozessoren 1110, 1115 enthalten, die an einen Graphikspeicher-Controller-”Hub” (GMCH) 1120 gekoppelt sind. Die optionale Art der zusätzlichen Prozessoren 1115 ist in 11 mit gestrichelten Linien angegeben.
  • Jeder Prozessor 1110, 1115 kann irgendeine Version des Prozessors 1500 sein. Es sollte jedoch angegeben werden, dass es unwahrscheinlich ist, dass in den Prozessoren 1110, 1115 integrierte Graphiklogik- und integrierte Speichersteuereinheiten vorhanden sein würden.
  • 11 veranschaulicht, dass der GMCH 1120 an einen Speicher 1140 gekoppelt sein kann, der z. B. ein dynamischer Schreib-Lese-Speicher (DRAM) sein kann. Dem DRAM kann für wenigstens eine Ausführungsform ein nichtflüchtiger ”Cache” ”zugeordnet sein.
  • Der GMCH 1120 kann ein Chipsatz oder ein Abschnitt eines Chipsatzes sein. Der GMCH 1120 kann mit dem (den) Prozessor(en) 1110, 1115 in Verbindung stehen und die Wechselwirkung zwischen dem (den) Prozessor(en) 1110, 1115 und dem Speicher 1140 steuern. Der GMCH 1120 kann außerdem als eine beschleunigte Busschnittstelle zwischen dem (den) Prozessor(en) 1110, 1115 und anderen Elementen des Systems 1100 wirken. Für wenigstens eine Ausführungsform steht der GMCH 1120 mit dem (den) Prozessor(en) 1110, 1105 über einen Mehrpunktbus, wie z. B. einen ”Frontside”-Bus (FSB) 1195, in Verbindung.
  • Außerdem ist der GCMH 1120 an eine Anzeige 1145 (wie z. B. eine Flachbildanzeige) gekoppelt. Der GCMH 1120 kann einen integrierten Graphikbeschleuniger enthalten. Der GCMH 1120 ist ferner an einen Eingabe-/Ausgabe-Controller-”Hub” (E/A-Controller-”Hub”) (ICH) 1150 gekoppelt, der verwendet werden kann, um verschiedene Peripherievorrichtungen an das System 1100 zu koppeln. In der Ausführungsform nach 11 ist z. B. eine äußere Graphikvorrichtung 1160 gezeigt, die eine diskrete Graphikvorrichtung sein kann, die zusammen mit einer weiteren Peripherievorrichtung 1170 an den ICH 1150 gekoppelt ist.
  • Alternativ können zusätzliche oder andere Prozessoren außerdem in dem System 1100 vorhanden sein. Der zusätzliche Prozessor (die zusätzlichen Prozessoren) 1115 kann (können) einen zusätzlichen Prozessor (zusätzliche Prozessoren), der der gleiche (die die gleichen) wie der Prozessor 1110 ist (sind), einen zusätzlichen Prozessor (zusätzliche Prozessoren), der (die) heterogen oder asymmetrisch zu dem Prozessor 1110 ist (sind), Beschleuniger (wie z. B. Graphikbeschleuniger oder digitale Signalverarbeitungseinheiten (DSP-Einheiten)), feldprogrammierbare Gatteranordnungen oder irgendeinen anderen Prozessor enthalten. Es kann verschiedene Unterschiede zwischen den physikalischen Betriebsmitteln 1110, 1115 hinsichtlich eines Spektrums der Metriken des Leistung geben, einschließlich Architektur-, Mikroarchitektur-, Thermo- und Leistungsaufnahmeeigenschaften und dergleichen. Diese Unterschiede manifestieren sich selbst effektiv als Asymmetrie und Heterogenität unter den Verarbeitungselementen 1110, 1115. Für wenigstens eine Ausführungsform können sich die verschiedenen Verarbeitungselemente 1110, 1115 in derselben Die-Baugruppe befinden.
  • In 12 ist ein Blockschaltplan eines zweiten Systems 1200 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 12 gezeigt ist, ist das Mehrprozessorsystem 1200 ein Punkt-zu-Punkt-Verbindungsystem, wobei es einen ersten Prozessor 1270 und einen zweiten Prozessor 1280 enthält, die über eine Punkt-zu-Punkt-Verbindung 1250 gekoppelt sind. Wie in 12 gezeigt ist, kann jeder der Prozessoren 1270 und 1280 irgendeine Version des Prozessors 1500 sein.
  • Alternativ können einer oder mehrere der Prozessoren 1270, 1280 ein anderes Element als ein Prozessor sein, wie z. B. ein Beschleuniger oder eine feldprogrammierbare Gatteranordnung.
  • Während er nur mit zwei Prozessoren 1270, 1280 gezeigt ist, ist es selbstverständlich, dass der Schutzumfang der vorliegenden Erfindung nicht in dieser Weise eingeschränkt ist. In anderen Ausführungsformen können ein oder mehrere zusätzliche Verarbeitungselemente in einem gegebenen Prozessor vorhanden sein.
  • Der Prozessor 1270 kann ferner einen integrierten Speicher-Controller-”Hub” (IMC-”Hub”) 1272 und die Punkt-zu-Punkt-Schnittstellen (P-P-Schnittstellen) 1276 und 1278 enthalten. Ähnlich kann der zweite Prozessor 1280 einen IMC 1282 und die P-P-Schnittstellen 1286 und 1288 enthalten. Die Prozessoren 1270, 1280 können Daten über eine Punkt-zu-Punkt-Schnittstelle (PtP-Schnittstelle) 1250 unter Verwendung der PtP-Schnittstellenschaltungen 1278, 1288 austauschen. Wie in 12 gezeigt ist, koppeln die IMCs 1272 und 1282 die Prozessoren an jeweilige Speicher, nämlich einen Speicher 1242 und einen Speicher 1244, die Teile des Hauptspeichers sein können, die lokal mit den jeweiligen Prozessoren verbunden sind.
  • Die Prozessoren 1270, 1280 können jeder über die einzelnen P-P-Schnittstellen 1252, 1254 unter Verwendung der Punkt-zu-Punkt-Schnittstellenschaltungen 1276, 1294, 1286, 1298 Daten mit einem Chipsatz 1290 austauschen. Der Chipsatz 1290 kann außerdem Daten über eine Hochleistungsgraphikschnittstelle 1239 mit einer Hochleistungsgraphikschaltung 1238 austauschen.
  • Ein (nicht gezeigter) gemeinsam benutzter ”Cache” kann in jedem Prozessor außerhalb beider Prozessoren enthalten sein, jedoch mit den Prozessoren über eine P-P-Verbindung verbunden sein, so dass die lokalen ”Cache”-Informationen irgendeines oder beider Prozessoren in dem gemeinsam benutzten ”Cache” gespeichert sein können, falls ein Prozessor in einem Modus mit niedrigerer Leistung gesetzt ist.
  • Der Chipsatz 1290 kann über eine Schnittstelle 1296 an einen ersten Bus 1216 gekoppelt sein. In einer Ausführungsform kann der erste Bus 1216 ein Peripheriekomponentenverbindungsbus (PCI-Bus) oder ein Bus, wie z. B. ein PCI-Express-Bus oder ein anderer E/A-Verbindungsbus der dritten Generation sein, obwohl der Schutzumfang der vorliegenden Erfindung nicht so eingeschränkt ist.
  • Wie in 12 gezeigt ist, können verschiedene E/A-Vorrichtungen 1214 zusammen mit einer Busbrücke 1218, die den ersten Bus 1216 an einen zweiten Bus 1220 koppelt, an den ersten Bus 1216 gekoppelt sein. In einer Ausführungsform kann der zweite Bus 1220 ein Bus mit niedriger Anschlussstiftanzahl (LPC-Bus) sein. An einen zweiten Bus 1220 können in einer Ausführungsform verschiedene Vorrichtungen gekoppelt sein, einschließlich z. B. einer Tastatur/Maus 1222, Kommunikationsvorrichtungen 1226 und einer Datenspeichereinheit 1228, wie z. B. eines Plattenlaufwerks oder einer anderen Massenspeichervorrichtung, die Code 1230 enthalten kann. Ferner kann eine Audio-E/A 1224 an den zweiten Bus 1220 gekoppelt sein. Es sei angegeben, dass andere Architekturen möglich sind. Anstelle der Punkt-zu-Punkt-Architektur nach 12 kann z. B. ein System einen Mehrpunktbus oder eine andere derartige Architektur implementieren.
  • In 13 ist ein Blockschaltplan eines dritten Systems 1300 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Gleiche Elemente in den 12 und 13 tragen gleiche Bezugszeichen, wobei bestimmte Aspekte der 12 aus 13 weggelassen worden sind, um es zu vermeiden, andere Aspekte nach 13 zu verbergen.
  • 13 veranschaulicht, dass die Verarbeitungselemente 1270, 1280 eine integrierte Speicher- und E/A-Steuerlogik (”CL”) 1272 bzw. 1282 enthalten können. Für wenigstens eine Ausführungsform kann die CL 1272, 1282 eine Speicher-Controller-”Hub”-Logik (IMC) enthalten, wie z. B. jene, die oben im Zusammenhang mit den 89 und 12 beschrieben worden ist. Außerdem kann die CL 1272, 1282 die E/A-Steuerlogik enthalten.
  • 13 veranschaulicht, dass nicht nur die Speicher 1242, 1244 an die CL 1272, 1282 gekoppelt sind, sondern dass außerdem die E/A-Vorrichtungen 1314 außerdem an die Steuerlogik 1272, 1282 gekoppelt sind. Die Alt-E/A-Vorrichtungen 1315 sind an den Chipsatz 1290 gekoppelt.
  • In 14 ist ein Blockschaltplan eines SoC 1400 gemäß einer Ausführungsform der vorliegenden Erfindung gezeigt. Ähnliche Elemente in 15 tragen gleiche Bezugszeichen. Außerdem sind die Kästen mit gestrichelten Linien optionale Merkmale in weiterentwickelteren SoCs. In 14 ist (sind) eine Verbindungseinheit(en) 1402 an Folgendes gekoppelt: einen Anwendungsprozessor 1410, der einen Satz von einem oder mehreren Kernen 1502A–N und eine gemeinsam benutzte ”Cache”-Einheit(en) 1506 enthält; eine Systemagenteneinheit 1510; eine Bus-Controller-Einheit(en) 1516; eine integrierte Speicher-Controller-Einheit(en) 1514; einen Satz oder einen oder mehrere Medienprozessoren 1420, der bzw. die eine integrierte Graphiklogik 1508, einen Bildprozessor 1424 zum Bereitstellen einer Standbild- und/oder Videokamerafunktionalität, einen Audioprozessor 1426 zum Bereitstellen einer Hardware-Audio-Beschleunigung und einen Videoprozessor 1428 zum Bereitstellen einer Videocodier-/-decodierbeschleunigung enthalten kann bzw. können; eine Einheit statischen Schreib-Lese-Speichers (SRAM-Einheit) 1430; eine Speicherdirektzugriffseinheit (DMA-Einheit) 1432; und eine Anzeigeeinheit 1440 zum Koppeln an eine oder mehrere äußere Anzeigen.
  • Die Ausführungsformen der hier offenbarten Mechanismen können in Hardware, Software, Firmware oder einer Kombination derartiger Implementierungsvorgehensweisen implementiert sein. Die Ausführungsformen der Erfindung können als Computerprogramme oder Programmcode implementiert sein, die in programmierbaren Systemen ausgeführt werden, die wenigstens einen Prozessor, ein Speichersystem (einschließlich flüchtigen und nichtflüchtigen Speichers und/oder Speicherelementen), wenigstens eine Eingabevorrichtung und wenigstens eine Ausgabevorrichtung umfassen.
  • Der Programmcode kann angewendet werden, um Daten einzugeben, um die hier beschriebenen Funktionen auszuführen und Ausgabeinformationen zu erzeugen. Die Ausgabeinformationen können in bekannter Weise in eine oder mehrere Ausgabevorrichtungen eingespeist werden. Für die Zwecke dieser Anmeldung enthält ein Verarbeitungssystem irgendein System, das einen Prozessor, wie z. B. einen digitalen Signalprozessor (DSP), einen Mikrocontroller, eine anwendungsspezifische integrierte Schaltung (ASIC) oder einen Mikroprozessor, aufweist.
  • Der Programmcode kann in einer prozeduralen Programmiersprache auf hoher Ebene oder in einer objektorientierten Programmiersprache implementiert sein, um mit einem Verarbeitungssystem zu kommunizieren. Der Programmcode kann auf Wunsch außerdem in einer Assemblier- oder Maschinensprache implementiert sein. In der Tat ist der Schutzumfang der hier beschriebenen Mechanismen nicht auf irgendeine spezielle Programmiersprache eingeschränkt. In irgendeinem Fall kann die Sprache eine kompilierte oder eine interpretierte Sprache sein.
  • Ein oder mehrere Aspekte wenigstens einer Ausführungsform können durch repräsentative Befehle implementiert sein, die in einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logik innerhalb des Prozessors repräsentiert, die, wenn sie durch eine Maschine gelesen werden, die Maschine veranlassen, eine Logik herzustellen, um die hier beschriebenen Techniken auszuführen. Derartige Darstellungen, die als ”IP-Kerne” bekannt sind, können in einem greifbaren, maschinenlesbaren Medium gespeichert sein und an verschiedene Kunden oder Herstellungseinrichtungen geliefert werden, um sie in die Fertigungsmaschinen zu laden, die die Logik oder den Prozessor tatsächlich bilden.
  • Derartige maschinenlesbare Speichermedien können ohne Einschränkung nichtflüchtige greifbare Anordnungen von durch eine Maschine oder eine Vorrichtung hergestellten oder gebildeten Artikeln sein, einschließlich Speichermedien, wie z. B. Festplatten, irgendeines anderen Typs einer Platte, einschließlich Disketten, optischer Platten, (Kompaktplatten-Festwertspeichern (CD-ROMs), wiederbeschreibbaren Kompaktplatten (CD-RWs)) und magnetooptischen Platten, Halbleitervorrichtungen, wie z. B. Festwertspeichern (ROMs), Schreib-Lese-Speichern (RAMs), wie z. B. dynamischen Schreib-Lese-Speichern (DRAMs), statischen Schreib-Lese-Speichern (SRAMs), löschbaren programmierbaren Festwertspeichern (EPROMs), Flash-Speichern, elektrisch löschbaren programmierbaren Festwertspeichern (EEPROMs), magnetischer oder optischer Karten oder irgendeines anderer Medientyps, der für das Speichern elektronischer Befehle geeignet ist.
  • Dementsprechend enthalten die Ausführungsformen der Erfindung außerdem nichtflüchtige, greifbare maschinenlesbare Medien, die Befehle in dem vektorfreundlichen Befehlsformat enthalten oder Entwurfsdaten enthalten, wie z. B. eine Hardware-Beschreibungssprache (HDL), die die Strukturen, Schaltungen, Vorrichtungen, Prozessoren und/oder Systemmerkmale, die hier beschrieben sind, definiert. Derartige Ausführungsformen können außerdem als Programmprodukte bezeichnet werden.
  • In einigen Fällen kann ein Befehlsumsetzer verwendet werden, um einen Befehl von einem Quellbefehlssatz zu einem Zielbefehlssatz umzusetzen. Der Befehlsumsetzer kann z. B. einen Befehl (z. B. unter Verwendung einer statischen binären Übersetzung, einer dynamischen binären Übersetzung einschließlich einer dynamischen Kompilierung), übersetzen, ”morphen”, emulieren oder anderweitig in einen oder mehrere andere Befehle umsetzen, die durch den Kern zu verarbeiten sind. Der Befehlsumsetzer kann in Software, Hardware, Firmware oder einer Kombination daraus implementiert sein. Der Befehlsumsetzer kann sich in dem Prozessor, außerhalb des Prozessors oder teilweise in dem und teilweise außerhalb des Prozessors befinden.
  • 16 ist ein Blockschaltplan, der die Verwendung eines Software-Befehlsumsetzers, um binäre Befehle in einem Quellbefehlssatz in binäre Befehle in einem Zielbefehlssatz umzusetzen, gemäß den Ausführungsformen der Erfindung gegenüberstellt. In der veranschaulichten Ausführungsform ist der Befehlsumsetzer ein Software-Befehlsumsetzer, obwohl alternativ der Befehlsumsetzer in Software, Firmware, Hardware oder verschiedenen Kombinationen daraus implementiert sein kann. 16 zeigt ein Programm in einer Sprache 1602 auf hoher Ebene, das unter Verwendung eines x86-Kompilierers 1604 kompiliert werden kann, um einen binären x86-Code 1606 zu erzeugen, der nativ durch einen Prozessor mit wenigstens einem x86-Befehlssatz-Kern 1616 ausgeführt werden kann (es wird angenommen, dass einige der Befehle, die kompiliert worden sind, in dem vektorfreundlichen Befehlsformat vorhanden sind). Der Prozessor mit wenigstens einem x86-Befehlssatz-Kern 1616 repräsentiert irgendeinen Prozessor, der im Wesentlichen die gleichen Funktionen wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatz-Kern durch das kompatible Ausführen oder anderweitige Verarbeiten (1) eines wesentlichen Anteils des Befehlssatzes des Intel-x86-Befehlssatz-Kerns oder (2) von Objektcode-Versionen von Anwendungen oder anderer Software, die darauf abzielen, auf einem Intel-Prozessor mit wenigstens einem x86-Befehlssatz-Kern ausgeführt werden, ausführen kann, um im Wesentlichen das gleiche Ergebnis wie ein Intel-Prozessor mit wenigstens einem x86-Befehlssatz-Kern zu erreichen. Der x86-Kompilierer 1604 repräsentiert einen Kompilierer, der betreibbar ist, um binären x86-Code 1606 (z. B. Objektcode) zu erzeugen, der mit einer oder ohne eine zusätzliche Verknüpfungsverarbeitung in dem Prozessor mit wenigstens einem x86-Befehlssatz-Kern 1616 ausgeführt werden kann. Ähnlich zeigt 90 das Programm in der Sprache 1602 auf hoher Ebene, das unter Verwendung eines Kompilierers 1608 für einen alternativen Befehlssatz kompiliert werden kann, um binären Code 1610 des alternativen Befehlssatzes zu erzeugen, der nativ durch einen Prozessor ohne wenigstens einen x86-Befehlssatz-Kern 1614 (z. B. einen Prozessor mit Kernen, die den MIPS-Befehlssatz von MIPS Technologies of Sunnyvale, CA, ausführen und/oder die den ARM-Befehlssatz von ARM Holdings of Sunnyvale, CA, ausführen) ausgeführt werden kann. Der Befehlsumsetzer 1612 wird verwendet, um den binären x86-Code 1606 in Code umzusetzen, der nativ durch den Prozessor ohne einen x86-Befehlssatz-Kern 1614 ausgeführt werden kann. Dieser umgesetzte Code ist wahrscheinlich nicht der gleiche wie der binäre Code 1610 des alternativen Befehlssatzes, weil ein Befehlsumsetzer, der dies kann, schwierig herzustellen ist; der umgesetzte Code erreicht jedoch den allgemeinen Betrieb und kann aus Befehlen aus dem alternativen Befehlssatz bestehen. Folglich repräsentiert der Befehlsumsetzer 1612 Software, Firmware, Hardware oder eine Kombination daraus, die es durch Emulation, Simulation oder irgendeinen anderen Prozess einem Prozessor oder einer anderen elektronischen Vorrichtung, die keinen x86-Befehlssatz-Prozessor oder -Kern aufweist, ermöglicht, den binären x86-Code 1606 auszuführen.
  • Bestimmte Operationen des Befehls (der Befehle) in dem hier offenbarten vektorfreundlichen Befehlsformat können durch Hardware-Komponenten ausgeführt werden und können in maschinenausführbaren Befehlen verkörpert sein, die verwendet werden, um eine Schaltung oder eine andere Hardware-Komponente, die mit den Befehlen programmiert ist, zu veranlassen, die Operationen auszuführen, oder um wenigstens dazu zu führen, das eine Schaltung oder eine andere Hardware-Komponente, die mit den Befehlen programmiert ist, die Operationen ausführt. Die Schaltung kann einen Universal- oder Spezialprozessor oder eine Logikschaltung enthalten, um nur einige Beispiele zu nennen. Die Operationen können außerdem optional durch eine Kombination aus Hardware und Software ausgeführt werden. Die Ausführungslogik und/oder ein Prozessor können eine spezifische oder spezielle Schaltungsanordnung oder eine andere Logik enthalten, die in Reaktion auf einen Maschinenbefehl oder ein oder mehrere Steuersignale, das bzw. die aus dem Maschinenbefehl abgeleitet wird bzw. werden, einen durch den Befehl spezifizierten Ergebnisoperanden speichern. Die Ausführungsformen des (der) hier offenbarten Befehls (Befehle) können in einem oder mehreren der Systeme nach den 1116 ausgeführt werden, wobei die Ausführungsformen des Befehls (der Befehle) in dem vektorfreundlichen Befehlsformat in Programmcode gespeichert sein können, der in den Systemen auszuführen ist. Außerdem können die Verarbeitungselemente dieser Figuren eine der ausführlich beschriebenen Pipelines und/oder Architekturen (z. B. die In-der-Reihenfolge- und die Nicht-in-der-Reihenfolge-Architekturen) verwenden, die hier ausführlich beschrieben sind. Die Decodiereinheit der In-der-Reihenfolge-Architektur kann z. B. den (die) Befehl(e) decodieren, den decodierten Befehl zu einer Vektor- oder Skalareinheit weiterleiten, usw.
  • Die obige Beschreibung ist vorgesehen, bevorzugte Ausführungsformen der vorliegenden Erfindung zu veranschaulichen. Aus der obigen Erörterung sollte außerdem offensichtlich sein, dass insbesondere in einem derartigen Bereich der Technik, in dem das Wachstum schnell ist und weitere Fortschritte nicht leicht vorausgesehen werden, die Erfindung durch die Fachleute auf dem Gebiet in der Anordnung und in den Einzelheiten modifiziert werden kann, ohne von den Prinzipien der vorliegenden Erfindung innerhalb des Schutzumfangs der beigefügten Ansprüche und ihrer Äquivalente abzuweichen. Ein oder mehrere Operationen eines Verfahrens können z. B. kombiniert oder weiter auseinandergebrochen werden.
  • Alternative Ausführungsformen
  • Während Ausführungsformen beschrieben worden sind, die das vektorfreundlichen Befehlsformat nativ ausführen würden, können alternative Ausführungsformen der Erfindung das vektorfreundliche Befehlsformat durch eine Emulationsschicht ausführen, die in einem Prozessor ausgeführt wird, der einen anderen Befehlssatz ausführt (z. B. ein Prozessor, der den MIPS-Befehlssatz von MIPS Technologies of Sunnyvale, CA, ausführt, ein Prozessor, der den ARM-Befehlssatz von ARM Holdings of Sunnyvale, CA, ausführt). Während die Ablaufpläne in den Figuren eine spezielle Reihenfolge der Operationen zeigen, die durch bestimmte Ausführungsformen der Erfindung ausgeführt werden, sollte außerdem erkannt werden, dass eine derartige Reihenfolge beispielhaft ist (alternative Ausführungsformen können z. B. die Operationen in einer anderen Reihenfolge ausführen, bestimmt Operationen kombinieren, bestimmte Operationen überlappen usw.).
  • In der obigen Beschreibung sind für die Zwecke der Erklärung zahlreiche spezifische Einzelheiten dargelegt worden, um ein eingehendes Verständnis der Ausführungsformen der Erfindung bereitzustellen. Es wird jedoch für einen Fachmann auf dem Gebiet offensichtlich sein, dass eine oder mehrere andere Ausführungsformen ohne einige dieser spezifischen Einzelheiten praktiziert werden können. Die beschriebenen speziellen Ausführungsformen sind nicht bereitgestellt, um die Erfindung einzuschränken, sondern um die Ausführungsformen der Erfindung zu veranschaulichen. Der Schutzumfang der Erfindung ist nicht durch die oben bereitgestellten spezifischen Beispiele zu bestimmen, sondern nur durch die Ansprüche im Folgenden.

Claims (19)

  1. Vorrichtung, die Folgendes umfasst: eine Befehlsausführungspipeline, die eine Funktionseinheit aufweist, wobei die Funktionseinheit das Folgende umfasst, um einen ersten Befehl und einen zweiten Befehl zu unterstützen: eine Addiererbankschaltungsanordnung, um jeweils abwechselnd die Elemente eines ersten Eingangsvektors zu jeweiligen benachbarten Elementen des ersten Eingangsvektors zur Unterstützung des ersten Befehls zu addieren und um jeweils die Elemente einer Seite eines zweiten Eingangsvektors zu einem Element einer anderen Seite des zweiten Eingangsvektors zur Unterstützung des zweiten Befehls zu addieren; und eine Durchleitungsauswahlschaltungsanordnung, um die jeweiligen benachbarten Elemente für das Durchleiten zu dem Ergebnis des ersten Befehls auszuwählen und Elemente der anderen Seite des Eingangsvektors für das Durchleiten zu dem Ergebnis des zweiten Befehls auszuwählen.
  2. Vorrichtung nach Anspruch 1, wobei die Funktionseinheit ferner eine Addiererauswahlschaltungsanordnung umfasst, die der Addiererbank vorausgeht, wobei die zusätzliche Auswahlschaltungsanordnung dazu dient, jeweilige Elemente des ersten und des zweiten Eingangsvektors für die Addition in der Addiererbankschaltungsanordnung auszuwählen.
  3. Vorrichtung nach Anspruch 2, wobei die Addiererauswahlschaltungsanordnung aus einer ersten Multiplexierer-Bank besteht.
  4. Vorrichtung nach Anspruch 3, wobei die Durchleitungsauswahlschaltungsanordnung aus einer zweiten Multiplexierer-Bank besteht.
  5. Vorrichtung nach Anspruch 4, wobei die erste Multiplexierer-Bank und die zweite Multiplexierer-Bank an eine ROM-Schaltungsanordnung gekoppelt sind, um Steuereingaben zu empfangen, wobei der ROM Mikrocode für den ersten und den zweiten Befehl enthält.
  6. Vorrichtung nach Anspruch 1, wobei das Element einer anderen Seite des zweiten Eingangsvektors ein Element höchster Ordnung der anderen Seite des zweiten Eingangsvektors ist.
  7. Vorrichtung nach Anspruch 6, wobei die Elemente einer Seite des zweiten Eingangsvektors höherer Ordnung als das Element der anderen Seite des zweiten Eingangsvektors sind.
  8. Verfahren, das Folgendes umfasst: Ausführen einer Bildintegralberechnung durch Folgendes: Erzeugen eines zweiten Vektors durch das Ausführen eines ersten Befehls, der abwechselnde Elemente eines ersten Vektors zu jeweiligen Nachbarelementen des ersten Vektors addiert und die resultierenden Summationen in dem zweiten Vektor darstellt und die jeweiligen benachbarten Elemente zu dem zweiten Vektor durchleitet; und Erzeugen eines dritten Vektors durch das Ausführen eines zweiten Befehls, der die Elemente einer Seite des zweiten Vektors zu einem Element einer anderen Seite des zweiten Vektors addiert und die andere Seite des zweiten Vektors durchleitet.
  9. Verfahren nach Anspruch 8, wobei das Verfahren beim Ausführen des ersten Befehls das Leiten erster Steuereingaben von einem ROM zu einer Auswahlschaltungsanordnung und beim Ausführen des zweiten Befehls das Leiten zweiter Steuereingaben von dem ROM zu der Auswahlschaltungsanordnung umfasst.
  10. Verfahren nach Anspruch 8, wobei die Steuereingaben bestimmen, welche Elemente des ersten Vektors zu dem zweiten Vektor durchgeleitet werden und welche Elemente des zweiten Vektors zu dem dritten Vektor durchgeleitet werden.
  11. Verfahren nach Anspruch 8, wobei das Element der anderen Seite des zweiten Vektors ein Element höchster Ordnung der anderen Seite des zweiten Vektors ist.
  12. Verfahren nach Anspruch 11, wobei die Elemente einer Seite des zweiten Vektors höherer Ordnung als das Element der anderen Seite des zweiten Vektors sind.
  13. Verfahren nach Anspruch 8, wobei der erste und der zweite Befehl durch eine gleiche Funktionseinheit ausgeführt werden.
  14. Maschinenlesbares Medium, das Programmcode enthält, der, wenn er durch einen Computer ausgeführt wird, den Computer veranlasst, ein Verfahren auszuführen, wobei das Verfahren Folgendes umfasst: Ausführen einer Bildintegralberechnung durch Folgendes: Erzeugen eines zweiten Vektors durch das Ausführen eines ersten Befehls, der abwechselnde Elemente eines ersten Vektors zu jeweiligen Nachbarelementen des ersten Vektors addiert und die resultierenden Summationen in dem zweiten Vektor darstellt und die jeweiligen benachbarten Elemente zu dem zweiten Vektor durchleitet; und Erzeugen eines dritten Vektors durch das Ausführen eines zweiten Befehls, der die Elemente einer Seite des zweiten Vektors zu einem Element einer anderen Seite des zweiten Vektors addiert und die andere Seite des zweiten Vektors durchleitet.
  15. Maschinenlesbares Medium nach Anspruch 14, wobei das Verfahren beim Ausführen des ersten Befehls das Leiten erster Steuereingaben von einem ROM zu einer Auswahlschaltungsanordnung und beim Ausführen des zweiten Befehls das Leiten zweiter Steuereingaben von dem ROM zu der Auswahlschaltungsanordnung umfasst.
  16. Maschinenlesbares Medium nach Anspruch 14, wobei die Steuereingaben bestimmen, welche Elemente des ersten Vektors zu dem zweiten Vektor durchgeleitet werden und welche Elemente des zweiten Vektors zu dem dritten Vektor durchgeleitet werden.
  17. Maschinenlesbares Medium nach Anspruch 14, wobei das Element einer anderen Seite des zweiten Vektors ein Element höchster Ordnung der anderen Seite des zweiten Vektors ist.
  18. Maschinenlesbares Medium nach Anspruch 17, wobei die Elemente einer Seite des zweiten Vektors höherer Ordnung als das Element der anderen Seite des zweiten Vektors sind.
  19. Maschinenlesbares Medium, das Programmcode enthält, der, wenn er durch einen Computer ausgeführt wird, den Computer veranlasst, ein Verfahren auszuführen, wobei das Verfahren Folgendes umfasst: Erzeugen von Objektcode für eine Bildintegralberechnung durch das Ausführen des Folgenden: Erzeugen eines ersten Befehls, der einen zweiten Vektor durch das Addieren abwechselnder Elemente eines ersten Vektors zu jeweiligen benachbarten Elementen des ersten Vektors erzeugt und die resultierenden Summationen in dem zweiten Vektor darstellt und die jeweiligen benachbarten Elemente zu dem zweiten Vektor durchleitet; und Erzeugen eines zweiten Befehls, der einen dritten Vektor durch das Addieren der Elemente einer Seite des zweiten Vektors zu einem Element einer anderen Seite des zweiten Vektors erzeugt und die andere Seite des zweiten Vektors durchleitet.
DE112013005236.9T 2012-12-28 2013-06-18 Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle Withdrawn DE112013005236T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/730,665 US9442723B2 (en) 2012-12-28 2012-12-28 Method and apparatus for integral image computation instructions
US13/730,665 2012-12-28
PCT/US2013/046412 WO2014105137A1 (en) 2012-12-28 2013-06-18 Method and apparatus for integral image computation instructions

Publications (1)

Publication Number Publication Date
DE112013005236T5 true DE112013005236T5 (de) 2015-08-06

Family

ID=51018674

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112013005236.9T Withdrawn DE112013005236T5 (de) 2012-12-28 2013-06-18 Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle

Country Status (5)

Country Link
US (2) US9442723B2 (de)
KR (2) KR101814356B1 (de)
CN (1) CN105359052B (de)
DE (1) DE112013005236T5 (de)
WO (1) WO2014105137A1 (de)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9442723B2 (en) * 2012-12-28 2016-09-13 Intel Corporation Method and apparatus for integral image computation instructions
DE102014214711B4 (de) 2014-07-25 2023-01-05 Continental Autonomous Mobility Germany GmbH Verfahren zum Betrieb eines Assistenzsystems eines Kraftfahrzeugs sowie Assistenzsystem
US9715432B2 (en) * 2014-12-23 2017-07-25 Intel Corporation Memory fault suppression via re-execution and hardware FSM
US10248876B2 (en) 2016-06-27 2019-04-02 Texas Instruments Incorporated Method and apparatus for avoiding non-aligned loads using multiple copies of input data
US10275243B2 (en) 2016-07-02 2019-04-30 Intel Corporation Interruptible and restartable matrix multiplication instructions, processors, methods, and systems
JP2018022339A (ja) * 2016-08-03 2018-02-08 富士通株式会社 演算処理装置及び演算処理装置の制御方法
CN110337635B (zh) 2017-03-20 2023-09-19 英特尔公司 用于点积操作的***、方法和装置
US10372456B2 (en) * 2017-05-24 2019-08-06 Microsoft Technology Licensing, Llc Tensor processor instruction set architecture
WO2019009870A1 (en) 2017-07-01 2019-01-10 Intel Corporation SAVE BACKGROUND TO VARIABLE BACKUP STATUS SIZE
CN107861757B (zh) * 2017-11-30 2020-08-25 上海寒武纪信息科技有限公司 运算装置以及相关产品
US11789729B2 (en) 2017-12-29 2023-10-17 Intel Corporation Systems and methods for computing dot products of nibbles in two tile operands
US11669326B2 (en) 2017-12-29 2023-06-06 Intel Corporation Systems, methods, and apparatuses for dot product operations
US11023235B2 (en) 2017-12-29 2021-06-01 Intel Corporation Systems and methods to zero a tile register pair
US11809869B2 (en) 2017-12-29 2023-11-07 Intel Corporation Systems and methods to store a tile register pair to memory
US11093247B2 (en) 2017-12-29 2021-08-17 Intel Corporation Systems and methods to load a tile register pair
US11816483B2 (en) 2017-12-29 2023-11-14 Intel Corporation Systems, methods, and apparatuses for matrix operations
US10664287B2 (en) 2018-03-30 2020-05-26 Intel Corporation Systems and methods for implementing chained tile operations
US11093579B2 (en) 2018-09-05 2021-08-17 Intel Corporation FP16-S7E8 mixed precision for deep learning and other algorithms
US11579883B2 (en) 2018-09-14 2023-02-14 Intel Corporation Systems and methods for performing horizontal tile operations
US10970076B2 (en) 2018-09-14 2021-04-06 Intel Corporation Systems and methods for performing instructions specifying ternary tile logic operations
US10719323B2 (en) 2018-09-27 2020-07-21 Intel Corporation Systems and methods for performing matrix compress and decompress instructions
US10990396B2 (en) 2018-09-27 2021-04-27 Intel Corporation Systems for performing instructions to quickly convert and use tiles as 1D vectors
US10866786B2 (en) 2018-09-27 2020-12-15 Intel Corporation Systems and methods for performing instructions to transpose rectangular tiles
US10929143B2 (en) 2018-09-28 2021-02-23 Intel Corporation Method and apparatus for efficient matrix alignment in a systolic array
US10963256B2 (en) 2018-09-28 2021-03-30 Intel Corporation Systems and methods for performing instructions to transform matrices into row-interleaved format
US10896043B2 (en) 2018-09-28 2021-01-19 Intel Corporation Systems for performing instructions for fast element unpacking into 2-dimensional registers
US10963246B2 (en) 2018-11-09 2021-03-30 Intel Corporation Systems and methods for performing 16-bit floating-point matrix dot product instructions
US10929503B2 (en) 2018-12-21 2021-02-23 Intel Corporation Apparatus and method for a masked multiply instruction to support neural network pruning operations
US11294671B2 (en) 2018-12-26 2022-04-05 Intel Corporation Systems and methods for performing duplicate detection instructions on 2D data
US11886875B2 (en) 2018-12-26 2024-01-30 Intel Corporation Systems and methods for performing nibble-sized operations on matrix elements
US20200210517A1 (en) 2018-12-27 2020-07-02 Intel Corporation Systems and methods to accelerate multiplication of sparse matrices
US10942985B2 (en) 2018-12-29 2021-03-09 Intel Corporation Apparatuses, methods, and systems for fast fourier transform configuration and computation instructions
US10922077B2 (en) 2018-12-29 2021-02-16 Intel Corporation Apparatuses, methods, and systems for stencil configuration and computation instructions
US11269630B2 (en) 2019-03-29 2022-03-08 Intel Corporation Interleaved pipeline of floating-point adders
US11016731B2 (en) 2019-03-29 2021-05-25 Intel Corporation Using Fuzzy-Jbit location of floating-point multiply-accumulate results
US10990397B2 (en) 2019-03-30 2021-04-27 Intel Corporation Apparatuses, methods, and systems for transpose instructions of a matrix operations accelerator
US11175891B2 (en) 2019-03-30 2021-11-16 Intel Corporation Systems and methods to perform floating-point addition with selected rounding
US11403097B2 (en) 2019-06-26 2022-08-02 Intel Corporation Systems and methods to skip inconsequential matrix operations
US11334647B2 (en) 2019-06-29 2022-05-17 Intel Corporation Apparatuses, methods, and systems for enhanced matrix multiplier architecture
US11714875B2 (en) 2019-12-28 2023-08-01 Intel Corporation Apparatuses, methods, and systems for instructions of a matrix operations accelerator
US11972230B2 (en) 2020-06-27 2024-04-30 Intel Corporation Matrix transpose and multiply
US11941395B2 (en) 2020-09-26 2024-03-26 Intel Corporation Apparatuses, methods, and systems for instructions for 16-bit floating-point matrix dot product instructions
US12001887B2 (en) 2020-12-24 2024-06-04 Intel Corporation Apparatuses, methods, and systems for instructions for aligning tiles of a matrix operations accelerator
US12001385B2 (en) 2020-12-24 2024-06-04 Intel Corporation Apparatuses, methods, and systems for instructions for loading a tile of a matrix operations accelerator

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100455266C (zh) 2005-03-29 2009-01-28 深圳迈瑞生物医疗电子股份有限公司 宽景成像处理方法
KR100866230B1 (ko) 2007-04-12 2008-10-30 삼성전자주식회사 파노라마 사진 촬영 방법
JP2011180792A (ja) 2010-03-01 2011-09-15 Sony Corp 画像処理装置及び画像処理方法、並びにコンピューター・プログラム
US8972698B2 (en) 2010-12-22 2015-03-03 Intel Corporation Vector conflict instructions
GB2489914B (en) * 2011-04-04 2019-12-18 Advanced Risc Mach Ltd A data processing apparatus and method for performing vector operations
CN102147866B (zh) * 2011-04-20 2012-11-28 上海交通大学 基于训练自适应增强和支持矢量机的目标识别方法
US9442723B2 (en) * 2012-12-28 2016-09-13 Intel Corporation Method and apparatus for integral image computation instructions

Also Published As

Publication number Publication date
CN105359052A (zh) 2016-02-24
US20140189291A1 (en) 2014-07-03
KR101814356B1 (ko) 2018-01-04
KR101722346B1 (ko) 2017-03-31
WO2014105137A1 (en) 2014-07-03
KR20170037685A (ko) 2017-04-04
US20170132012A1 (en) 2017-05-11
CN105359052B (zh) 2018-06-12
KR20150101994A (ko) 2015-09-04
US9442723B2 (en) 2016-09-13
US9766897B2 (en) 2017-09-19

Similar Documents

Publication Publication Date Title
DE112013005236T5 (de) Verfahren und Vorrichtung für Integralbild-Berechnungsbefehle
DE102018003612A1 (de) Befehle für Dualzieltyp-Umwandlung-, Akkumulation- mit gemischter Präzision und atomare Speicheroperationen mit gemischter Präzision
DE112013005343T5 (de) Befehle für Codierungsalgorithemen mit gleitendem Fenster
DE112011105122T5 (de) Systeme, Vorrichtungen und Verfahren zum Vermischen zweier Quelloperanden in einem einzigen Ziel unter Verwendung einer Schreibmaske
DE112013005372T5 (de) Befehl zum Bestimmen von Histogrammen
DE102018124945A1 (de) Einrichtung und verfahren für komplexe multiplikation
DE102018005977A1 (de) Gleitkomma- zu festkomma-umwandlung
DE112013005188B4 (de) Prozessor und vefrahren zur vektorisierung von zusammengeführten, mehrfach geschachtelten schleifen
DE112011105121T5 (de) Systeme, Vorrichtungen und Verfahren zum Schrittmustersammeln von Datenelementen und Schrittmusterstreuen von Datenelementen
DE102018125232A1 (de) Einrichtung und Verfahren für komplexe Multiplikation und Akkumulation
DE102016006400A1 (de) Hardware-prozessoren und verfahren für eng-gekoppelte heterogene datenverarbeitung
DE112014006508T5 (de) Prozessoren, Verfahren, Systeme und Anweisungen für Fliesskommaaddition mit drei Quellenoperanden
DE112011105818T5 (de) Systeme, Vorrichtungen und Verfahren zum Expandieren einer Speicherquelle in ein Zielregister und komprimieren eines Quellenregisters in eine Zielspeicherstelle
DE102019100009A1 (de) Vereinheitlichter Hardwarebeschleuniger für Verschlüsselungssysteme mit symmetrischen Schlüsseln
DE112012007063T5 (de) Zusammenfügen von benachbarten Sammel-/Streuoperationen
DE102018125817A1 (de) Systeme und Verfahren zum Laden eines Kachelregisterpaars
DE102015002215A1 (de) Sortierbeschleunigungsprozessor, -Verfahren, -Systeme und -Befehle
DE112012007058T5 (de) Vektormaskengesteuertes Clock-Gating für Leistungseffizenz eines Prozessors
DE102015007422A1 (de) Befehlssatz zum Eliminieren fehlausgerichteter Speicherzugriffe während der Verarbeitung eines Arrays mit fehlausgerichteten Datenzeilen
DE112013004798T5 (de) Befehlssatz zur Nachrichtenplanung des SHA256-Algorithmus
DE112016004351T5 (de) Prozessoren, Verfahren, System und Befehle zum Datenelement-Vergleich
DE112017003336T5 (de) Vorrichtungen, verfahren und systeme zum elementsortieren von vektoren
DE102018006008A1 (de) Vorrichtung und Verfahren zur Multiplikation einer komplexen Zahl mit der konjugierten
DE112017000983T5 (de) System und Verfahren zum Ausführen eines Befehls zum Permutieren einer Maske
DE112017003347T5 (de) Systeme, Vorrichtungen und Verfahren für Strided-Ladevorgänge

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R083 Amendment of/additions to inventor(s)
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0001000000

Ipc: G06F0009380000

R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee